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
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 :
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
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
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
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
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
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
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.
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
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
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
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
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
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
15 matches
Mail list logo
