[webkit-dev] help needed on compiling the webkit on embedded linux platform.
Hi, I am using the free scale imx3-stack board. It has embedded linux. Could any one help me on how to use web kit on embedded linux for browsing ? Regds, S.Ramesh Chandra. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Unable to compile the webkit on the Redhat enterprise linux 9
Hi, I am new to webkit. Yester day I downloaded the sources on to my Red hat enterprise linux 9. I tried to compile with the following command. QTDIR=/usr/share/qt4/ WebKit/WebKitTools/Scripts/build-webkit I am getting the following error. Calling 'qmake CONFIG+=qt-port –r OUTPUT_DIR=/home/seamless/Webkit/WebKit.pro CONFIG=+release CONFIG-=debug' in /home/seamless/Webkit/WebKitBuilt/Release ***Unknown option –r Could you please help me in this? Thank you, S.Ramesh Chandra. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] My Windows build notes
Thanks Adam. On Tue, Oct 14, 2008 at 5:47 AM, Adam Roben [EMAIL PROTECTED] wrote: On Oct 13, 2008, at 7:09 PM, Mike Belshe wrote: It took me a while to get my windows build going, so I thought I'd share what I learned: Thanks, Mike! This kind of information is very helpful in keeping our instructions up-to-date. 1) I had to completely start over with cygwin. I uninstalled and reinstalled using the cygwin-downloader from here: http://webkit.org/building/tools.html 2) Several components were missing from cygwin: - perl, make, gcc, bison, gperf, curl, unzip, flex 3) Used cpan get Win32API::Registry to download that module Steps (2) and (3) were required even after installing via cygwin-downloader? You can see the list of packages it installs here: http://trac.webkit.org/browser/trunk/WebKitTools/CygwinDownloader/cygwin-downloader.py#L47. You can see that the list includes all the packages you mentioned (even perl-libwin32, which should install the Win32API::Registry module, I believe). Yes. I've read some about multiple cygwin installations, maybe I have multiple cygwins on one box? The cygwin install/uninstall process is basically voodoo. Even after I deleted everything cygwin related I could find, I reinstalled using the cygwin-downloader but I didn't have these components. Overall, I think cygwin is really brittle. We might be able to make this more reliable by putting this into the windows-specific tooling and then reference it explicitly rather than relying on cygwin's installer? 4) After downloading the source, I also had to run update-webkit. I suspect this is a required step, although I don't think it is documented? This is documented here http://webkit.org/building/checkout.html: 1. Type this command to update your source tree: WebKit/WebKitTools/Scripts/update-webkit If you downloaded the tarball, this will bring it up to date. Windows users must always execute this command after first obtaining the code, since it will download additional libraries that are needed to build. Not sure how I missed that. Seems so obvious now! :-) I'm happy to update documentation if you point me at it; but I'm not sure if my experience is due to pilot error or if things have changed. The documentation all lives in the WebKitSite directory of the WebKit source tree. Patches to clarify/fix the build instructions can be posted on https://bugs.webkit.org/. Thanks! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unable to compile the webkit on the Redhat enterprise linux 9
Hello, Disclaimer: I'm more of a GTK+/Debian guy =). On Tue, 2008-10-14 at 10:31 -0400, Ramesh Satyavaram wrote: I am new to webkit. Yester day I downloaded the sources on to my Red hat enterprise linux 9. I tried to compile with the following command. There is no such thing as Red Hat Enterprise 9. Either you are using Red Hat 9, or Fedora 9. If you're using the former it is already way old, and you probably have a too old version of qmake. Do check if qmake's version is current. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] My Windows build notes
On Oct 13, 2008, at 7:09 PM, Mike Belshe wrote: It took me a while to get my windows build going, so I thought I'd share what I learned: Thanks, Mike! This kind of information is very helpful in keeping our instructions up-to-date. 1) I had to completely start over with cygwin. I uninstalled and reinstalled using the cygwin-downloader from here: http://webkit.org/building/tools.html 2) Several components were missing from cygwin: - perl, make, gcc, bison, gperf, curl, unzip, flex 3) Used cpan get Win32API::Registry to download that module Steps (2) and (3) were required even after installing via cygwin- downloader? You can see the list of packages it installs here: http://trac.webkit.org/browser/trunk/WebKitTools/CygwinDownloader/cygwin-downloader.py#L47 . You can see that the list includes all the packages you mentioned (even perl-libwin32, which should install the Win32API::Registry module, I believe). 4) After downloading the source, I also had to run update-webkit. I suspect this is a required step, although I don't think it is documented? This is documented here http://webkit.org/building/checkout.html: Type this command to update your source tree: WebKit/WebKitTools/Scripts/update-webkit If you downloaded the tarball, this will bring it up to date. Windows users must always execute this command after first obtaining the code, since it will download additional libraries that are needed to build. I'm happy to update documentation if you point me at it; but I'm not sure if my experience is due to pilot error or if things have changed. The documentation all lives in the WebKitSite directory of the WebKit source tree. Patches to clarify/fix the build instructions can be posted on https://bugs.webkit.org/. Thanks! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] python bindings to qwebkit - who's responsible for doing this work (anyone?)
hiya folks, last month or so i added glib bindings to webkit, in order to make them available via pygtk's codegen.py as python bindings, for pywebkitgtk. to make that as clear as mud: around webkit's c++ DOM bindings i added glib bindings so that i could add python bindings. wait - don't laugh - it does actually make sense - there _is_ a good reason for doing it that way :) the background to this story of insanity (300 auto-generated glib objects and 1,570 auto-generated functions and the work's only 70% complete) is that i decided to port pyjamas, itself a port of GWT, to pure python. in looking for decent technology to utilise, i stumbled onto webkit. now, of course, because pyjamas ( http://pyjd.org and http://pyjs.org ) absolutely rocks, and is utterly cool, i'd like to see pyjamas ported to different DOM model layers, and so, a couple of days ago, i had a quick hack at doing pyjamas-khtml: http://github.com/lkcl/pyjamas-desktop/tree/master/pyjamas-khtml which isn't unfortunately going so well, because there's a fundamental flaw in the design of the python bindings to khtml.DOM: https://bugs.kde.org/show_bug.cgi?id=172740 it's _this_ why i'm looking to contact the people who are doing the work on QWebKit, to find out what the plans are, for doing python bindings, and to advise you - whomever you might be - to watch out for two things: 1) not to make the same design mistake 2) to consider ways in which drastic amounts of development time can be saved ... allow me to explain :) issue 1, first. there's something very, very important that gobject can do, and i am unsure that it is appropriate to use e.g. QObject to do the same thing, or even if Qt4 is capable of doing what gobject can provide (which it could very well do, but i don't know how), and it's this: gobject can do base classing. object inheritance trees, and, absolutely absolutely critically, run-time typecasting. even more importantly than that, python-gobject can pick up on the gobject type and will return the correct python object. the key is here, in create_gdom_object(), line 284, of GDOMBindings.cpp: http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom/GDOMBinding.cpp#L294 the critical line is this: gpointer res = g_object_new(dob-getGobjType(), NULL); that getGobjType() function is a pure virtual function, in the glib bindings c++ object (which represents the webkit DOM object). the auto-generator (Gobject.pm) creates each and every one of the 300 class instances where getGobjType() is declared, and so they return a GDOM_GOBJECT_TYPE_NODE, GDOM_GOBJECT_TYPE_ELEMENT, GDOM_GOBJECT_TYPE_HTML_BODY_ELEMENT etc. etc. etc. from there, python-pygobject is clever enough to implement the equivalent of c++ dynamic typecasting, such that _even_ when you do pywebkitgtk.document.getElementById(body_id), instead of a GDOM_GOBJECT_TYPE_NODE - i.e. a pywebkitgtk.DOMNode python object being returned (with the underlying c++ object being typecast down to a WebCore::Node*), a GDOM_GOBJECT_TYPE_HTML_BODY_ELEMENT is returned, and thus python-pygobject creates a pywebkitgtk.HTMLBodyElement. like i mentioned in my previous post, regarding khtml.DOM, i cannot express enough how absolutely vital it is that this issue is done correctly. as a workaround, khtml.DOM offers typecasting functions - in python - and the use of these functions is a complete nightmare (for reasons explained in the kde-devel post) without the combination of a HashMap and the support and use of the equivalent of c++ runtime typecasting, developers who use python-qwebkit for any serious DOM manipulation work are... screwed. utterly. issue 2, next. many people assume that glib equals gtk, and that gtk equals glib. and that glib equals gobject equals gtk. i certainly made the mistake of thinking that, in order to do gobject bindings, i would need the gtk libraries. you don't. glib and gobject have nothing to do with gtk (but - Gtk is _entirely_ dependent on gobject). so, when i said that i had done glib bindings around webkit's DOM model - i really _meant_ that i had done glib bindings around webkit - NOT i repeat NOT gtk bindings [around webkit's DOM model]. the importance of this - particularly in saving you (whomever you might be) vasts amounts of time and effort - cannot be underestimated. if you utilise the glib bindings to webkit to provide python-qwebkit with bindings to webkit's DOM model, my guess is that it would take about... eight hours, absolute maximum. if you endeavour to do a separate and distinct set of bindings to the webkit DOM model - either direct in python or onto QObject (based on GObject.pm auto-generator or the JSBindings auto-generator) i estimate that the average developer will take approximately one month to complete the work (300 objects), excluding Canvas DOM bindings which would be about another 7 to 10 days (a further 100 to 150 objects). if you endeavour to work off the back of the python-pykde work,
[webkit-dev] webkit core need to be cleanly separated from ports, behind a vector table
https://bugs.webkit.org/show_bug.cgi?id=21598 copy of the bugreport is here: a c struct containing pointers to higher order functions. used extensively in FreeDCE, linux kernel and the NT 4.0 kernel (e.g. the Lsa Security). good library interfaces are _so_ divorced from other libraries that they don't even access standard c or c++ libraries. evvverry single function - of everything that they need - goes into the vector table. in the case of kernels, you don't have any choice but to do that. in FreeDCE, it was just good practice. for webkit, it's a little insane to do a complete redesign of the library, _but_ - a good starting point would be the boundary between the ports and the webkit core (with the second stage being to _not_ call direct HTTP access for XMLHTTPRequest, but to call out to the functions in the vector table, to perform the URL data fetching. that would be _extremely_ useful). basically, the interface would look _incredibly_ similar to what webkitwebview.cpp looks like at the moment. except that you'd go via a vector table, and the initialisation would involve setting some 80 functions. _really_ good library design has ONE public function - ONE! and it's the function which returns you a pointer to the vector table, for the port developers to fill in all of the higher order function pointers. the advantages of taking this approach will be explained on the mailing list. the amount of actual work required to be done is really quite remarkably small, and would in many ways be quite simple and non-challenging (always nice to have something _simple_ to do which offers quite a lot of advantages). so - with that in mind: explanation :) quite simple: total independence from ports. that's what a good library offers. _really_ good libraries can actually be dlopen()ed on the _one_ function which gets the vector table - this technique was deployed extensively in samba TNG, and _really_ extensively in an obscure little project i did in 2000, called xmlvl - an xml-based programming language [put me off using xml for life, that did :) ] so, without recompiling the whole of webkit, developers would be able to write their own port of webkit. actually, you'd be able to drop the word port entirely, and even split out the QWebKit code, WebkitGTK code etc. into separate libraries or entirely remove them from webkit altogether, with the expectation that separate projects would take up the joining code (Webkit/qt/* and Webkit/gtk/* etc). what can you do once this is done? 1) you could make lynx utilise webkit!!! lynx would get javascript execution :) all that lynx would have to do is provide its own vector table of functions :) btw, not many people are aware that lynx has a svgalib port and an X-lib port, but it does. that would make lynx a proper web browser! woo-hoo! 2) you could make a daemon out of webkit. a headless webkit (ooer). a search-engine executor which could _properly_ execute javascript on a page (a bit like DumpRenderTree, only doing it properly, and allowing developers to print out the full HTML web page) and thus be able to pass the *TRUE* content to the search engine. 3) you can make the bindings (e.g. the webkit-glib bindings) FULLY independent of the port under which they operate. so, the python bindings which are at present hacked on top of pywebkitgtk become fully independent: they'd be called... ohhh... i dunno... pywebkit-glib or something. and THEN - crucially... absolutely absolutely crucially, python-qwebkit would AUTOMATICALLY get python bindings to the DOM model, without having to do tons and tons of unnecessary work adding YET ANOTHER set of bindings (python or qobject / qt) to webkit, to maintain. and, the webkit-glib-dom-mm c++ bindings would equally be independent of gtk, qt, wxWidgets etc. etc. etc. and every other programming language. 3) you could make a web scraper - like pykhtml - out of webkit. this is a really straightforward, simple and small amount of work, for a very very large strategic payoff, that increases the usefulness, power, flexibility and reach of webkit. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit core need to be cleanly separated from ports, behind a vector table
The term webkit core in your subject is very confusing. Do you mean WebKit or WebCore? There is platform-specific code in both. dave On Oct 14, 2008, at 4:24 PM, Luke Kenneth Casson Leighton wrote: https://bugs.webkit.org/show_bug.cgi?id=21598 copy of the bugreport is here: a c struct containing pointers to higher order functions. used extensively in FreeDCE, linux kernel and the NT 4.0 kernel (e.g. the Lsa Security). good library interfaces are _so_ divorced from other libraries that they don't even access standard c or c++ libraries. evvverry single function - of everything that they need - goes into the vector table. in the case of kernels, you don't have any choice but to do that. in FreeDCE, it was just good practice. for webkit, it's a little insane to do a complete redesign of the library, _but_ - a good starting point would be the boundary between the ports and the webkit core (with the second stage being to _not_ call direct HTTP access for XMLHTTPRequest, but to call out to the functions in the vector table, to perform the URL data fetching. that would be _extremely_ useful). basically, the interface would look _incredibly_ similar to what webkitwebview.cpp looks like at the moment. except that you'd go via a vector table, and the initialisation would involve setting some 80 functions. _really_ good library design has ONE public function - ONE! and it's the function which returns you a pointer to the vector table, for the port developers to fill in all of the higher order function pointers. the advantages of taking this approach will be explained on the mailing list. the amount of actual work required to be done is really quite remarkably small, and would in many ways be quite simple and non-challenging (always nice to have something _simple_ to do which offers quite a lot of advantages). so - with that in mind: explanation :) quite simple: total independence from ports. that's what a good library offers. _really_ good libraries can actually be dlopen()ed on the _one_ function which gets the vector table - this technique was deployed extensively in samba TNG, and _really_ extensively in an obscure little project i did in 2000, called xmlvl - an xml-based programming language [put me off using xml for life, that did :) ] so, without recompiling the whole of webkit, developers would be able to write their own port of webkit. actually, you'd be able to drop the word port entirely, and even split out the QWebKit code, WebkitGTK code etc. into separate libraries or entirely remove them from webkit altogether, with the expectation that separate projects would take up the joining code (Webkit/qt/* and Webkit/gtk/* etc). what can you do once this is done? 1) you could make lynx utilise webkit!!! lynx would get javascript execution :) all that lynx would have to do is provide its own vector table of functions :) btw, not many people are aware that lynx has a svgalib port and an X-lib port, but it does. that would make lynx a proper web browser! woo-hoo! 2) you could make a daemon out of webkit. a headless webkit (ooer). a search-engine executor which could _properly_ execute javascript on a page (a bit like DumpRenderTree, only doing it properly, and allowing developers to print out the full HTML web page) and thus be able to pass the *TRUE* content to the search engine. 3) you can make the bindings (e.g. the webkit-glib bindings) FULLY independent of the port under which they operate. so, the python bindings which are at present hacked on top of pywebkitgtk become fully independent: they'd be called... ohhh... i dunno... pywebkit-glib or something. and THEN - crucially... absolutely absolutely crucially, python-qwebkit would AUTOMATICALLY get python bindings to the DOM model, without having to do tons and tons of unnecessary work adding YET ANOTHER set of bindings (python or qobject / qt) to webkit, to maintain. and, the webkit-glib-dom-mm c++ bindings would equally be independent of gtk, qt, wxWidgets etc. etc. etc. and every other programming language. 3) you could make a web scraper - like pykhtml - out of webkit. this is a really straightforward, simple and small amount of work, for a very very large strategic payoff, that increases the usefulness, power, flexibility and reach of webkit. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] bindings layer should have a consistent way of getting at named items in collections
I currently see nameGetter, namedItem and getNamedItem in a number of different files that all currently have custom bindings that normalize to a nameGetter function. Can we just have all the collection types normalize on a single name for this function? It would mean that much of this custom binding could be avoided. I'm running into this with Chromium as I am trying to replace our PluginArray and MimeTypeArray with WebKit's. This is messing with our templates that currently just use namedItem (although could just as easily use nameGetter if that's preferred). The big differences with our MimeTypeArray implementation is that it kept a Vector of MimeTypes, returned raw pointers and used namedItem instead of nameGetter. It would be great if we could unify these. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bindings layer should have a consistent way of getting at named items in collections
On Tue, Oct 14, 2008 at 3:15 PM, Ojan Vafai [EMAIL PROTECTED] wrote: I currently see nameGetter, namedItem and getNamedItem in a number of different files that all currently have custom bindings that normalize to a nameGetter function. Can we just have all the collection types normalize on a single name for this function? It would mean that much of this custom binding could be avoided. I'm running into this with Chromium as I am trying to replace our PluginArray and MimeTypeArray with WebKit's. This is messing with our templates that currently just use namedItem (although could just as easily use nameGetter if that's preferred). The big differences with our MimeTypeArray implementation is that it kept a Vector of MimeTypes, returned raw pointers and used namedItem instead of nameGetter. It would be great if we could unify these. I support this idea. Unification of this concept would indeed be nice. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bindings layer should have a consistent way of getting at named items in collections
On Oct 14, 2008, at 3:15 PM, Ojan Vafai wrote: I currently see nameGetter, namedItem and getNamedItem in a number of different files that all currently have custom bindings that normalize to a nameGetter function. Can we just have all the collection types normalize on a single name for this function? It would mean that much of this custom binding could be avoided. I'm running into this with Chromium as I am trying to replace our PluginArray and MimeTypeArray with WebKit's. This is messing with our templates that currently just use namedItem (although could just as easily use nameGetter if that's preferred). The big differences with our MimeTypeArray implementation is that it kept a Vector of MimeTypes, returned raw pointers and used namedItem instead of nameGetter. It would be great if we could unify these. It would be great to make things as consistently as possible, though the key here is as possible. Some of the IDL interfaces define an explicit namedItem() or getNamedItem() function, while others have only an implicit name getter. It is even possible in theory for an interface to have only a method named namedItem() but no implicit get- by-name behavior. What I would suggest is to give every class that supports get-by-name a method called namedGetter, which is just an inline call to namedItem or getNamedItem or whatever, if there is an appropriate such method. Then the bindings generator could be changed so it can make use of that, and not require you to write namedItem() by hand in the JS bindings (by this I mean the JSC JS bindings). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
