Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore
Didn't KDOM have an XML parsing abstraction? Would that be worth studying? dave On Jul 27, 2007, at 3:26 PM, Maciej Stachowiak wrote: On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote: On Friday 27 July 2007 16:50:01 Darin Adler wrote: I'm not happy with the code organization here. XMLTokenizer now has tons of ifdefs and two separate implementations. It's fine to have a QXmlStream implementation, but the two implementations should be in separate files, side by side, as we do in the platform layer. I agree that the #ifdef's are not optimal, and we can move parts of the code out. But currently a lot of code is still shared between the QXmlStream and the libxml based implementations, so we have two choices: 1. just add an XMLTokenizerQt.cpp and duplicate lots of code. 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp and keep a common XMLTokenizer.cpp for code that is used in both. 3. Have some ifdef's in the one file. The first option is no good, as we'd have to duplicate lot's of shared code leading to maintenance issues in the long term. The second option is better, but also here we'd have quite a bit more duplicated code than required as long as we don't do some bigger refactoring to abstract out the common parts. This is something we wanted to avoid at the moment. So we went for option 3. 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. Regards, Maciej Or the XML parser should be abstracted out so we have a single XMLTokenizer built on a single parser abstraction. That will be IMO almost impossible to do in an efficient way as the two parsers work very differently. I think this is also the type of patch that should be reviewed by at least one person other than the folks concentrating on the Qt port. We've had other people look at most patches. The QXmlStream changes are required, and I think the only issue to discuss here could be separating implementations. This is something I'd like to do in the longer term, but as you're trying to stabilize currently I didn't feel that this should have been done right now. With the huge number of check-ins today, I'm sure there are other interesting things like this that I missed. I think we did a thorough job reviewing our patches and testing them on all platforms (Mac, Windows, gtk and Qt). We also kept most changes rather small and atomic to make reviewing easier. Lars ___ 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] Re: [webkit-changes] [24723] trunk/WebCore
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote: On Friday 27 July 2007 16:50:01 Darin Adler wrote: I'm not happy with the code organization here. XMLTokenizer now has tons of ifdefs and two separate implementations. It's fine to have a QXmlStream implementation, but the two implementations should be in separate files, side by side, as we do in the platform layer. I agree that the #ifdef's are not optimal, and we can move parts of the code out. But currently a lot of code is still shared between the QXmlStream and the libxml based implementations, so we have two choices: 1. just add an XMLTokenizerQt.cpp and duplicate lots of code. 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp and keep a common XMLTokenizer.cpp for code that is used in both. 3. Have some ifdef's in the one file. The first option is no good, as we'd have to duplicate lot's of shared code leading to maintenance issues in the long term. The second option is better, but also here we'd have quite a bit more duplicated code than required as long as we don't do some bigger refactoring to abstract out the common parts. This is something we wanted to avoid at the moment. So we went for option 3. 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. Regards, Maciej Or the XML parser should be abstracted out so we have a single XMLTokenizer built on a single parser abstraction. That will be IMO almost impossible to do in an efficient way as the two parsers work very differently. I think this is also the type of patch that should be reviewed by at least one person other than the folks concentrating on the Qt port. We've had other people look at most patches. The QXmlStream changes are required, and I think the only issue to discuss here could be separating implementations. This is something I'd like to do in the longer term, but as you're trying to stabilize currently I didn't feel that this should have been done right now. With the huge number of check-ins today, I'm sure there are other interesting things like this that I missed. I think we did a thorough job reviewing our patches and testing them on all platforms (Mac, Windows, gtk and Qt). We also kept most changes rather small and atomic to make reviewing easier. Lars ___ 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] Question to the Adobe ApolloWebKit developers, tips and tricks to getting your "branch" to compile.
Quick hack to capture the information (please feel free to clean it up): http://trac.macosforge.org/projects/webkit/wiki/ApolloWebKit Dave Chris Brichford <[EMAIL PROTECTED]> wrote: > Some assembly is required. :). First thing you will need to do is download > some libraries our port depends on. > > When compiling on windows you will need: > icu from http://www.icu-project.org/download/ (we are using version 3.4.1). > Libxml from ftp://xmlsoft.org/libxml2/ > Libxslt from ftp://xmlsoft.org/libxslt/ > Loki from http://sourceforge.net/projects/loki-lib/ ( We'll probably remove > this dependency in the future ). > You will also need cygwin ( http://www.cygwin.com ) with at least the > following packages and their dependencies: > Bash > Bison > Cygutils > Flex > Gawk > Gcc-G++ > Gperf > Make > Perl > > > When compiling on mac you will just need: > Loki from http://sourceforge.net/projects/loki-lib/ ( We'll probably remove > this dependency in the future ). > > > You will want to arrange the source tree as follows: > > someDirectory/A/B/WebCore/... > someDirectory/A/B/JavaScriptCore/... > someDirectory/A/B/WebKit/... > someDirectory/SDK/libxml/... > someDirectory/SDK/libxslt/... > someDirectory/SDK/loki/... > someDirectory/SDK/icu/source/... > > > If you are compiling on windows, then you will want to create new sln file > that references: > someDirectory/A/B/WebCore/WebCore.apolloproj/win/WebCore.vc2005.vcproj > someDirectory/A/B/JavaScriptCore/JavaScriptCore.apolloproj/win/JavaScriptCore.vc2005.vcproj > someDirectory/A/B/WebKit/WebKit.apolloproj/win/WebKit.vc2005.vcproj > > On mac if you arrange the source tree as describe above there is a good > chance things should just build. The build output on both mac and windows > will be in someDirectory/build/... > > That should get the project to compile. To link you will have to build > libxml, libxslt, and icu ( Loki does not need to be built because > WebKit/apollo just some of its header files ) and change the project settings > on WebKit's project file to link against the version you built. You can > either build static or dynamic libraries for libxml, libxslt, and icu. We > build those libraries as static libs. > > Hope this helps, > Chris Brichford > Adobe Systems Inc. > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fuenty, Chris > Sent: Friday, July 27, 2007 9:54 AM > To: webkit-dev@lists.webkit.org > Subject: [webkit-dev] Question to the Adobe ApolloWebKit developers,tips and > tricks to getting your "branch" to compile. > > First off, I know you guys don't claim your version of WebKit you are working > with is a branch, I just used it for lack of a better term :P. > > Anyway, I have the latest P4 branch out of perforce. What's your guy's tips > and tricks to get it to compile right-out-of-the-box? Is there a certain > reversion I need to use (Sorry, not sure if you have those in perforce, I'm > struggling trying to understand how P4 works)? > > I'm running into errors mainly in TemporaryLinkStubs.cpp. Most of those from > what I can read out of some compile logs, are allready implemented in other > classes. I'm not very proficent in C++ (Please forgive me, If I was, I'd > love to help out). Lastly, I do get a lot of unresolved external errors upon > linking. I don't know what all I need to do to get all of this working, so > if an adobe dev could possiably help me out, that would be great. > > --Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
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
On Friday 27 July 2007 21:15:27 Lars Knoll wrote: > On Friday 27 July 2007 21:05:00 Darin Adler wrote: > > On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote: > > > I'm fine with moving to this approach (even though it'll still lead > > > to some code duplication if we do it the easy way without > > > refactoring). > > > > I don't think we should insist on doing it without refactoring. It > > seems good to add private member functions as necessary so we can > > share as much of the code as possible. > > Good, I was just under the impression that you wanted to avoid these kind > of changes at the moment. I'll prepare a patch then. Patch is in http://bugs.webkit.org/show_bug.cgi?id=14791 . Please review. Cheers, Lars ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
RE: [webkit-dev] Question to the Adobe ApolloWebKit developers, tips and tricks to getting your "branch" to compile.
Some assembly is required. :). First thing you will need to do is download some libraries our port depends on. When compiling on windows you will need: icu from http://www.icu-project.org/download/ (we are using version 3.4.1). Libxml from ftp://xmlsoft.org/libxml2/ Libxslt from ftp://xmlsoft.org/libxslt/ Loki from http://sourceforge.net/projects/loki-lib/ ( We'll probably remove this dependency in the future ). You will also need cygwin ( http://www.cygwin.com ) with at least the following packages and their dependencies: Bash Bison Cygutils Flex Gawk Gcc-G++ Gperf Make Perl When compiling on mac you will just need: Loki from http://sourceforge.net/projects/loki-lib/ ( We'll probably remove this dependency in the future ). You will want to arrange the source tree as follows: someDirectory/A/B/WebCore/... someDirectory/A/B/JavaScriptCore/... someDirectory/A/B/WebKit/... someDirectory/SDK/libxml/... someDirectory/SDK/libxslt/... someDirectory/SDK/loki/... someDirectory/SDK/icu/source/... If you are compiling on windows, then you will want to create new sln file that references: someDirectory/A/B/WebCore/WebCore.apolloproj/win/WebCore.vc2005.vcproj someDirectory/A/B/JavaScriptCore/JavaScriptCore.apolloproj/win/JavaScriptCore.vc2005.vcproj someDirectory/A/B/WebKit/WebKit.apolloproj/win/WebKit.vc2005.vcproj On mac if you arrange the source tree as describe above there is a good chance things should just build. The build output on both mac and windows will be in someDirectory/build/... That should get the project to compile. To link you will have to build libxml, libxslt, and icu ( Loki does not need to be built because WebKit/apollo just some of its header files ) and change the project settings on WebKit's project file to link against the version you built. You can either build static or dynamic libraries for libxml, libxslt, and icu. We build those libraries as static libs. Hope this helps, Chris Brichford Adobe Systems Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuenty, Chris Sent: Friday, July 27, 2007 9:54 AM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Question to the Adobe ApolloWebKit developers,tips and tricks to getting your "branch" to compile. First off, I know you guys don't claim your version of WebKit you are working with is a branch, I just used it for lack of a better term :P. Anyway, I have the latest P4 branch out of perforce. What's your guy's tips and tricks to get it to compile right-out-of-the-box? Is there a certain reversion I need to use (Sorry, not sure if you have those in perforce, I'm struggling trying to understand how P4 works)? I'm running into errors mainly in TemporaryLinkStubs.cpp. Most of those from what I can read out of some compile logs, are allready implemented in other classes. I'm not very proficent in C++ (Please forgive me, If I was, I'd love to help out). Lastly, I do get a lot of unresolved external errors upon linking. I don't know what all I need to do to get all of this working, so if an adobe dev could possiably help me out, that would be great. --Z ___ 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] Most methods in WebUIDelegate are not getting called
setContentRect: is only called when opening a new window through
JavaScript, and only with Safari 2.
In general, these methods are not notifications -- they are requests.
So, for example, a user resize of the window may change the WebView's
contentRect but, because the user -- not WebKit -- requested the
change, you will not receive a setContentRect: call.
NSView has notifications about frame and bounds changes. Perhaps
those will solve your problem. See, for example, +[NSView
setPostsFrameChangedNotifications:].
Geoff
On Jul 27, 2007, at 12:37 PM, piet wrote:
I need to know when the contentRect of a WebView changes so I added
a WebUIDelegate listening to setContentRect:.
Problem: setContentRect: is never called.
I added more methods to the WebUIDelegate, listening to show/close,
focus/unfocus, set status text, set frame/content and mouse-move,
but none of them gets called except for mouse-move
(mouseDidMoveOverElement:).
Is there anything wrong with my code? I tested with both Safari 2
and Safari 3. For a minimal testcase, you can add the following
code to /Developer/Examples/WebKit/MiniBrowser/MyDocument.m, line
263. The only output to the console comes from the NSLog() in
mouseDidMoveOverElement:
- (void)webViewClose:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewClose");
}
- (void)webViewFocus:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewFocus");
}
- (void)webViewUnfocus:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewUnfocus");
}
- (void)webView:(WebView *)sender setStatusText:(NSString *)text
{
NSLog(@"WebView UI delegate:setStatusText %@", text);
}
- (void)webView:(WebView *)sender setFrame:(NSRect)frame
{
NSLog(@"WebView UI delegate:setFrame w=%f h=%f",
frame.size.width, frame.size.height);
}
- (void)webView:(WebView *)sender setContentRect:(NSRect)contentRect
{
NSLog(@"WebView UI delegate:setContentRect w=%f h=%f",
contentRect.size.width, contentRect.size.height);
}
- (void)webView:(WebView *)sender mouseDidMoveOverElement:
(NSDictionary *)elementInformation modifierFlags:(unsigned int)
modifierFlags
{
NSLog(@"WebView UI delegate:mouseDidMoveOverElement");
}
Get the free Yahoo! toolbar and rest assured with the added
security of spyware protection.
___
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] Most methods in WebUIDelegate are not getting called
I need to know when the contentRect of a WebView changes so I added a
WebUIDelegate listening to setContentRect:.
Problem: setContentRect: is never called.
I added more methods to the WebUIDelegate, listening to show/close,
focus/unfocus, set status text, set frame/content and mouse-move, but none of
them gets called except for mouse-move (mouseDidMoveOverElement:).
Is there anything wrong with my code? I tested with both Safari 2 and Safari 3.
For a minimal testcase, you can add the following code to
/Developer/Examples/WebKit/MiniBrowser/MyDocument.m, line 263. The only output
to the console comes from the NSLog() in mouseDidMoveOverElement:
- (void)webViewClose:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewClose");
}
- (void)webViewFocus:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewFocus");
}
- (void)webViewUnfocus:(WebView *)sender
{
NSLog(@"WebView UI delegate:webViewUnfocus");
}
- (void)webView:(WebView *)sender setStatusText:(NSString *)text
{
NSLog(@"WebView UI delegate:setStatusText %@", text);
}
- (void)webView:(WebView *)sender setFrame:(NSRect)frame
{
NSLog(@"WebView UI delegate:setFrame w=%f h=%f", frame.size.width,
frame.size.height);
}
- (void)webView:(WebView *)sender setContentRect:(NSRect)contentRect
{
NSLog(@"WebView UI delegate:setContentRect w=%f h=%f",
contentRect.size.width, contentRect.size.height);
}
- (void)webView:(WebView *)sender mouseDidMoveOverElement:(NSDictionary
*)elementInformation modifierFlags:(unsigned int)modifierFlags
{
NSLog(@"WebView UI delegate:mouseDidMoveOverElement");
}
-
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection. ___
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
On Friday 27 July 2007 21:05:00 Darin Adler wrote: > On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote: > > I'm fine with moving to this approach (even though it'll still lead > > to some code duplication if we do it the easy way without > > refactoring). > > I don't think we should insist on doing it without refactoring. It > seems good to add private member functions as necessary so we can > share as much of the code as possible. Good, I was just under the impression that you wanted to avoid these kind of changes at the moment. I'll prepare a patch then. > The reason I'm particularly sensitive on this issue is that fixing the > structure of ifdef'd code like this is something we've spent a lot of > time on the last two years. We still have quite a bit left to fix from > decisions I regret when adapting the code to Mac OS X, and I'd like to > avoid introducing new cases of it now. I agree. We mostly try to avoid these things for our platform specific code in Qt as well. > > Should we move the XMLTokenizer class to WebCore/platform then? > > No. > > If we were making an independent XML abstraction that didn't depend on > the rest of WebKit then it would belong there. But since we've decided > to not go that way, this is just platform-specific code in another > subdirectory, which we do as needed. See the loader directory, for > example. Ok. > I'm not sure I like the filename XMLTokenizerLibXml.cpp, but I can't > think of anything better. I'd be happer to find a better name, but I couldn't think of one. Cheers, Lars ___ 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
On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote: I'm fine with moving to this approach (even though it'll still lead to some code duplication if we do it the easy way without refactoring). I don't think we should insist on doing it without refactoring. It seems good to add private member functions as necessary so we can share as much of the code as possible. The reason I'm particularly sensitive on this issue is that fixing the structure of ifdef'd code like this is something we've spent a lot of time on the last two years. We still have quite a bit left to fix from decisions I regret when adapting the code to Mac OS X, and I'd like to avoid introducing new cases of it now. Should we move the XMLTokenizer class to WebCore/platform then? No. If we were making an independent XML abstraction that didn't depend on the rest of WebKit then it would belong there. But since we've decided to not go that way, this is just platform-specific code in another subdirectory, which we do as needed. See the loader directory, for example. I'm not sure I like the filename XMLTokenizerLibXml.cpp, but I can't think of anything better. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On Jul 27, 2007, at 11:51 AM, Lars Knoll wrote: Could you explain what you mean by 'good reason'? A JavaScript engine API that isolates clients from implementation details and can be potentially used cross platform is valuable. The files in the API directory represent an attempt to create one. That's the only reason these exist at all! I'd also prefer not having it in there. Still for Qt as a platform, the correct typedef is unsigned short. This API should have nothing to do with Qt as a platform. Any use of Qt in the implementation should be a hidden detail. To have this usable by plugins it would have to be a cross browser API as well as a cross platform one. Are there any efforts on the way in this direction? Yes, I think there's potential for this as a cross-JavaScript-engine API and hence a cross-browser one. No, we don't have specific plans to make that happen yet. 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. -- Darin ___ 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
On Friday 27 July 2007 20:50:53 Darin Adler wrote: > On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote: > > 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp > > and keep a common XMLTokenizer.cpp for code that is used in both. > > I like that option best. It's the pattern used in platform for cases > like this. I'm fine with moving to this approach (even though it'll still lead to some code duplication if we do it the easy way without refactoring). Should we move the XMLTokenizer class to WebCore/platform then? Lars ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
> > I do understand this for your Windows port. In Qt we try to have the > > same types across all platforms. This is also true for our QChar > > abstraction that is built on top of an unsigned short. So for us > > typedef'ing this to wchar_t is as wrong as unsigned short would be > > for your windows port. > > I'm sorry we don't see eye to eye on this. In the future there's good > reason for this to be API. It was designed to be cross-platfom API > without any reliance on any particular platform. I'd like to see this > left as a possibility for Windows. Could you explain what you mean by 'good reason'? > > For the Qt port, the 'platform' typedef is an unsigned short. So one > > could say that the #ifdef for __BULDING_QT does about the same thing > > as the #ifdef (WIN32) for your Windows port. > > OK. But would we expect people to define __BULDING_QT when using this > header? We are not planning to export this header as part of our public API. If someone want's to use this API together with JavascriptCore he is free to do so, but this is not at all related to a Qt port of WebKit. > We've gone out of our way to not use the internal definitions like > Platform.h in these headers, designed to be API and in a subdirectory > named "API", and it's strange to have __BUILDING_QT here. I'd also prefer not having it in there. Still for Qt as a platform, the correct typedef is unsigned short. > >> Also, since JSStringRef.h is an API header, it's not good to have > >> it depend on an project-internal define, so that's another reason > >> to remove the recent change to JSStringRef.h. > > > > Well, it's not an API header for us. Still it's used internally in > > WebKit, so we need to do something with the typedef. Different ports > > do sometimes have slightly different goals. > > Longer term I'd like to see this as cross-platform API. Even though > you don't see the need for this in your Qt port today, I think you > might in the future, for example if it was used as part of a plug-in > API and we wanted the plug-ins to work in both Qt WebKit on Windows > and the WebKit on Windows that's released with Safari. To have this usable by plugins it would have to be a cross browser API as well as a cross platform one. Are there any efforts on the way in this direction? > Could you think about this a little more and see if you're swayed by > my arguments? Also, please discuss this with Maciej if you have a > chance. On Friday 27 July 2007 20:32:32 Darin Adler wrote: > One last comment that might help. > > The idea here is that this is a low level API. Lower level than, say, > the WebKit API. It's not built on top of the platform APIs like AppKit > on Mac OS X. The idea is that it's potentially independent of WebKit. > That's a good argument for having it match the low level platform and > not be built on top of, say, AppKit or Qt. That extends even to things > like this type. If someone want's to use JavascriptCore with this low level API he is free to do so. > I guess the whole wchar_t thing is a snafu, though, because we > normally would not want a type that is different on different > platforms. Maybe we should dump the idea of using wchar_t on Windows > for this. Yes. If the API is supposed to be cross platform it would make most sense if the types are also compatible. wchar_t is unfortunately a pretty unusable type for cross platform API's as it is 16bit on Windows and 32bit on Linux. > 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 builtin, we chose a different path and used unsigned short on all platforms (as it's 16bit on all platforms we support). Lars ___ 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
On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote: 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp and keep a common XMLTokenizer.cpp for code that is used in both. I like that option best. It's the pattern used in platform for cases like this. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore
On Friday 27 July 2007 16:50:01 Darin Adler wrote: > I'm not happy with the code organization here. XMLTokenizer now has > tons of ifdefs and two separate implementations. It's fine to have a > QXmlStream implementation, but the two implementations should be in > separate files, side by side, as we do in the platform layer. I agree that the #ifdef's are not optimal, and we can move parts of the code out. But currently a lot of code is still shared between the QXmlStream and the libxml based implementations, so we have two choices: 1. just add an XMLTokenizerQt.cpp and duplicate lots of code. 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp and keep a common XMLTokenizer.cpp for code that is used in both. 3. Have some ifdef's in the one file. The first option is no good, as we'd have to duplicate lot's of shared code leading to maintenance issues in the long term. The second option is better, but also here we'd have quite a bit more duplicated code than required as long as we don't do some bigger refactoring to abstract out the common parts. This is something we wanted to avoid at the moment. So we went for option 3. > Or the XML parser should be abstracted out so we have a single > XMLTokenizer built on a single parser abstraction. That will be IMO almost impossible to do in an efficient way as the two parsers work very differently. > I think this is also the type of patch that should be reviewed by at > least one person other than the folks concentrating on the Qt port. We've had other people look at most patches. The QXmlStream changes are required, and I think the only issue to discuss here could be separating implementations. This is something I'd like to do in the longer term, but as you're trying to stabilize currently I didn't feel that this should have been done right now. > With the huge number of check-ins today, I'm sure there are other > interesting things like this that I missed. I think we did a thorough job reviewing our patches and testing them on all platforms (Mac, Windows, gtk and Qt). We also kept most changes rather small and atomic to make reviewing easier. Lars ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
One last comment that might help. The idea here is that this is a low level API. Lower level than, say, the WebKit API. It's not built on top of the platform APIs like AppKit on Mac OS X. The idea is that it's potentially independent of WebKit. That's a good argument for having it match the low level platform and not be built on top of, say, AppKit or Qt. That extends even to things like this type. I guess the whole wchar_t thing is a snafu, though, because we normally would not want a type that is different on different platforms. Maybe we should dump the idea of using wchar_t on Windows for this. 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. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On Jul 27, 2007, at 11:18 AM, Lars Knoll wrote: I do understand this for your Windows port. In Qt we try to have the same types across all platforms. This is also true for our QChar abstraction that is built on top of an unsigned short. So for us typedef'ing this to wchar_t is as wrong as unsigned short would be for your windows port. I'm sorry we don't see eye to eye on this. In the future there's good reason for this to be API. It was designed to be cross-platfom API without any reliance on any particular platform. I'd like to see this left as a possibility for Windows. For the Qt port, the 'platform' typedef is an unsigned short. So one could say that the #ifdef for __BULDING_QT does about the same thing as the #ifdef (WIN32) for your Windows port. OK. But would we expect people to define __BULDING_QT when using this header? We've gone out of our way to not use the internal definitions like Platform.h in these headers, designed to be API and in a subdirectory named "API", and it's strange to have __BUILDING_QT here. Also, since JSStringRef.h is an API header, it's not good to have it depend on an project-internal define, so that's another reason to remove the recent change to JSStringRef.h. Well, it's not an API header for us. Still it's used internally in WebKit, so we need to do something with the typedef. Different ports do sometimes have slightly different goals. Longer term I'd like to see this as cross-platform API. Even though you don't see the need for this in your Qt port today, I think you might in the future, for example if it was used as part of a plug-in API and we wanted the plug-ins to work in both Qt WebKit on Windows and the WebKit on Windows that's released with Safari. Could you think about this a little more and see if you're swayed by my arguments? Also, please discuss this with Maciej if you have a chance. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On Friday 27 July 2007 18:56:40 Darin Adler wrote:
> On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:
> > On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
> >> On 7/27/07 1:51 PM, "Simon Hausmann" <[EMAIL PROTECTED]> wrote:
> >>> Does anybody know/remember why JSChar is defined to wchar_t on
> >>> Windows and if
> >>> it is still needed?
> >>
> >> I think this was/is needed to match ICU's definition of UChar
> >> ("Define UChar to be wchar_t if that is 16 bits wide; always
> >> assumed to be unsigned. If wchar_t is not 16 bits wide, then
> >> define UChar to be uint16_t. This makes the definition of UChar
> >> platform-dependent but allows direct string type compatibility
> >> with platforms with 16-bit wchar_t types.")
> >
> > That's correct. And for the same reasons we should follow the same
> > pattern for UChar, even when ICU is not involved.
> >
> > I think that UnicodeQt4.h is the file that should be changed, not
> > JSStringRef.h.
>
> I should be more specific about the reasons I have for preferring this.
>
> It's a good feature for both JSChar and UChar that on the Windows
> platform, the 16-bit unsigned integer type they use is wchar_t,
> rather than unsigned short. That's because there are all sorts of
> Windows Unicode APIs that take wchar_t, and it's great to have the
> type match.
I do understand this for your Windows port. In Qt we try to have the same
types across all platforms. This is also true for our QChar abstraction that
is built on top of an unsigned short. So for us typedef'ing this to wchar_t
is as wrong as unsigned short would be for your windows port.
> The same issue exists on Mac OS X, but on that platform the types for
> characters, Unichar and unichar, are unsigned short.
>
> Anyway, for the JavaScript API, it's great to have the character
> typedef match the platform typedef, as long as the platform typedef
> is a 16-bit unsigned integer. I'd like us to preserve that feature
> even when building for Qt. That increases the chance that client code
> using the JavaScript API can be independent of the particular
> underlying JavaScriptCore implementation.
For the Qt port, the 'platform' typedef is an unsigned short. So one could say
that the #ifdef for __BULDING_QT does about the same thing as the #ifdef
(WIN32) for your Windows port.
> Also, since JSStringRef.h is an API header, it's not good to have it
> depend on an project-internal define, so that's another reason to
> remove the recent change to JSStringRef.h.
Well, it's not an API header for us. Still it's used internally in WebKit, so
we need to do something with the typedef. Different ports do sometimes have
slightly different goals.
Cheers,
Lars
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Question to the Adobe ApolloWebKit developers, tips and tricks to getting your "branch" to compile.
First off, I know you guys don't claim your version of WebKit you are working with is a branch, I just used it for lack of a better term :P. Anyway, I have the latest P4 branch out of perforce. What's your guy's tips and tricks to get it to compile right-out-of-the-box? Is there a certain reversion I need to use (Sorry, not sure if you have those in perforce, I'm struggling trying to understand how P4 works)? I'm running into errors mainly in TemporaryLinkStubs.cpp. Most of those from what I can read out of some compile logs, are allready implemented in other classes. I'm not very proficent in C++ (Please forgive me, If I was, I'd love to help out). Lastly, I do get a lot of unresolved external errors upon linking. I don't know what all I need to do to get all of this working, so if an adobe dev could possiably help me out, that would be great. --Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, "Simon Hausmann" <[EMAIL PROTECTED]> wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and if
it is still needed?
I think this was/is needed to match ICU's definition of UChar
("Define UChar to be wchar_t if that is 16 bits wide; always
assumed to be unsigned. If wchar_t is not 16 bits wide, then
define UChar to be uint16_t. This makes the definition of UChar
platform-dependent but allows direct string type compatibility
with platforms with 16-bit wchar_t types.")
That's correct. And for the same reasons we should follow the same
pattern for UChar, even when ICU is not involved.
I think that UnicodeQt4.h is the file that should be changed, not
JSStringRef.h.
I should be more specific about the reasons I have for preferring this.
It's a good feature for both JSChar and UChar that on the Windows
platform, the 16-bit unsigned integer type they use is wchar_t,
rather than unsigned short. That's because there are all sorts of
Windows Unicode APIs that take wchar_t, and it's great to have the
type match.
The same issue exists on Mac OS X, but on that platform the types for
characters, Unichar and unichar, are unsigned short.
Anyway, for the JavaScript API, it's great to have the character
typedef match the platform typedef, as long as the platform typedef
is a 16-bit unsigned integer. I'd like us to preserve that feature
even when building for Qt. That increases the chance that client code
using the JavaScript API can be independent of the particular
underlying JavaScriptCore implementation.
Also, since JSStringRef.h is an API header, it's not good to have it
depend on an project-internal define, so that's another reason to
remove the recent change to JSStringRef.h.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [webkit-changes] [24723] trunk/WebCore
On Jul 27, 2007, at 7:50 AM, Darin Adler wrote: With the huge number of check-ins today, I'm sure there are other interesting things like this that I missed. I looked over the other check-ins, and I think I was wrong about this -- my only real concerns are the UChar/JChar one and the XML ifdefs. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore
I'm not happy with the code organization here. XMLTokenizer now has tons of ifdefs and two separate implementations. It's fine to have a QXmlStream implementation, but the two implementations should be in separate files, side by side, as we do in the platform layer. Or the XML parser should be abstracted out so we have a single XMLTokenizer built on a single parser abstraction. I think this is also the type of patch that should be reviewed by at least one person other than the folks concentrating on the Qt port. With the huge number of check-ins today, I'm sure there are other interesting things like this that I missed. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, "Simon Hausmann" <[EMAIL PROTECTED]> wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and if
it is still needed?
I think this was/is needed to match ICU's definition of UChar
("Define UChar to be wchar_t if that is 16 bits wide; always
assumed to be unsigned. If wchar_t is not 16 bits wide, then define
UChar to be uint16_t. This makes the definition of UChar platform-
dependent but allows direct string type compatibility with
platforms with 16-bit wchar_t types.")
That's correct. And for the same reasons we should follow the same
pattern for UChar, even when ICU is not involved.
I think that UnicodeQt4.h is the file that should be changed, not
JSStringRef.h.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Building Win32/Release WebKit: linker error LNK1106
Just an addition: Win32/Debug build has been finished successfully. Artem Ananiev wrote: Hi, all, I'm trying to build WebKit in Release mode and get the following message from linker when building WebCore subproject: 1>Performing Pre-Build Event... 1>cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler 1>tmp.cpp 1>make: Nothing to be done for `all'. 1>Creating library... 1>..path\to\webkit..\WebKitBuild\lib\WebCore.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x20150F02 The disk drive has about 12Gb of free space. I have also noticed another interesting thing: when "Creating library..." is in progress, WebKitBuild/lib/WebCore.lib is created and rapidly grows from a couple of megs to 128M, then to 256M, and at last to 512M. After LNK1106 error is displayed, the file is removed. Thanks, Artem ___ 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] Building Win32/Release WebKit: linker error LNK1106
Hi, all, I'm trying to build WebKit in Release mode and get the following message from linker when building WebCore subproject: 1>Performing Pre-Build Event... 1>cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition of the compiler 1>tmp.cpp 1>make: Nothing to be done for `all'. 1>Creating library... 1>..path\to\webkit..\WebKitBuild\lib\WebCore.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x20150F02 The disk drive has about 12Gb of free space. I have also noticed another interesting thing: when "Creating library..." is in progress, WebKitBuild/lib/WebCore.lib is created and rapidly grows from a couple of megs to 128M, then to 256M, and at last to 512M. After LNK1106 error is displayed, the file is removed. Thanks, Artem ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Cache
Hi, Where is persistent HTTP Cache handling done in MainLine Webkit ? In S60, Persistent storage and HTTP Header parsing is done in: ResourceLoader\CacheSrc\* Meta Data Handling for Cache is done from : void DocumentImpl::processHttpEquiv(const DOMString &equiv, const DOMString &content) In MainLine Webkit, void Document::processHttpEquiv(const String &equiv, const String &content), Only Cookies are handled. Cache related is not handled. Similarly, I could not find Http header handling for Cache. In GDK Port, CURL does not support Cache right ? The Cache related files inside WebCore\Loader are webcore memory cache, am I right ? Thanks Vamsi. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] type of JSChar
On 7/27/07 1:51 PM, "Simon Hausmann" <[EMAIL PROTECTED]> wrote:
> Does anybody know/remember why JSChar is defined to wchar_t on Windows and if
> it is still needed?
I think this was/is needed to match ICU's definition of UChar ("Define
UChar to be wchar_t if that is 16 bits wide; always assumed to be unsigned.
If wchar_t is not 16 bits wide, then define UChar to be uint16_t. This makes
the definition of UChar platform-dependent but allows direct string type
compatibility with platforms with 16-bit wchar_t types.")
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] type of JSChar
Hi, during our work on making the Qt port of WebKit compile on Windows with MSVC and MingW g++ we ran into the following code in JavaScriptCore/API/JSStringRef.h: ... #if !defined(WIN32) && !defined(_WIN32) typedef unsigned short JSChar; #else typedef wchar_t JSChar; #endif ... JSChar being defined as wchar_t caused compiles problems for us inside WebCore itself when converting from JSChar to UChar. For now we added a || defined(__BUILDING_QT) to the condition, but we're wondering why JSChar is defined as wchar_t on Windows in the first place. We ran into this problem only when compiling with g++, MSVC seems to silently convert wchar_t to unsigned short. Unfortunately the svn history does not provide anything regard this #ifdef since it was added to the svn repository. Does anybody know/remember why JSChar is defined to wchar_t on Windows and if it is still needed? Simon signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
