Re: [webkit-dev] Reporting FCKeditor related bugs

2007-01-12 Thread Maciej Stachowiak


On Jan 12, 2007, at 6:36 AM, David D. Kilzer wrote:


Hi FredCK,

I'd recommend filing all of the bugs.  That way if someone else  
gets the notion to create a reduced test case or fix the bug,  
that's less work you'll have to do in the long run!


Please do a cursory search for existing bugs before filing new ones  
as well.  For example, links are clickable in the editing area  
may be similar to Bug 11297.  (It took me three searches to find  
that one, though, so don't spend all your time search for pre- 
existing bugs!)  It's better to have the bugs documented and later  
marked RESOLVED/DUPLICATE than to not have them documented at all.


http://bugs.webkit.org/show_bug.cgi?id=11297


I agree with Dave's suggestion. Having the bugs filed is more  
important than level of detail in the bug. We will likely need  
reductions for these at some point to be able to fix them, but those  
don't have to be done at the same time or even by the same person as  
originally filing the bug.


Cheers,
Maciej



Thanks!

Dave


On Jan 12, 2007, at 4:40 AM, Frederico Caldeira Knabben wrote:

It is really nice to see that FCKeditor is almost running with the  
nightly.
There are still some bugs, and before I do any move, I would like  
to be sure

this is something acceptable.

I've always tried to create bug reports whithout associating them to
FCKeditor. I simply got a buggy thing in the editor, and reducted  
it as much

as possible to generate precise reports.

All we know how reductions are important. And we also know that their
creation take a lot of time. So, the report of bugs were going  
pretty slow.


I've noted instead that, for the TinyMCE editor, there are many  
generic bugs
strictly specifying TinyMCE compatibility. Something like  
TinyMCE: Format
pulldown doesn't work. Those reports have not so much  
information. Many

times just a line of descrition of the bug.

I have a list of bugs of FCKeditor with Safari. Should I start  
filling

simple FCKeditor: ... reports for all of them?

In these way we would all have a clear compatibility status, and  
in the mean
time myself, and others interested would be working for the  
regressions.


Thanks for the information,
FredCK

PS: The following are the current known bugs:

- links are clickable in the editing area
- the Save button doesn't update the hidden field before posting
- bogus br remain in the code
- Templates doesn't work when inserting in the cursor position
- paste buttons are always disabled
- find dialog doesn't work
- Remove Format button adds Apple tag to the code
- enter key inside forms create further forms.
- hidden fields doesn't show up
- span class=Apple-style-span when formatting
- hr, ul and ol have id=undefined
- the Link dialog is not loading correctly
- objects are not selectable and dragable
- Insert Special Char doesn't work
- the Size toolbar combo has no effect in text
- panels on toolbar items are positioned wrongly
- panels are not hidden when clicking outside them
- context menu icons are not showing
- tables are compressed on creation
- form fields are enabled in the editing area


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] W3C's proposed new HTML Working Group charters

2007-01-17 Thread Maciej Stachowiak


Hi Everyone,

The Safari Team at Apple gave official feedback on the W3C's proposed  
new HTML and related Working Group charters: http://www.w3.org/ 
2006/11/HTML-WG-charter.html


I posted our feedback publicly here: http://webkit.org/blog/?p=89

I encourage those of you who work for W3C Member organizations to  
submit appropriate feedback as well, time permitting; the deadline is  
this Friday.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Definitive build system

2007-02-12 Thread Maciej Stachowiak


On Feb 12, 2007, at 10:23 AM, Jean-Charles VERDIE wrote:



We have internally chosen CMake. We are going to release a modified
version of WebKit plus the whole build stuff in the next few weeks but
feel free to contact me to get additional information


When you release your port, are you planning to merge the changes  
back to the main WebKit tree?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Open Design beyond Open Source

2007-02-16 Thread Maciej Stachowiak


Hey George,

Thanks for sharing your concerns.

On Feb 16, 2007, at 10:29 PM, George Staikos wrote:


On 16-Feb-07, at 9:22 PM, Mike Emmel wrote:

Here is the link of what you have to go through to commit now.

http://webkit.org/coding/contributing.html

People wanting to do a new port are not going to go through this long
trial program just to commit in fact that have not.  The KDE team has
pre-existing interest and both OSX and S60 are commercial.  The  two
true open source ports gdk/windows plus the wx widget port have
basically been failures so far.


   If you mean to say that the impression given off by the webkit  
project is one of we don't want you or at least we're not really  
interested in having more people join our project, I have to  
agree.  I still don't get the feeling of a welcoming project.   Is  
it a form of extreme paranoia that some new developer might  
introduce a bug?  Maybe I'm not sure I consider that a valid  
reason though.


We really do want the WebKit project to be open to new contributors.  
We spend a lot of effort working on this. If we didn't care about  
having new developers join, we wouldn't have the whole public  
repository and web site at all.


It is true that the WebKit project has somewhat higher barriers to  
entry than other large open source projects, like KDE. But I believe  
the barriers are lower than some others, like Mozilla.


Here are the barriers I think we have:

1) We require code review for all changes.

2) We do not grant commit access automatically; we expect people to  
have a track record of being good contributors. Note that this is  
more about showing that you can work with others and are not a source  
of conflict or negativity. It is not about coding skills.


3) We do not give review privileges automatically. This is more about  
understanding project policies and having good judgment


4) We require all code changes that affect processing of web content  
to come with a regression test case (if it is possible to make one).


I think getting a patch reviewed is easier than in Mozilla, where you  
need a review and a superreview and adherence to all review  
happening in bugzilla is much more strict (we often bypass that and  
do review via email or IRC for established developers). But perhaps  
it is harder than for KDE, where things are often committed without  
review.


I think it is also easier to get commit privileges than in Mozilla. I  
checked some stats, and everyone who has contributed more than 5  
patches so far this year already has commit rights. That says to me  
that the people actively contributing have the access they need. Now,  
it may be that some people were discouraged from even contributing in  
the first place. But that shows a lack of commitment to me.



So from and opens source perspective webkit is not a smashing success
in drawing in the open source community only the KDE team has really
contributed and they were the original developers. The S60 port also
has a history of working with KHTML before webkit was made
a open project.


  I wouldn't say so.  I think the KDE contribution is effectively  
nil.  The Qt port is distinct from KDE plans.  KDE as a community  
has yet to find a way to work together with WebKit for reasons that  
I think you're also experiencing and perhaps not clearly  
articulating.  Yes I'm writing this from @kde.org and have  
contributed a huge amount to KDE, KHTML, etc over the past 8-9  
years.  Until I have the KDE community feeling welcome and  
confident in participating, and until we have functioning code and  
development happening for a useful kpart, I don't see our Qt port  
as anything relevant to KDE.  I'm trying to make it relevant, and I  
want it to be relevant, but it really isn't.


   I've had a webkit SVN account for almost 2 years now.  I first  
tried to merge WebKit code back to KDE after all the KDE developers  
effectively gave up, and after successfully merging JavaScriptCore  
(with Maksim's help), determined that it just wasn't feasible to go  
any further without a complete replacement.  I then started the  
current Qt port and managed to enlist several KDE developers to  
help me.  At least one has given up again already, unsurprisingly.   
We made some great progress but it's an absolutely ridiculous  
development model as far as getting real work done.  So far we had:


1) Work outside webkit SVN to start the port
   - webkit renames and refactors hit us hard
2) Port again, also outside of WebKit SVN (note: we were doing a  
very large number of commits/week.  far more than now)
3) Spend far too much time merging from WebKit SVN, especially when  
things like renames and refactors happen

4) Eventually give up and merge back to webkit SVN
5) End up in a ridiculous situation of having one member of the  
porting team as the only person with rights to review the work.   
Interesting, since that person has no-one who can review his work  
under the 

[webkit-dev] Question for editing experts about Undo/Redo

2007-02-23 Thread Maciej Stachowiak


Hey everyone,


I was discussing editing client methods with George and Lars, and the  
following came up. WebKit (on the mac at least) appears to re- 
register undo items when you do an undo or redo action. See  
WebEditorClient.mm (registerCommandForUndoOrRedo), and Editor.cpp  
which calls registerCommandforUndo for both the original editing and  
a redo.


But the Cocoa documentation implies that this should not be  
necessary, NSUndoManager should adjust the undo chain on an Undo or  
Redo action: http://developer.apple.com/documentation/Cocoa/ 
Conceptual/UndoArchitecture/


Does anyone know why we are explicitly re-registering on undo and redo?

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Branch for Gtk/Gdk port

2007-02-23 Thread Maciej Stachowiak


Since Krzysztof has been doing most of the work to maintain the  
WebKit Gdk port, I'd like to defer to his opinion on this.


- Maciej

On Feb 23, 2007, at 2:58 PM, Krzysztof Kowalczyk wrote:


Speaking purely for myself, not the webkit team...

Fixing compilation issues due to refactoring changes is trivial. In
the past I can recall only one issue that required me to spend
non-trivial amount of time figuring out a fix for a change due to
refactoring. So a branch doesn't make a difference for that.

The problem is that at any given time there usually are just 0 or 1
people actively working on gdk port. If the number is 0, the port is
usually broken. If the number is 1 then port usually works. So the
solution is to have at least 1 person working on gdk port i.e.
attracting more people that make fixes and submit the patches. Given
that in recent times gdk port has been stable and that didn't attract
new contributions, I don't see how a branch will make a difference.

And finally, a branch that isolates from changes in trunk causes you
much more pain during merge and based on my past experience of doing
merges from hell after working on a branch, it's not at all clear to
me that this is a win. You trade a series of small, short pains for a
big, long pain.

-- kjk

On 2/23/07, Juan Antonio Suarez Romero [EMAIL PROTECTED] wrote:

Hi all, webkiters ;-)

In some posts I read some issues about the Gtk/Gdk port. In one, I  
read

about the posibility of creating a branch for this port.

What about this idea?.

IMHO having a stable branch in which send the contributions about  
this

port is very confortable.

This branch should allow to work only in the gtk/gdk contributions,
using a stable version of the repository. It's very unpleased  
that the

port compiles one day, but not the next, due to contributions done to
other ports.

Also, this branch should allow more people can contribute to the  
port,

as having a stable release makes easier the study of the system,
without every day something changes.

And finally, this branch should allow the building of a stable and
functional WebKitGtk system. The integration with the trunk should be
more quickly, adding the parts that are not implemented. In this way,
the trunk should contain functional ports.



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVG Stabilization

2007-02-25 Thread Maciej Stachowiak


On Feb 25, 2007, at 3:32 AM, Nikolas Zimmermann wrote:


Hey Maciej,


Seems like there is rough consensus around this plan. So I filed bugs
to disable the experimental features for now:
http://bugs.webkit.org/show_bug.cgi?id=12883

And to do some kind of additional testing/review of the various SVG
microsyntax parsers (it turns out there are a lot):
http://bugs.webkit.org/show_bug.cgi?id=12884


Perfect. I think this covers most cases.


Some people have suggested that use should also be left on. I think
to make this possible would require significant additional testing,
including test cases of unusual situations like circular references,
nested references, etc. If anyone wants to do that testing, feel
free, and ideally please document it with test cases. Note: rewriting
use in a completely different way is unlikely to make it more
suitable for prime time, since the biggest problem with it is that it
is new, relatively untested code.


Agreed, it's definately new code, though the scenarios you are  
mentioning

are covered by tests (LayoutTests/svg/custom). In detail:

SVGElementInstance tests / (SVG) DOM scripting:
use-elementInstance-event-target.svg
use-elementInstance-methods.svg
use-instanceRoot-modifications.svg
use-modify-container-in-target.svg
use-modify-target-container.svg
use-modify-target-symbol.svg
use-property-changes-through-dom.svg
use-property-changes-through-svg-dom.svg

All of these tests operate on the new SVGElementInstance interfaces.
(instanceRoot method of SVGUseElement, returns the root  
SVGElementInstance).


The built SVGElementInstance tree is tested automatically within
use-elementInstance-methods.svg (checks instance tree consistency)

event handling on use:
use-event-handler-on-referenced-element.svg
use-event-handler-on-use-element.svg

Tests the various ways to set up event listeners on use elements:
either on the use element itself, or on the referenced element.
events have to be propagated to the SVGElementInstance (!) object, not
the original referenced element, nor our internal clone.

use on use tests:
use-forward-refs.svg
use-recursion-1.svg (use on g which references the use itself  
again.)

use-recursion-2.svg (use direct self-referencing
use-recursion-3.svg (use on g, containing a use which  
references itself)
use-recursion-4.svg (same like -3.svg, but one level deeper  
referencing)


This covers the hairy parts. Complex deep references, circular  
references,

self-references. All test work excellent w/o crashs or leaks.


How about cases like this:

- use referencing g which contains another use referencing  
something else (valid double use chain).

- valid use chains of larger size, like 2 or 3
- use inside one g referencing another g which contains a use  
reference back to the original g (loop with two use elements  
referencing each other's parents)

- use inside a marker
- use referencing a path with markers
- use referencing a path with markers which themselves contain  
use references (valid ones)
- use referencing a path with markers which themselves contain  
use references to a parent of the original use (invalid loop via  
markers)


I'm sure there must be other complex cross-referencing cases along  
these lines.


I'd also like to hear from others what they think of this level of  
testing. For now I will disable use along with other experimental  
features, but we could bring it back, given evidence of sufficient  
testing.


Regards,
Maciej




Simple use examples (no deep referencing):
use-on-g-containing-use.svg
use-on-g.svg
use-on-rect.svg
use-on-symbol-inside-pattern.svg
use-on-symbol.svg
use-on-text.svg
use-on-use.svg

The usual suspects: simple tests - w/o fancy features.

Misc:
use-events-crash.svg
use-symbol-overflow.svg
use-transform.svg

Other simple tests.

--
I hope the use on use tests are quite sufficient to test the  
tricky parts

of the new SVGUseElement / SVGElementInstance code.

I'd like to invent anyone interessed to stress test the use code.
We're already much better than Opera/FF/Batik (yes even Batik) with  
the

current implementation - and all it needs is heavy testing IMHO.

Niko

P.S. The only known use problem is that the event dispatching is not
completely implemented. IIRC the last missing issue is: (quote from  
1.1 spec)


An element and all its corresponding SVGElementInstance objects  
share an
event listener list. The currentTarget attribute of the event can  
be used to

determine through which object an event listener was invoked.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Re: SVG stabilization: use support

2007-03-02 Thread Maciej Stachowiak


On Mar 2, 2007, at 11:27 AM, Nikolas Zimmermann wrote:


Hello WebKit fellows,

I've filed a master bug yesterday which fixes all currently  
reported use

bugs (except one minor bug with use in a not showing cursor).

http://bugs.webkit.org/show_bug.cgi?id=12936
(not reviewed yet)

As Andreas Neumann stated in a previous mail, our use implementation
may be new and relatively untested, though it's performance   
stability

is already quite nice.

I'm wondering wheter we could reeanble use again in ToT,
as I don't consider it an experimental feature anymore (compared to
ie. animations, filters, foreignObject - which are really alpha  
quality.)


I think this would be reasonable. I'd like to hear from others before  
we make the call. Does anyone think we should leave use off?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Support for E4X

2007-04-04 Thread Maciej Stachowiak


On Apr 4, 2007, at 6:54 AM, Rodrigo Melo wrote:

Hi, I'm interested work on it too. I've started reading something  
about E4X and WebKit, and specially looking at JavaScriptCore code.  
My first question was where I would start to code.


Although we've discussed E4X support, we're not entirely sure we want  
it. It's a big chunk of extra functionality that isn't really used on  
the web. And the web already provides the DOM for XML processing. So  
we'd want to hear some some good reasons before adding support.


Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit coverage (a little welcome present)

2007-05-04 Thread Maciej Stachowiak


On May 4, 2007, at 2:48 PM, Holger Freyther wrote:


Hey,

I adjusted, updated and improved my gcov scripts and let it run on  
the WebKit repository. Leopard will probably have something more  
visually appealing but for everyone not at Apple this http:// 
www.openembedded.org/~zecke/coverage/webkit/mac/index.html might  
look interesting.



The commands that were run:

WebKitTools/Scripts/build-webkit  
GCC_GENERATE_TEST_COVERAGE_FILES=YES  
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES EXTRA_LINK= -ftest-coverage - 
fprofile-arcs OTHER_CFLAGS= -MD  OTHER_LDFLAGS= -ftest-coverage  
-fprofile-arcs -framework AppKit

WebKitTools/Scripts/run-webkit-tests
WebKitTools/Scripts/run-javascriptcore-tests  
GCC_GENERATE_TEST_COVERAGE_FILES=YES  
GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES EXTRA_LINK= -ftest-coverage - 
fprofile-arcs OTHER_CFLAGS= -MD  OTHER_LDFLAGS= -ftest-coverage  
-fprofile-arcs -framework AppKit


Open issues:
Some files get compiled but are not executed so no .gcda,.gcna get  
generated. I could guess the line numbers and add them to the  
statistic. I could ignore these files, or just list them.



So is that of interest for anyone?


Looks awesome to me. I think we should get your scripts in the  
repository and consider setting up a buildbot to eventually run the  
tests in a gcov-enabled build. Can you submit some patches?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit coverage (a little welcome present)

2007-05-04 Thread Maciej Stachowiak


On May 4, 2007, at 3:45 PM, Holger Freyther wrote:



Am 04.05.2007 um 23:59 schrieb Maciej Stachowiak:


So is that of interest for anyone?


Looks awesome to me. I think we should get your scripts in the  
repository and consider setting up a buildbot to eventually run  
the tests in a gcov-enabled build. Can you submit some patches?





For now the sourcecode can be found here www.openembedded.org/ 
~zecke/coverage/webkit/WebKitToolsCoverage.tar but there are  
probably some issues which I want to mention before posting it to  
the bug tracker.


	- The .css and image files are copied from LTP (http:// 
ltp.sourceforge.net/coverage/lcov.php, http:// 
ltp.cvs.sourceforge.net/ltp/utils/analysis/lcov/bin/genhtml? 
revision=1.11view=markup). Is that GPL an issue, should we  
recreate a green, red and amber 1x1 image? Should the css be  
changed/recreated?


We'd prefer not to have GPL code the repository. I think for green,  
red and amber images, recreating them is best. For the CSS, we could  
probably get someone to help make a clean room version unless the  
excerpt was small enough to constitute fair use.


	- The page layout is inspired by lcov as well. I don't think this  
is an issue.


Agreed.

	- The regenerate-coverage-display and cov.py originate from the  
monotone project. ATM I try to track the origin and find the  
license. I have identified the original author and will drop him a  
mail.


Thanks!

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] JS fuzz tester

2007-05-08 Thread Maciej Stachowiak


From mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=jsfunfuzz

This is hot. Does anyone want to run this and report bugs? Jesse  
Ruderman already reported these two:


http://bugs.webkit.org/show_bug.cgi?id=10878
http://bugs.webkit.org/show_bug.cgi?id=10880

But he said that he found 260 bugs in Mozilla's JS with this.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal: feature branch

2007-05-09 Thread Maciej Stachowiak


Hi everyone,

The WebKit tree has been locked down for stabilization for a long  
time, and I think there is a desire to work on features and less  
essential bug fixes. It would be bad to hold this up indefinitely as  
stabilization continues. I propose we create a branch (tentative  
name: feature-branch) where feature work, as well as non-critical  
compliance, compatibility and performance work can go.


We would still use normal review policy so that changes could be  
merged to trunk in the future without additional review.


To make this work well, we'd need a buildbot tracking the branch, and  
maybe even separate nightly builds once there is interesting stuff in  
there.


Thoughts?

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKit Project Goals

2007-05-10 Thread Maciej Stachowiak


Hi Everyone,

I recently watched a video on the topic of preventing poisonous  
people from hurting an open source project. One of the practices it  
recommends for a large open source project is to have a mission  
statement, so it's clear to everyone what is and isn't in scope for  
the project. I'm not too fond of the name mission statement (it  
sounds a little corporate) but I do think it's important to write  
down our goals as a project.


Ultimately I'd like to put this on the WebKit site, but I wanted to  
throw out some ideas for discussion. I'd like to hear if anyone  
thinks I have missed any project goals, if any of these are worded  
badly, or if it is worth calling out more non-goals.



WebKit Project Goals

WebKit is an open source Web content engine for browsers and other  
applications. We value real-world web compatibility, standards  
compliance, stability, performance, security, portability, usability  
and relative ease of understanding and modifying the code (hackability).


Web Content Engine - The project's primary focus is content deployed  
on the World Wide Web, using standards-based technologies such as  
HTML, CSS, JavaScript and the DOM. However, we also want to make it  
possible to embed WebKit in other applications, and to use it as a  
general-purpose display and interaction engine.


Open Source - WebKit should remain freely usable for both open source  
and proprietary applications. To that end, we use BSD-style and LGPL  
licenses.


Compatibility - For users browsing the web, compatibility with their  
existing sites is essential. We strive to maintain and improve  
compatibility with existing web content, sometimes even at the  
expense of standards. We use regression testing to maintain our  
compatibility gains.


Standards Compliance - WebKit aims for compliance with relevant web  
standards, and support for new standards
In addition to improving compliance, we participate in the web  
standards community to bring new technologies into standards, and to  
make sure new standards are pratical to implement in our engine. We  
use regression testing to maintain our standards compliance gains.


Stability - The main WebKit code base should always maintain a high  
degree of stability. This means that crashes, hangs and regressions  
should be dealt with promptly, rather than letting them pile up.


Performance - Maintaining and improving speed and memory use is an  
important goal. We never consider performance good enough, but  
strive to constantly improve. As web content becomes richer and more  
complex, and as web browsers run on more limited devices, performance  
gains continue to have value even if normal browsing seems fast enough.


Security - Protecting users from security violations is critical. We  
fix security issues promptly to protect users and maintain their trust.


Portability - The WebKit project seeks to address a variety of needs.  
We want to make it reasonable to port WebKit to a variety of desktop,  
mobile, embedded and other platforms. We will provide the  
infrastructure to do this with tight platform integration, reusing  
native platform services where appropriate and providing friendly  
embedding APIs.


Usability - To the extent that WebKit features affect the user  
experience, we want them to work in accordance with good human  
interface design principles, and to mesh well with platform-native HI  
conventions.


Hackability - To make rapid progress possible, we try to keep the  
code relatively easy to understand, even though web technologies are  
often complex. We try to use straightforward algorithms and data  
structures when possible, we try to write clear, maintainable code,  
and we continue to improve names and code structure to aid  
understanding. When tricky rocket science code is truly needed to  
solve some problem, we try to keep it bottled up behind clean  
interfaces.



Non-Goals

WebKit is an engine, not a browser. We do not plan to develop or host  
a full-featured web browser based on WebKit. Others are welcome to do  
so, of course.


WebKit is an engineering project not a science project. For new  
features to be adopted into WebKit, we strongly prefer for the  
technology or at least the use case for it to be proven.


WebKit is not a bundle of maximally general and reusable code - we  
build some general-purpose parts, but only to the degree needed to be  
a good web content engine.


WebKit is not the solution to every problem. We focus on web content,  
not complete solutions to every imaginable technology need.



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Regression fallout from change to make Frames start with an empty document

2007-05-12 Thread Maciej Stachowiak


My change to make Frames start with an empty document instead of  
creating one on demand caused some regressions (mostly in areas of  
the code that are not under automated test). I still think it is a  
fundamentally sound change and I'll try to fix the open regressions  
ASAP (hopefully I can figure out how to make test cases for these as  
well):


REGRESSION (r21367): Local css ignored until page is refreshed
http://bugs.webkit.org/show_bug.cgi?id=13661

REGRESSION:  Load never completes for nonexistent unqualified domain  
names

http://bugs.webkit.org/show_bug.cgi?id=13683

REGRESSION: Assertion failure in  
WebCore::FrameLoader::restoreScrollPositionAndViewState() going back  
from fark.com Photoshop contest

http://bugs.webkit.org/show_bug.cgi?id=13684

REGRESSION: Crash when starting Webkit with JavaScript disabled
http://bugs.webkit.org/show_bug.cgi?id=13691

REGRESSION: Progress bar never completes on link click that downloads
http://bugs.webkit.org/show_bug.cgi?id=13694


This also broke the Qt and Gdk ports. I will help to fix those but I  
could use someone who can easily build and test these ports to help  
me out. I think there are two basic problems:


1) Frame::init() needs to be called every time a new Frame is  
allocated, after it is attached to the frame tree.


2) FrameLoaderClient::committedLoad must ensure it calls  
FrameLoader::setEncoding before passing the first data chunk to the  
document. I think this is actually a remaining architectural problem  
with the loader, we are counting on the client to do too much in this  
case to have things work properly - I'd like to unwind this logic at  
some point to not rely on the client so much. In the short run, just  
adding the call is likely to just work.



Sorry about the breakage. I think this change will still be good in  
the long run.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Fix for Qt build

2007-05-12 Thread Maciej Stachowiak


I can't check this in right now because the SVN server is temporarily  
out of disk, but this appears to mostly fix the Qt build, at least in  
QtLauncher. Rob Buis helped me test and is running layout tests now.


Index: WebKitQt/ChangeLog
===
--- WebKitQt/ChangeLog  (revision 21427)
+++ WebKitQt/ChangeLog  (working copy)
@@ -1,3 +1,14 @@
+2007-05-12  Maciej Stachowiak  [EMAIL PROTECTED]
+
+Reviewed by Rob Buis.
+
+- call Frame::init as needed - this prevents crashes but  
pages don't appear.

+
+* Api/qwebframe.cpp:
+(QWebFramePrivate::init):
+* WebKitPart/WebKitPart.cpp:
+(WebKitPart::initView):
+
2007-05-08  Steve Falkenburg  [EMAIL PROTECTED]
 Reviewed by Ada.
Index: WebKitQt/Api/qwebframe.cpp
===
--- WebKitQt/Api/qwebframe.cpp  (revision 21427)
+++ WebKitQt/Api/qwebframe.cpp  (working copy)
@@ -79,6 +79,7 @@
 frameView-setScrollArea(qframe);
 frameView-setAllowsScrolling(frameData-allowsScrolling);
 frame-setView(frameView.get());
+frame-init();
 eventHandler = frame-eventHandler();
}
Index: WebKitQt/WebKitPart/WebKitPart.cpp
===
--- WebKitQt/WebKitPart/WebKitPart.cpp  (revision 21427)
+++ WebKitQt/WebKitPart/WebKitPart.cpp  (working copy)
@@ -123,6 +123,8 @@
 m_frame-setView(frameView);
 m_frameView-setParentWidget(parentWidget);
+m_frame-init();
+
 // Initialize KParts widget...
 setWidget(m_frame-view()-qwidget());
}

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fix for Qt build

2007-05-12 Thread Maciej Stachowiak


On May 12, 2007, at 7:59 AM, Holger Freyther wrote:



Am 12.05.2007 um 13:28 schrieb Holger Freyther:



Am 12.05.2007 um 12:32 schrieb Maciej Stachowiak:



I can't check this in right now because the SVN server is  
temporarily out of disk, but this appears to mostly fix the Qt  
build, at least in QtLauncher. Rob Buis helped me test and is  
running layout tests now.




Okay,
the difference between Mac and Gdk is in  
FrameLoaderClient::canCachePage. If canCachePage returns false,  
clear() will be called which sets m_frame-d-m_doc-m_ptr to 0.  
And on load setEncoding comes after calling saveDocumentState. So  
there is no way to restore/has a valid document.


Oh - that was actually a bug and I believe I've landed a fix.


I don't know how to fix it, but at least this explains why it  
crashes on Gdk and not on Mac. I think we should review codepath's  
ending in a clear().


void FrameLoader::provisionalLoadStarted()
{
m_firstLayoutDone = false;
cancelRedirection(true);
m_client-provisionalLoadStarted();

if (canCachePage()) {
if (m_client-canCachePage()) {
if (!m_currentHistoryItem-cachedPage()) {
cachePageToHistoryItem(m_currentHistoryItem.get());
purgePageCache();
}
} else {
// Put the document into a null state, so it can be  
restored correctly.·

clear();
}
}
}


The code now reads like this:

if (canCachePage()  m_client-canCachePage()  ! 
m_currentHistoryItem-cachedPage()) {

cachePageToHistoryItem(m_currentHistoryItem.get());
purgePageCache();
}


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content

2007-05-25 Thread Maciej Stachowiak


On May 25, 2007, at 4:18 PM, David Hyatt wrote:

Augmenting contextual menus really has nothing to do with plug-ins,  
so I'm not sure how the conversation ended up at plug-ins.  :)
Changing context menus is getting more into the realm of extensions.


Yeah, I don't get how it got there either. If you want to change  
context menus, then in a custom WebKit app, you can use the UI  
delegate: webView:contextMenuItemsForElement:defaultMenuItems:


If you want to do it from web content, I think your only option right  
now is to handle the contextmenu event and pop up a custom menu by  
hand.


In the future, HTML is going to get better support for customizing  
context menus from web content. Here's the current HTML5 draft:  
http://www.whatwg.org/specs/web-apps/current-work/#context. If you  
need a feature like this sooner rather than later, contact the  
appropriate WWDR representative.


Regards,
Maciej





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Augmenting WebKit contextual menus for non-plugin content

2007-05-25 Thread Maciej Stachowiak


On May 25, 2007, at 4:07 PM, Nathan Duran wrote:

I'm on record as accepting of, but not agreeing with, this  
argument ;)


Well it makes at least as much sense as the Contextual Menu Manager  
API's

continued existence does :)

It strikes me as rather silly to protest giving free reign to plugin
developers in the interest of maintaining some territorial sense of  
purity
(that QuickTime vs. PNG argument is pretty flimsy) when all it does  
is force
said developers to craft even dirtier solutions--such as the  
rampant abuse

of Input Managers.


It's not just sense of purity - the browser makes assumptions that  
certain types will be handled directly and counts on this to give a  
consistent user experience and for its internal workings. Pretty much  
all browsers reserve their built-in types. Many plugins mistakenly  
claim built-in types, since other browsers ignore that, and content  
would break in Safari if we don't do it right.


Anyway, if you are trying to change context menus from a custom  
WebKit app you don't have to use any hacks, there is an API for it  
(WebUIDelegate).


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Making use of a KJS_EXPORT macro

2007-06-01 Thread Maciej Stachowiak


Hey Geoff,

On Jun 1, 2007, at 9:51 AM, Geoffrey Garen wrote:


Hi Luciano.

I've found that the required exports from JavaScriptCore change all  
the time based on new functionality in WebCore or architectural  
changes in JavaScriptCore. I think that kind of documentation could  
quickly get out of sync with reality.


As I understand it, it's not documentation, but an alternative way of  
controlling the actual exports. Instead of an export file you can  
declare symbol visibility at compile time. In theory this could  
somewhat improve codegen, since the compiler would know some  
functions are not exported at compile time, not just link time.


 - Maciej



Geoff

On Jun 1, 2007, at 1:19 AM, Luciano Montanaro wrote:


Hi all.
I'm trying to reconcile the KJS and JSC repositories, and one of the
differences I have found is the usage of the KJS_EXPORT macro, which
expands to
__attribute ((visibility(default))) on GCC and
__declspec(dllexport) or __declspec(dllimport) on Microsoft  
compilers.


I think it's a useful feature, and it offers a way to document  
which classes
are for internal use and which do not without cluttering the  
source code

too much.

Would a patch for annotating classes and methods with this macro  
be welcome?


Luciano
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebForms 2.0 and Webkit

2007-06-06 Thread Maciej Stachowiak


On Jun 6, 2007, at 11:09 AM, Andre-John Mas wrote:


Hi,

I have heard that the W3C was working on a specification known
as 'Web Forms 2.0'. Does anyone know what the status of this is
and whether there are any moves to incorporate this into
WebKit or any other mainline rendering engine?


The Web Forms 2.0 spec was originally created by the WHAT Working  
Group http://whatwg.org. It has been adopted by the W3C as part of  
HTML5, and we'll likely support some of its features as it gets  
reviewed and integrated into the main HTML5 spec.


(It is not at all the same thing as XForms.)

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Maciej Stachowiak


On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low- 
res artwork and CSS referring to such (background-image, and the  
like), depending on their screen pixels, printer resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are possible  
which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple stylesheets  
in HTML/XML, or to select from multiple blocks in a single stylesheet.


2) DPI is not really the relevant factor to make the decision, what's  
important is the UI scale factor. If I'm running at 144 DPI but at 1x  
scale, I want the same images as at 72 dpi 1x scale.


3) Passing the resolution to the server forces the selection logic to  
be on the server side, not the client. But that's not really sensible  
- if the server has multiple  resolution versions of a resource, such  
as an image, it should advertise them to the client and let the client  
choose. For example, at 1.5 UI scale factor, if the server has 3x and  
2x images available the client could reasonably choose 2x (the next  
scale up) or 3x (since it is an integer multiple of the scale factor).





The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page  
zoom of 200% would request 233.33 dpi)


This doesn't make sense with the way clients actually work. What you  
care about with images embedded in web content is the relative scale  
of CSS pixels relative to device pixels, which does not have any  
necessary direct relation to the physical DPI. You don't actually want  
to serve different images to different DPI screens if they are both  
running at the same scale factor.





Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
Content-Resolution: auto-adjust header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.


• A dpcm (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.



What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.


I think the whole design of it is wrong. It's based on DPI instead of  
scale factor, it pushes the decision to the server when it should be  
made on the client side, and it handles things at the HTTP level that  
should be (and indeed are) handled by CSS media queries.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accept- Content-Resolution headers proposal

2007-06-07 Thread Maciej Stachowiak


On Jun 7, 2007, at 9:00 AM, Nicholas Shanks wrote:


Sorry,


Accept-Content: text/css, text/dsssl, text/xsl


should of course have referred to Accept-Type  :-)


Actually it should have been Accept:. There is no Accept-Type header.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ResourceHandle and the Frame parameter

2007-06-12 Thread Maciej Stachowiak


On Jun 12, 2007, at 2:33 PM, Darin Adler wrote:

I think we'll have to rethink this. ResourceHandle is intended to  
be a low level networking layer, and so it doesn't make sense to  
have higher level concepts like a Frame*, but clearly we'll need to  
make a design change so there's a higher level that's easy to plug  
in to.


Or we can just give up on the notion of ResourceHandle as a low  
level networking abstraction.


As Darin says, the intent is that ResourceLoader is the layer that  
knows about high-level networking stuff in the engine, ResourceHandle  
is supposed to be low-level and ignorant of the higher-level loading  
code. In my opinion, the right way to put in hooks that depend on the  
loading context would be to add appropriate ResourceHandleClient  
methods.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ResourceHandle and the Frame parameter

2007-06-12 Thread Maciej Stachowiak


On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak wrote:



On Jun 12, 2007, at 2:33 PM, Darin Adler wrote:

I think we'll have to rethink this. ResourceHandle is intended to  
be a low level networking layer, and so it doesn't make sense to  
have higher level concepts like a Frame*, but clearly we'll need  
to make a design change so there's a higher level that's easy to  
plug in to.


Or we can just give up on the notion of ResourceHandle as a low  
level networking abstraction.


As Darin says, the intent is that ResourceLoader is the layer that  
knows about high-level networking stuff in the engine,  
ResourceHandle is supposed to be low-level and ignorant of the  
higher-level loading code. In my opinion, the right way to put in  
hooks that depend on the loading context would be to add  
appropriate ResourceHandleClient methods.


Now that I think about it, I guess that won't do much to help you add  
port-specific hooks - although the ResourceHandleClient (normally a  
ResourceLoader) could call up to a platform-specific WebKit layer via  
FrameLoaderClient. It's hard to tell what the best model is without  
more details about why the low-level networking code in question  
needs access to the high-level objects.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ResourceHandle and the Frame parameter

2007-06-12 Thread Maciej Stachowiak


On Jun 12, 2007, at 5:41 PM, Morgan L wrote:



--- Maciej Stachowiak [EMAIL PROTECTED] wrote:



On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak
wrote:



On Jun 12, 2007, at 2:33 PM, Darin Adler wrote:


I think we'll have to rethink this.

ResourceHandle is intended to

be a low level networking layer, and so it

doesn't make sense to

have higher level concepts like a Frame*, but

clearly we'll need

to make a design change so there's a higher level

that's easy to

plug in to.

Or we can just give up on the notion of

ResourceHandle as a low

level networking abstraction.


As Darin says, the intent is that ResourceLoader

is the layer that

knows about high-level networking stuff in the

engine,

ResourceHandle is supposed to be low-level and

ignorant of the

higher-level loading code. In my opinion, the

right way to put in

hooks that depend on the loading context would be

to add

appropriate ResourceHandleClient methods.


Now that I think about it, I guess that won't do
much to help you add
port-specific hooks - although the
ResourceHandleClient (normally a
ResourceLoader) could call up to a platform-specific
WebKit layer via
FrameLoaderClient. It's hard to tell what the best
model is without
more details about why the low-level networking code
in question
needs access to the high-level objects.


I tried to give some motivating examples in my initial
post.  A good example is network code that might like
to put up a dialog, and it would like that dialog to
be properly parented above the window from which the
resource request originated.


Our approach for this in WebKit would be to make it a delegate  
callback up to the app - we never throw up dialogs from low-level  
code without control over the app. I think other ports should have  
the same approach, unless there's some deep reason that can't be done.



There could also be
network policy decisions, which do not involve UI,
that depend on the originating frame.


Policy decisions are something that we try to do at the  
ResourceLoader layer or calling up to WebKit or all the way to the app.


In both cases, it may be more costly to implement solutions using  
callbacks to the ResourceHandleClient.


Is it really that big a deal? We already have a bunch of stuff on Mac  
and Windows Safari that calls all the way up to the app (for instance  
on every redirect) and it is not a significant performance hit.



In short, forcing consumers / embedders to plumb new
hooks through ResourceHandleClient and ResourceLoader
seems like a larger burden, both in terms of initial
development and maintainability (since the hooks
wouldn't be exercised by Safari).


The tradeoff is that it breaks the intended layering of WebKit.  
WebCore/platform should be a layer that wraps platform-specific APIs.  
It should (in theory) have no knowledge of higher-level parts of  
WebCore, and should communicate solely through abstract client  
interfaces. WebKit should be the layer that implements API and policy  
on top of the core networking code.


It may be that this approach is ultimately not workable, but I'm not  
really convinced by your examples. There's no reason new dialogs or  
policy decisions can't be handled the same way that all the existing  
ones are, as far as I can tell.



At any rate, my hope is that you will accept a trivial
patch to plumb a Frame down to
ResourceHandle::loadResourceSynchronously and that you
will preserve some context that is equivalent to the
Frame in the future.  I think less is more in this
case :-)


I really think that moves things in the wrong direction. I'd rather  
see patches to add appropriate ResourceHandleClient calls to handle  
the cases of interest to you.


Otherwise we have to totally rethink the intended separation of  
responsibilities between ResourceHandle and ResourceLoader.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] XMLHttpRequest and readyState==3

2007-06-26 Thread Maciej Stachowiak


On Jun 26, 2007, at 10:29 AM, Christopher Allen wrote:


Geoffrey Garen wrote:

From code inspection, I see that XMLHttpRequest updates responseText
every time it receives data.

Perhaps you're seeing the results of slightly different networking
implementations. For example, you might need to send data in larger
chunks in order to convince the networking layer to flush its data  
up to

the application level.


We've written up a simple example using perl cgi and js/xhr to
demonstrate this problem. In Firefox, the expected behavior appears.
Every second, a new line appears counting up from 1 to 10. In Safari,
there's a 10 second delay with nothing, and then 10 lines appear
counting up from 1 to 10 all at once, just as the readyState goes from
3 to 4. We never see readyState going from 3 to 3 as we do with
Firefox.

URL demonstrating this behavior: http://www.synchroedit.com/pt/

URL with source code for this test:
http://www.synchroedit.com/pt/perl-test.tar.gz

The perl cgi script has autoflushing enabled, which means the buffer
is flushed for every newline. In Firefox, the responseText is updated
whenever the perl side sends and flushes data, while Safari's
responseText stays empty until the perl cgi closes the connection and
the request enters readyState 4.

So to return back to our original question -- this capability is
needed for synchronous applications that keep an ongoing connection to
the server to avoid polling and other performance issues. Is this
capability supposed to be to in Safari, thus our test above
demonstrates a bug? Are we missing something? Is there an alternative
approach that would make this behavior work right in WebKit/Safari 3
as well?


This is a networking layer issue - it buffers the data up to some  
limit depending on what MIME type you send it with. Two workarounds  
that I think will work:


1) prime the connection with 256 bytes sent before any of the real  
data.
2) Use a MIME type that won't be subject to sniffing (I think  
application/xml as opposed to text/xml may fit the bill).


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Re: Spinneret build issue (on Windows)

2007-06-29 Thread Maciej Stachowiak


Hello,

On Jun 29, 2007, at 5:00 PM, Double-Dee Zee wrote:


Somebody out there must be using Spinneret, can you please help?

Is Spinneret now defunct?  If yes, then why was that Win32 build  
issue resolved just 10 days ago?  Is someone successfully using  
Spinneret with the new Win32 build?


We originally made Spinneret as a testbed for Windows WebKit, when  
there was no WebKit-based Windows browser available for Windows. Now  
that Safari is out, those of us at Apple are not really maintaining  
Spinneret, since you can use Safari to test. We don't have a simple  
testbed app for Mac OS X in the source tree either. We're accepting  
patches from others who want to fix it, but we're not really going to  
maintain it ourselves, and we think other browsers using WebKit in  
general should be hosted separately.


What's the interest level in keeping Spinneret in the WebKit  
repository? Would people object to removing it entirely?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accessing Web Kit DOM properties via Javascript

2007-07-03 Thread Maciej Stachowiak


On Jul 3, 2007, at 1:51 PM, Andrew Murphy wrote:


Hello.

This is my first time posting here, though I have lurked for a few  
days, so I think that my question is on topic for this list.   
Please let me know if it isn't. :)



I'm wondering if there's any way in Web Kit to access a page's DOM  
properties via, say, Javascript?  (In my final use I'll be wanting  
to use ActionScript, but Javascript is a simpler way to create a  
testable example.)


For example, is it possible to access the coords property of an  
HTMLAnchorElement like this:


coords only applies to an HTMLAreaElement, not an HTMLAnchorElement.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accessing Web Kit DOM properties via Javascript

2007-07-03 Thread Maciej Stachowiak


On Jul 3, 2007, at 2:10 PM, Darin Adler wrote:


On Jul 3, 2007, at 2:07 PM, Maciej Stachowiak wrote:


On Jul 3, 2007, at 1:51 PM, Andrew Murphy wrote:

For example, is it possible to access the coords property of an  
HTMLAnchorElement like this:


coords only applies to an HTMLAreaElement, not an  
HTMLAnchorElement.


Are you sure?

This lists coords for the anchor element: http://www.w3.org/TR/DOM- 
Level-2-HTML/html.html


You're right, and the coords markup attribute is even allowed for A.  
Looking at the original example more closely, the result is an empty  
string because no coords attribute is set on the A element in the  
markup. coords reflects an attribute value, it does not give the true  
coordinates of the A element. coords is meant for use with client- 
side image maps, and to my knowledge only has an actual effect for  
AREA, not A.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Accessing Web Kit DOM properties via Javascript

2007-07-04 Thread Maciej Stachowiak


On Jul 4, 2007, at 11:22 AM, Andrew Murphy wrote:


Ahh.. I see now.  Thank you for clearing that up for me. :)

Forgive me for asking but, does anyone know if there is a way to  
access the

true coordinates of page elements?


Yes, you can use offsetTop and offsetLeft properties in combination  
with offsetParent. Some Googling will tell you how to make it work.


 - Maciej





- - - - - - - - -
-[andrew murphy]-
flash subject matter expert
[EMAIL PROTECTED]

delvinia interactive
214 king street west, suite 214
toronto canada M5H 3S6
voice 416.364.1455 ext. 232
fax 416.364.9830
www.delvinia.com

CONFIDENTIALITY NOTICE
This email message may contain privileged or confidential  
information. If
you are not the intended recipient or received this communication by  
error,

please notify the sender and delete the message without copying or
disclosing it.

AVIS DE CONFIDENTIALITÉ
Ce message peut contenir de l'information légalement privilégiée ou
confidentielle. Si vous n'êtes pas le destinataire ou croyez avoir  
reçu par
erreur ce message, nous vous saurions gré d'en aviser l'émetteur et  
d'en

détruire le contenu sans le communiquer a d'autres ou le reproduire.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej  
Stachowiak

Sent: July 3, 2007 5:16 PM
To: Darin Adler
Cc: webkit-dev Development
Subject: Re: [webkit-dev] Accessing Web Kit DOM properties via  
Javascript



On Jul 3, 2007, at 2:10 PM, Darin Adler wrote:


On Jul 3, 2007, at 2:07 PM, Maciej Stachowiak wrote:


On Jul 3, 2007, at 1:51 PM, Andrew Murphy wrote:


For example, is it possible to access the coords property of an
HTMLAnchorElement like this:


coords only applies to an HTMLAreaElement, not an
HTMLAnchorElement.


Are you sure?

This lists coords for the anchor element: http://www.w3.org/TR/DOM-
Level-2-HTML/html.html


You're right, and the coords markup attribute is even allowed for A.
Looking at the original example more closely, the result is an empty  
string
because no coords attribute is set on the A element in the markup.  
coords
reflects an attribute value, it does not give the true coordinates  
of the A
element. coords is meant for use with client- side image maps, and  
to my

knowledge only has an actual effect for AREA, not A.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.0/886 - Release Date:  
04/07/2007

1:40 PM


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.0/886 - Release Date:  
04/07/2007

1:40 PM


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Issue retrieving SourceCode: SC containing Trojan horses?!?

2007-07-17 Thread Maciej Stachowiak


On Jul 17, 2007, at 9:49 AM, Paul Bakker wrote:


Hi,

Trying to download and install WebKit, following the instructions at http://webkit.org/building/tools.html 
, but am running into the following:


First I downloaded the tar file with sourcecode, but unzipping it  
gave errors in my McAffee (up to date0 firewall software.


Then I tried through “svn checkout http://svn.webkit.org/repository/webkit/trunk 
 WebKit” in Cygwin. it goes for quite a while and then the same error.


Cygwin fails with the following message:
AWebKit/LayoutTests/fast/encoding/noscript-in-head-expected.txt
AWebKit/LayoutTests/fast/encoding/denormalised-voiced-japanese- 
chars-expected.png
svn: Can't open file 'WebKit/LayoutTests/fast/encoding/.svn/tmp/text- 
base/utf-32-big-endian-nobom.xml.svn-base': No such file or directory


In my firewall software, I see this file is removed due to a “  
Exploit-ObscuredHtml (Trojan). Following a link in the FW software,  
I get this: http://us.mcafee.com/virusInfo/default.asp?id=descriptionvirus_k=131453


So, are there actually Trojan horses within the sourcecode files?!?!  
Of is my FW software complaining about nothing and should I just  
disable the FW temporarily?


No, there aren't trojans in the source code. But some of our test  
files do unusual things on purpose to test behavior in edge cases, and  
it sounds like your firewall software is unhappy about that.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Safari or webkit issue - http getting chopped,

2007-07-19 Thread Maciej Stachowiak


On Jul 19, 2007, at 11:21 AM, Andre-John Mas wrote:


Let's try this again, this time with the text:

I have a server in my domain called 'chat' and have a Tomcat server  
running
there on port 8081. On that Tomcat server I have web application the  
provides

an RSS feed. The URL I normally use is:

http://char:8081/ds/rss-feeds.do

This page is a form allowing me to select the feeds I want from the  
server.
This works correctly. Now when I tell the server that parameters for  
the RSS I

start getting issues. The RSS query is:

http://chat:8081/ds/rss.do?report=visits


Is it correct that one is char and the other is chat?

In any case, please file a bug, and attach a tcpflow dump of the  
network transaction. It looks like something is misinterpreting  
chat: as a protocol instead of a host name, but I can't tell just by  
guessing






What happens is that I get told:

 The page you opened redirected you to a page that isn’t supported  
by Safari.
 Safari can’t open the page “chat:8081/ds/rss.do?report=visits”  
because it

 cannot redirect to locations starting with “chat:”.

This is strange since this page works correctly in Firefox (Mac,  
Linux,
Windows), IE6 and Opera. Using wget also shows no redirection  
happening. I am

suspecting that this is something is Safari/Webkit going funny.

A few things I have tried:

 1 - changing application/rss+xml - application/xml  -- same  
behaviour


 2 - changing application/rss+xml - text/plain -- same behaviour

 3 - changing rss version=2.0 to xxx version=2.0 -- same  
behaviour


 4 - doing both 3 and 4 -- URL doesn't get mangled


It sounds like this is something Safari RSS is doing, probably it  
converts the URL to a feed: URL by stripping off the http:, and  
prepending feed:, but then it mistakenly thinks chat: is the URI of  
what the feed: protocol points to. But it's hard to be sure without a  
reproducible case, and I'm not sure why the query would affect this.


Regards,
Maciej




 5 - changing host name to 192.168.2.101 or fully qualified  
chat.mydomain.com

-- URL doesn't get mangled


This affects Safari 3 and the latest WebKit build (2007-07-18) on  
the Mac. It

also seems focused on RSS being the document type.

Andre

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Pleyo unveils OWB, its refactor of WebKit

2007-07-20 Thread Maciej Stachowiak


Hi Jean-Charles,

On Jul 20, 2007, at 1:06 PM, Jean-Charles VERDIE (Pleyo) wrote:


Dear Webkitters,

Pleyo, by my voice and others such as Max or Sebastien, has been  
talking here now and then about the future outcome of its own  
refactored version of WebKit, based on a specific Abstraction Layer  
that we believe would help make portage to embedded platforms easier.


We are finally ready to show you the very first iteration. It's  
based on the rev. 19826 of WebKit, code named Robespierre as the  
french revolutionnary hero :)


Since we are not willing to head to a fork, we hope that some (not  
to say more...) of our changes will eventually go back to WebKit  
trunk, while we will keep merging from WebKit ToT on a regular  
basis. So expect to see some patchs arrive in the following weeks,  
Maxime already started sending some and more pleyo folks do the same  
in a near future...


The website is not really finalized but we couldn't wait to get some  
feedback on our work. We will add more details on legal, extensions  
and technical architecture later.


Welcome to the WebKit community. We look forward to your  
contributions, and we especially appreciate the great patches that  
Maxime has been sending the past few months.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] kiosk browser on Windows

2007-07-24 Thread Maciej Stachowiak


On Jul 24, 2007, at 4:04 PM, Sam Carleton wrote:


Folks,

I have already written a kiosk browser for Windows using the
WebControl (IE6 or IE7), but I need a cross platform browser and would
prefer to use Safari rather then Firefox.  Is it possible to use
webkit on windows?  Is there an open source kiosk program out there
that will aid me in my efforts?


WebKit on Windows is open source, however, some of the support  
libraries in Apple's Windows port are only licensed for use with  
Safari. It's possible that in the future there will be a version of  
the Windows port that does not depend on these libraries.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit Project Goals

2007-07-24 Thread Maciej Stachowiak


I sent this a while ago with not much comment. Any thoughts? Should I  
post this on webkit.org somewhere?


 - Maciej

On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote:



Hi Everyone,

I recently watched a video on the topic of preventing poisonous  
people from hurting an open source project. One of the practices it  
recommends for a large open source project is to have a mission  
statement, so it's clear to everyone what is and isn't in scope for  
the project. I'm not too fond of the name mission statement (it  
sounds a little corporate) but I do think it's important to write  
down our goals as a project.


Ultimately I'd like to put this on the WebKit site, but I wanted to  
throw out some ideas for discussion. I'd like to hear if anyone  
thinks I have missed any project goals, if any of these are worded  
badly, or if it is worth calling out more non-goals.



WebKit Project Goals

WebKit is an open source Web content engine for browsers and other  
applications. We value real-world web compatibility, standards  
compliance, stability, performance, security, portability, usability  
and relative ease of understanding and modifying the code  
(hackability).


Web Content Engine - The project's primary focus is content deployed  
on the World Wide Web, using standards-based technologies such as  
HTML, CSS, JavaScript and the DOM. However, we also want to make it  
possible to embed WebKit in other applications, and to use it as a  
general-purpose display and interaction engine.


Open Source - WebKit should remain freely usable for both open  
source and proprietary applications. To that end, we use BSD-style  
and LGPL licenses.


Compatibility - For users browsing the web, compatibility with their  
existing sites is essential. We strive to maintain and improve  
compatibility with existing web content, sometimes even at the  
expense of standards. We use regression testing to maintain our  
compatibility gains.


Standards Compliance - WebKit aims for compliance with relevant web  
standards, and support for new standards
In addition to improving compliance, we participate in the web  
standards community to bring new technologies into standards, and to  
make sure new standards are pratical to implement in our engine. We  
use regression testing to maintain our standards compliance gains.


Stability - The main WebKit code base should always maintain a high  
degree of stability. This means that crashes, hangs and regressions  
should be dealt with promptly, rather than letting them pile up.


Performance - Maintaining and improving speed and memory use is an  
important goal. We never consider performance good enough, but  
strive to constantly improve. As web content becomes richer and more  
complex, and as web browsers run on more limited devices,  
performance gains continue to have value even if normal browsing  
seems fast enough.


Security - Protecting users from security violations is critical. We  
fix security issues promptly to protect users and maintain their  
trust.


Portability - The WebKit project seeks to address a variety of  
needs. We want to make it reasonable to port WebKit to a variety of  
desktop, mobile, embedded and other platforms. We will provide the  
infrastructure to do this with tight platform integration, reusing  
native platform services where appropriate and providing friendly  
embedding APIs.


Usability - To the extent that WebKit features affect the user  
experience, we want them to work in accordance with good human  
interface design principles, and to mesh well with platform-native  
HI conventions.


Hackability - To make rapid progress possible, we try to keep the  
code relatively easy to understand, even though web technologies are  
often complex. We try to use straightforward algorithms and data  
structures when possible, we try to write clear, maintainable code,  
and we continue to improve names and code structure to aid  
understanding. When tricky rocket science code is truly needed to  
solve some problem, we try to keep it bottled up behind clean  
interfaces.



Non-Goals

WebKit is an engine, not a browser. We do not plan to develop or  
host a full-featured web browser based on WebKit. Others are welcome  
to do so, of course.


WebKit is an engineering project not a science project. For new  
features to be adopted into WebKit, we strongly prefer for the  
technology or at least the use case for it to be proven.


WebKit is not a bundle of maximally general and reusable code - we  
build some general-purpose parts, but only to the degree needed to  
be a good web content engine.


WebKit is not the solution to every problem. We focus on web  
content, not complete solutions to every imaginable technology need.



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit

Re: [webkit-dev] WebKit licensing and LGPLv3

2007-07-25 Thread Maciej Stachowiak


Hi Allan,

I've forwarded your comments and those of others internally at Apple.  
I won't do #2 for moment. I'd still appreciate any other input on this  
point.


Regards,
Maciej

On Jul 24, 2007, at 11:05 PM, Allan Sandfeld Jensen wrote:


On Wednesday 25 July 2007 01:51, Maciej Stachowiak wrote:

1) We will continue to accept only code that's licensed under a BSD-
style (no advertising clause) license, or LGPL 2.1, or other
compatible license. We don't want to accept code that's LGPL 3 only,
as that would make the whole project LGPL 3.

I think continuing to require LGPL 2 or later would be the most  
sane and

most compatible.

2) We'd like to change the copyright notices from their current mix  
of

LGPL 2 or any later version and LGPL 2.1 or any later version to
just LGPL 2.1, to make this clear. This one is maybe more debatable,
so I'd like to know if anyone objects. It would prevent incorporating
WebKit code into LGPL 3 projects, and would require sign-off from all
copyright holders to ever change to a different LGPL version in the
future (in case the FSF came out with a version 3.1 or 4 that solved
some of the problems with v3).

I object. I would like to reserve the right to integrate WebKit with  
LGPL 3

projects like future KDE libs.

Though since we are talking LGPL the linking-issues are not that  
problematic,
it would still make it easier if the project continued to include  
the or

later clause.

Regards
`Allan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Javascript collector

2007-07-25 Thread Maciej Stachowiak


On Jul 25, 2007, at 1:02 PM, Patrick Hanna wrote:

I am running into a segmentation fault in  
Collector::collectOnMainThreadOnly on the line that reads:


cellBlock(cell)-collectOnMainThreadOnly.set(cellOffset(cell));

I believe that the reason is because the address passed in as  
'value' is the address of a stack variable. This address comes from  
PluginsFunc::callAsFunction. PluginBase is created on the stack and  
the constructor for DOMObject calls  
Collector::collectOnMainThreadOnly with 'this' as the parameter.


My question is, should Collector::collectOnMainThreadOnly work with  
stack pointers? If it is supposed to work, when does the  
CollectorBlock for the stack object get created? Specificy,  
CollectorBlock::collectOnMainThreadOnly is the structure that I'm  
running in to problems with.


That's definitely a bug. It's illegal to create JSObject subclasses on  
the stack at all, as this will break garbage collection. Please file  
it. I think it's only through luck that it's not crashing for others  
(and maybe it is, but we just don't know it yet.)


Two possible solutions:

1) make refresh() a static member function of PluginBase, since it  
only touches static data members anyway. Then you won't need to  
instantiate a PluginBase object.


2) Have PluginFuncs look at the this object, which should be a  
Plugins, which inherits from PluginBase and thus should have the  
refresh method.


Do you have steps to consistently reproduce this bug?

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] type of JSChar

2007-07-27 Thread Maciej Stachowiak


On Jul 27, 2007, at 11:59 AM, Darin Adler wrote:



We were really following ICU's lead here -- ICU being another low  
level library not built on top of a framework like Qt or AppKit.


I do see that. In Qt, although we have lot's of the same  
functionality as ICU built in, we chose a different path and used  
unsigned short on all platforms (as it's 16bit on all platforms we  
support).


Yes, and Qt also has its own JavaScript engine.

I'd really like this API to be independent of the high level  
framework it's being used with, and I think it's unfortunate that Qt  
is now mentioned in the header. I'd prefer a different solution.


I haven't really thought about this one much but if there is to be an  
ifdef used in this file at all, it should ideally use a symbol that  
would be set when building a Qt-using application, not an internal  
platform define (even if this API isn't exported to Qt applications  
for now).


Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

2007-07-29 Thread Maciej Stachowiak


On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:


On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:

On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:



Other organizations have requested the ability to use other XML
parsers as well, such as expat. Seems like in the long run we want a
different approach than just ifdefs in the XMLTokenizer.cpp file. It
seems like the best would be some abstraction layer on top of the
parser library, but if that is difficult then your option #2 sounds
like a docent long-run approach. I would have expected just about
every XML parsing library to have a SAX-like API, which shouldn't be
too hard to abstract, but perhaps QXml works differently.


I guess that assumption doesn't hold. QXmlStream is a streaming  
parser with an
API that is very different from SAX. It IMO a whole lot simpler to  
use than a
SAX like API and is inspired from similar APIs in the Java world. If  
you're

interested, have a look at http://doc.trolltech.com/4.3/qxmlstreamreader.html


I'm told libxml has a StreamReader-style API now as well, so if that's  
the better alternative, we could design the XML code around that style  
of API (though probably not right at the moment).


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] JavaScript fuzzer for security testing

2007-08-04 Thread Maciej Stachowiak


On Aug 4, 2007, at 6:26 PM, Boyd Waters wrote:

Everyone saw the post about the JavaScript fuzzing tool released by  
Mozilla developers this week:


http://blog.mozilla.com/security/2007/08/02/javascript-fuzzer-available/
http://www.squarefree.com/2007/08/02/introducing-jsfunfuzz/
http://www.squarefree.com/2007/08/02/fuzzing-for-correctness/

Has anyone pointed this tool at WebKit?


Yes. It found some minor bugs in the past, but no crashes or potential  
security issues. We've got some bugs in bugzilla on it and we're  
continuing to run the tool.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Small question about versioning

2007-08-17 Thread Maciej Stachowiak


On Aug 16, 2007, at 11:20 PM, Mike Hommey wrote:


Hi,

When a change like [1] occurs, does it mean the current tree is
released as version 523.2 or that the previous revision was the
release of 523.1 ?


These version numbers in the .xcodeproj files are an Apple-internal  
versioning scheme. They do not indicate a release. The Mac OS X  
version of WebKit isn't really released in the conventional source  
tarball form.


Releases of the Gtk and Qt ports, and versioning schemes for them,  
would be up to the developers of those respective ports. I don't  
believe there have been any releases for either port yet.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Assistance

2007-08-19 Thread Maciej Stachowiak


On Aug 19, 2007, at 9:08 AM, David D. Kilzer wrote:


Hi David,

I would guess that you should start looking in  
RenderObject::paintBoxShadow()
and RenderObject::drawBorderArc(), although I'm not a rendering  
expert.  (Maybe

I will be after reading Hyatt's blog postings!)


paintBoxShadow is likely the only place that would need to change. But  
it looks to me like the code there is already trying to handle the  
border-radius case:


if (s-hasBorderRadius()) {
IntSize topLeft = begin ? s-borderTopLeftRadius() : IntSize();
IntSize topRight = end ? s-borderTopRightRadius() : IntSize();
IntSize bottomLeft = begin ? s-borderBottomLeftRadius() :  
IntSize();
IntSize bottomRight = end ? s-borderBottomRightRadius() :  
IntSize();
	context-clipOutRoundedRect(rect, topLeft, topRight, bottomLeft,  
bottomRight);
context-fillRoundedRect(rect, topLeft, topRight, bottomLeft,  
bottomRight, Color::black);

}

This code looks like it should work, I'm not sure why it doesn't.

REgards,
Maciej





http://webkit.org/blog/114/webcore-rendering-i-the-basics/

Also, if you're going to submit patches through the open source  
project, please
consider filing a Bugzilla bug at http://bugs.webkit.org/.  If  
there is a
matching Radar for a bug, note that in a bug comment and add the  
InRadar

keyword.  Thanks!

Dave


David den Boer [EMAIL PROTECTED] wrote:


So I want to take a dip into the wekit render code for the first
time, mostly for my own knowledge, and also to fix the bug below :


(image)


That is a div with a border-radius and a drop shadow, and it does not
work properly. There is another border-radius bug I found with
background colors too, and I feel that they  are close to the same
thing.

Can someone point me to the correct area of code to start  
investigating?


Thanks,
David.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Directory for Safari 3 for Windows plugins that isn't in Program Files?

2007-08-21 Thread Maciej Stachowiak


On Aug 21, 2007, at 5:21 PM, David D. Kilzer wrote:

Please file a bug using http://bugreport.apple.com/.  If you don't  
have an

ADC account, please create a free online account using
http://connect.apple.com/.

Also, please provide the Radar bug number in a reply once you've  
filed it.

Thanks!


I think it's actually a WebKit bug, not a Safari bug, so in principle  
it could be filed in bugs.webkit.org instead or in addition.


 - Maciej




Dave


MILIANO Vitorio [EMAIL PROTECTED] wrote:


Anders Carlsson wrote:


It won't matter where you install your plug-in as long as you
add a registry entry for it as described in


http://developer.mozilla.org/en/docs/Plugins:_The_first_install_problem

I've finally tested this, and this does not seem to be the case.

Safari 3.0.3 (522.15.5) for Windows appears to only check
HKEY_LOCAL_MACHINE\Software\MozillaPlugins for plugins, not
HKEY_CURRENT_USER\Software\MozillaPlugins.  This means that it will  
not

(and does not) pick up NPAPI plugins installed without Administrator
privileges.

Where should I file this as a bug?

Thanks,
Vitorio Miliano


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Unused variable shouldDumpSubframesAsText in DumpRenderTree.m

2007-08-22 Thread Maciej Stachowiak


On Aug 21, 2007, at 10:38 PM, Mike Hommey wrote:

On Tue, Aug 21, 2007 at 03:48:49PM -0700, Anyang Ren [EMAIL PROTECTED] 
 wrote:

r24862 added an unused variable shouldDumpSubframesAsText
to DumpRenderTree.m:


Speaking of unused variable, here is a list of warnings I got while
building the Qt and Gdk ports from r25144 with -Wall:


[...]


I don't know if I should file a bug or several bugs.


Patches would be great, however, I'd suggest splitting the platform- 
specific ones from the ones in platform-independent code. For the mac  
port at least, we build with -W -Wall -Werror and a bunch of other  
warnings (but we do explicitly turn a few off). I'd recommend the same  
for other ports - fixing warnings as you go beats getting bitten by  
them later.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Window::isSafeScript: which URLs to use in the error message

2007-08-31 Thread Maciej Stachowiak


On Aug 31, 2007, at 2:24 PM, Anyang Ren wrote:


In kjs_window.cpp, Window::isSafeScript(ExecState *exec), we have:

 KURL actURL = activeFrame-loader()-url();
 WebCore::String actDomain = actURL.host();
 ...
 KURL thisURL = frame-loader()-url();
 ...
 WebCore::String thisDomain = thisURL.host();

 if (actDomain == thisDomain  actURL.protocol() ==
thisURL.protocol()  actURL.port() == thisURL.port())
   return true;

 if (Interpreter::shouldPrintExceptions()) {
 printf(Unsafe JavaScript attempt to access frame with URL %s
from frame with URL %s. Domains, protocols and ports must match.\n,
thisDocument-URL().latin1(), actDocument- 
URL().latin1());

 }
 String message = String::format(Unsafe JavaScript attempt to access
frame with URL %s from frame with URL %s. Domains, protocols and ports
must match.\n,
 thisDocument-URL().latin1(), actDocument- 
URL().latin1());


Since thisURL and actURL are the URLs used in the test, why are
we using thisDocument-URL() and actDocument-URL() in the
error messages?


I think perhaps the message should mention both. thisURL and actURL  
(not such great names!) may identify the frame that is considered to  
own this frame in cases like about:blank or javascript: frame source,  
but they are not the true URL of the frame, so may not be very helpful  
in the error message. I think the format should be something like:


Unsafe JavaScript attempt to access frame with URL %s (owned by %s)  
from frame with URL %s (owned by %s). Domains, protocols and ports  
must match.\n


But the owned by part should probably be dropped entirely in the  
common case where the URLs are the same.


We'd take a patch to improve this.

In fact, actDocument could be NULL.  Earlier in this function, we  
have:


 WebCore::Document* actDocument = activeFrame-document();

 if (actDocument) {
   if (thisDocument-domainWasSetInDOM()  actDocument- 
domainWasSetInDOM()) {

 if (thisDocument-domain() == actDocument-domain())
   return true;
   }
 }

The if (actDocument) test suggests that actDocument could
be NULL.


I'm not sure it's possible for a frame to be executing script with a  
null document, so I don't think this is actually possible. In fact, in  
current trunk, I don't think it is ever possible for any frame to have  
a null document.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Purpose of Path class?

2007-09-19 Thread Maciej Stachowiak


On Sep 19, 2007, at 10:14 AM, Oliver Hunt wrote:

Pardon? Path provides the abstraction for the path implementation of  
each platform's graphic library (eg. CoreGraphics, Qt, and Cairo).   
So we have to have a Path class if we want to be able to draw paths.


Specifically it wraps a bezier path.

Regards,
Maciej




--Oliver

On Sep 19, 2007, at 3:07 AM, eminemence wrote:



Thanks for the reply.
So isn't this Path class something more specific to cairo?
Also what is the exact use of a PATH if we can still break down  
operation

into single operations and do it?
Any advantages of having a path?
BR.
Mayur Kankanwadi.


Oliver Hunt-2 wrote:


The Path class provides an abstraction for paths drawn with a Canvas
element, and for rendering paths in SVG.

--Oliver

On Sep 18, 2007, at 10:44 PM, Mayur Kankanwadi wrote:


Hi All,
I have seen the Path class in WebCore and am not so sure as to what
exactly is it's purpose?
Can someone elaborate on this?
Thanks in advance.
BR.
Mayur Kankanwadi.


DISCLAIMER
==
This e-mail may contain privileged and confidential information
which is the property of Persistent Systems Pvt. Ltd. It is
intended only for the use of the individual or entity to which it
is addressed. If you are not the intended recipient, you are not
authorized to read, retain, copy, print, distribute or use this
message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent
Systems Pvt. Ltd. does not accept any liability for virus infected
mails.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev




--
View this message in context: 
http://www.nabble.com/Purpose-of-Path-class--tf4478939.html#a12774455
Sent from the Webkit mailing list archive at Nabble.com.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Extending the multipart support

2007-09-21 Thread Maciej Stachowiak


On Sep 21, 2007, at 8:09 AM, David D. Kilzer wrote:

WebKit supports multipart/x-mixed-replace as long as the content  
type doesn't
change (14149) or as long as it's not used through an XMLHttpRequest  
(14392):


http://bugs.webkit.org/show_bug.cgi?id=14149
http://bugs.webkit.org/show_bug.cgi?id=14392

The multipart/related (7168), multipart/mixed (9389)  and multipart/ 
alternate
(no bug filed; please consider filing one) content types are not  
supported yet.


http://bugs.webkit.org/show_bug.cgi?id=7168
http://bugs.webkit.org/show_bug.cgi?id=9389


To support non-replace multipart schemes, where resources are  
considered related, you'd want to provide some implementation of the  
cid: URL scheme that knows how to find attachments. Currently we  
consider this the domain of mail clients to handle. Is there  
significant non-replace multipart content on the web that would be  
useful to support?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] feature-branch is open for business again

2007-10-02 Thread Maciej Stachowiak


Oliver (with a bit of help from Eric and others) has gotten the  
rebased feature-branch reasonably solid. There are still some SVG  
issues, but it's all clear for other patches.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Branch Plan

2007-10-10 Thread Maciej Stachowiak


Hi Everyone,

Trunk has been closed to new feature development and risky changes in  
general for a long time. Most of the need to do heavy stabilization  
has passed. In the meantime, we have had feature-branch, which has  
recently been updated and brought much closer to trunk. It's time for  
trunk to reopen soon. If there are no objections, we'd like to execute  
the following sometime tomorrow:


1) Announce that trunk and feature-branch are temporarily closed to  
commits.


2) Create branches/safari-3-branch/ from trunk/. This is the branch  
that Apple will use for final stabilization of and updates to Safari  
3. We'd like to keep this branch Apple-managed, since we will have to  
comply with Apple-internal release engineering process. However, we  
welcome and encourage others to track this branch with their own  
stabilization branches, either in SVN or elsewhere. We may be able to  
merge in port-specific changes that do not affect the core code, but  
it's best not to assume such changes can go in.


3) Merge all patches one at a time from branches/feature-branch/ onto  
trunk/. We are doing this instead of just using an svn copy so that  
revisions on trunk remain in order, to allow tools like the nightlies  
and buildbots to maintain sanity and to make future history bisection  
searches to continue to work. At this point feature-branch/ will be  
obsolete and will be renamed to indicate this.


4) Announce that trunk is once again open for general development.

We will keep trunk nightlies and buildbots, and will add nightlies and  
buildbots for the stable branch as quickly as we can.


Note: if you are currently on feature-branch then you can follow the  
change transparently by using svn switch once trunk reopens.


If anyone has comments or objections, let me know. We will likely pull  
the trigger on this tomorrow afternoon (US Pacific time).


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Branch Plan

2007-10-10 Thread Maciej Stachowiak


On Oct 10, 2007, at 3:51 PM, Timothy Hatcher wrote:


Having branch in the name is redundant. I propose branches/safari-3.


On the one hand, you're right that it's redundant. On the other hand, - 
having branch there makes it easier to talk about. We're more likely  
to say let's merge this change to the safari 3 branch than let's  
merge this change to branches slash safari 3. Similarly it would have  
been a bit weird for feature-branch to just be called branches/ 
feature. I'm not dead set on this but currentlly I like having -branch  
at the end a bit better.


 - Maciej



On Oct 10, 2007, at 3:47 PM, Maciej Stachowiak wrote:


Create branches/safari-3-branch/ from trunk/.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Branch Plan

2007-10-10 Thread Maciej Stachowiak


On Oct 10, 2007, at 4:46 PM, Timothy Hatcher wrote:

Might I suggest Safari-3-branch then? All of our other branches have  
a capital Safari.


Capital S sounds good to me.


On Oct 10, 2007, at 4:24 PM, Matt Lilek wrote:

Perhaps safari-3-branch could be named safari-3-apple and then  
have an identical safari-3-public or safari-3-ports branch.   
This way all the branching would happen in one fell swoop and all  
the porters are on the same page as to which branches are which and  
such.


Just my two cents.


Non-Apple branches probably shouldn't have Safari in the name. Maybe  
WebKit-3-stable would be a good name for a community-managed shared  
stable branch. If there was a shared such branch (as opposed to  
individual vendor branches) then we'd have to figure out what the  
checkin policy would be for such a branch.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Trunk is open

2007-10-14 Thread Maciej Stachowiak


All layout tests are now passing on the Tiger release buildbot.

Trunk is once again open for all approved patches (including patches  
previously only approved for feature-branch that have not landed yet).


However, I still recommend a primary focus on getting the remaining  
buildbots to green and getting all tests passing.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] We are porting webkit to windows ce

2007-10-29 Thread Maciej Stachowiak


On Oct 29, 2007, at 11:30 PM, George Staikos wrote:



On 30-Oct-07, at 2:22 AM, Maciej Stachowiak wrote:


Below is a document I have written up describing the webkit port
that our team want to build. We’d like to know what the community  
thinks of

the port we are proposing.


Sounds like a neat idea. Keep in mind that Safari is a registered  
trademark of Apple Inc. So I suggest picking a different name for  
the project.


Also, a company called Wake3 apparently already has a Windows CE  
port in progress: http://www.wake3.com/. They have not released  
any code yet as far as I know, but you may wish to get in touch  
with them.


 We also have WebKit up and running on WinCE.


I hope the WinCE ports can eventually come together and perhaps land  
in the webkit.org tree.


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] We are porting webkit to windows ce

2007-10-29 Thread Maciej Stachowiak


On Oct 29, 2007, at 10:58 PM, [EMAIL PROTECTED] wrote:


Hi All

Below is a document I have written up describing the webkit port
that our team want to build. We’d like to know what the community  
thinks of

the port we are proposing.


Sounds like a neat idea. Keep in mind that Safari is a registered  
trademark of Apple Inc. So I suggest picking a different name for the  
project.


Also, a company called Wake3 apparently already has a Windows CE port  
in progress: http://www.wake3.com/. They have not released any code  
yet as far as I know, but you may wish to get in touch with them.


Regards,
Maciej



Ledwinka

= port webcore to wince =

We create a new port of webcore for windows ce. Right now this port is
compliered by visual studio 2005. The goals for our port are

* As little platform specific code in Webcore as possible.
* Small memory footprint
* Same API as S60Webkit

= port javascriptcore to wince =

Still in processing


We are asking for help from the rest of the WebKit community on how  
to best
achieve these goals. We hope this port is friendly for embedded  
devices,

easy for porting to other handhold device platform.

Here is the website for our porting on sf.net
http://sourceforge.net/projects/safarimobile

and this is the maillist
https://lists.sourceforge.net/lists/listinfo/safarimobile-develop




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WTF license terms

2007-11-02 Thread Maciej Stachowiak


Hi everyone,

I'd like to change the license terms for the contents of  
JavaScriptCore/wtf from LGPL to Apple modified BSD, except for the  
copy of Google's TCMalloc and the unicode/ directory. All the  
copyrights on files besides tcmalloc and unicde are held by Apple and  
it looks like the only non-Apple contributions are a handful of  5  
line build fixes which were too small for copyright. Mainly I'd like  
to apply this to RefPtr, Vector, and the Hash-related classes.


I would like to do this to make the code usable by the widest possible  
range of projects, including even proprietary code, and open source  
projects with licenses that are not LGPL-compatible. This is basic  
data structure code, and although it is highly optimized it is not  
really specific to web browsing.


I wanted to run this proposed license change by the community. I know  
there have been some concerns about which code is BSD and which is  
LGPL. In this case, I think maximum reusability is the right thing for  
this code.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WTF license terms

2007-11-03 Thread Maciej Stachowiak


On Nov 3, 2007, at 1:31 AM, Mike Hommey wrote:


On Fri, Nov 02, 2007 at 08:34:21PM -0700, Maciej Stachowiak wrote:


Hi everyone,

I'd like to change the license terms for the contents of  
JavaScriptCore/wtf
from LGPL to Apple modified BSD, except for the copy of Google's  
TCMalloc
and the unicode/ directory. All the copyrights on files besides  
tcmalloc

and unicde are held by Apple and it looks like the only non-Apple
contributions are a handful of  5 line build fixes which were too  
small
for copyright. Mainly I'd like to apply this to RefPtr, Vector, and  
the

Hash-related classes.

I would like to do this to make the code usable by the widest  
possible

range of projects, including even proprietary code, and open source
projects with licenses that are not LGPL-compatible. This is basic  
data

structure code, and although it is highly optimized it is not really
specific to web browsing.

I wanted to run this proposed license change by the community. I  
know there
have been some concerns about which code is BSD and which is LGPL.  
In this

case, I think maximum reusability is the right thing for this code.


While speaking of licensing, what makes it a real mess is probably  
more

the fact there are both 2-clause and 3-clause BSD code than the use of
LGPL and BSD. And it's obviously worse when these 3 are used in
different files in the same directory.


Keep in mind that the 3-clause BSD-style licenses are not the  
classic BSD license with advertising clause, which *requires* mention  
in advertising. It just withholds the right to claim endorsement by  
particular companies (in some cases Apple, in a few others Google). I  
don't believe this conflicts with LGPL or creates any practical problem.



By the way, I filed bug #14885 a while ago, which has fortunately been
fixed, but new files additions broke it again. So, coders, please be
careful when add LGPLed files, and check the FSF address to be  
correct.


Patches welcome.

Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WTF license terms

2007-11-03 Thread Maciej Stachowiak


On Nov 3, 2007, at 1:20 AM, Mike Hommey wrote:


On Fri, Nov 02, 2007 at 08:34:21PM -0700, Maciej Stachowiak wrote:


Hi everyone,

I'd like to change the license terms for the contents of  
JavaScriptCore/wtf
from LGPL to Apple modified BSD, except for the copy of Google's  
TCMalloc
and the unicode/ directory. All the copyrights on files besides  
tcmalloc

and unicde are held by Apple and it looks like the only non-Apple
contributions are a handful of  5 line build fixes which were too  
small
for copyright. Mainly I'd like to apply this to RefPtr, Vector, and  
the

Hash-related classes.

I would like to do this to make the code usable by the widest  
possible

range of projects, including even proprietary code, and open source
projects with licenses that are not LGPL-compatible. This is basic  
data

structure code, and although it is highly optimized it is not really
specific to web browsing.

I wanted to run this proposed license change by the community. I  
know there
have been some concerns about which code is BSD and which is LGPL.  
In this

case, I think maximum reusability is the right thing for this code.


I don't see what the problem is with LGPL. It's not GPL, you know, and
allows proprietary code to use it (under some conditions, though)


We'd like people to be able to fold these particular classes into  
their code without making a shared library or a relinkable object. I'm  
not even really sure what difference a shared library makes for code  
that is entirely implemented as template classes in headers.  
Effectively there is no ability to relink in such cases, since all the  
interesting code goes in the file that includes the header.


Anyway, I don't want to trigger a wide-ranging discussion about the  
pros and cons of different licenses. Mainly I'd like to hear if any  
major contributors would have a problem with this move.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Keeping track of supported specs on wiki

2007-11-09 Thread Maciej Stachowiak


On Nov 9, 2007, at 10:47 AM, Philippe Kalaf wrote:


Hi guys,

I created a new wiki page at :

https://svn.macosforge.org/projects/webkit/wiki/SpecSupport.

The point is to track the specs that are currently supported or not.  
For
the specs that are being worked on (partially supported), we should  
have

a detailed progress page similar to the SVG status page at :

http://webkit.org/projects/svg/status.xml.

My knowledge of the supported specs is limited so I only modestly  
filled

in the table. I would appreciate it if everyone pitched in to complete
this table. If you are working on a spec please create a detailed  
status

page as well.

Once we have a more complete tables, I can write a script that would
convert them into a nicer colored HTML tables that we can have on the
main website.


Thanks for creating this page - I think it's a useful resource. I  
think instead of a yes/no support page, we should list specifications  
we are targeting, and rough status of implementation. No  
implementation of a web spec is truly bug-free so I am not sure it is  
ever correct to say Full, but it could be in a Stable state where  
you think you have complete feature coverage and few known bugs.


Also, I'm not sure we need to mention standards that we are *not*  
targeting. I will update the list with this in mind.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Keeping track of supported specs on wiki

2007-11-09 Thread Maciej Stachowiak


On Nov 9, 2007, at 5:55 PM, Rob Burns wrote:


Hello all,

I have to say I like Philippe's version of the page better. I think  
it is more appropriate for an open source project like webkit. I  
would agree with Maciej that the word stable might be more  
appropriate than full. However, I think its better to show all of  
the standards whether targeted by Apple or not. It might make sense  
to have an asterisk on the no response to indicate that Apple has  
no plans to target a particular standard.


The set of specs that currently have no support isn't necessarily  
identical to the set we are not targetting, or the set we would  
categorically rule out default support for. I think there are pretty  
few in the last category, and a huge number in the first if you take a  
broad view of what standards count.


I would rather list the standards we *do* currently care about  
(including things like IETF RFCs, ECMA standards, ISO standards, etc)  
than try to list a complete or partial list of ones we don't care about.


However, I assume other contributors are free to bring standard  
supports to WebKit. I know of two such projects myself where  
contributors are working to bring standards support to WebKit not  
currently targeted by Apple.


Perhaps the status column should be one of:

• No
• No* (not targeted by  Apple)
• Partial
• Stable


Again, I'm not sure No adds much value relative things not on this  
list probably are not currently targetted. I certainly do not want to  
make a commitment on behalf of either Apple or the whole WebKit  
project that we won't support particular specs.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving away from qmake

2007-11-12 Thread Maciej Stachowiak


On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote:



On 13/11/2007, at 00:00, Charles Woloszynski wrote:

I am working on a port of WebKit on Qt to a PowerPC platform.   
Please make sure that we don't break the Qt port in this switch.  I  
am comfortable with autotools, so that is not a big deal for me.  I  
am concerned, however, that this will cause a fork with the work  
being done by the Trolltech folks (since I think that they are  
primarily qmake-promoters).


Can we get some feedback from Trolltech on their ability to accept  
a switch to autotools for Webkit/Qt so we can switch to one new  
engine for all these ports?


It would obviously be great if build systems could be shared between  
ports, but at the same time I don't think that this desire to share  
build systems should introduce obstacles to the adoption of WebKit  
ports in the wider open source community.  The maintainers of the Qt  
and wxWidgets ports have a desire to keep their build systems  
similar to those used by the underlying toolkits of their port as it  
greatly simplifies their integration work.  The same is true of the  
Apple ports and their build systems.


While the introduction of another build system would introduce  
slightly more overhead for changes that require modifications be  
made to the build system, such changes are relatively infrequent and  
are typically simple additions or removals of files.  The extra work  
required would be small in comparison to the benefit that the GTK+  
port would gain from using a more native build system.


As someone who adds and removes files frequently, I do find the build  
system proliferation to be a nontrivial cost. However, I think the  
worst build systems from this point of view are ones that aren't  
easily human-editable, which I think is mainly the Xcode and Visual  
Studio project files. If we add more build systems, it would be really  
helpful to put up a page that tells you what steps you should take if  
you add or remove files. Maybe we could even write a script to add a  
file to or remove a file from all build systems.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving away from qmake

2007-11-13 Thread Maciej Stachowiak


On Nov 12, 2007, at 1:26 PM, Timothy Hatcher wrote:

We could add a script that would add/remove/rename files in all the  
project files for the various build systems.


Yeah, that's what I had in mind, more than a meta-build-system. If we  
had that, it would remove 90% of the pain of multiple build systems.  
Adding new generated source files could still be an issue, though.


Cheers,
Maciej



On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote:


Kevin Ollivier [EMAIL PROTECTED] wrote:


[...]  The tricky part AFAICT would be XCode, though, because
even if there is a scripted solution for this, it would probably  
need

to be run on a Mac where we have access to AppleScript or some other
scripting tool that can read and make changes to XCode projects...
[...]


Xcode project files are plain text as well.  It's possible to  
update them via
script (see WebKitTools/Scripts/sort-Xcode-project-file), but it  
requires a

little more insight than just staring at the source.


— Timothy Hatcher


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Origyn BAL abstraction for WebKit: branch request

2007-11-13 Thread Maciej Stachowiak


On Nov 12, 2007, at 3:03 AM, Jean-Charles VERDIE (Pleyo) wrote:


Dear webkit stakeholders

Back in july, Pleyo announced a new port of Webkit, not onto a  
specific platform but over an Abstraction Layer that we called OwBAL  
and which lets us address specific needs which do not perfectly fit  
with the platform approach. Actually, our goals are to be able to  
adapt WebKit not to a platform, but a set of libraries which can be  
all-but-one identical, or completely different, or whatever.  
Platform approach makes sense when porting to a comprehensive  
environment, but it does not address our needs. So that platform  
made big parts of the code redundant for us.


Today, our abstraction code is almost mature and we'd like to move  
it back to webkit.org. I believe that since our changes are quite  
intrusive in many parts of webcore, jscore and platform, a branch  
could be a good start where we could put the code so that we can  
start advocating some (if not all) of our changes to eventually end  
up being part of webkit trunk.


Can anyone tell me how to process?


I am ok with this in principle. However, in general, being on a branch  
doesn't align you with the project as closely as staying in sync with  
the trunk. In particular, there is still the risk of ending up  
diverging from the core. In particular the S60 port may take a long  
time to merge up to a more modern baseline. Still, it is probably  
better to be on a branch in webkit.org than in a completely separate  
repository, in terms of code sharing and communication.


Are there any other opinions? Besides being a meta-port, what specific  
platforms and libraries does your version of WebKit target?


Does anyone working on OWB already have SVN access?

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Re: ProjectVision

2007-11-23 Thread Maciej Stachowiak


On Nov 23, 2007, at 9:31 AM, Alp Toker wrote:


http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diffversion=1

Please revert this change until the topic has been discussed on the  
mailing list or bug tracker. You can't just make up a project vision  
like that.


I don't think this page is meant to represent an opinion of the whole  
project, but rather a set of requests from the QtWebKit developers  
from the project as a whole. I think it would be a good idea to  
discuss the substance of the requests on the mailing list. I have  
already discussed some offline with Lars and George. Are you guys up  
for discussing these topics by email? I am also happy to discuss  
further off-list.


It would be great if the Qt developers could also make more use of  
the bug tracker and allow for peer review from the wider WebKit  
team. Unilateral commits by Qt guys have broken other builds  
recently wasting everyone's time.


Actually, I'm somewhat concerned as well about the QtWebKit work  
drifting away from the core somewhat. Doing work primarily in a  
separate repository and then pushing changes upstream creates a  
situation where the Qt developers communicate less with the rest of  
the project, and makes other developers less aware of their changes.  
It also means more distance from project infrastructure like the  
buildbots.


Qt guys, is there anything we could do to make it easier for you to  
work directly in the webkit.org repository?


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Objective-C API: What would you change?

2007-11-26 Thread Maciej Stachowiak


On Nov 24, 2007, at 8:10 PM, Alp Toker wrote:

We've started re-modelling the WebKit/GTK+ public API on the WebKit  
Objective-C API, since it's closer to GTK+ conventions than our  
existing API (eg. WebView vs Page).


Going through the headers and documentation, I sometimes notice  
concepts that don't quite match up with the state of WebCore or  
appear redundant.


Any specifics?

I'm wondering what the developers and users of the current API would  
do differently if they could re-write it today without any  
consideration for backward compatibility.


What would you change? What's obsolete? Any poorly named methods?


If we had the chance to do it over again:

- I would remove WebDocumentView and subclasses,  
WebDocumentRepresentation and subclasses, and WebFrameView from the  
public API, and just put the relevant methods on WebFrame with the  
option to test for certain capabilities that may only be present  
conditionally (such as ability to convert to string). This is what was  
done in the COM API. This is probably the biggest needless complication.


- I probably wouldn't expose WebArchive and WebResource in quite the  
same way.


- It's also possible the design the API to not have WebFrame be a  
heavyweight object, but just an identifying token, with all the real  
API on WebView. However WebView already has a huge number of methods,  
so it's probably sufficient to give good convenience wrappers for  
common operations at the WebView level.


- I wouldn't directly expose objects relating to specific network APIs  
since this makes things hard to change later.


That's the main things I can think of. I bet Darin has more.

You didn't ask, but some things I like include:

- The main object you interact with being a view
- ObjC DOM API that reflects the DOM specs, something special-purpose  
and handwritten would be harder to maintain
- The sets of delegate methods provided (corresponding to signals in  
other ports probably).


What parts do application developers have the greatest difficulties  
with?


I don't think there is that much API confusion. The bits I have seen  
are mostly about interfacing to stuff inside the engine, like the way  
to talk to scripting.


Would you have included more default behaviour, forced application  
developers to implement more policy, or is the balance just right?


I think the Mac port does a pretty good job of striking the right  
balance. The only problem is that the default behaviors we chose are  
designed to make sense in a browser, and you have to do work to  
override them for less browsery uses like a mail or IRC client. Not  
sure how to fix this, though.


This information should help the GTK+ port and others avoid making  
the same mistakes.


I bet Darin has more thoughts on this topic.

Cheers,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Comments on ProjectVision document

2007-11-29 Thread Maciej Stachowiak


On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:

I would prefer a discussion on the mailing list. I think it's  
important that
everyone contributing to the project can state it's opinion and hear  
all

arguments.


Sounds good to me.

Here's some parts I can comment on briefly:


Commit and review rights


I agree that we should have a fair and open policy on commit and  
review rights. Notwithstanding Alp's remarks that Apple has been  
reasonable in administering this, I think open source projects thrive  
on openness. I'm hoping we can improve the situation soon. One thing  
we are working on now is putting together a complete list of current  
committers anr reviewers to publish on the wiki.


Project planning should become more transparent. The mailing list  
should be used for larger discussions or decisions that affect all  
platforms, to give all involved parties a chance to comment.


I agree that large changes should be discussed on the mailing list.  
I'll try to post information about Apple's near to mid term feature,  
performance and architecture goals for the project to inform everyone  
and for discussion.


* Platforms need to have an idea of when to expect the next stable  
WebKit version.

* Releases should be time based.
* Release schedules and a (loosely defined) roadmap should be  
discussed and agreed upon inside the community.


These requests are pretty challenging to meet. We have a few  
conflicting constraints:


1) Currently more than half of development, and probably a bigger  
proportion of core cross-platform work, is done by Apple engineers.  
Also, most dogfood testing is currently done on the Mac platform via  
nightlies. That means it is strongly advantageous to be relatively in  
sync with Apple's release cycles; otherwise we'll be forced to do  
stabilization and feature development based on Apple product cycle in  
a vendor branch instead of on trunk. I think that would be a bad thing  
for the project as a whole, since Apple's Safari releases would end up  
out of sync with project releases.


2) Apple's general policy is to not comment on future product  
releases, either dates or features. For the WebKit open source  
project, it is obviously important to have shared discussion of the  
overall roadmap. So we finesse this by discussing plans and roadmap in  
general, and not details of the timetable.


3) As more organizations and companies ship WebKit-based products,  
there will be more different vendor release cycles to consider.


I can tell you that Apple's drive for stable WebKit releases is likely  
to become more frequent now that Safari 3 is out, and we are unlikely  
to see a gap as big as the Safari 2 -- Safari 3 gap for the  
foreseeable future.


We'll probably have to evolve our approach over time.

* The webkit.org/blog should aggregate the blogs of all contributors  
(Surfin' Safari and blogs of external contributors)


I think I'd like to keep Surfin' Safari as a blog for WebKit  
contributors where we also post occasionally Apple-focused info, and  
where any significant contributor is welcome to post. But I think we  
should add a planet.webkit.org type aggregator which includes Surfin'  
Safari and other WebKit contributor blogs.



* The main webpage and the navigation bar should be platform agnostic


I think the main page mostly is. Many of the pages linked from the  
sidebar have Mac or Safari specific info. However, that's not a matter  
of policy but just happens to be what the pages started with. The  
content is all in SVN and we welcome patches to add build info for  
other platforms. If we get enough different platforms maybe we can use  
a tab approach to split out instructions that are different per- 
platform.


* Safari specific things should go in a subpage (with a prominent  
link form the main page)


Is there anything on the main page that you consider Safari-specific?


* A free use WebKit logo would be great to have


I agree; I'm not a huge fan of the current one. We're thinking of  
having a design contest, I expect Adam will be starting some  
discussion about this.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Apple's feature and performance goals for WebKit

2007-11-29 Thread Maciej Stachowiak


In the spirit of greater openness, here are some of the general areas  
where Apple is interested in improvement in the near to mid term, in  
no particular order:


- Major JavaScript performance improvements. JavaScriptCore improved a  
lot since the Safari-3-stable branch; we think this is an important  
area for continuing improvement. We've already had a lot of non-Apple  
contribution here and welcome more.


- Support for offline web applications. We have local SQL storage now.  
We're also interested in many of the other evolving HTML 5 and Web API  
features for this.


- Better compliance to specifications including CSS 2.1,  
XMLHttpRequest, and so forth.


- Improvements to rich media integration (you can see this with the  
recent HTML5 video and audio support).


- Improvements to graphics, including more complete support for SVG  
and for new canvas features from HTML5 and other browsers.


- Continuing to push the envelope with CSS, with experimental support  
for advanced CSS features.


- HTML5 support generally, as the spec becomes more complete.

- Support for features of interest to web developers.

- Memory footprint improvements.

- Support for more advanced Web API specs of interest, such as  
possibly Selectors API or XMLHttpRequest v2.


- Continuing web compatibility improvements.

- Additional performance improvements to page load speed.

 We may post more details about some of these soon. I'm curious what  
is of interest to other WebKit contributors. I'm especially interested  
in areas where particular organizations or individuals might be  
interested in directly contributing.


It might be worth collecting this kind of data on a wiki page.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Calling all WebKit bloggers

2007-11-29 Thread Maciej Stachowiak


On Nov 29, 2007, at 12:17 PM, Robert Błaut wrote:


On 11/29/07, Adam Roben [EMAIL PROTECTED] wrote:

Hey everyone-
I'm starting to work on setting up a blog aggregator at
http://planet.webkit.org/ and am looking for a set of blogs to  
seed it

with. If you have a blog that you'd like included, please send me an
email at [EMAIL PROTECTED] with the URL of the feed you want
aggregated. WebKit-specific category feeds are preferred over general
ones. Thanks!


It's great to hear that official Planet Webkit is creating now :) I've
prepared to set up a sort of unofficial Planet Webkit on webkit.pl
domain but it's currently pointless ;) So I want to share a part of
my Venus (http://www.intertwingly.net/code/venus/) config file with
blog URLs I've collected so far. I hope it will be helpful:


We should probably limit it to blogs by people who consider themselves  
WebKit contributors. I would guess currently some KHTML developers do  
not think of themselves that way at all (for example Maks, although  
he's a great guy and maybe we will win him over someday).


Cheers,
Maciej




[http://webkit.org/blog/feed/atom/]
name = Surfin' Safari
blog = 1

[http://www.atoker.com/blog/feed/]
name = Alp Toker
blog = 1
filter = webkit|kthml

[http://labs.trolltech.com/blogs/feed/atom/]
name = Trolltech Labs
blog = 1
filter = webkit|khtml

[http://zrusin.blogspot.com/feeds/posts/default]
name = Zack Rusin
blog = 1
filter  = webkit|khtml

[http://bdash.net.nz/blog/feed.atom]
name = Mark Rowe
blog = 1
filter = webkit

[http://www.kdedevelopers.org/blog/278/feed]
name = Allan Sandfeld Jensen
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/1088/feed]
name = Nikolas Zimmermann
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/1089/feed]
name = Rob Buis
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/105/feed]
name = Adam Treat
blog = 1
filter = webkit|khtml

[http://www.kdedevelopers.org/blog/11/feed]
name = Maksim Orlovich
blog = 1
filter = webkit|khtml

[http://blog.justinhaygood.com/feed/]
name = Justin Haygood
blog = 1
filter = webkit|khtml

[http://zecke.blogspot.com/feeds/posts/default]
name = Holger Freyther
blog = 1
filter = webkit|khtml

PS. Adam, sorry for duplicate :(
--
Regards
Robert Blaut
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Apple's feature and performance goals for WebKit

2007-11-29 Thread Maciej Stachowiak


On Nov 29, 2007, at 3:16 PM, Nicholas Shanks wrote:


On 29 Nov 2007, at 10:56, Maciej Stachowiak wrote:

We may post more details about some of these soon. I'm curious what  
is of interest to other WebKit contributors. I'm especially  
interested in areas where particular organizations or individuals  
might be interested in directly contributing.



In reply to Maciej's goals email, I thought more about the features  
I would like to see in WebKit that are not there for one reason or  
another, and would like to know how best to add these on a  
conditional basis such that normal users can remain oblivious, and  
power users can customise them. For example, an API for Safari,  
NetNewsWire, Sandvox c. to hook into, or user defaults that apply  
to all WebKit clients without the app needing to support them  
explicitly. In the case of the latter, how should the defaults be  
named?


Things I would like to see (new features and high priority bugs)  
include…


• Fixed support for :last-child, :nth-child and related selectors.  
This is probably the biggest issue.


I agree with complete support for Selectors as a goal. I don't think  
this needs to be conditional in any way. One thing that is important  
is to make sure that support is added in a way that is performant and  
properly handles dynamic updates, so we don't set ourselves up


• Support for better typography, including kerning, automatic  
ligatures, true (AAT/OpenType) Small Caps, font-stretch, c.  (this  
can be a pref—off by default, if Apple prefers performance to  
presentation. As I have a fast computer i don't really care about a  
few milliseconds here or there during layout, i spend much longer  
reading the text than i spend waiting for it to be drawn. Maybe  
there should be browser engine tests that examine how easy the  
screen is to read.)


We're interested in investigating ways to get better typography  
without as much or possibly any perf hit. I'd agree with this as a  
goal. I guess I should have mentioned typography and text support, and  
I think our @font-face support shows our commitment there.


• Support for the link navigation elements in HTML headers and an  
API to be exposed with Safari implementation.


The DOM API is sufficient for WebKit clients to implement this if they  
choose to. Having this as a UI feature in Safari is not a WebKit  
request so I can't comment on that.


• Alternate stylesheets automatically offered with Safari interface  
for switching between them  (will require API for other WebKit  
clients)


The DOM API exposes alternate stylesheet switching. As for the Safari  
UI feature request, again, this is not the place.


• Allow user disabling of horrible/clueless author stylesheets   
(will require API)


Again, already possible at the API level, UI requests should go to the  
relevant browsers.


• A means by which to inject CSS and JavaScript into sites I visit,  
and have those modifications remembered across sessions.


Same thing - I think the needed API is there, can't comment on it as a  
UI request.


• A means by which to disable quirks mode for text/html (i would  
like this to be a persistent pref)


That does not make sense to me. What possible reason would there be to  
show a quirks mode page in standards mode? Standards mode pages  
already do not trigger quirks mode. But if you really want this at the  
API level, you can do it by preprocessing incoming HTML to force a  
standards mode doctype.


• A means by which to disable marquee, applet or other arbitrary  
things


Applet can be disabled by turning off Java. marquee can be  
(effectively) disabled with a user stylesheet.


• Ability to right-click on an element and remove it from flow  
(probably by adding a display: none attribute; so the DOM tree is  
intact)


The API capabilities needed for this are there. Can't comment on it as  
a UI feature request.


• Ability to customise one's HTTP headers manually, especially the  
Accept-* ones  (another persistent pref)
	• and further, the ability to specify what headers would be  
automatically sent in response to a 3xx code


This capability exists at the API level (ever request is sent to the  
ResourceLoadDelegate before hitting the net). Can't comment on it as a  
UI feature request.


• When rendering a web page aurally, the page should go through a  
series of xslt transformations: (HTML to) XHTML to SSML,  which  
would then either be sent to a third party TTS (e.g. swift from  
cepstral.com) or further transformed to PlainTalk + Applebet and  
sent to the Speech Manager.


I think the current VoiceOver architecture works fine for rendering  
web pages aurally, or at least, any specific issues could be addressed  
based on the existing architecture. I'm not sure what the basis for  
your request is.



And a developer-only feature:
• A means by which to manipulate the current media to something  
other than screen (e.g. for previewing tv, handheld, print

Re: [webkit-dev] Apple's feature and performance goals for WebKit

2007-11-30 Thread Maciej Stachowiak


On Nov 30, 2007, at 12:27 PM, Rob Napier wrote:

On Nov 29, 2007 8:59 PM, Nicholas Shanks [EMAIL PROTECTED]  
wrote:

On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:

 • Ability to right-click on an element and remove it from flow
 (probably by adding a display: none attribute; so the DOM tree is
 intact)

 The API capabilities needed for this are there. Can't comment on it
 as a UI feature request.

I thought contextual menus were handled by WebKit. Again, this isn't
something that should only be in one client app, but ought to be
everywhere HTML is rendered, so that the user experience is consistent
and the feature doesn't get mis-implemented or simply left missing
from some client.

As a developer using WebKit, I definitely don't want my rendering to  
magically change just because the user wanted to change something in  
Safari. Some of the places I use WebKit aren't obviously HTML to  
the user (in an IM chat window for instance), so the fact that we  
would then render incorrectly would be exceedingly confusing.  
There's no way he would think oh, that's a WebKit configuration I  
made. I'm very appreciative that WebKit keeps this stuff out of the  
Framework so my non-browser apps don't become dependent on Safari or  
any other web browser.


The WebKit API on Mac provides some built-in context menu items, but  
gives applications full customization over the context menu items. So  
you can either add custom context menu items, for instance to add the  
feature Nicholas wants, or remove existing items.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] New open committer and reviewer policy

2007-11-30 Thread Maciej Stachowiak


See announcement here: 
http://webkit.org/blog/146/new-open-committer-and-reviewer-policy/
And document here: http://webkit.org/coding/commit-review-policy.html

We'll try to get mailing lists for reviewers and committers set up as  
fast as possible and would like to use this community-driven policy to  
choose all future committers and reviewers.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] XML Events in WebKit

2007-12-07 Thread Maciej Stachowiak


On Dec 7, 2007, at 8:53 AM, Antoine Quint wrote:


Hi,

On 7 déc. 07, at 17:38, David Hyatt wrote:


Yeah, they don't seem particularly compelling to me either.

If someone does implement these, they should put the implementation  
behind an #ifdef so that those projects that aren't interested in  
them can turn them off.


XML Events basically come in handy when you want a generic markup- 
based way to add event listeners for custom events. For instance, if  
XBL was implemented in WebKit, and I had my own custom magic UI  
control implemented with some custom XML element, I'll likely want  
to fire custom DOM Events, and XML Events would be a neat way for  
users of my widget to listen to some of these custom events without  
resorting to a purely script-based approach using addEventListener().


XML Events doesn't seem terribly compelling to me, because event  
handling about running script, so avoiding use of script to define  
event handlers isn't hugely compelling. And on the other hand, it's  
much more verbose for very simple cases than onkeypress/onclick/ 
etc style event listener attributes.


Furthermore, the current trend among web developers is to attach all  
event handlers separately in script (unobstrusive JavaScript), so  
XML Events seems to be going in the wrong direction by putting more  
event listeners back in the markup.


It's a lot of ifs, but if WebKit ever supports XBL and custom DOM  
Events, then it'd be worth re-thinking the usefulness of XML Events  
in WebKit.



I think XBL bindings could support onwhatever style attributes if they  
want to make simple cases easy for their custom events.


Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Sending custom elements over the wire (was Re: [webkit-dev] XML Events in WebKit)

2007-12-09 Thread Maciej Stachowiak


Getting marginally off-topic for webkit-dev, but I don't mind having a  
bit of general web standards discussion here...


On Dec 8, 2007, at 8:05 AM, Antoine Quint wrote:


On 8 déc. 07, at 01:14, Ian Hickson wrote:


On Fri, 7 Dec 2007, Antoine Quint wrote:


XML Events basically come in handy when you want a generic markup- 
based way to
add event listeners for custom events. For instance, if XBL was  
implemented in
WebKit, and I had my own custom magic UI control implemented with  
some custom

XML element, [...]


...then you shouldn't be sending it over the wire, so it shouldn't
matter... (You shouldn't send custom, aka proprietary, vocabularies  
over
the wire, since you have no way to guarentee the end user can  
handle it.)



We're drifting away from the original topic a bit, but I'm wondering  
if such a statement would jeopardize the validity of the existence  
of XBL, or if you see XBL as a technology for standalone, browser- 
based application? Personally, I see no big problem using custom  
grammars when XBL is available on the client.


XBL is a better solution than today's de facto approach to custom  
elements, div class=something plus after-the-fact script hooks. It  
lets you avoid having semantically neutral div elements in the case  
where you want to make a custom widget that basically acts like an  
existing element with known semantics. For example, when making a  
custom button or checkbox with XBL, it's clearly better to bind to  
button or input type=checkbox respectively than to div  
class=button or div class=checkbox.


However, sometimes it is useful to package behavior and presentation  
that doesn't sensibly correspond to the semantics of any existing  
standard element. One example of this would be a tri-state checkbox.  
But it's likely there will always be application interaction elements  
that can't reasonably be expressed as a fancy version of a well-known  
control.


In this case you'll still have the option of div with a special  
class. And it is also technically feasible to use XML to bind to a  
custom element in the HTML namespace, or in XML a custom element in a  
custom namespace. I am not sure there is a material difference among  
these options. In each case there are no predefined semantics being  
expressed. But semantics could be added through widespread convention,  
as with microformats.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] XML Events in WebKit

2007-12-09 Thread Maciej Stachowiak


On Dec 7, 2007, at 7:02 PM, Raj Kiran Talusani wrote:


Guys,

thanks very much for all the comments. let me be more specific about  
my problem.


i want to add multimodal capabilities to the webkit. I want to  
trigger (or communicate with) an external app based on events  
happening in the xhtml document. Also i want to insert custom events  
into the XHTML context based on results from the external process.  
Is there any way i can do this with current version of webkit. any  
pointers on what needs to be done?


Are you working with the Mac OS X WebKit API? If so, you can use the  
Objective-C DOM API to attach native event listeners, and to inject  
custom events. Alternately, you can use the Objective-C JavaScript  
bindings to export a custom native object to JavaScript, and call that  
from event listeners defined in script or using onxxx handlers. You  
could also use the JavaScript bindings to call JavaScript functions  
that dispatch custom events.


Which way works better will depend on the details of your application.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] some WebCore::String plans

2007-12-18 Thread Maciej Stachowiak


Mostly sounds good.

On Dec 18, 2007, at 10:51 AM, Darin Adler wrote:

The WebCore::String class needs some work. I have some plans to  
improve it. Here's an outline of what I have in mind.


immutability
- eliminate all non-const functions from StringImpl; fixes tricky  
sharing semantics
- change all uses of const StringImpl* to just plain StringImpl*  
because there will no longer be any real difference between these  
types
- then, once RefCounted is made thread-safe, then we could remove  
the copy() function altogether, since the only reason to use it  
would be thread safety


ownership
- change functions that return StringImpl* to return  
PassRefPtrStringImpl instead, if they sometimes make a new object;  
makes it harder to accidentally leak
- change functions that take StringImpl* to take  
PassRefPtrStringImpl instead if they take ownership; can reduce  
reference count churn
- make a release() function on String that returns a  
PassRefPtrStringImpl; can reduce reference count churn


clarity
- eliminate functions that return a StringImpl* from StringImpl,  
because it's to easy to misunderstand and think these modify the  
string in place
- eliminate functions that return a String from String -- also easy  
to use wrong for the same reasons


Where would we put functions that take a string and return a modified  
one? Seems like we'll still want those, if our string type becomes  
truly immutable.




performance
- change TextStream into a class named StringBuilder for clients  
that are building up strings (name inspired by Java); it will have  
get() and release() functions that will return PassRefPtrStringImpl


I kind of like the += syntax for a StringBuilder better than the   
syntax, but I guess that's harder to use if there's no operator+. It  
seems like the obvious implementation techniques are making a  
VectorUChar and appending to it, or keeping a VectorStringImpl,  
neither of those would play well with a non-releasing get().


- add functions that take a PassRefPtrStringImpl and return a  
PassRefPtrStringImpl for many string operations, since those can  
optimize the only one reference case and re-use the same character  
buffer; change the String class to use those as appropriate
- rename the String::impl() function to String::get() to match other  
RefPtr classes
- consider eliminating String and using RefPtrStringImpl at most  
or all call sites
- consider changing call sites that take a const String to instead  
take StringImpl* or PassRefPtrStringImpl


names
- rename StringImpl to SharedString
- consider renaming WebCore::String to StringRefPtr since it's a  
lightweight wrapper around a RefPtr; one benefit is that it would  
allow us to eliminate the header name PlatformString.h


If you did both of those things, a better name for SharedString might  
be String.




These plans are still a bit rough. Please let me know what you  
think. Depending on what feedback I get, I might make a Wiki page  
about this.


Some of this I will do soon. Some of it is longer-term.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Pulling together on WebKit Mobile

2008-01-14 Thread Maciej Stachowiak


On Jan 14, 2008, at 3:48 PM, [EMAIL PROTECTED] wrote:


Dear WebKit Team,

Going back to the original topic (Pulling together on WebKit  
Mobile)


Wake3 has a working version of WebKit for Windows Mobile.  We  
definitely
want to contribute back to the community.  We posted earlier about  
this,

but didn't get much of a reply.

For more information on Wake3, see the video demo on our website at
www.wake3.com.  We also gave a live demo at a recent Silicon Valley  
Mobile
Monday event (see our presentation at http://www.mobilemonday.us/?p=188) 
.

We are planning a public Beta in the next few months and we plan to
release source then.

My main concern is to make sure Windows Mobile code is part of the  
main
trunk, and not a side branch.  My recommended first step to make the  
trunk

more Windows Mobile friendly is to update the Windows version to build
without requiring proprietary Apple libraries.

How does the community feel about this?

Last, we will be at the Mobile World Congress (formerly 3GSM Congress)
next month in Barcelona.  Send email if you want to meet up and see a
demo.


We might need to have two different versions of the WIN platform.  
I'd be ok with changing the name of the one based on Apple libraries  
if appropriate.


 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: Communication (was Re: [webkit-dev] Pulling together on WebKit Mobile)

2008-01-15 Thread Maciej Stachowiak


On Jan 14, 2008, at 8:02 PM, Adam Roben wrote:


Oliver Hunt wrote:

On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:


The best and easiest way to discuss this would be on IRC in the
#webkit channel of
freenode...


Sure, but it seems tough to get a time when everyone interested is  
on.

Should we set a time to discuss this?


I think you'd be safe anywhere between 2pm and 10pm PST, although  
that's
only an educated guess based on my recollection of when GTK, QT,  
and Apple

folk are around.


It's been mentioned (by some of the Trolltech folks, I believe) that  
using IRC so exclusively for communication not only makes it very  
easy for information to be lost into the aether but is also  
difficult for those not operating on California (or US) time.  
Perhaps we should be making an effort to have more of our  
discussions take place on webkit-dev, at the very least in the cases  
where they originate on webkit-dev as well?


We could also consider logging the IRC channel. This is something I've  
been hesitant to do before, but it makes asynchronous participation  
easier, and that's important as we span more time zones and get more  
people involved in the project part-time.


Cheers,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bit field error on wince

2008-01-22 Thread Maciej Stachowiak


On Jan 21, 2008, at 10:35 PM, ledwinka wrote:

During my work on porting s60 webcore to wince, I found there is a  
css bug

in render_style.h file, here is the struct define


You're probably better off basing a port on something more recent  
(like trunk or the Safari 3 branch) since many windows platform/ 
compiler issues like this have already been resolved.


 - Maciej




   struct NonInheritedFlags {
   bool operator==( const NonInheritedFlags other ) const {
   return (_effectiveDisplay == other._effectiveDisplay) 
   (_originalDisplay == other._originalDisplay) 
   (_bg_repeat == other._bg_repeat) 
   (_overflow == other._overflow) 
#if NOKIA_CHANGES
   (_inputRequired == other._inputRequired) 
#endif
   (_vertical_align == other._vertical_align) 
   (_clear == other._clear) 
   (_position == other._position) 
   (_floating == other._floating) 
   (_table_layout == other._table_layout) 
   (_page_break_before == other._page_break_before) 
   (_page_break_after == other._page_break_after) 
   (_styleType == other._styleType) 
   (_affectedByHover == other._affectedByHover) 
   (_affectedByActive == other._affectedByActive) 
   (_affectedByDrag == other._affectedByDrag) 
   (_pseudoBits == other._pseudoBits) 
   (_unicodeBidi == other._unicodeBidi);
 }

   bool operator!=( const NonInheritedFlags other ) const {
   return !(*this == other);
   }

   EDisplay _effectiveDisplay : 5;
   EDisplay _originalDisplay : 5;
   EBackgroundRepeat _bg_repeat : 2;
   EOverflow _overflow : 4 ;
#if NOKIA_CHANGES
   bool _inputRequired : 1 ;
#endif
   EVerticalAlign _vertical_align : 4;
   EClear _clear : 2;
   EPosition _position : 2;
   EFloat _floating : 2;
   ETableLayout _table_layout : 1;

   EPageBreak _page_break_before : 2;
   EPageBreak _page_break_after : 2;

   PseudoId _styleType : 3;
   bool _affectedByHover : 1;
   bool _affectedByActive : 1;
   bool _affectedByDrag : 1;
   int _pseudoBits : 6;
   EUnicodeBidi _unicodeBidi : 2;
   } noninherited_flags;

On wince platform , any code access to bit field in this struct ,  
such as


EDisplay _effectiveDisplay : 5;

will produce asm code like this

EDisplay dis = noninherited_flags. effectiveDisplay;

mov r3 lsl #27
mov r3 asr #27
str r3 [sp]  // write to stack variable

this problem is the ASR instruction. If _effectiveDisplay contain a  
value
big than 0x0f, such as 0x1x, the ASR instruction will cause the high  
bits
fill with 1 , for example, if _effectiveDisplay equal EDisplay::NONE  
or

EDisplay::INLINEBOX,  EDisplay dis will EQUALS -14 or -13, not a valid
value.

How to solve this problem? thanks a lot!



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Fwd: [whatwg] postMessage support now in Firefox trunk, implementation issues, feedback, tests

2008-01-30 Thread Maciej Stachowiak


Jeff Walden mentioned on IRC that some of the tests mentioned below  
fail in WebKit TOT and seem to show cross-domain postMessage not  
working (I suspect it's failing security checks for some unrelated  
reason). Can someone (ideally someone who understands postMessage)  
please try these? I'm afraid the steps are a little complicated.


I'm also curious if the PAC file approach would be a viable way to do  
cross-domain security testing more generally (it is able to test  
different subdomains and ports unlike our current approach).


Begin forwarded message:


From: Jeff Walden [EMAIL PROTECTED]
Date: January 29, 2008 10:36:51 PM PST
To: [EMAIL PROTECTED]
Subject: [whatwg] postMessage support now in Firefox trunk,  
implementation issues, feedback, tests

Reply-To: [EMAIL PROTECTED]

https://bugzilla.mozilla.org/show_bug.cgi?id=postMessage

I just landed HTML5 postMessage support in Firefox, so it should be  
in Firefox 3!  Thanks to WebKit people for pushing on this, because  
I didn't think this had a chance of making 3, to be utterly honest,  
having tried once before several months ago.  To be honest, I'm  
still in a state of shock this got taken.  :-)



First:

I strongly encourage all implementers of postMessage to compare how  
they do against the set of tests (for both postMessage and  
MessageEvent functionality) that I wrote during implementation of  
postMessage.  I made special efforts not to do any Mozilla-specific  
testing without a user-agent guard, and I don't believe there are  
any unguarded Mozilla-specific tests any more -- and to an extent  
nothing not specified by HTML5 or otherwise commonly implemented,  
more or less.  There's significant bustage against the tests in the  
user agents I tested even on basic functionality, to the extent that  
the API's not usable for what it was intended due to incorrect  
errors being thrown on access and such.  (I've guarded against these  
problems in the tests with try/catches and sentinel timeout checks  
when there's no other way to communicate a failure).  The tests are  
available here:


http://web.mit.edu/jwalden/www/whatwg/postMessage.zip

To run the tests, extract them somewhere on your hard drive and  
start an HTTP server on port  serving the postMessage/ folder as  
its root folder.  Make sure that your server will serve .xhtml files  
with the XHTML MIME-type -- a couple tests use it because I was too  
lazy to use external files for scripts and wanted to include special  
characters literally (or wanted to test specific Unicode-related  
handling).  Next, set up proxy autoconfig in your UA to point to http://localhost:/proxy.js 
.  Now navigate to:


http://localhost:/tests/dom/tests/mochitest/whatwg/

From there click the Run tests link to see how you do.  For  
individual test results, see the individual test links.  Be very  
careful when you run these -- the uri-checking hard-codes URIs  
instead of using something like location.href in the interest of  
robustness against colluding failures, so running with, say, a  
stray hash or question mark at the end of a page URL will usually  
cause that test to fail.


I spent a lot of time on these tests, and I'm not aware of any bugs  
in them, but I'd very much appreciate people reading through them,  
running them, and checking for any errors I might have made, say, in  
not marking a test as Moz-specific or such (subject to the points  
noted below).



Second:

The spec's incomplete or vague on a few points right now.  The  
points I know where I forged new ground or think clarifications/ 
explicit notes may be in order are:


* event.domain/uri values in a rewritten about:blank document
The spec seems to somewhat indicate that we should be using  
about:blank and  as uri/domain right now, but that's fairly  
useless in terms of allowing postMessage in dynamically-created  
pages.  This probably wants to change to reflect the document's  
origin/principal, and assuming things go the way most browsers have  
implemented it, this means those values are the same as for the  
opener of about:blank.  This is tested in  
test_postMessage_special.xhtml.  Note that there are two different  
tests of this behavior which change the document in slightly  
different ways, and Mozilla expects them to have the same results  
right now.


* event.domain/uri values in data: URLs
Mozilla currently gives data: URLs the principal of the opener/ 
parent, so we use that URI for computing uri/domain of messages from  
data: URLs.  The two tests for this are UA-guarded for now as  
behaviors differ across browsers on this, but in the long run  
everyone should come to an agreement on this.


* event.domain with non-standard ports
We have it so domain doesn't include the port number, ever.  The  
spec says this, but it's not absolutely explicit.


* event.domain/uri values for IDN URLs
We use the Unicode-ized values of these, not the Punycode versions.   
(Actually, that's a lie -- 

Re: [webkit-dev] Acid3 status

2008-01-30 Thread Maciej Stachowiak


Hi Eric,

On Jan 29, 2008, at 4:34 PM, Eric Seidel wrote:

Hixie is nearly done with his Acid3 test.  He's said he has space  
for 2 more tests, but is otherwise ready.


Acid3 has certainly found some bugs in WebKit.  WebKit has also  
found bugs in Acid3 (I'm sure we'll find more).


Thanks for classifying the failures. This is really useful! Standards  
compliance and long-term interoperability are important to the WebKit  
project. Acid tests are a fun and productive way to update corners of  
our web standards support that might otherwise not get enough love,  
with some confidence that other browsers will also improve.


Working on Acid3 fixes is a great thing to do, and a fun way to get  
into WebKit hacking for those who have been thinking about dipping  
their toes in.


 - Maciej



Here is a list of all of the failures we currently have, and their  
associated Bugzilla bugs:


Failed 35 tests.
Test 0: expected: pre-wrap, got: normal - found unexpected computed  
style

4812 - :last-child bug
Test 1: method [object NodeIterator].nextNode() didn't forward  
exception

4714 - NodeIterator forwarding exceptions
Test 2: expected: [object HTMLElement], got: null - expectation 13  
failed
Test 4: expected: null, got: [object HTMLIFrameElement] -  
expectation 21 failed
Test 6: expected: [object HTMLTitleElement], got: null - failed to  
handle regrafting correctly

3492 - TreeWalker brokenness
Test 8: Null value
16766 - Range doesn't update on tree modifications
Test 11: when trying to surround two halves of comment: wrong  
exception raised; code = 3

16749 - Range.surroundContents throws wrong exception
Test 13: collapsed is wrong after deletion
16766 - Range doesn't update on tree modifications
Test 18: expected: 10, got: 8 - DOCTYPE nodeType wrong
12751 - DocType nodes aren't part of the document
Test 23: no exception for createElementNS('null', ':div')
16833 - createElementNS doesn't throw enough exceptions
Test 25: failed to raise exception
16693 - createDocumentType does not throw enough exceptions
Test 26: e1 - parent element doesn't exist after looping
Test 27: e1 - parent element doesn't exist after waiting
17076 - Document tree does not survive long enough
Test 35: expected: 0, got: 1 - :first-child still applies to element  
that was previously a first child

Test 36: expected: 1, got: 0 - last child did not match :last-child
Test 37: expected: 1, got: 0 - :only-child did not match only child
5468 - broken :first-child, :last-child, :only-child selectors
Test 38: expected: 0, got: 1 - removing all children didn't make the  
element match :empty

11387 - :empty applies to all elements
Test 39: expected: 1, got: 0 - :nth-child(odd) failed with child 0
6248 - implement :nth-child selectors
Test 40: expected: 1, got: 0 - part 2:7
5468 - broken :first-child, :last-child, :only-child selectors
Test 42: expected: 1, got: 0 - rule did not start matching after  
change

11384 - CSS2/3 child selectors aren't dynamic
Test 44: expected: 0, got: 1 - misparsed selectors
16751 - html* .test {} is parsed as html .test
Test 59: expected: submit, got:  - button doesn't have type=submit
16798 - HTMLButtonElement.type should default to submit
Test 64: expected: ./test.html, got: test.html - object elements  
didn't resolve URIs correctly

16799 - HTMLObjectElement.data should cannonicalize urls
Test 66: expected: null, got: #text - wrong localName
17060 - Text.localName should be null
Test 69: expected: 33, got: 0 - SVGSVGTextElement.getNumberOfChars()  
incorrect

17062 - SVGTextElement.getNumberOfChars returns incorrect value
Test 71: UTF-8 encoded XML document with invalid character did not  
have a well-formedness error

17079 - XML document sent with wrong encoding should fail
Test 72: expected: TITLE (first test), got: TITLE - undefined
17080 - WebKit fails Acid3 HTML parsing test
Test 73: Undefined value
17082 - WebKit fails Acid3 modification of style text block test
Test 74: expected: 10, got: 1 - click event handler called the wrong  
number of times

17083 - Acid3 expects nested event dispatch support
Test 75: getSVGDocument failed for iframe referencing an svg  
document.

17061 - HTMLIFrameElement should have a getSVGDocument() method
Test 76: Value undefined (result of expression anim.beginElement) is  
not object.
Test 77: expected: 0, got: 100 - Incorrect animVal value after svg  
animation.

17077 - SVG Animation is broken (and thus turned off)
Test 78: expected: 4776, got: 5550 - getComputedTextLength failed.
17078 - SVGTextElement.getComputedTextLength does not work as expected
Test 86: calling setMilliseconds() with no arguments didn't result  
in NaN

16753 - Date.set* methods with no arguments should result in NaN
Test 92: Function object's prototype's constructor was ReadOnly
15003 - Function object's prototype's constructor should not be  
ReadOnly

Elapsed time: 4.03s (debug build)

There are also some visual failures:
16760 - HTML Object elements should not render 404 content
16770 

Re: [webkit-dev] Incremental Layout

2008-02-03 Thread Maciej Stachowiak


On Feb 2, 2008, at 4:23 AM, ankush tiwari wrote:


Hi All,

Is there any plan of making webkit render pages incrementally for  
better performance?


WebKit does render incrementally, although normally pending scripts  
block parsing and pending stylesheets block layout and painting until  
a significant timeout has passed, to prevent showing incorrect content.


I'm not sure what you mean by better performance but in general,  
rendering more often will make the total page load take longer,  
although it may be able to render for the first time sooner.


 - Maciej




Thanks,
Ankush.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] whats bidi stand for?

2008-02-03 Thread Maciej Stachowiak


On Feb 2, 2008, at 3:09 PM, Eric Seidel wrote:

That sounds like one vote for renaming that file.   
BidirectionalTextLayout.cpp :)


Or maybe BidirectionalWordSorting or similar.  Mitz and Hyatt are  
two of very few to ever have hacked on that file.


bidi is a pretty common term of art. Also, the code in the file does  
more than just bidi handling, so LineLayout.cpp as Hyatt suggested may  
be the best name. I don't think BidirectionalWordSorting would be  
right - bidi applies at boundaries between right-to-left and left-to- 
right text, which are not directly related to word boundaries.


Regards,
Maciej




-eric

On Sat, Feb 2, 2008 at 1:02 AM, Cameron McCormack [EMAIL PROTECTED]  
wrote:

Hi Bin.

Bin Chen:
 I am reading the source code of webkit right now, I find a file name
 like bidi, I can't know the exact meaning, can you tell me whats  
this

 stand for?

Bidi is an abbreviation for bidirectional text, and refers to  
blocks

of text that use both left-to-right and right-to-left scripts (e.g. a
paragraph with English text that also includes some Arabic text).   
See:


 http://en.wikipedia.org/wiki/Bi-directional_text

--
Cameron McCormack, http://mcc.id.au/
   xmpp:[EMAIL PROTECTED]  ▪  ICQ 26955922  ▪  MSN  
[EMAIL PROTECTED]

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Trunk policy regarding new features and stabilization

2008-02-04 Thread Maciej Stachowiak


Hi Eric,

On Jan 23, 2008, at 11:50 PM, Eric Seidel wrote:

I'd like to get some clarification from other members of the WebKit  
project, regarding the policy regarding having features on/off on  
trunk.  Specifically Apple folks, since they are the largest single  
vendor actively contributing to the WebKit Open Source Project.


I think there's two separate questions here. First, what formal  
policy, if any, do we follow for disabling features or removing code.  
Second, there's the specific question of what to do about  
foreignObject specifically.


Regarding policy:

I think there are a few reasons why a feature might be removed or  
disabled, either permanently or on a vendor's release branch:


1) The feature is so destabilizing that it affects testability, and we  
don't expect it to get fixed soon. This would be a reason to disable  
code on trunk.
2) The feature is relatively minorly unstable but has no clear  
maintainer and may be bitrotting a bit. This might also be a reason  
(though in this case it would be good to ask around first).
3) The feature has some significant problem (stability or correctness)  
that would lead us not to want vendors to ship it in its current state.


In case 3, a case could be made for disabling only on appropriate  
vendor release branches. (On the other hand, if there are many such  
branches we want to encourage them to do the right thing.) On the  
other hand, if no one is actively working on the feature, and no one  
especially objects, it might be ok to disable on trunk.


We don't really have a formal policy on this, we just try to use  
common sense and discussion if there is disagreement.



As for this specific instance:

Oliver Hunt suggested disabling foreignObject. I'm not sure which  
specific problems he was worried about, or which of the above  
categories they would fall in. Oliver, could you please clarify what  
the specific problems with foreignObject are. Oliver  Eric, can you  
please discuss and decide together whether foreignObject should in  
fact be enabled by trunk?


To address some specific questions:

I'm interested in discussing the general policy towards new features  
on trunk and stabilization of trunk during release times for  
various vendors.


This was prompted by my recent discovery that SVG_FOREIGN_OBJECT  
feature had been turned off.  I assume for stabilization  
concerns.  I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=16991 
 about that specific case.


* Is trunk the advised location for all feature development?  At  
what point should a feature be moved off onto it's own branch?
* Is the current policy that there will be times of stabilization  
for the trunk, to match with a certain vendor or set of vendors  
release cycles?
* If a vendor (or group of contributers) wishes to ship from trunk,  
is there a procedure by which they can close trunk to new feature  
development?


Apple has not requested any formal or de facto stabilization period.  
Trunk remains open for feature development, porting, performance work,  
bug fixing, and all the usual good stuff. If we need something more  
stable than trunk we will use branches as appropriate.



My personal preferences would be:
* Trunk is the location for all feature development.  Large features  
which would disturb other development (introduce more than N p1  
bugs, break the build, break patches repeatedly, etc.)


You didn't finish this sentence, but I assume it meant to raise such  
features as a possible exception. Currently I think this is the shared  
understanding of the project.


* Currently there is no policy to enact a time of stabilization  
for trunk, however I think such could make sense if there was a way  
for enough contributers to agree.  Stabilization periods should last  
no more than a month or two, during which time, all feature work  
should continue on a feature branch (similar to last summer, except  
*not nearly so long*).
* I know of no such procedure, but I can see rational for creating  
one.  Without one, my default would be to leave trunk always open,  
unless policies are defined allow for its closure (like perf  
regressions?).


I think the overly long stabilization period on trunk did not work  
out very well and I don't think we should do it again in the near  
future.


I hope this answers your questions.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How to abstract text drag delay and hysteresis

2008-02-21 Thread Maciej Stachowiak

On Feb 21, 2008, at 5:37 AM, Tor Arne Vestbø wrote:

 Hi,

 First of all, this is my first post to the webkit-dev list, so hi
 everyone! :)

 Now...we would like to provide values for text drag delay and  
 hysteresis
 based on Qt defaults. What would be the preferred way of abstracting  
 this?

 Adding #if PLATFORM(QT) in EventHandler.cpp does not sit quite right
 with me, but maybe a global function?

Ideally some code in WebCore/platform should abstract this out. Using  
global functions would be ok.

  - Maciej



 Tor Arne

 -- 
 Tor Arne Vestbø, Software Engineer
 Trolltech ASA, Oslo, Norway
 http://www.trolltech.com/

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Google Summer of Code, Proposal

2008-02-26 Thread Maciej Stachowiak

On Feb 25, 2008, at 11:31 PM, Eric Seidel wrote:

 I think WebKit should consider participating in Google's Summer of
 Code this year.

 To facilitate such, I have created a wiki page, where potential
 mentors, as well as project ideas can be placed:

 http://trac.webkit.org/projects/webkit/wiki/Google%20Summer%20of%20Code%202008

 I have added a couple project ideas of my own.  I have not signed up
 as a mentor due to my status as a Google employee and the clause
 Google employees, interns, contractors, and family members are
 ineligible to participate.  I will have to check if I'm allowed to
 mentor, but based on that statement, I believe not.

I think that statement applies only to student participants, not to  
mentoring organizations or mentors.

  - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Compatibility Hitlist

2008-03-11 Thread Maciej Stachowiak

On Mar 11, 2008, at 4:22 AM, Martin Kerz wrote:

 Hi,

 some time ago I filed a bug concerning the compatibility hitlist ( 
 http://webkit.org/projects/compat/hitlist.html 
  )

 It's completely outdated. As I see it, it should either be removed,  
 because people can get the impression that webkit does not render  
 the listed pages properly, or be updated. In the latter case we  
 would need some candidates for the list.

 Here's the bug report: http://bugs.webkit.org/show_bug.cgi?id=17280

 What do you think?

I agree that it should be removed. It hasn't been maintained and never  
worked so well for focusing energy on fixing compatibility issues. A  
patch to remove it would be welcome.

  - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] interested in js speed-up

2008-03-13 Thread Maciej Stachowiak


On Mar 12, 2008, at 4:57 PM, ToolmakerSteve wrote:



Akos Kiss-2 wrote:


we got interested in speeding up the
JavaScript engine of WebKit.



But, But, the world is moving on to ECMAScript 4 / Javascript 2.  
Does it
make sense to do anything other than to use, and to help improve,  
the open
source Mozilla/Tamarin codebase? That will give you the next  
generation of
functionality AND dramatic performance gains, if you use its tracing  
jit

code branch. Improve that code branch, and everyone in the world wins!


Mozilla and Tamarin are interesting projects that we respect. However,  
we believe that competition is good for the web, and having two strong  
open source web engines is great for the web. For example, the  
competition over JS performance since the release of the SunSpider  
benchmark has result in huge improvements in both WebKit and Gecko.  
Similarly, some have argued that Mozilla should drop Gecko development  
and use WebKit as the layout engine, but the Firefox betas show a lot  
of improvements in memory use and standards support. We do exchange  
ideas with the Mozilla community and sometimes pieces of code, but in  
general we're not looking to replace core parts of WebKit with core  
parts of Mozilla.


Also, while the Tamarin project is an interesting piece of technology,  
let's be careful not to oversell it. Tamarin only provides half of a  
JavaScript engine (the execution engine but not a parser/compiler to  
generate the bytecodes), it cannot yet handle arbitrary JavaScript  
code from the web, and at least the classic version is not  
particularly fast on normal JS, only on typed code (which no one uses  
yet and which is syntactically incompatible with current JavaScript).  
It's true that the tracing JIT branch promises to do reasonably well  
on normal untyped JS as well, but now we're talking about a rewrite,  
not a proven technology.


We'd like to see what we can do with our own technology for now.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How is JSConsole used/accessible in current webkit?

2008-03-18 Thread Maciej Stachowiak

On Mar 18, 2008, at 5:44 PM, Richard Bailey wrote:

 I've been reading through the code and seem to be missing how I can  
 activate JSConsole.

 It is functioning, or disabled in current webkit?

If you use Safari 3.1 with a WebKit nightly, the Web Inspector's  
console will be used as the JS error console.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Document's content type

2008-04-15 Thread Maciej Stachowiak


On Apr 15, 2008, at 12:25 AM, Artem Ananiev wrote:


Hi,

is there any way to find the content type of the Document? I see two  
methods - doctype() and realDocType() - in WebCore::Document,  
however they always return NULL (at least for HTML documents)...


These would give the doctype declaration, not the content type (which  
is sent as part of the http protocol). The content type is stored in  
the ResourceResponse, I believe we keep around the original response  
for a document but I don't recall where off-hand.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Desperate for webkit help

2008-04-16 Thread Maciej Stachowiak


Hi Mark,

On Apr 16, 2008, at 10:32 AM, Mark Pauley wrote:

The bug is in the php tool, not in webkit.  From the RFC (rfc1341 http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) 
:


boundary := 0*69bchars bcharsnospace

bchars := bcharsnospace /  

bcharsnospace :=DIGIT / ALPHA / ' / ( / ) / +  /
_
   / , / - / . / / / : / = / ?

'+' is absolutely allowable, I'm betting that your upload tool  
source has a faulty regular expression for grabbing multipart  
boundaries.  Perhaps what we really want here is a method of  
specifying the multipart boundary to webkit... and so allow all  
manner of hackers to work around parsing issues like this one  
without encouraging people to write crappy parsers.


or, you could grab the webkit source, hack a work-around and ship  
your own webkit dylib embedded in your app.  Let's not go tooling  
with code that works on millions of people's machines because of a  
fault in code that works on thousands of people's machines.


You are correct by the letter of the spec that + is allowed in the  
boundary separator. However, this is not the first time we've had a  
site break in WebKit-based browsers when it worked fine in other  
browsers, due to our choice of boundary characters. Even though the  
spec allows a wide character set, I think it would be wise to limit  
the characters we use to those sent by other browsers, since some web  
developers develop against IE/Firefox and test against Safari as an  
afterthought, if at all.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Does WebKit support 304 Not Modified for Ajax requests?

2008-05-09 Thread Maciej Stachowiak


On May 9, 2008, at 8:50 AM, Scott Schmitz wrote:

I have a web application that makes extensive use of xmlhttprequest  
(AJAX).  I have optimized these GET requests such that the server  
will return a 304 not modified if the ETag matches up from a prior  
request.  That way, if the browser cache already has the data, I  
just send the header back and not the data itself.


This works great for Firefox and Internet Explorer.  In the case of  
those browsers, I return ETag and last modified headers for the  
initial request.  The browser caches the data and includes


If-Modified-Since:
If-None-Match:

headers when it makes a request again.  If the server determined  
that the cache is good, it returns


304 not-modified response and all is good.

WebKit and Safari do not do this.  Best I can see, the browser makes  
its request and does not include any Etag at all.  I see this via  
Web Inspector - Network Panel.


Anyone know what is going on?


We support If-Modified-Since but not If-None-Match when revalidating.  
The best place to file the bug would be http://bugreport.apple.com/  
because it is actually an issue in CFNetwork, the underlying network  
library that WebKit uses (at least on the Mac and Windows ports).


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] -moz-user-focus in webkit?

2008-05-13 Thread Maciej Stachowiak


On May 13, 2008, at 5:08 AM, Johan Lund wrote:


Is there something equivalent to -moz-user-focus in webkit?


In WebKit trunk, you can use the tabIndex attribute on any element to  
add focusability, but I do not think there is a way through CSS, or a  
way to remove focusability.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Integrate postMessage changes to 3.1 branch?

2008-05-15 Thread Maciej Stachowiak

On May 14, 2008, at 11:17 PM, Adam Barth wrote:

 Does it make sense to integrate the postMessage changes to the
 Safari-3-1-branch?  The concern is that someone shipping a port might
 ENABLE(CROSS_DOCUMENT_MESSAGING) and get a significantly out-of-spec
 implementation.  Another option is to rip out the code hiding under
 the #if.

Safari release branches are made for the purpose of Safari software  
updates, so we don't normally make changes that aren't strictly  
necessary for that purpose. If anyone else wants to make a release  
based on a variant of our release branch I guess we should strongly  
warn them against enabling additional experimental features. In the  
past we have not had a problem with vendors copying release branches  
and enabling unstable features, for example things like SVG  
experimental features were in this state in the Safari-3-0-branch.

If there is a serious risk of a significant problem, I would consider  
ripping out the code as an option.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] The SquirrelFish Cometh

2008-05-17 Thread Maciej Stachowiak
Hi Everyone,

Over the past few weeks, a few of us have been working on a major  
reworking of the JavaScriptCore interpreter, code named  
SquirrelFish. This work has been done mainly by Geoff Garen, Oliver  
Hunt and Cameron Zwarich, with help from myself, Sam Weinig, and  
occasional others. The classic version of JavaScriptCore is an AST- 
based interpreter. Although it was highly tuned, and competitive with  
advanced bytecode engines in benchmarks, we could see that we would  
run into the limits of the architecture soon.

So we started SquirrelFish, an incremental rewrite of JavaScriptCore's  
execution logic to convert it into a state-of-the art bytecode VM.  
Most of this work has been done on a branch of the public SVN  
repository, to avoid destabilizing the trunk. We are now very close to  
finishing off the last few blockers. There will be a formal  
announcement to the general public when we are ready, including  
performance data and more details about the internals. But for now I  
wanted to let WebKit insiders know that it is coming.

We are also at the point where we could use testing help to verify  
that SquirrelFish can handle the real-world web. If anyone would like  
to help test, and is willing to get their hands a bit dirty, check out  
http://svn.webkit.org/repository/webkit/squirrelfish.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Staying on edge

2008-05-21 Thread Maciej Stachowiak

On May 21, 2008, at 12:55 AM, Andrei Maxim wrote:

 Hi all,

 I've been working with the latest WebKit mostly because of its ACID 3
 compliance (I'm treating it as the standard rendering of the web pages
 I work on and then adding fixes, where required, for more popular
 browsers), but I'd like to stay on the edge without having to manually
 download the DMG file and then copy the application to the
 Applications folder each time a nightly build is out.

 Is there a way to automate the process like a hidden setting? So far
 I've been using my RSS reader to grab the enclosures from the Mac
 nightly feed, but I still have to mount the image and drag it. Plus,
 this means I have to open my RSS reader *before* my browser and wait a
 couple of minutes till it downloads.

http://web.mac.com/reinholdpenner/Software/NightShift.html

NightShift automatically downloads and updates WebKit, the Safari  
HTML rendering engine, to the latest nightly version. No user  
intervention is required, everything is fully automated.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Cross browser automated tests

2008-05-21 Thread Maciej Stachowiak

On May 18, 2008, at 5:09 PM, Sylvain Pasche wrote:

 Hi,

 I'm working on an experimental project to build a set of cross browser
 automated tests. The idea would be: having a repository of browser
 independent automated tests. Each browser developer could contribute
 tests to it and use these tests for testing their product. Existing  
 test
 suites that could be run in an automated way could be imported into it
 (something that has already been done by Mozilla/WebKit for the dom
 tests for instance). The technical details of the testing environment
 and API would need to be discussed.

 These tests could be run automatically on today's available browsers.
 With the test results published, Web developers could check what  
 feature
 (if covered by tests) are implemented (and to what extent) in a given
 browser.

 What do you think about it? Would there be interest in such a project
 from WebKit?

We'd be glad to include any additional tests generated by the project,  
and certainly anyone is welcome to use our tests.

However, we would also want automated regression tests that continue  
to use our harness, which can check many things automatically that are  
not readily testable in-browser, and which is optimized for speed (so  
it can run thousands of tests in a couple of minutes instead of  
hours). These qualities are important to us, and I am not sure a cross- 
browser test harness can achieve them.

 I started already to extract automated tests from Mozilla and WebKit  
 and
 run them on a set of browsers. I first tried to see what tests are not
 WebKit specific. I considered tests which are using
 layoutTestController.dumpAsText(). For these tests, I can use  
 something
 like document.body.nodeValue to get a text serialization of the  
 document
 and compare it against the -expected.txt file.

nodeValue won't cut it, but innerText or textContent may work (depends  
on the test).



 I ran these tests with a few browsers and published results on
 http://www.browsertests.org/. Note that for WebKit I used the Linux
 GtkLauncher program (some tests made the browser crash). I plan to run
 these tests on Safari Mac/Windows for comparison.

 By the way, Mozilla reftest system [1] is interesting in that project
 because it is a browser independent way of testing the layout engine.
 See pages 8-12 on http://www.browsertests.org/test.

 I also started a thread on a Mozilla group, visible at [2]


 Sylvain

 [1] http://mxr.mozilla.org/mozilla/source/layout/tools/reftest/README.txt
 [2]
 http://groups.google.com/group/mozilla.dev.quality/browse_frm/thread/b2a959c7547b9877/d5705f4f664bab53

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread Maciej Stachowiak

On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori (another gtk
 browser based on webkit), I receive or core dump whenever I click on  
 any
 part of a webpage or try to navigate to another.  After inspecting the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively ()  
 from
 /usr/local/lib/libwebkit-1.0.so.1.0

Sounds like pthread_attr_get_np is not working as expected. It is used  
to get the stack base, for purposes of the conservative garbage  
collector.

  - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread Maciej Stachowiak

On May 30, 2008, at 12:15 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:13:43PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori (another  
 gtk
 browser based on webkit), I receive or core dump whenever I click  
 on any
 part of a webpage or try to navigate to another.  After inspecting  
 the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively  
 () from
 /usr/local/lib/libwebkit-1.0.so.1.0

 Sounds like pthread_attr_get_np is not working as expected. It is  
 used to
 get the stack base, for purposes of the conservative garbage  
 collector.

 - Maciej

 Thanks, I'll look into my implementation and check it with people who
 actually know what they're doing!

pthread_attr_get_np is not really all that important, just any way to  
get the stack base. If OpenBSD has any function at all that works for  
that purpose you could just add another branch to the ifdef.  
Regrettably there is no portable way to do it.

  - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit on OpenBSD

2008-05-30 Thread Maciej Stachowiak

On May 30, 2008, at 1:51 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:22:54PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 12:15 PM, James Turner wrote:

 On Fri, May 30, 2008 at 12:13:43PM -0700, Maciej Stachowiak wrote:

 On May 30, 2008, at 10:37 AM, James Turner wrote:

 I've spent the last couple days trying to compile WebKit on  
 OpenBSD
 -current.  After adding the signbit function, changing isfinite to
 finite and adding the missing pthread_attr_get_np function, I was
 finally able to get it to compile.

 However, when I try to run the Gtk test browser or midori  
 (another gtk
 browser based on webkit), I receive or core dump whenever I  
 click on any
 part of a webpage or try to navigate to another.  After  
 inspecting the
 core dump with gdb I'm left with this:

 #0  0x0d501dc8 in KJS::Collector::markStackObjectsConservatively  
 () from
 /usr/local/lib/libwebkit-1.0.so.1.0

 Sounds like pthread_attr_get_np is not working as expected. It is  
 used to
 get the stack base, for purposes of the conservative garbage  
 collector.

 - Maciej

 Thanks, I'll look into my implementation and check it with people  
 who
 actually know what they're doing!

 pthread_attr_get_np is not really all that important, just any way  
 to get
 the stack base. If OpenBSD has any function at all that works for  
 that
 purpose you could just add another branch to the ifdef. Regrettably  
 there
 is no portable way to do it.

 - Maciej

 So, I looked through OpenBSD's diff stack function and tried using
 pthread_stackseg_np like:

 stack_t stack;
 pthread_stackseg_np(thread, stack);

 But I'm still getting a segfault at the same location.  This again  
 could
 be the wrong function to use, but it's the only thing I can find that
 looks remotely like it would work :/

It sounds like it should work (looks analogous to the Solaris  
thr_stksegment). Can you try in the debugger? You should be able to  
see if it is trying to access an address outside the stack range, or  
doing an unaligned access, or something.

Regards,
Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-06-04 Thread Maciej Stachowiak


On Jun 3, 2008, at 10:58 PM, Paul Pedriana wrote:

Thanks for the response. I'm sorry, and perhaps I misunderstand, but  
I believe your statement about inline operator new is incorrect.  
Unless I misunderstand you, what you say is not supported by any  
existing compiler nor is it supported by the C++ language standard.  
In summary, the 'inline' keyword does not negate or obviate the One  
Definition Rule. You can demonstrate the problem with the code  
below. Feel free to correct any misunderstanding that I may have of  
your explanation.


This happens to work as intended on Mac OS X because  
WTF_PRIVATE_INLINE expands to:


__private_extern__ inline __attribute__((always_inline))

This prevents an externally visible definition of global operator new  
and delete from being seen.


I agree this is technically wrong and I suspect it may cause problems  
on, for example, Linux platforms. I think the Qt port has turned off  
FastMalloc for this reason.


I can think of two possible solutions:

1) Instead of overloading the global operator new and delete, have a  
FastAllocated base class that overloads the class operator new and  
delete, and make every class in WebCore and JavaScriptCore inherit  
from it; for non-class types, avoid using new, delete, new[] or  
delete[] (perhaps template functions could be provided). The downside  
is that I can't think of an easy way to then flag mistaken use of new/ 
delete on primitive types, or forgetting to inherit from the  
FastAllocated base class. Then again, we don't try to flag mistaken  
use of malloc() instead of fastMalloc() and that has been ok.


2) Require allocation to happen in some way other than new and  
delete, for instance always with template functions. Then perhaps we  
could use #defines to make any actual use of new and delete an  
error.


Either of these would be a large change to the source, especially #2  
(#1 only needs to affect classes with no other subclass and the few  
places we use new[] on non-class types to make arrays).


Perhaps someone else has a more clever idea.

Regards,
Maciej




I do not mean to criticize WebKit. We think it is a great thing  
which in general is surprisingly well coded. We would love to work  
with any resolution which has the desired effect in the way of  
memory management.


The error you get:
SomeLib.lib: error LNK2005: void * __cdecl operator new(unsigned  
int) ([EMAIL PROTECTED]@Z) already defined in main.obj
SomeLib.lib: error LNK2005: void __cdecl operator delete(void  
*) ([EMAIL PROTECTED]@Z) already defined in main.obj

Source code:
// Main.cpp
#include stdlib.h
extern void DoSomething();

void* operator new(size_t s){ return malloc(s); }
void  operator delete(void* p)  { free(p); }
void* operator new[](size_t s)  { return malloc(s); }
void  operator delete[](void* p){ free(p); }

int main(int, char*[]) {
void* p = malloc(10);
free(p);
DoSomething();
return 0;
}

// SomeLib.cpp - compiled in a separate lib
#include stdlib.h

inline void* operator new(size_t s) { return malloc(s); }
inline void  operator delete(void* p)   { free(p); }
inline void* operator new[](size_t s)   { return malloc(s); }
inline void  operator delete[](void* p) { free(p); }

void DoSomething(){
void* p = malloc(10);
free(p);
}
Thanks.





On 03/06/2008, at 21:13, Paul Pedriana wrote:


Thanks for the info. IMHO, tcmalloc is not appropriate for console,
embedded, and mobile platforms. It trades space for speed, and  
that's
the opposite of what you want outside the desktop. This is why the  
Nokia

S60 people replaced tcmalloc, for example.


As far as I can tell, Nokia's S60 port predates the adoption of  
tcmalloc by WebKit.  The code in their latest svn.webkit.org source  
tree contains a variant of dlmalloc that was used up until Safari  
2.0, though I have not checked to see whether it is compiled in to  
their build.  That said, it is obvious that the space vs. speed  
tradeoffs differ between devices, and that flexibility in the  
memory allocator used is desirable.


Unfortunately, overriding operator new and delete does not do the  
right

thing. These operators are application-global functions and when you
redirect them for one library you are thus redirecting them for the
entire rest of the app. Needless to say, that is a bad thing. In  
console
and embedded development, as I note in the aforementioned paper,  
it is

typically verboten for a library to use operator new/delete.


On the platforms with which I am familiar, the implementation that  
I linked to has no effect outside of the library in which it is  
defined.  I've not worked with consoles or embedded devices so the  
toolchain and environment may differ there, but I would be a little  
surprised to see an inline function that is implemented in a header  
become visible to an object file that did not include the header.




Neither will you see professional commercial software do this.



It's also a problem 

  1   2   3   4   5   6   7   8   9   10   >