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
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 th
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 Mai
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 :
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 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 assume
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: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 if
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 ne
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 revers
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 u
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
> > 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 wind
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
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
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 f
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 pla
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
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
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
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 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
> > >
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.
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
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 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 sho
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. XMLToke
28 matches
Mail list logo
