[webkit-dev] Re: Porting to other graphics architectures
Brian Edmond wrote: Hi, I am looking at porting WebKit to the QNX Neutrino operating system and am trying to figure out the requirements for the target graphics system and OS. I have looked at the GTK+ version under Linux a bit. I wanted to know if WebKit required an underlying windowing system with widgets or if you could port it to a system using only a graphics library and input event management. Looking at the GTK+ version it seems to use buttons and the like for display. Thanks for any information, Hi Brian, You can port WebKit to a graphics system without needing an underlying UI toolkit. This approach is often taken in WebKit ports for platforms where the browser is the main/only user interface on the target system. In fact, if you look at the GTK+ port, it actually falls back to a Cairo-only rendering path without actually using GTK+ at all when printing. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] absolutePosition
The absolutePosition function in the render tree is extremely problematic. It also does not work in the presence of transforms or multi-column layout and is extremely slow (calling it inside other loops is often the cause of O(n^2) behavior). I would like every WebKit reviewer to be on the lookout for any patches that attempt to introduce additional calls to this function. The patch author should have to justify why the call had to be added and be sure there was no other way to achieve the same effect. dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Porting to other graphics architectures
On Thu, 2008-01-17 at 15:02 -0500, Brian Edmond wrote: > Hi, > > > > Sorry of this is not the correct forum for this question. > > > > I am looking at porting WebKit to the QNX Neutrino operating system > and am trying to figure out the requirements for the target graphics > system and OS. I have looked at the GTK+ version under Linux a bit. > I wanted to know if WebKit required an underlying windowing system > with widgets or if you could port it to a system using only a graphics > library and input event management. Looking at the GTK+ version it > seems to use buttons and the like for display. Thanks for any > information, > Hello, I'm not really the right person who could give you the right answer, but i can see buttons and other widgets are used only for a matter of painting them the style they're shown in a normal GTK+ application. Drawing GTK+ widgets just mean getting the style of the box and render it in the graphics context. Again, I never worked with graphics such as cairo and I've no minimal knowledge of that, but having a graphics library for drawing lines, boxes, text and other stuff might be enough. Bye. > -- http://lethalman.blogspot.com - Thoughts about computer technologies http://syx.googlecode.com - Smalltalk YX project http://www.ammazzatecitutti.org - E adesso ammazzateci tutti 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
[webkit-dev] Porting to other graphics architectures
Hi, Sorry of this is not the correct forum for this question. I am looking at porting WebKit to the QNX Neutrino operating system and am trying to figure out the requirements for the target graphics system and OS. I have looked at the GTK+ version under Linux a bit. I wanted to know if WebKit required an underlying windowing system with widgets or if you could port it to a system using only a graphics library and input event management. Looking at the GTK+ version it seems to use buttons and the like for display. Thanks for any information, Brian Brian Edmond Crank Software Inc. www.cranksoftware.com [EMAIL PROTECTED] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] innerHTML
Am Thu, 17 Jan 2008 17:24:39 +0530 schrieb "ankush tiwari" <[EMAIL PROTECTED]>: > Hi All, > > Can someone please help me in getting a patch for "innerHTML" on > gtk-port. > > Thanks, > Ankush. Hi Ankush, in JavaScript innerHTML refers to the contents of an element in source code form, so you either want to look at the JavaScriptCore API which is available in WebKitGtk or you want an interface to the page source from a WebView or WebFrame. For the latter it seems that a model similar to WebDataSource is desirable which would have to be implemented. Regards, Christian Dywan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] innerHTML
Hi All, Can someone please help me in getting a patch for "innerHTML" on gtk-port. Thanks, Ankush. ___ 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
My vote would be to use #if PLATFORM(XX) to wrap relevant source files, and to create new Configurations to choose which libraries to link to. I think this is the simplest while still providing the functionality we need: -we must have the ability to link to different libraries for different builds, so that we can not link with, for example, CoreGraphics or Cairo -we do not want to have to maintain multiple project files -the #pragma comment code below looks like it gets too spaghetti-ish too quickly Cheers, Dan > > On Jan 16, 2008, at 2:19 PM, [EMAIL PROTECTED] wrote: > >> You can solve this by creating additional configurations in the same >> VS >> projects/solution. Configurations are set up to let you choose >> different >> link libraries for different targets. The different targets can >> also set >> different #defines to select CG vs Cairo, etc. >> >> Personally I don't like this so much since it is a pain to maintain >> multiple configurations, but it does solve the problem for selecting >> different libraries to link. >> >> Cheers, >> Dan >> >>> This was a non-issue for Cairo, since it was completely contained in >>> our source tree (and not externally linked against). That was less >>> than ideal though, and you still had the linking problem in the other >>> direction (with CG always being linked against). >>> >>> dave > > You can link against different libraries using the Visual Studio > "#pragma comment" feature, e.g.: > > #pragma comment(lib, "wininet.lib") > > This works, but if you want to link against debug and other variants, > you quickly end up with a mess like: > > #ifdef _DEBUG > #ifdef _UNICODE_ > #pragma comment (lib, "coollibDU.lib") > #else > #pragma comment (lib, "coollibD.lib") > #endif > #else > #ifdef _UNICODE_ > #pragma comment (lib, "coollibU.lib") > #else > #pragma comment (lib, "coollib.lib") > #endif > #endif > > I think for us to have a viable native windows port, we need to be > able to link against a pre-built Cairo libraries. > > I am just not looking forward to having to create multiple targets in > the project files, as this will involve figuring out how to pass this > along from the "build-webkit" script, etc., etc. > > But can we decide on a course of action soon? I'd like to generate a > patch that gets the win32 (native) target to build soon, but I don't > want to spend too much time on a dead-end. > > Thanks, > -Brent > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
