[webkit-dev] Cache

2007-07-27 Thread Vamsi
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

Re: [webkit-dev] Building Win32/Release WebKit: linker error LNK1106

2007-07-27 Thread Artem Ananiev
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: 1Performing Pre-Build Event... 1cl : Command line warning D9040 :

[webkit-dev] type of JSChar

2007-07-27 Thread Simon Hausmann
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Darin Adler
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

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

2007-07-27 Thread Darin Adler
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Darin Adler
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

[webkit-dev] Question to the Adobe ApolloWebKit developers, tips and tricks to getting your branch to compile.

2007-07-27 Thread Fuenty, Chris
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Darin Adler
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Lars Knoll
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Lars Knoll
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.

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

2007-07-27 Thread Lars Knoll
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Darin Adler
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

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

2007-07-27 Thread Darin Adler
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

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

2007-07-27 Thread Lars Knoll
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

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

2007-07-27 Thread Lars Knoll
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

Re: [webkit-dev] type of JSChar

2007-07-27 Thread Darin Adler
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

[webkit-dev] Most methods in WebUIDelegate are not getting called

2007-07-27 Thread piet
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,

Re: [webkit-dev] Most methods in WebUIDelegate are not getting called

2007-07-27 Thread Geoffrey Garen
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

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

2007-07-27 Thread Lars Knoll
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

RE: [webkit-dev] Question to the Adobe ApolloWebKit developers, tips and tricks to getting your branch to compile.

2007-07-27 Thread Chris Brichford
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

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