Re: [webkit-dev] automatic webkit bugzilla bug-posting / management tool
On 8/8/09, Jeremy Orlow jor...@chromium.org wrote: Have you looked at WebKitTools/Scripts/bugzilla-tool? There's a lot of overlap between what it does and what you do, but there are definitely (very cool) features in yours that it doesn't have. another thing that was initially in there, and is commented out right now, well, you can see part of it: changelogextract.py. the reasoning behind this is to migrate from having the ChangeLog text _in_ the ChangeLog to having it in a separate suite of files. the unfortunate thing about ChangeLog is that a) it's a moving target b) it's a _rolling_ moving target. by keeping the entries on a per-patch-group basis separate, you save time and effort esp. when maintaining patches for over a year. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] automatic webkit bugzilla bug-posting / management tool
as part of managing 29 patches to webkit i decided to develop a system
which parses the ChangeLog entries and re-creates the patches. but -
not only that, there's a system for automatic uploading of the patch
attachment, as well:
http://lkcl.net/webkit/patman
it could probably be adapted equally well to work on any bugzilla
system, but the Webkit ChangeLog format makes it particularly
convenient to use.
one of the important things that the patman tool does is re-create the
ChangeLog entry at the _top_ of the relevant ChangeLog file, and also
it updates the date.
then, it goes through looking for the files listed in the ChangeLog,
and splits them out of the svn diff (yes, there's a diff/patch parser
included in the tool)
also, it looks for the first https://bugs.webkit.org entry, parses the
number and then spits out the re-formatted patches in to a file
patches/patch.bugnumber.txt
then, if you want to submit the patch as an attachment, run
patman/poemposter.py (yes, that's where the code came from - poem
posting :) with the following arguments:
bugnumber 'bugdescription' [optional review flag - use ? to request review]
the [daftly-named] poemposter.py will search for the file
patches/patch.{bugnumber}.txt and will upload it automatically to
bugs.webkit.org, to the requested bugreport.
you will need to create a file login.txt with:
user: email address
pass: bugzilla password
as this is a bit of a hack-job, you will need to do svn diff f -
patman/patchsplit.py doesn't accept any arguments yet, it just assumes
that there is a file f in the current working directory.
also, the tool must be run from the top-level webkit svn.
but, it should prove to be incredibly useful to those people
submitting bugreports for review, and save a great deal of time.
also, the patch-parsing system on its own might prove to be useful for
the commit queue processing, as it is capable of splitting out the
contents of patches e.g. individual ChangeLog entries.
you can see the process by which the ChangeLog entry is re-created as
a diff (see use of FakeChangeSet) that is always at the top of the
file.
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] automatic webkit bugzilla bug-posting / management tool
On 8/8/09, Jeremy Orlow jor...@chromium.org wrote: Have you looked at WebKitTools/Scripts/bugzilla-tool? *sigh* - nooo :) There's a lot of overlap between what it does and what you do, but there are definitely (very cool) features in yours that it doesn't have. Maybe you or someone else could try pulling some of this logic into bugzilla-tool? Both are written in Python, so it might not be that hard! perhaps it was best that i didn't know it existed, otherwise i might have limited what i decided to do :) ultimately much of these tools should all go into python-bzutils. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] status update: webkit gobject bindings [svn r46395]
this is a progress report for archival and informational purposes on the upkeep of bug #16401, providing useable and useful glib / gobject bindings to the full webkit DOM implementation. pending inclusion in webkit svn, the code is being kept up-to-date on an ad-hoc basis at http://github.org/lkcl/webkit/16401.master. as the last 16401.master update (svn r44624 or so) was from a few months ago, yesterday was update to svn r46395 day, which was uneventful except for two major things: * updating to latest svn forced the use of the latest (git) revision of libsoup, which in turn incorporated a critical bugfix. * since the last change, a new attribute concept has been added to webkit IDL files: [reflect] and [reflectURL]. an initial attempt to ignore any properties with such attributes was made, but that quickly turned webkit-gobject (and pywebkitgtk) into something completely unusable, and it had to be fixed immediately. in short, then, the latest svn update has been done successfully without loss of functionality to the bindings, and the python bindings (pywebkitgtk) which in turn depend on webkit glib/gobject bindings have also suffered no loss of functionality, either. regarding the #16401 patch work, david kiltzer made an excellent suggestion two weeks ago which paved the way to split the 6,000-line patch down into smaller patches. individual discussions can now take place and be easily tracked. it is anticipated that if a discussion shows signs of getting too complex, covering too many issues, that it be split into further separate bugreports. so far, there are fifteen separate patches (all linked as blocking #16401) with more expected. the biggie is CodeGeneratorGObject.pm: everything else is infrastructure. CodeGeneratorGObjectLibrary1.pm is the first split, and it is anticipated that this file be split further (on an arbitrary 50% basis unless someone voices a better suggestion which saves developer time and money). patches to GNUmakefile.ams have *not* yet been submitted. all patches but the one to WebKitWebFrame have *zero* impact on the normal compilation process of webkit, regardless of compile-time options. all of the remaining patches simply add code that will remain completely unused, until the GNUmakefile.ams and WebKitWebFrame are also patched. the addition of LANGUAGE_GOBJECT to the IDL files has thrown up some oddities, just in the review process, such as #27603. it turns out that the HTML5 spec has moved on, making certain exceptions in the IDL files unnecessary. this is very fortunate, because all the work put into the gobject bindings is made useless if there are features missing from them. in that regard, it may be of interest to note these curious questions: https://bugs.webkit.org/show_bug.cgi?id=27435#c10 https://bugs.webkit.org/show_bug.cgi?id=27435#c13 the summary of these questions, regarding provision of XMLHttpRequest via language bindings, is basically, wtf?? :) and, as can be seen by the extensive but non-exhaustive replies, XMLHttpRequest via language bindings is a critical and integral part _of_ the language bindings. the summary lesson, shown by the only project currently and fully using the webkit gobject bindings (pyjamas desktop) is that it is absolutely absolutely necessary to have access to absolutely absolutely everything [in the DOM] - or you might as well not bother. at all. with respect to sam and alexey, the curious questions that you usefully raise highlight quite how much of a mismatch of understanding and appreciation for what is possible with web browser language bindings there still is, in the webkit community. [overall this leaves me somewhat flustered because i must be failing to communicate correctly just how powerful this stuff really is]. also it's worth noting that pyjamas desktop provides an indirect route to comparing xulrunner language bindings against webkit language bindings (and the plan is to add MSHTML as well, using python-win32com). so far, the differences are trivial and small, with webkit being the 2nd class citizen with respect to its provision of access to the DOM. one of the reasons why i am fighting the reviewers so hard is to ensure that what is accepted into webkit svn does not result in the webkit gobject bindings falling behind its peer, python-xpcom and MSHTML. simple differences which can be trivially worked around are tolerable, but significant differences, such as missing out entire areas of functionality such as XMLHttpRequest or having properties which are strings in MSHTML, KHTML and python-xpcom but are integers in webkit really cannot be tolerated. if you are interested in seeing webkit obtain useful and useable free software language bindings, how can you help? * first, compile up the patched #16401.master version of webkit from github * second, compile up the patched version of pywebkitgtk: http://code.google.com/p/pywebkitgtk/issues/detail?id=13 * third, install pyjamas (see
[webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
starting here:
https://bugs.webkit.org/show_bug.cgi?id=27435#c3
the issue is raised and noted that the W3C specification has several
functions with the exact same name and several parameters, and that c
simply is not equipped to cope with this.
the reason why i'm raising this on webkit-dev is because, contrary to
belief, the gobject bindings are _not_ limited to the GTK+: the GTK+
port is just at present the only port which has the necessary
linkage code. [reason: gobject has nothing to do with gtk.
#include gobject.h does not require #include gtk.h].
anyway - the summary conclusion that i came to in dealing with this issue is:
* to provide a good enough solution
* to provide that which does the job for the most people
* to provide the longest number of arguments and let callers work with that.
just so you know, mozilla _also_ suffers from this exact same problem,
and the solutions attempted, over several years of development, are...
a bit of a mess.
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ed216e6eb453649a/76829e33f396aade?lnk=gstq=lkcl#76829e33f396aade
here is where i have provided a good enough / does the job for most
people solution, this is in 2DCanvasContext's drawImage function:
https://bugzilla.mozilla.org/show_bug.cgi?id=502234
given that the existing XULrunner code _entirely_ cuts everything but
javascript off from drawImage, absolutely _anything_ is an
improvement. the 3-args version is therefore a good enough
compromise.
the gobject bindings do not implement 2D SVG Canvas [yet] - it was
simply far too much additional work. the XULrunner example is
therefore noted as advance warning about what kind of grungy
decisions lie ahead.
xan notes here: https://bugs.webkit.org/show_bug.cgi?id=27435#c4
a recommendation for doing hand-crafted fix-ups. yes, that's what
MSHTML does, effectively, because they too are using c (thanks to DCOM
which in turn relies on MSRPC which is in fact DCE/RPC the underlying
implementations are all c
*huge-intake-of-breath-at-overlong-sentence*)
the general policy in DCE/RPC is to simply stack a number on the end
of the function [and up-rate the IDL revision number, for backwards
compatibility - a feature not present in webkit].
so, sam, you finally have an explanation as to why adam did this:
https://bugs.webkit.org/show_bug.cgi?id=16401#c194
+sub Uniquify {
+my $name = shift;
+my $avoid = shift;
+if ($name eq $avoid) {
+$name = $name . 2;
+}
Please explain this.
it looks like it's the beginnings of trying to make auto-generated
gobject bindings that support the cases where functions in the IDL
have identical names. by postfixing a number on them.
now.
from experience with the gobject bindings thanks to pywebkitgtk as
intermediate bindings which pyjamas-desktop uses, i've found that the
cases where there are clashes like this are extremely rare, or that by
having defaults (and passing in 0, False, NULL or '') is perfectly
sufficient.
passing in 0, False, NULL is what XULrunner's [optional] IDL tag is
all about, and it's a route i'd strongly suggest avoiding. if
[optional] is added, then further analysis is made of the argument,
and, depending on its type, 0, False or NULL is passed in - but that's
only on _javascript_ bindings: the native c++ access (the xullrunner
equivalent of linking direct to WebCore) and the language bindings
are... well... pretty much left to their own devices i.e. stuffed in
most cases.
so, yes, the number of cases encountered are pretty rare.
* XMLHttpRequest open function takes 5 arguments, 3 of which are optional.
it's been discovered that passing in False, '','' as those three arguments
does the job.
* KeyboardEvent initKeyboardEvent function takes... oo... 14 arguments
in the W3C DOM specification and one extra one in Webkit (contrary to
the W3C standard), to provide notification when, and discrimination
of, the Alt-Gr key. a patch has been submitted which simply
eliminates on of these functions, for gobject bindings:
https://bugs.webkit.org/show_bug.cgi?id=27436
if you _don't_ do that, then the gobject bindings will simply fail to
compile, because you get two c functions with exactly the same name
[sam: note. answering / explaining
https://bugs.webkit.org/show_bug.cgi?id=16401#c194 ]
there are a couple of others, but it's no big deal.
overall, then, as noted above, i think you can see that this is a
hairy / grungy area but that the number of exceptions which need to be
dealt with are pretty limited, and the evidence and insights in here
support xan's statement:
https://bugs.webkit.org/show_bug.cgi?id=27435#c5
and the answer to mark's comment -
https://bugs.webkit.org/show_bug.cgi?id=27435#c5 is: in the
auto-generator, _and_ if it's demonstrated and proven that you _need_
it: if you have a clash, you simply tack on a number. increment until
done.
where it is quite often the case that by simply having default values
and
Re: [webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
On 7/23/09, Maciej Stachowiak m...@apple.com wrote: Responding to review comments should be done in the relevant bugzilla bug, not on the mailing list. It's ok to post here if you think an issue needs wider input from the community, but that doesn't seem to be the case with this issue. maciej, thank you for making that point. i'm going to do a rusty 7fs russell and rewrite what you've said so that i can respond to it. We generally have a policy of keeping responses to review comments in the relevant bugzilla bug, not on the mailing list, as you can see from the guidelines [insert URL here]. It's ok to post here if you think an issue needs wider input from the community. i was curious as to why you felt the need to make this post to the mailing list, because doesn't seem to be the case with this issue. ok - now we have something that can be responded to. On 7/23/09, after reconsidering matters carefully and rewriting them, Maciej Stachowiak m...@apple.com wrote: We generally have a policy of keeping responses to review comments in the relevant bugzilla bug, not on the mailing list, as you can see from the guidelines [insert URL here]. ah, sorry. the issue raised by mark had only a passing reference to the bug report, and was a more generic and wider matter that did not fit in with the bugreport, and had nothing to do with the subject line of the bug so, yes, i thought it best to raise it here. It's ok to post here if you think an issue needs wider input from the community. i was curious as to why you felt the need to make this post to the mailing list, because doesn't seem to be the case with this issue. there are absolutely loads of reasons. 1) so that people could find it, and discuss it. 2) in keeping the matter locked up in the bugreport, it risked becoming a discussion which nobody could find, not for love nor money, even if they wanted to contribute to it, or if they knew that it might affect their project adversely. so, out of a sense of responsibility and duty to the free software community that i serve i thought it best to raise this with a wider audience. 3) i appreciate that technical matters _should_ be discussed in bugreports - if relevant - however on strategic design decisions i felt that it would be more appropriate to discuss it here. 4) the sheer number of related and affected bugreports makes it awkward to contain the discussion to a single bugreport. the list of related bugs is #16401, #27410, #27423 through to #27437 (excluding #27434) 5) the discussions run to close to 300 comments, now, in #16401, with absolutely no search capabilities or useful archiving. to continue to use that as the parent bugreport would simply result in the discussion being utterly lost. i trust that this comprehensive answer illustrates to you that it was, although extremely quick, not without sound reasons that i chose to raise this matter on the lists, and i trust that you will in future do myself and others on this list the courtesy of not make it necessary for me to spend considerable time explaining and justifying my actions and decisions. thank you. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, hi maciej, I think your webkit-dev emails are becoming disruptive. whilst at the same time apologising for being disruptive, i'd like to ask you why you consider that to be a bad thing. Sending profanity-laced walls of text is not an appropriate use of this list. i apologise for the use of profanity which may cause offense. i ask you to consider this: if it wasn't for the frustration at being treated in a completely inappropriate fashion, i wouldn't feel the need to use profanity to express frustration, would i? if you see things from my perspective, it's that i have great enthusiasm to contribute to free software in areas which require such a wild and overwhelming mix of expertise that nobody is willing to step up to the plate. that's where i step in. Please find a way to communicate without annoying the rest of the list, i will be delighted to do so. in return, you - apple employees - will treat my contributions with a little more respect, and perhaps even apologise for some of the inappropriate treatment. or I will ask the list administrators to censor you from the mailing list for the period of at least a week. i'm sorry to have to say this but i promise you that that will do nothing but prove my point. _read_ what i've written. sticking fingers in ears will only get the ends of your fingers sticky, not solve the problem. sorry i have to go, baby's crying. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. dear ariya, i apologise for that. i invite you to consider this, especially in light of the subject being discussed: if there was not a deep seated problem with the way that apple is treating people who contribute to the webkit project, then my ire would not have been raised such that i felt it necessary to express my frustration using swearwords, would it? saying that again, in shorter form: if there were no problems with the patch process, there would be no swearing. so, if you would like to help contribute something, please help apple take into consideration the lessons learned from #16401 so that something like the absolutely appalling lack of respect shown for my contributions does not happen again. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: I concur with Maciej. Luke, in some other culture your posts are already considered derogatory and insulting. also - (i apologise for not thinking of this earlier) - it's worth emphasising that early on in the #16401 development process, when things were going well, the development was progressing rapidly, and i was collecting valuable contributions, advice and input from several sources, including apple employees as well as free software sources, i felt absolutely no need to swear. then, as the sheer scale of the work began to become clear to the reviewers, they began to feel overwhelmed, and, in an effort to reduce stress levels, began to throw up barriers. i began to provide technical counter-arguments and justifications for the progress, and still i did not feel any need to swear. i was asked to take several weeks worth of steps backwards, and began to feel pressurised: eight weeks at eleven hour days has a price. alp toker noticed that things were not going swimmingly and asked that the cost - financial and psychological - be taken into consideration. it was not. at this point, with rules and procedures and processes being placed over-and-above actual people, things started to break down. now we're suddenly gone from development being fun and exciting into development that is about fulfilling your duty and fulfilling the committment to the free software community that you serve, _especially_ in the face of continued hostility and complete lack of respect. this is the experience that you, apple, should never subject anyone to - should not be should not have been responsible for subjecting onto _anyone_. i trust that you, apple, will learn from this breakdown in communications. i trust that the changes to procedures and processes that you will make will help you to spot such things well in advance and act accordingly and appropriately, to make contributing to webkit as interesting and exciting as it should be. lastly, ariya, i've mentioned this elsewhere, but it's worth reiterating, here. as an experienced and gifted developer, i can take any code, from anywhere, and can pretty much immediately make useful contributions to it. i then also have the skills to manage, build and release that code. not everyone has the ability to do that. so i put up with a lot of flak from people such as apple employees in order to serve those users and developers who do _not_ have the ability that i do. and i invite you to ask yourselves: whom do _you_ serve? the answer to that question is the reason why i make the recommendation that webkit gets a charter. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On 7/13/09, Maciej Stachowiak m...@apple.com wrote: Hi Luke, I think your webkit-dev emails are becoming disruptive. Sending profanity-laced [apologised and explained already] walls of text maciej, i thought i'd best pick up on this one and nip it in the bud, even though i've replied already. look at what i wrote. it says that webkit is missing a charter, and cites the apache software foundation charter's key point of treating people with respect as part of the success of the ASF's development and progress. describing the very contribution in which i mention that respect for contributions is key as walls of text is therefore somewhat ironic, is it not, as it clearly says i have no respect for your contribution, yes? you might want to think about that, yes? and perhaps write a message saying, i apologise, i did not mean to convey disrespect, i was upset by the swearwords that you included, which, i also realise from what you've said they were provoked, but i was still upset. also i'd like to officially apologise on behalf of apple for apple employees subjecting you to personal attack and denigration when you were only trying to help contribute to webkit's success. something like that would go down well, and would be a good indication that apple recognises the root of the problem and is willing to engage with unpaid, unsponsored free software contributors in an appropriate and inclusory way. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: updated glib/gobject bindings patch
-- Forwarded message -- From: Luke Kenneth Casson Leighton l...@lkcl.net Date: Jul 12, 2009 9:49 PM Subject: updated glib/gobject bindings patch To: webkit-dev@lists.webkit.org this is worthwhile sending to the webkit-dev list, as i know that there are people following along. https://bugs.webkit.org/attachment.cgi?id=32633action=review for those people who would like to skip the patch webkit step, feel free to use http://github.com/lkcl/webkit/16401.master instead, you'll find it's a lot easier. for those people who may not be aware: the glib/gobject bindings patch is a significant strategic addition to webkit for the free software community. in combination for example with pywebkitgtk's #13 patch, it puts webkit on a par with python-xpcom + python-hulahop and _finally_ brings webkit up on a part with pykhtml [KHTML has had python bindings to its DOM for .. years]. also, as you can see (read further below), vala bindings have also been created for webkit. macosx users have had numerous dynamic language bindings to webkit for several years - except GNU/Darwin hasn't been keeping up-to-date with cocoa and other Objective-C frameworks, meaning that it's only macosx users that can take advantage of the incredible flexibility offered. free software platforms are excluded. which is why these glib/gobject bindings are so strategically important. as a consequence, it's important i believe to get them right, and to get them to put webkit on a par with its peers from a free software perspective, which are: * MSHTML (the engine behind IE) * XULRunner (the engine behind firefox) * KHTML (the engine behind KDE's Konqueror) * Opera (except that's proprietary and i can't find the language bindings) it's significant to note that of the available browser engines, 2/5 are proprietary, and 1/5 is only DOM level 2 compliant. so - with those insights in mind, here is what i posted on the patch, and i trust that people will be interested to move this strategically important issue forward. l. okaay, this is the 2 steps backwards, 1 step forwards patch which, as explained, cannot take into consideration adam's fantastic work because it was impossible for me to follow it. even _one_ feature removed (and the first that adam picked was event handling) meant that the test framework (pyjamas desktop) was totally cut off at the knees. dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way forward is to take this as-is and then to move forward from there. over what is likely to be a period of several months, retro-fix issues that have been raised and recorded will - should - be created. it would have been nice if people had listened to my advice on this months ago, but, not believing me, you had to find out for yourselves [by taking up adam's time as well as mine]. at least we're moving forward, now, rather than playing silly buggers. i'll be _more_ than happy to help review individual small dedicated controlled manageable single-purpose patches that anyone cares to contribute: perhaps by comparing the differences between what adam has done and what this patch provides it may make individuals' lives easier when it comes to updating this strategically critical area of functionality. there is a _lot_ still left to be done - but, butbutbut, what is here is _provably_ working. it would be very nice if it stayed that way, and that pyjamas-desktop, the only current project which utilised these bindings with near 100% code coverage, carried on working. still on the critical TODO list, after this patch is accepted (let alone any bug-fixes / coding-standards / review update work!) is: Enums, SVG 2D Canvas, and Exception handling. this latter is proving tiresome to not have, in pywebkitgtk (and pyjamas-desktop): several bugs could not be found in pyjamas-desktop until python-xpcom / XULRunner was added as an alternative back-end peer [to pywebkitgtk]. up until then, due to the lack of error reporting from runtime exceptions, style attributes and a few others just... silently vanished (fortunately with no useability impact, but that was down to luck). as requested, i've made review comments to https://bugs.webkit.org/show_bug.cgi?id=16401#c191 and https://bugs.webkit.org/show_bug.cgi?id=16401#c194 - the coding-standards issues i immediately fixed (as they're dead-easy) however there were issues raised that should have been raised eight months ago, when i had a complete map of the code and a handle on the 600+ auto-generated files in my head. i've answered them as best i can: now it's time to move on. one thing that can be seen from this patch: it includes LANGUAGE_GOBJECT as a #define. this is in for two separate reasons: 1) until someone can show me how to get a TextDocument object, in order to pass it to XMLHttpRequest.open(), for that reason and for that sole reason alone
Re: [webkit-dev] Patch process - let's make it better
Hi everyone, One common topic for discussion has been how to make our process around patch submission better. As the project grows, it's becoming more important for this process to work really smoothly, and we are seeing some breakdowns. well, this is interesting - some good timing on sending this message. i believe it would be reasonable to say that regarding #16401, breakdown would be an understatement of the first order. I've been doing a lot of thinking about this, and discussion with some project old hands. I think the right way to tackle this is to identify the process problems, and make sure we address each one. yes. perhaps, as i have been on the receiving end of some quite shit and unnecessary treatment, i can help give some insights here. 1) there is no charter for webkit. one absolutely vital thing which prevents problems is to have a charter which outlines, up-front, the expectations and development of the project. the apache foundation charter states clearly that: * developers shall treat each other with mutual respect. * contributions shall be considered on technical merit for the freedce foundation, after the samba fiasco in which continuous goal-post moving and technical bullying was utilised to make significant technical contributions - and their contributors - look like shit, we modified this to: * contributions shall be considered on strategic technical merit providing a charter clearly outlines an encouraging environment, and also allows you to gently - or forcefully - bring people back into line. in the case of webkit, then, a charter containing these vital guidelines would have stopped the disrespectful treatment i got absolutely dead in its tracks. if a free software developer says, no, i am a free software _contributor_, not a paid-up employee whom you can [effectively] _demand_ [sponge off]. i don't have time or money to give more than i have to get this issue dealt with, it ing well means no, you can't ask for more than i've already gifted to this project, and the people who were asking should, instead of getting stroppy, go oh - sorry, i apologise for that! i didn't mean in any way to etc. and generally indicate gratitude for, and respect for, the contributions made. read the comments on #16401 bearing in mind that they are _free_ and _unpaid_ contributions (not funded by any company or sponsor), and watch the breakdown in the conversation due to assumptions made by apple paid-up employees - it's very interesting reading. 2) there are no branches the KDE development process has what, over a hundred contributors. they don't step on each others' toes. why? because the committers are allowed to create branches. a branch, with relaxed conditions, allows people to collaborate BEFORE quotes landing quotes and still feel like they are part of the project. take the #16401 work as a classic example: with over 5,000 lines, not one of the groups of contributors could officially collaborate on improvements because the contributors had no central official place in which to collaborate, to meet the over-strict and far too time-consuming review requirements. also, if you look around, there are one hell of a lot of unofficial branches of webkit. i found _yet another one_ recently, this time by intel, as part of their 3D desktop project! intel should never have felt it necessary to create a separate repository: they should have been _invited_ to have commit rights. there are plenty of scripts out there that can protect commits to branches etc. so the main trunk can be protected. 3) the review process is hostile and confrontational. it even says, up-front, this process may seem daunting. that's got to stop. i would not be surprised if the confrontational approach is a hang-over from internal apple development ethos. it doesn't work in the free software world: if you're going to state, up-front, we're going to be tough on you, then potential contributors will just say sod you, then and walk away. 4) automation of coding standards checking this is trivial to do. hindent immediately springs to mind. it could even be added as a commit hook to trunk (leaving branches alone of course). 5) assumptions that people know where to read about webkit standards and processes there seems to be an assumption that people know all about webkit's standards, and irritation and in some cases outright hostility when people with enthusiasm and the willingness to contribute simply are not aware of these standards. 5) assumptions that people know where to read about webkit standards and processes there seems to be an assumption that people know all about webkit's standards, and irritation and in some cases outright hostility when people with enthusiasm and the willingness to contribute simply are not aware of these standards. why _should_ they be? where in the world is it made
[webkit-dev] opera unite api: extensions to add web server capability to browser engines
http://dev.opera.com/libraries/unite/
this is a stunningly cool idea, so much so i had to let people know
about it and invite webkit developers (i'll ping the mozilla ones
separately) to provide an implementation, too. the key bit is best
hinted at from http://dev.opera.com/articles/view/opera-unite-developer-primer/
- exerpt here:
The request event listeners
A Web server handles requests from clients and sends reponses back to
them. The Opera Unite Web server is event-based and will raise a DOM
event in the service every time a Web browser makes a connection to
the server asking for files related to the Opera Unite Service. In
order to respond to such events, we need to set up event listeners.
This is done in window.onload:
var webserver;
var entries = [];
window.onload = function () {
webserver = opera.io.webserver
if (webserver)
{
//Handle requests for various URLs
webserver.addEventListener('_index', showEntryList, false);
webserver.addEventListener('entry', showEntry, false);
webserver.addEventListener('form', showForm, false);
webserver.addEventListener('save', saveEntry, false);
}
}
What is going on here?
We are checking if the service is actually a Web service, by checking
for the webserver object. If it is present, we add four event
listeners _index, entry, form and save.
The code for the _index request, the showEntryList function, is quite
simple. When receiving a request, it writes back a HTML page with a
list of the saved entries.
function showEntryList(e)
{
var response = e.connection.response;
response.write( '!DOCTYPE html'
+ 'htmlheadtitleEntries/title/head'
+ 'bodyul'
);
for ( var i = 0, entry; entry = entries[i]; i++ )
{
response.write('li'+entry.date+': a
href=entry?id='+i+''+entry.title+'/a/li');
}
response.write('/ul'
+ 'pa href=formAdd en entry/a./p'
+ '/body/html'
);
response.close();
}
in other words, this really is an actual implementation of a web
server - in javascript - as part of the opera browser engine itself.
implementation details of the proxy service, operaunite.com, are
understandably sketchy. it provides firewall-busting technology which
duh is kinda important to have, otherwise everyone running private web
services in their browser are completely inaccessible.
i can think of a ton of uses for this, well beyond just a few web
pages. if implementations are made truly peer-to-peer (and not
dependent on operaunite.com) then ... dang.
imagine for example the combination of xmpp, unite, and google wave services.
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines
http://davidkellogg.com/wiki/Main_Page it turns out that there already exists a firefox extension which adds only web server functionality to the firefox web browser (and any other XUL engine). what POW (plain old web server) doesn't have is firewall-busting technology built-in - therefore no peer-to-peer capabilities. that would appear to leave webkit as the one browser engine which doesn't have this feature. looking around, it would appear that implementing extensions to webkit are expected to utilise objective-c only. [there is a good reason why mozilla went for COM - it's accessible and easily extensible across a wide range of free software languages and environments]. l. On 6/16/09, Luke Kenneth Casson Leighton l...@lkcl.net wrote: http://dev.opera.com/libraries/unite/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines
On 6/16/09, Oliver Hunt oli...@apple.com wrote: unite is a browser feature, not an engine feature and as such it would not be appropriate for it to be implemented as part of WebKit. great! webkit gets left behind, as technology moves forward. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines
Um. Unite is not part of rendering, layout or javascript. It is part of the browser. WebKit is not a browser. It is a browser engine. ... a browser engine where the javascript namespace / DOM namespace that can be extended? Could you explain how unite represents part of rendering, layout or the DOM? you're nit-picking. perhaps a better question is, instead of saying it's not possible, it's not possible, is to ask: how can the javascript namespace be extended? how can objects be dropped into the global javascript namespace [such as how google added google.gears into the namespace] how can those objects be dropped into the global namespace _without_ having to recompile webkit? how can those objects be dropped into the global namespace in a generic fashion using free software tools _without_ requiring a boat-load of apple-only [near-proprietary] technology [i.e. without requiring objective-c] thanks to COM, and thanks to the design of the mozilla XUL system, developers of firefox extensions can drop objects into the global namespace at will, without having to ask the mozilla developers to drop everything and add some random extensions. why? because gecko itself is just _one_ of the technologies that is added to the global namespace, and adding more is dead-easy, and can be done even by a random plugin developer. now. how the heck does anyone do that with webkit? correction: how does anyone get some object into the global namespace that will sit side-by-side next to document. and window. and all other global objects? l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GDOM-Binding: using gdom_css_style_sheet_add_rule()
On 6/10/09, Leon Winter l...@ring0.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
the GDOM-Binding provides functions for setting up global CSS rules
and manipulating them. I'm interested in this functions, especially in:
WEBKIT_API glong
gdom_css_style_sheet_add_rule (GdomCSSStyleSheet *thiz, gchar *
selector, gchar * style, gulong index);
Okay, we need a GdomCSSStyleSheet, lets have a look:
WEBKIT_API GdomCSSStyleSheet *
gdom_dom_implementation_create_css_style_sheet (GdomDOMImplementation
*thiz, gchar * title, gchar * media);
So far so good, seems we need a GdomDOMImplementation object but there
is no function that returns this object.
function, no, property, yes.
$ grep DOMImplementation */*/*.idl */*/*/*.idl
WebCore/dom/Document.idl:readonly attribute [V8Custom]
DOMImplementation implementation;
WebCore/dom/DOMImplementation.idl:] DOMImplementation {
WebCore/dom/DOMImplementation.idl:// DOMImplementationCSS
interface from DOM Level 2 CSS
WebCore/dom/DOMImplementation.idl:// HTMLDOMImplementation
interface from DOM Level 2 HTML
WebCore/page/DOMWindow.idl://attribute
DOMImplementationListConstructor DOMImplementationList;
WebCore/page/DOMWindow.idl://attribute
DOMImplementationSourceConstructor DOMImplementationSource;
WebCore/page/DOMWindow.idl:attribute
DOMImplementationConstructor DOMImplementation;
WebKit/win/Interfaces/DOMCore.idl:@interface DOMImplementation : DOMObject
WebKit/win/Interfaces/DOMCore.idl:interface IDOMImplementation : IDOMObject
WebKit/win/Interfaces/DOMCore.idl:- (DOMImplementation *)implementation;
WebKit/win/Interfaces/DOMCore.idl:HRESULT implementation([out,
retval] IDOMImplementation** result);
WebKit/win/Interfaces/WebKit.idl:#include IGEN_DOMDOMImplementation.idl
the top one is the clue. ignore the [V8Custom] modifier flag, that
just says that when doing google v8 engine, there's a custom
implementation of the function that fetches that property.
so:
GdomDocument *doc = get_dom_document();
GdomDOMImplementation *di;
GdomCSSStyleSheet *css;
g_object_get(doc, implementation, di, NULL);
css = gdom_dom_implementation_create_css_style_sheet (di, title, media);
g_object_unref(di);
g_object_unref(css);
g_object_unref(doc);
try that.
i'd be interested to see a successful creation of an example like
this: these things are a bit new, and collecting some working examples
would help people a lot.
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] GObject Code Generator constants handling code to be added
On 6/10/09, Leon Winter l...@ring0.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
so if you delete the .lo then the build process happily recreates
the .o
Actually it was rm DerivedSources/JS*.lo. Thanks for all your help
so far.
yaay.
Here is a working XPath sample:
yaay!
res = gdom_document_evaluate(doc, exp, body, resolver, 0, NULL);
Next thing interesting thing would be knowing how to set fifth arg for
gdom_document_evaluate which is an enum that controls the output
order. As far as I know the enum is not exported via binding so at the
moment we have to set this value by hand.
ahh, yerrs... hmmm... that will require adding more code to #16401,
which will result in yet more objections as the size of the patch will
increase. well, tough: it should have been landed months ago.
i'll look at a way to find and create some enums.
l.
Just for the record, the values can be found here:
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/WebKitDOMRef/XPathResult_idl/Classes/XPathResult/index.html#//apple_ref/js/clconst/XPathResult/ORDERED_NODE_ITERATOR_TYPE
thank you for helping, leon :)
they're in the IDL file (in this case, WebCore/xml/XPathResult.idl) :
module xpath {
interface [GenerateConstructor, Conditional=XPATH] XPathResult {
const unsigned short ANY_TYPE = 0;
const unsigned short NUMBER_TYPE= 1;
const unsigned short STRING_TYPE= 2;
const unsigned short BOOLEAN_TYPE = 3;
const unsigned short UNORDERED_NODE_ITERATOR_TYPE = 4;
const unsigned short ORDERED_NODE_ITERATOR_TYPE = 5;
const unsigned short UNORDERED_NODE_SNAPSHOT_TYPE = 6;
const unsigned short ORDERED_NODE_SNAPSHOT_TYPE = 7;
const unsigned short ANY_UNORDERED_NODE_TYPE= 8;
const unsigned short FIRST_ORDERED_NODE_TYPE= 9;
so what is needed is just some quick modifications to the
CodeGeneratorGObject.pm which spits the constants out into the header
file.
does anyone have any suggestions as to the best way to proceed? any
conventions of prefixes that should be added to the constants? is
there a webkit-preferred convention that should be followed? is there
a glib / gobject convention that should be followed?
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit #16401
[hiya sean, moving this to webkit-dev as other people may benefit from it, hope you don't mind] On 6/9/09, Sean Neilan s...@seanneilan.com wrote: I'm almost there! snei...@myhost:~/Desktop$ gcc main.c -o main `pkg-config --cflags --libs webkit-1.0` main.c: In function ‘print_attribute’: main.c:191: warning: passing argument 2 of ‘gdom_named_node_map_get_named_item’ discards qualifiers from pointer target type /usr/local/include/webkit-1.0/gdom/GdomNamedNodeMap.h:42: note: expected ‘gchar *’ but argument is of type ‘const gchar *’ main.c:191: warning: assignment from incompatible pointer type ok - that means that you've successfully linked etc. and that the webkit-1.0 pkg-config is picking up header files _probably_ from the right location. i assume you didn't do ./configure with a --prefix=/usr option somewhere, which would mean that your locally-compiled version of webkit has ended up by default in /usr/local/lib and the headers in /usr/local/include/webkit-1.0 snei...@myhost:~/Desktop$ ./main ./main: symbol lookup error: ./main: undefined symbol: webkit_web_frame_get_dom_document ok - that means that you likely have two versions of the webkit library on your system. you successfully compiled against the first, which has the gdom bindings functions in it (hence no compile warnings) but, if you look in /etc/ld.so.conf you'll likely find that /usr/local/lib isn't first. consequently, and because the revision number is the same, it is likely that when the test app ran, it picked up the version of libwebkit-1.0.0 in /usr/lib, which of course doesn't have webkit_web_frame_get_dom_document in it and so the error is expected behaviour as per the setup. here's a few solutions: 1) remove the system-wide version of webkit from /usr/lib 2) edit ld.so.conf to put /usr/local/lib first (i _think_ this works...) 3) there might be some tricks you can play with LD_LIBRARY_PATH 4) re-run autogen.sh or just configure with --prefix=/usr and make install bear in mind that this will _overwrite_ the system-wide version of webkit so only do this if it won't interfere with anything you're already using. other people may be able to recommend some other tricks - but first can you confirm that you indeed have two versions of webkit installed? l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
Just grabbed the latest git. make complains about that: ar: DerivedSources/.libs/JSCSSCharsetRule.o: No such file or directory yeah, i got that too - bizarre that you repeated it. it's because the .lo file exists but the .o does not. so if you delete the .lo then the build process happily recreates the .o do rm DerivedSources/.libs/JS*.lo and then make. if that _really_ doesn't work then do make clean - failing that, make distclean. btw you really should install ccache it will save a ton of time. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit #16401
[moving this discussion to webkit-dev] On 6/7/09, Leon Winter l...@ring0.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tried to port my javascript further in order to find new issues and I found some as expected: Luke, in your example main.c you use the custom function get_absolute_top() in order to compute the absolute distance to the top. It seems thats currently the only way but it shouldnt since we have the excellent getBoundingClientRect() function on every DOM element in JavaScript and it would make a lot of sense do provide this function aswell in the binding. Using this function we can access the distance the top directly because the engine computed it anyway before in order to display. I searched for this function in the binding but did not find it, however there is GdomRect which one should gain via GdomCSSPrimitiveValue. However there are no functions to access GdomRect and there is no constructor for GdomCSSPrimitiveValue. ok. the getBoundingClientRect function is declared as a javascriptism, and is therefore declared as Not Part Of The Vision For Webkit Language Bindings As Dictated By Apple The Great Fascist Leaders All Hail Apple And Bow Before Them For They Expect Us To Obey Them Without Question let's have a look at this, in other implementations: https://developer.mozilla.org/En/DOM:element.getBoundingClientRect yes, mozilla has getBoundingRectClient. let's double-check whether that's actually available, by trying an actual real-world test in e.g. mozilla-xpdom / python-hulahop. modify the source in http://lkcl.net/pyjamas/pyjamas-xpdom.tgz as follows: n = doc.createTextNode(hello) print n body = doc.getElementsByTagName(body).item(0) body.appendChild(n) print body.getBoundingClientRect() ^^ run it, and yes, we get this: XPCOM component 'unknown' (implementing nsIDOMClientRect) so yes, in the firefox Gecko / XUL engine, competitor to webkit, it can be deduced to support this function across all language bindings. from the same web page, it is quoted: getBoundingClientRect() was first introduced in the MS IE DHTML object model. ok - that's a DCOM interface. and through DCOM, you can bind any language to DCOM that has a DCOM support library (python-win32com, visual basic, visual c++, visual .NET etc.) what about KDE? i'd be surprised if KHTML had it, but hey, i like surprises. http://developer.kde.org/documentation/library/3.4-api/khtml/html/classDOM_1_1Element.html ehhh, no. they've implemented most of DOM level 1 and 2, bless them. DOM level 3 isn't on the roadmap, and CSSOM most certainly isn't. what about opera? hhmmm, they implement DOM level 3 and various recommendations, and also, ah ha! http://my.opera.com/edvakf/blog/2008/10/16/opera-9-60 a poorly-implemented version of getBoundingClientRect. there _seems_ to be some hints that their API has other language bindings - an article said javascript, java, or perl god help us. what about webkit? vi WebCore/dom/Element.idl #if defined(LANGUAGE_JAVASCRIPT) LANGUAGE_JAVASCRIPT // CSSOM View Module API ClientRectList getClientRects(); ClientRect getBoundingClientRect(); #endif no. so, your answer, leon: if you want getBoundingClientRect in the gdom glib/gobject bindings, you're going to have to fight for it. good justifications for adding it include: * it's in every other web engine technology that implements this level of W3C standards (CSSOM?) * every other web engine technology makes the functions that are available to javascript _also_ available to all other language bindings. comments from apple as to why this function is restricted to just javascript are requested. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit #16401
[again, posting to webkit-dev for benefit of other developers] The event listeners/callbacks seems to be broken: g_signal_connect (G_OBJECT (div), browser-event, G_CALLBACK (dispatch_event_cb), div); According to gcc dispatch_event_cb() takes no args, which is bad since there is no way to get details about the event. yep - i just ran that example main.c (http://lkcl.net/webkit/main.c) and i get this, when clicking on the click me to see hrefs words. (test2:9403): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.18.4/gobject/gsignal.c:3075: signal name `browser-event::click' is invalid for instance `0xcf3b70' so - yeah, whoops, something wrong there. not surprising, because this area of functionality (event handling) has changed. i'll be looking at it today, find out what's going on. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Working XPath example via GDOM-Binding
so if you delete the .lo then the build process happily recreates the .o Actually it was rm DerivedSources/JS*.lo. Thanks for all your help so far. yaay. Here is a working XPath sample: yaay! res = gdom_document_evaluate(doc, exp, body, resolver, 0, NULL); Next thing interesting thing would be knowing how to set fifth arg for gdom_document_evaluate which is an enum that controls the output order. As far as I know the enum is not exported via binding so at the moment we have to set this value by hand. ahh, yerrs... hmmm... that will require adding more code to #16401, which will result in yet more objections as the size of the patch will increase. well, tough: it should have been landed months ago. i'll look at a way to find and create some enums. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Working XPath example via GDOM-Binding
I forget to mention the console output during execution: (test:32645): GLib-GObject-CRITICAL **: g_param_spec_double: assertion `default_value = minimum default_value = maximum' failed (test:32645): GLib-GObject-CRITICAL **: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed yehh, i'm not sure where they come from. can you raise them as a bugreport, dependent on #16401, as low priority, for investigation at some point, so they're not forgotten about? l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
[taking this discussion onto webkit-dev for the benefit of other people who may wish to use the glib / gobject bindings in the future] On 6/6/09, Leon Winter l...@ring0.de wrote: Hi, @Luke: how is XPath supposed to work? GdomXPathResult *res; GdomXPathEvaluator evaluator; char *exp = //html:a; GdomDocument *doc = get_dom_document(); GdomNodeList *els = gdom_document_get_elements_by_tag_name(doc, body); GdomNode *body = gdom_node_list_item(els, 0); GdomXPathNSResolver *resolver = gdom_x_path_evaluator_create_ns_resolver(evaluator, body); segfaults right at the last line. I found new creation methid for GdomXPathEvaluator, perhaps there should be one. ok - thanks to mark rowe for highlighting the deliberate mistake: https://bugs.webkit.org/show_bug.cgi?id=16401#c202 the first argument to any of the glib / gobject bindings needs to be the object of the type which matches the IDL class from which the function was auto-generated, so: this function in Document.idl: XPathNSResolvercreateNSResolver(in Node nodeResolver); results in a function in GdomDocument.h: WEBKIT_API GdomXPathNSResolver * gdom_document_create_ns_resolver (GdomDocument *thiz, GdomNode * node_resolver); so as you can see, you have passed in an (uninitialised!) pointer to GdomXPathEvaluator evaluator, not a pointer to the GdomDocument object - hence the segfault. try this instead: GdomXPathNSResolver *resolver = gdom_x_path_evaluator_create_ns_resolver(doc, body); l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
On 6/8/09, Leon Winter l...@ring0.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, GdomXPathNSResolver *resolver = gdom_x_path_evaluator_create_ns_resolver(doc, body); l. Yeah minor mistake from my side (sorry for that), anyway it segfaults since we cannot initialize GdomXPathEvaluator (as told before). does anyone else have any experience of using XPath from e.g. objective-c bindings which would help leon out in being able to create a glib / gobject example, that could then be used both in the free software project that he is creating, that uses the glib / gobject bindings, and also be used to test XPath from the glib / gobject bindings? l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
On 6/8/09, Leon Winter l...@ring0.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon Winter wrote: Hi, GdomXPathNSResolver *resolver = gdom_x_path_evaluator_create_ns_resolver(doc, body); l. Yeah minor mistake from my side (sorry for that), anyway it segfaults since we cannot initialize GdomXPathEvaluator (as told before). Regards, Leon Winter Hi, I just checked the header-files and I found out, that it was not my mistake actually, since there are two functions: WEBKIT_API GdomXPathNSResolver * gdom_x_path_evaluator_create_ns_resolver (GdomXPathEvaluator *thiz, GdomNode * node_resolver); WEBKIT_API GdomXPathNSResolver * gdom_document_create_ns_resolver (GdomDocument *thiz, GdomNode * node_resolver); Anyway we cannot use XPath at the moment because we need a (GdomXPathEvaluator object: WEBKIT_API GdomXPathResult * gdom_x_path_evaluator_evaluate (GdomXPathEvaluator *thiz, gchar * expression, GdomNode * context_node, GdomXPathNSResolver * resolver, gushort type, GdomXPathResult * in_result); not being funny or anything, but are you _sure_ you need a GdomXPathEvaluator object? if you look in GdomDocument.h, yo can see this: WEBKIT_API GdomXPathResult * gdom_document_evaluate (GdomDocument *thiz, gchar * expression, GdomNode * context_node, GdomXPathNSResolver * resolver, gushort type, GdomXPathResult * in_result); which again looks pretty damn similar to the [isolated and inaccessible] gdom_x_path_evaluator_evaluate function, to me :) cut/pasting in another [relevant] discussion into this one thread: [] Erm, nope. The initial code was: GdomXPathResult *res; GdomXPathEvaluator evaluator; char *exp = //html:select; GdomDocument *doc = get_dom_document(); GdomNodeList *els = gdom_document_get_elements_by_tag_name(doc, body); GdomNode *body = gdom_node_list_item(els, 0); GdomXPathNSResolver *resolver = gdom_x_path_evaluator_create_ns_resolver(evaluator, body); // segfaults because we cannot init evaluator And I quote myself (mail from 2009-06-07 01:18 in my UTC+1 timezone) segfaults right at the last line. I found new creation methid for GdomXPathEvaluator, perhaps there should be one. I mentioned GdomXPathEvaluator :) ok, let me try and walk it through. in GdomXPathEvaluator.h, you have this: WEBKIT_API GdomXPathNSResolver * gdom_x_path_evaluator_create_ns_resolver (GdomXPathEvaluator *thiz, GdomNode * node_resolver); and in GdomDocument, mark indirectly points out that you have this: WEBKIT_API GdomXPathNSResolver * gdom_document_create_ns_resolver (GdomDocument *thiz, GdomNode * node_resolver); so - uhnnn.. oh. ah. oops. ok - can anyone explain what the difference between an XPathNSResolver return result from Document.createNSResolver and from XPathEvaluator.createNSResolver is? can leon just use gdom_document_create_ns_resolver() and basically completely ignore the (self-contained and apparently isolated) XPathNSEvaluator class and (inaccessible) functions? GdomXPathResult *res; char *exp = //html:select; GdomDocument *doc = get_dom_document(); GdomNodeList *els = gdom_document_get_elements_by_tag_name(doc, body); GdomNode *body = gdom_node_list_item(els, 0); GdomXPathNSResolver *resolver = gdom_document_create_ns_resolver(doc, body); /* now you use this */ res =gdom_document_evaluate (doc, expression, GDOM_NODE(context_node), resolver, gushort type, in_result); */ btw leon, it's worth reiterating: you really must use pointers to glib objects, they get refcounted and automatically freed etc. etc. if you put stuff on the stack like this: GdomXPathEvaluator evaluator; you will get into an awful mess. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
Well I tried:
GdomXPathResult *res;
char* exp = //html:select;
GdomDocument *doc = get_dom_document();
GdomNodeList *els = gdom_document_get_elements_by_tag_name(doc,
body);
GdomNode *body = gdom_node_list_item(els, 0);
GdomXPathNSResolver *resolver =
gdom_document_create_ns_resolver(doc, body);
g_warning(init completed);
gdom_document_evaluate(doc, exp, GDOM_NODE(body), resolver, 0, res);
The warning is printed followed by a segfault.
gdb told me (relevant parts):
#0 0x7fb6215ea058 in g_type_check_instance_cast () from
/usr/lib/libgobject-2.0.so.0
#1 0x7fb623d21cb9 in WebKit::core () from
/usr/local/lib/libwebkit-1.0.so.2
#2 0x7fb623cc55ab in gdom_document_evaluate () from
/usr/local/lib/libwebkit-1.0.so.2
It seems like an argument is broken.
hmm, i'm guessing it's the uninitialised last argument (from the
g_type_check_instance_cast) but it could equally, athough unlikely, be
the body arg.
you really need to recompile some of these object files with debug
info. try rm DerivedSources/gdom/*GdomDocument*.lo, do export CXX=gcc
-g -g, re-run configure etc. that will get you _just_ debug info in
the gdom_document_* functions which will be enough for the purposes
here, without forcing you to recompile absolutely damn everything.
but yes - try NULL on that last argument (just a guess, here) err
nope, no can do, there - take a look at
DerivedSources/gdom/GdomDocument.cpp:
GdomXPathResult *
gdom_document_evaluate (GdomDocument *thiz, gchar * expression,
GdomNode * context_node, GdomXPathNSResolver * resolver, gushort type,
GdomXPathResult * in_result)
{
WebCore::XPathResult * _g_in_result = WebKit::core(in_result);
g_return_val_if_fail (_g_in_result, 0);
}
so - nope, in_result cannot be NULL, and you absolutely must _not_
pass in an uninitialised variable, either.
so - you're going to have to find a GdomXPathResult instance from somewhere.
keep looking around for documentation on this function, i'll do
likewise: if anyone has anything to contribute that can help leon out,
it would be appreciated.
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
On 6/8/09, Luke Kenneth Casson Leighton l...@lkcl.net wrote:
Well I tried:
GdomXPathResult *res;
char* exp = //html:select;
GdomDocument *doc = get_dom_document();
GdomNodeList *els = gdom_document_get_elements_by_tag_name(doc,
body);
GdomNode *body = gdom_node_list_item(els, 0);
GdomXPathNSResolver *resolver =
gdom_document_create_ns_resolver(doc, body);
g_warning(init completed);
gdom_document_evaluate(doc, exp, GDOM_NODE(body), resolver, 0, res);
The warning is printed followed by a segfault.
gdb told me (relevant parts):
#0 0x7fb6215ea058 in g_type_check_instance_cast () from
/usr/lib/libgobject-2.0.so.0
#1 0x7fb623d21cb9 in WebKit::core () from
/usr/local/lib/libwebkit-1.0.so.2
#2 0x7fb623cc55ab in gdom_document_evaluate () from
/usr/local/lib/libwebkit-1.0.so.2
It seems like an argument is broken.
hmm, i'm guessing it's the uninitialised last argument (from the
g_type_check_instance_cast) but it could equally, athough unlikely, be
the body arg.
you really need to recompile some of these object files with debug
info. try rm DerivedSources/gdom/*GdomDocument*.lo, do export CXX=gcc
-g -g, re-run configure etc. that will get you _just_ debug info in
the gdom_document_* functions which will be enough for the purposes
here, without forcing you to recompile absolutely damn everything.
but yes - try NULL on that last argument (just a guess, here) err
nope, no can do, there - take a look at
DerivedSources/gdom/GdomDocument.cpp:
GdomXPathResult *
gdom_document_evaluate (GdomDocument *thiz, gchar * expression,
GdomNode * context_node, GdomXPathNSResolver * resolver, gushort type,
GdomXPathResult * in_result)
{
WebCore::XPathResult * _g_in_result = WebKit::core(in_result);
g_return_val_if_fail (_g_in_result, 0);
}
so - nope, in_result cannot be NULL, and you absolutely must _not_
pass in an uninitialised variable, either.
so - you're going to have to find a GdomXPathResult instance from somewhere.
keep looking around for documentation on this function, i'll do
likewise: if anyone has anything to contribute that can help leon out,
it would be appreciated.
from a random google search, leading to this:
http://www.faqts.com/knowledge_base/view.phtml/aid/34022
a code snippet is this:
// test with no prefix doesn't find nodes:
var xpathResult = xmlDocument.evaluate(
//element,
xmlDocument,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
showing that yes, it should be possible to pass in NULL as that last argument.
hmmm, ok, gimme 1 sec, i'll just update CodeGeneratorGObject.pm so it
can accept NULL arguments and pass them on...
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] gdom_x_path_evaluator_create_ns_resolver [was: webkit #16401]
from a random google search, leading to this: http://www.faqts.com/knowledge_base/view.phtml/aid/34022 a code snippet is this: // test with no prefix doesn't find nodes: var xpathResult = xmlDocument.evaluate( //element, xmlDocument, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null ); showing that yes, it should be possible to pass in NULL as that last argument. hmmm, ok, gimme 1 sec, i'll just update CodeGeneratorGObject.pm so it can accept NULL arguments and pass them on... ok - try a git pull from http://github.org/lkcl/webkit/16401.master - i've disabled the g_return_val_if_fail() macros so that NULL can be passed in to all arguments - if you get a segfault somewhere in WebKit core code, you know you shouldn't have passed in one of the arguments as NULL :) try this: res = gdom_document_evaluate(doc, exp, GDOM_NODE(body), resolver, 0, NULL); or even this: res = gdom_document_evaluate(doc, exp, NULL, resolver, 0, NULL); l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] #16401 webkit glib / gobject bindings
the purpose of this message is to highlight to webkit users and developers the increased flexibility and reach of webkit when it is extended to programming languages other than c++ and javascript. appcelerator is one project that has stated clearly on its roadmap the provision for python and ruby bindings to its API, and thus should be paying particular attention. google (for android), should be paying attention in order to optimise application development where webkit is used as a front-end, as java bindings to the glib/gobject bindings would result in a performance increase of applications that would otherwise be forced to be implemented in javascript, on a platform (android) where performance is of absolute paramount importance. adobe should be paying attention if it wishes to extend adobe AIR to other languages, such as vala, python, ruby, java, perl etc. for all these projects, glib / gobject bindings to the webkit DOM model represent the best, quickest, most portable and the most flexible way to add language bindings. in the python case, thanks to pygtk's codegen which is a well-established, long-standing and extremely successful way to auto-generate python bindings to glib / gobject bindings, it took as little as 6 hours to create 1,500 functions and 350 python classes - most of which was spent going err how does codegen work, and how do i get it to accept header files to make a useable .defs file? so - vala bindings have been done here: https://bugs.webkit.org/attachment.cgi?id=27558 and python bindings have been done here: http://code.google.com/p/pywebkitgtk/issues/detail?id=13 [ruby unfortunately doesn't have an equivalent to codegen for python-gtk. incredibly and unbelievably, the ruby-gtk developers wrote 45,000 lines of gtk2 bindings code BY HAND, which is completely crazed, given that codegen.py exists and proves the concept, and given that ruby and python are quite similar dynamic languages.] why should there be language bindings to webkit anyway? well, perhaps that question is best asked of the OLPC SUGAR team, who abandoned the use of webkit and settled on XUL, precisely _because_ it has an understandable and language-independent interface (based on COM), on top of which python bindings could easily be added, in two stages (via python-xpcom), resulting in python-hulahop: http://wiki.laptop.org/go/HulaHop python-hulahop is the competitor to pywebkitgtk [with patch #13 applied to pywebkitgtk and #16401 applied to webkit] what have the OLPC developers been able to do that can't be done unless you have DOM bindings? they've written the web browser _in_ python. entirely. and then some. whilst they haven't actually done any DOM (web page) manipulation (which is tricky to get right) as demonstrated here: http://lkcl.net/pyjamas/pyjamas-xpdom.tgz they _have_ hooked in to things like DOM event management and event handling. why can't i just use the objective-c bindings to get python, ruby, etc. access? well - you can. good luck with that. no - seriously, why can't i just use the objective-c bindings? you can - it's just that the only platform on which there is well-known and significant use of objective-c is: apple mac. and, not least is the fact that the objective-c language bindings are specifically restricted to conform to the W3C DOM specification, despite that standard having been demonstrated as an unrealistic ideal that doesn't stack up against real-world requirements and real-world implementations. [the W3C DOM specification itself is full of comments stating how it should be done, right next to statements about how specific browsers _actually_ work. apple's objective-c bindings conform to how it _should_ be done]. so - you can perfectly well use objective-c, and from there you can get automatic and dynamic access to the language bindings, as _long_ as you pull in a whole bunch of infrastructure that has really only been tried and tested on the macosx platform. ... or, you can back the proven tried-and-tested portable platform-independent glib / gobject library, and write an auto-generator that will create language bindings of your choice (as demonstrated by both the vala and the python bindings). so - all this sounds great! developers get to write applications in their preferred programming language, instead of being forced to write javascript or c++ - sounds idyllic! what's the status? a synopsis of the 199 prior comments is here: https://bugs.webkit.org/show_bug.cgi?id=16401#c200 summary: it's not good. apple's developers have been both incredibly helpful and also incredibly UNhelpful, both at the same time. often exactly the same person. adding language bindings on top of an API that has 450 nearly 500 objects, 2,500 functions and over 20,000 individual properties is... deeply and hideously convoluted. it took nearly eight weeks of non-stop 11 hour days to get the bindings to the position that they are in (fully working, and useful). it was only by
Re: [webkit-dev] WebKit partial rendering issue
On Fri, May 15, 2009 at 5:29 PM, David Hyatt hy...@apple.com wrote: On May 15, 2009, at 12:18 PM, lkcl wrote: https://bugs.webkit.org/show_bug.cgi?id=25696#c2 thanks to paul for the guidance and for the leading work / patches on which this is based, paul, the code that you sent me has a bug where the scrollbars on a frame will go blank and disappear when you move the mouse over them. the reason is that the empty rect causes the return out of the paint function, prematurely, i fixed this by allowing the scrollbars always to be painted. if anyone can think of a better way to do this other than to comment out code (even though it can be demonstrated as completely broken) that'd be great. There is nothing wrong with the code in ScrollView.cpp that I can see, so I'm not sure why commenting out code would be necessary. it was the quickest fix possible that i could find - thank you for the suggestion on setting the can blit on scroll flag to false, i'll try to work that into the customers' app. might have to add it to the gtk gobject interface if it's not already there. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] libsoup
On Tue, Feb 24, 2009 at 6:34 PM, Christian Dywan christ...@twotoasts.de wrote: Hey, note that some time ago the WebKitGtk hackers decided to drop support for libcurl and always work with libsoup. ohh. ... same difference? :) If you check out the source from the repository by now, you have to build with libsoup. The idea is that you want to be able to access the network implementation and by far the most effecient approach is to expose the SoupSession* and SoupMessage* objects where appropriate. So you don't have to fork or customize anything. Support for custom URI schemes is planned in libSoup for the future. okaaay. excellent. run-time loadable? so it would be possible to e.g. do a python plugin? Further more Glib is going to support networking functionality. intriguing. if that goes through to gobject so you could pass in an object into webkit (or libsoup) which conforms to a standard [networking] interface that would be _very_ interesting. And you don't depend on WebKit supporting a particular feature. If your use case is missing, file a feature request, the libSoup maintainer is a nice person :) :) run-time access to anything-conceivable, in any language. standardised interface of course. so, imagine an application which ohh, i dunno - redefines what http:// actually _is_. or it performs virus-checking or spam-filtering, or does rewrites, stripping out certain kinds of javascript before letting it get to the webkit application. or, it takes care of this SSL security bug that was announced last week, by pre-analysing the URL and forcing certain web sites to go through https instead of the silly mixture of http + https as is done at the moment. that sort of thing is neither libsoup's job nor is it webkit's job, but it's still essential and/or conceivable, and the design of neither libsoup nor webkit should restrict or impose on anyone who wants to do that kind of complex data analysis. at the moment, the only way to do that kind of thing is to have a proxy - but then you have to point the web browser at the proxy, and also, if you get any URLs that the proxy isn't designed to cope with, or if in fact libsoup tries to load URLs direct, because they are e.g. ftp:// and the web browser was only configured to point at an http:// proxy, you're screwed. so putting in a proxy doesn't cut the mustard. so the feature i'd like to see in libsoup is: _everything_ goes through to a dynamically-loadable module and i _mean_ everything. if there isn't a dynamic module loaded (by libsoup) then the default behaviour is the current behaviour. otherwise, the dynamic loadable module gets the chance to call all the shots. in that way, a dynamic loadable module - chosen by the _user_, even at runtime - can do whatever it likes to the URLs. to the data. personally i'd use that to create a python module which merges file:// in with http:// in order to load the startup html file from the user's desktop with the AJAX locations i.e. make file:///home/user/myapplication/ a legal location. i'd also make it possible for python-based CGI scripts to be executable as if they were http. in other words (and this only just occurred to me!) i'd cut out the middle-man - the web server - entirely from the loop. the situation is this (bear with me) * i've got pywebkitgtk doing DOM model manipulation, now, so it's possible to (like Adobe AIR / Flex) directly manipulate the DOM model using languages other than javascript. including, from python, asking for Web Pages using XmlHttpRequest. actually, gdom_xml_http_request_open() because it's gobject bindings. * via the python bindings, executing gdom_xml_http_request_open() results in calls through to libsoup, which ah no, you see it _doesn't_ result in a call to libsoup, because i just loaded the application from file:///home/lkcl/apps/testajaxapp.html and so WebKit goes HAH! GOTCHA! THAT'S A SECURITY RISK! LOADING AJAX FROM file:// IS BAAD. * so, first off, i have to create a fake version of http:// using my very own special (non-existent at the moment) libsoup dynamically-loadable module - written in python - which goes http:// ? no no nooo, i don't think so - let's check the filesystem /home/lkcl/apps/ first. * then, when gdom_xml_http_request_open() goes http://apps/server;, that is now a _completely_ non-existent URL, but that's ok _because_: * again, the python module that's loaded by libsoup goes http://apps? that's for meee! and it then looks in /home/lkcl/apps/server and guess what? it finds that there's a cgi-bin script (or a django app, or a WSGI python app) which the python module DIRECTLY RUNS in order to obtain the http content! in other words, you're _cutting out_ the web server! the python module (dynamically loaded by libsoup) _is_ the web server. this is the final piece in the puzzle that i've been racking my brains over. it's all very well to say oh yes, pyjamas-desktop (or any other Webkit-based
Re: [webkit-dev] webkit glib DOM bindings demo code
http://lkcl.net/webkit/main.c the modifications to main.c are getting a little bit more sophisticated, so i thought it best to post it as a separate link, with explanations here. get_absolute_top() is a [bad] port of the pyjamas-desktop javascript function of the same absolute camelised name, DOM.getAbsoluteTop() - source code here: http://github.com/lkcl/pyjamas-desktop/tree/master/pyjamas-webkit/pyjamas/DOM.py#L378 you can at least see what was being attempted :) scroll_into_view() is quite obvious: given any particular node in the DOM tree, scroll_into_view() ensures that that node will be visible. having used get_absolute_top() to locate its absolute position, gdom_dom_window_scroll_to() is called to actually move the window scroll position. it's left as an exercise to the reader (at the moment) to do scrolling on X position and to write a get_absolute_left() to match, and to get the width/height of the window and of the node and put the node at the _bottom_ of the scrolling window (or in the middle) with a little maths. print_attribute() is necessary in instances where XML is being created, or in cases where an HTML element has non-W3C-compliant attributes. in such cases, you cannot get the property - i.e. you cannot use g_object_get() - because the attribute's not named in the IDL file. such attributes end up in the NamedNodeMap, you thus have to use gdom_named_node_map_get_named_item() to get at them. this being c, it's all rather damn long-winded and awkward. set_example_css_property() shows how to set a border CSS property (yippee!) - it's the only one of the functions that actually makes any modifications to the page. i've corrected the examples, adding in g_free() which i had left out up until now (whoops!) l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit glib DOM bindings demo code
here's a second example:
static void walk_table_node(GdomNode *node)
{
GdomNode *child;
g_object_get(node, first_child, child, NULL);
while (child)
{
gchar *name;
g_object_get(child, node_name, name, NULL);
printf(table child node %s\n, name);
if (strcmp(name, tr) == 0)
{
walk_tr_node(child); /* etc. etc. */
}
g_object_get(child, next_sibling, child, NULL);
}
}
void walk_all_tables (void)
{
GdomDocument *doc = get_dom_document();
GdomNodeList *els;
gulong tags_length;
gulong i;
els = gdom_document_get_elements_by_tag_name(doc, table);
g_object_get(els, length, tags_length, NULL);
printf(table count: %d\n, tags_length);
for (i = 0; i tags_length; i++)
{
walk_table_node(gdom_node_list_item(els, i));
}
}
as can be seen:
* els = document.getElementsByTagName(table) is replaced by
gdom_document_get_elements_by_tag_name(doc, table);
* els.length is replaced by g_object_get(els, length, NULL); where
length MUST be an unsigned long (not an unsigned int - i made that
mistake already :) it's VITAL to check the idl file - NodeList.idl in
this case)
* els.item(i) is replaced by gdom_node_list_item(els, i);
* node.firstChild, node.nodeName, node.nextSibling all again use
g_object_get() to obtain those properties.
this is all in c.
it's the same sort of thing in python with pywebkitgtk - except
_slightly_ less messy. in pyjamas-desktop, once i get round to it, the
messy names will go away, and revert back to
moreSensibleNamingSchemes.
i'm recommending to change the naming schemes back to more sensible
ones than_this_stupid_looking_one, on the basis that the convention
has already been decided by netscape, and is now a specification.
mozilla doesn't do this (in xul interface bindings), so why it's being
done here is ... it just makes things _bizarre_.
thoughts, anyone?
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit glib DOM bindings demo code
back in august or so when i was first working on the glib DOM
bindings, a number of people who expressed an interest asked for
advice on how to use the glib / gdom bindings in c. as my primary
focus was on the python bindings, using the auto-generator
(codegen.py) to automatically write that code, i gave some notes but
left it to the people who contacted me to write the code, as i didn't
have a reason to do it, myself.
now i've had a good reason to do the work, here is some code (attached
and also link here) that shows how to begin manipulating and
interacting with the DOM model:
http://lkcl.net/webkit/gdom_bindings_gtklauncher_demo.patch
notes:
1) first thing you should notice is that add_event_listener isn't
declared in an accessible header file; it's a badly-named that does
the job it's required to do. it _is_ declared in
WebKit/gtk/webkit/EventListenerNode.h but is wrapped in an extern C
{ ... } which makes the c compiler veery unhappy. so - ignore that,
and use it anyway, bearing in mind that the name of the function _has_
to change.
2) there is a _single_ entrypoint linking the GTK-based Webkit GTK
port to the Gobject-based Webkit Glib-DOM bindings code:
webkit_web_frame_get_dom_document(). THAT'S ALL. once you've got
that pointer to a GdomDocument, you can do _anything_ to or with the
DOM model- without ever having to refer to the GTK code, _ever_ again.
for those people who are involved in the Qt and the wxWidgets and
other webkit ports, looking jealously at these shiny new glib/DOM
bindings, i'm really talking to you, as yes you _can_ get glib/DOM
bindings WITHOUT having to #include gtk.h. really.
3) the load-finished signal is hooked into purely so that the DOM
model can be manipulated _after_ the web page has loaded.
4) load_finished_cb() is where the majority of the demo work takes
place: a DIV tag is appended to the end of the document, with a Text
Node added to that DIV tag. also note that the DIV's id attribute
is set to helloworld. lastly, an onclick is added to the DIV, by
connecting to the shiny new browser-event signal.
5) when the DIV tag is clicked, dispatch_event_cb is called with the
node that the event came from (in this case, the DIV tag) and the
event itself. you can expect to be able to obtain, through the
gobject properties, to obtain all the lovely things like the type (in
this case it's a mouseevent) and then you will be able to get the x
coords, y coords etc. etc. in the example code shown, what's being
done is quite straightforward: all the hrefs of all anchor elements
are printed out, whenever the DIV is clicked.
6) the get_dom_document() function is there purely for convenience,
it's the equivalent of javascript global document. and it references
the static global web_view to get the frame and from that the frame's
document.
simple, really.
to use this code, you'll need the following:
https://bugs.webkit.org/attachment.cgi?id=25618
martin soto kindly rewrote the glib / gdom patch, and i've confirmed
that the rewrite he's done doesn't make pywebkitgtk and
pyjamas-desktop fall over, so there's at least _some_ confidence there
that the code still does the job it's designed to do :)
l.
f
Description: Binary data
___
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
On Tue, Oct 14, 2008 at 9:47 PM, David Hyatt [EMAIL PROTECTED] wrote: The term webkit core in your subject is very confusing. Do you mean WebKit or WebCore? There is platform-specific code in both. apologies. i mean whichever bit that you link webkit link against to produce a gtk port, or a qt port, or a wx port. l. ___ 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
[webkit-dev] #16401 - last available patch for webkit glib bindings
folks - further work from me, at this time, on the glib bindings, is at an end. any offers of payment or contracting offers if they've been made _may_ have gone into my spam folder: if that's the case and i've overlooked them please do contact me via the Email me button on my web site, http://lkcl.net as that goes direct to my server. to make your own lives easier, i can recommend that you listen to alp's sensible advice, and add all but the modifications to WebKitWebFrame.cpp and .h, which are the entry-points that need to be properly finalised. leaving _just_ those modifications out makes the entire 7,000 line patch _completely_ and i mean _completely_ isolated from the remainder of the webkit code. you get a libgdom.la ... and no way to use it. at all. at some point in the future, when it suits my own needs and requirements, i will of course carry on working on this code, and if other people benefit from that work - great. right now - with £25,000 of debt and nowhere to live i'm disinclined to work for free on such significant functionality. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] glib bindings
folks, hi, as you may be aware, the speed at which i write code, make decisions and get results is... lightning quick - some would say scarily quick. the last time i was involved in a major free software project, on which many individuals, companies and organisations relied to save vast amounts of money, it went horribly horribly wrong in a very short amount of time. the question, surely it doesn't have to be as complicated as all that got asked - and many of you will know that when that question gets asked, on any project, it's time to run like hell as fast as you can (which, as i was learning that particular lesson at the time, i didn't do...). webkit is an absolutely fantastic project - and it is also a strategically damn important one, at the cross-roads of a major list of who's who of free software projects - looking at http://trac.webkit.org/wiki/ApplicationsGtk it's like... every major user-interface project that's anything in free software is on that list - it's only missing google chrome, kdewebkit and adobe air because they happen not to be gtk-based applications (which is only what that wiki page lists). lots and lots of people are extremely excited by the possibilities that having free software bindings to webkit's DOM model opens up. they may not necessarily know _exactly_ why, but they can feel it. much of the reason for not knowing exactly why is because the glib bindings turn webkit into an extremely powerful widget set in its own right, rather than just another application, and so, much of the excitement comes from knowing that a great deal is possible, and looking forward to seeing those future applications come about. i've done - completed - much of the work, already. in about two weeks flat. the patch, to provide the minimal complete and useable functionality (as opposed to partially complete and therefore useless), is 7000 lines long and a whopping 250k in size, auto-generates three hundred glib objects and auto-generates 1,500 DOM manipulation functions, yet provides _three_ - only three - additional entry-point functions into the webkit-gtk port (and two of those are, strictly speaking, hacks). with very little modification to the webkit-gtk port, the entry interface between the glib bindings - which actually have absolutely nothing to do whatsoever with gtk - and the other ports, e.g. webkit-gtk, can be confined to one - just one - function, and involve the use of only two glib-bindings-based objects (it _may_ be possible to get that down to one, but... i'm not so sure it's a good idea to try). why am i writing this? it's quite simple: the amount of work done - in such a short amount of time - is in excess of people's ability to comprehend and accept. this is a very common occurrence in my life, leaving people simply unable to believe that i am capable of achieving what i can in the time i say i can do it, thus resulting in me receiving no money for work done. if i do the work _anyway_, then people get upset, comprehending neither the how nor the process. this has got to stop happening. so, we're going to start from scratch, with a requirements specificaition: http://github.com/lkcl/webkit/wikis/requirementsspecification from that, the decisions - the path to the results, which can be seen in the 16401-master branch at http://github.com/lkcl/webkit/tree/16401.master - are quite straightforward. if there's any questions, ask them, and we - not i - we will fill in the missing gaps. for the samba tng project, i did just over 2 years of work, sufficient to break the back of microsoft's monopoly (nearly ten years later). it took a team of _six_ people _five years_ to catch up with that work, from the day they started saying surely it doesn't have to be as complicated as all that (i.e. we don't believe, trust or respect you). i never want to be in a position where i'm saying well if you don't believe or trust what i'm saying, you're going to find _out_ why it has to quotes be as complicated as all that unquotes aren't you. ever again. especially not on this project - it's too damn important. so. i can't do everything - and i haven't _done_ everything. there's still a lot left to be done, even though what's already been done is already in a useable, useful state. except for that damn bug #20403 which mocks the gtk show grr. so - this message goes out, calling all interested people who would like to see glib bindings in webkit, and who would like to see python bindings to webkit, and c++ bindings and everything else, to get involved and move this project forward, knowing that the path to doing so has already been made much easier than it would otherwise be (if i wasn't involved). yours, l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] success! cross-compile and link of Programs/GtkLauncher from amd64-debian-linux host for win32 using mingw32
http://lkcl.net/webkit/cross-compile-gtk.notes.txt purpose of this cross-compile is to have a webkit-gtk for win32 with the glib bindings, #16401, and associated pywebkitgtk (that's turning out to be fun, already - cross-compile of python 2.5 with mingw32 wh!). build and link of webkit was a success. eventually. there's a horribly badly botched process for compiling icu 3.8.1: enough of the compile succeeds to be able to manually prise libicuuc.lib and .dll from icu's cold dead fingers without having to carry out a complete build, test and make install. running under wine is ... interesting. you have to patch cairo to scale fonts down 32 times, because wine ignores an important font scaling parameter right now. if you don't do this simple hack, text entry on a 1200 x 800 screen takes up 30% of your screen space. scaled very nicely, it is, too. text-entry in the GTK box at the top of GtkLauncher is fine: text-entry into any text boxes is not fine, although the focus shows cursor-flashing. my little test documentation page at http://lkcl.net/pyjamas-desktop/docs/output/docui.html shows a flashing cursor in a small box (too small for the cursor) overlapping the + and - icons, whenever you click on any of the treeview items. this is a lovely and weird and obtuse one. viewing any frames causes an instant segfault (oh look, yippeee, it's another repeat of https://bugs.webkit.org/show_bug.cgi?id=20403 except from a different angle, and on a different architecture: i'll see if i can hammer some life into gdb.exe under wine *sob*). radio-buttons are lifeless every second scan-line. despite the utter utter pain and horror of cross-compiling, and of locating all of the build dependencies (debianites are _so_ spoiled. there's just no going back...) it's an incredibly useful exercise. i seem to have run into every single possible UI bug there could possibly be! :) i'm just really puzzled that webkit works really rather well on unix and, given that it's virtually the same code, has all of these straaange things going on under wine. oh well :) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] [ANN] debian packages of webkit-glib and matching pywebkitgtk
if anyone's interested: amd64 debian packages including the glib bindings patch: http://sourceforge.net/project/showfiles.php?group_id=236659 libwebkit-dev is also included, if anybody wants to do e.g. *mm c++ bindings or, poor things, perl bindings. the build is from svn this morning: Repository UUID: 268f45cc-cd09-0410-ab3c-d52691b4dbfc Revision: 36129 the strategic importance of webkit with glib DOM bindings cannot be underestimated. macosx developers have had ObjectiveC DOM bindings for some time, and now the possibility of manipulating the DOM model, to develop rich media applications (*including* - in a future release, just to get you really excited, SVG DOM bindings). so, webkit with glib bindings becomes, effectively, a replacement or competitor to the following projects: * gtk2 * qt4 * gtkmozembed (thanks to webkit's NPAPI support) * Adobe AIR (even though Adobe AIR is also based on Webkit!) * wxWidgets * hippocanvas and other SVG-like applications graphics engines (this for a future release) the list just ... goes on! i say competitor but of course it's not: webkit-glib/gtk is a gtk widget, and so integrates into gtk+ applications seamlessly. the tantalising possibility exists for webkit-qt4 to also have its own bindings (contact me if you'd like to contract me to make that happen, i'd be delighted to do the work). for an example application - actually a convenient widget-set in its own right - you might like to look at Pyjamas-Desktop: http://pyjd.sf.net Full API documentation is provided, but for those people wishing to write their own python-based rich media applications, you would do well to avoid the hairy ball of lovely pywebkitgtk bindings (1,500 functions and 300 glib objects) and use the much simpler - and well-documented - API that is identical to that of Pyjamas (http://code.google.com/p/pyjamas) and is 99% identical to Google's Web Toolkit API (http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5). So, if you can't find out what a function does on the Pyjamas API documentation, look up its identical equivalent on GWT: it will do exactly the same thing. lastly, i just... i can't get over quite how blindingly quick webkit is, and how much functionality there is in it. So - my hat off to everyone involved in the project. it's great. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Where can I get basic WebKit software?
someone who should have been asking this question on webkit-dev... :) -- Forwarded message -- From: lkcl [EMAIL PROTECTED] To: Chromium-dev [EMAIL PROTECTED] Date: Thu, 4 Sep 2008 13:44:19 -0700 (PDT) Subject: Re: Where can I get basic WebKit software? chandra, hi, webkit's core is independent of the widget sets that use it. there _happens_ to be some widget set wrappers, which various teams have added, and these _happen_ to be included in the webkit source repository, for many people's convenience. you are pretty much on your own if adding your own home-grown drawing set, unless you can convince other people that it is a worthwhile task to do. also, from what i can gather, google's chrome team _did_ consider it worthwhile - and they have added skia as the drawing engine [which i am about to ask what that's about, and when the patch is going to be done to get that back into webkit]. so you should be looking at both the chromium version of webkit, and also the three widget-set-versions, wxWidgets, qt and gt, to compare the _differences_ between these, to find out how to add your own. i for one will be very interested to see your work, because i have added glib bindings to webkit (https://bugs.webkit.org/show_bug.cgi? id=16401) so that i can have them in pywebkitgtk (http:// code.google.com/p/pywebkitgtk/issues/detail?id=13) so that i can (finally) have pyjamas (http://code.google.com/p/pyjamas) running as a desktop app (http://pyjd.sf.net). i'm interested because jumping through two levels of bindings hoops - glib and then python - seems a bit silly, and one prerequisite to make it all a bit faster is to have native screeen drawing, not gtk-based sccreen drawing. thenn it''s worthwhile adding native python bindings to webkit. ... but yes - this is a question you should have asked on the webkit- dev mailing list :) l. On Sep 4, 3:06 pm, Chandra [EMAIL PROTECTED] wrote: Hi, I want to download basic platform independent WebKit toolkit? I tried in Internet. But, I found that all available download resources are integrated with third party platforms like Qt, Gtk, Java etc. My main intention is that I want to download basic WebKit software and then I will try to integrate my own platform with the basic WebKit. Thanks in advance. Regards Chandra ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how do you do callbacks out of webkit into c++, objC or other bindings - e.g. onclick ?
You can add event listeners for any event and any event target. The name of the function to add an event listener is addEventListener. To identify the event you want to listen to, you pass the event name. Events have names like resize, click, beforeclose, blur, etc. it works. thank you! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how do you do callbacks out of webkit into c++, objC or other bindings - e.g. onclick ?
pyjamas-desktop is the test-case for the glib bindings - but ignore that, i have a general question for which pyj/d is a specific case: in javascript, you can set an element's onclick method. how the heck do i get a callback, into c++, objc or any other binding, from an onclick? is there a mechanism for calling back, from javascript, into the bindings? so, for example, i could set an element's onclick method to call hello_now_we_are_going_to_pass_all_our_arguments_to_the_binding(...)? i've already set up an EventListener (using addWindowEventListener) but that's far from ideal, although it does take in eeeverything, which is required in a lot of instances in pyjamas, to handle e.g. mouse-move events, and to handle event preview, thus allowing opportunities to stop event propagation... .. all that's taken care of. what _isn't_ taken care of is overriding window onresize, element onclick, window onbeforeclose, window close, element onblur and all the other loovely events that are usually the exclusive domain of javascript. .. how do i get em? :) tia, l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] getting back to sub-classes of gobjects
On Wed, 27 Aug 2008 21:52:31 + (UTC) Luke Kenneth Casson Leightonlkcl lkcl net wrote: now, of course, i have the reverse problem: i need to get _back_ to the sub-class gobject instance. G_OBJECT_TYPE()? :) ori - thank you: such a simple answer :) now i have to work out _how_ to use that, and, also, how to use it in the pygtk wrappers. i'm sure it will become clear. btw just to reassure you: i really _do_ mean thank you for such a simple answer: this is the first time, this week, that i've done gobject programming, and i didn't exactly start with a small unambitious task ha ha :) l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] getting back to sub-classes of gobjects
btw just to reassure you: i really _do_ mean thank you for such a simple answer: this is the first time, this week, that i've done gobject programming, and i didn't exactly start with a small unambitious task ha ha :) Big go go go here! From a PyGTK enthusiast ;-) ha ha thank you alberto :) btw i worked out what the issue is: i need a hash map which records the link between the c++ objects and the glib objects. instead of creating a _new_ glib object (to wrap the same c++ object but possibly with an entirely different glib type - that's my bug) i need to check the hash map and return the glib object that was _originally_ created when the c++ object was created / looked up. both the JS bindings and the ObjC bindings follow this trick. ScriptInterpreter in the JS bindings case and WebScriptObject in the ObjC case. where that kinda breaks down, though, is if the glib object doesn't exist already (having never had a glib function called before which resulted in the correct corresponding glib object wrapper being created for the c++ object) . in this instance, i am somewhat screwed :) i located ... oh hell, i worked it out. i located DOM.mm (the objective C) and there's a function _wrapNode:(WebCore::Node *)impl which does a switch statement on the c++ object's nodeType()... it goes through the types, mapping them each to a wrapper class. (how in god's name i'm going to do that in the glib case... hmmm...) so, that covers the cases where there is no glib object. good grief. .. why couldn't this be... easy?? why couldn't webkit have been written in python, where everything would be nice, and we'd all be friends? :) l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM object model glib code auto-generation - it works!
https://bugs.webkit.org/show_bug.cgi?id=16401 folks, hi, this is just to say thank you to the people who kindly stopped by or answered questions, giving hints on what's needed. PassRefPtr was the last piece in the puzzle. i can now e.g. create and add text nodes to the DOM, call gdoc.get_element_by_id and all the other lovely functions which now make pywebkitgtk a *one megabyte* library :) i've still got some custom functions to add; i've missed out SVG wrappers entirely; i still have to add properties which i will start this morning. if anybody would like to either help or take over, the majority of the work has basically been done. esp once properties are added. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] adding gtk/gobject DOM bindings to webkit - code review and advice needed
https://bugs.webkit.org/show_bug.cgi?id=16401 update: generator-script is a complete mess (not because it's perl!) yet i'm making progress. i have no idea what i'm doing but that doesn't matter :) thanks for the pointers to documentation/tutorials it helped confirm some of the things needed. on the TODO list: * add properties * add in SVGDocument (from the js bindings, this looks really hairy) * add custom functions (i've commented out all custom functions for now) * make the gobject G_DEFINE_TYPE macro derive from the parent class. regarding this last one: i spotted just now that i'm always deriving from G_OBJECT so that will change tomorrow. i'm _really_ not sure how the _init functions get called, but having a quick peek at gtypes.h i think it's taken care of and i needn't fuss... latest attachment compiles and links. to actually test the whole thing i need to also add the bindings to pywebkitgtk _that's_ going to be fun. any pointers on that greatly appreciated: can you auto-generate webkit.defs? l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] adding gtk/gobject DOM bindings to webkit - code review and advice needed
hi folks,
(message goes out primarily webkit-dev but also gtk-devel-list because
someone there might be able to give some hints on the gobject code-generation
being developed.)
background:
https://lists.webkit.org/pipermail/webkit-dev/2008-August/thread.html
https://bugs.webkit.org/show_bug.cgi?id=16401
embarrassingly, after actually trying to use the - successful -
event manipulation and javscript-snippeting i added, i found that i was
considering techniques so damn awful, to be able to exchange variables
between the python and the javascript that i couldn't bring myself to do it
ha ha.
so i decided to have a go at the CodeGenerationGObject.pm that alp
kindly posted at https://bugs.webkit.org/show_bug.cgi?id=16401
this is what i have - and what it generates - so far (and i will
update it as i make progress):
http://lkcl.net/webkit
i won't say that i know what i'm doing, but i know the end-result - sort-of -
so i will meander towards the solution (as usual. eventually).
to speed that random hit-and-miss process, a review and some pointers
would be greatly appreciated.
what, ultimately, should the code look like?
is the private classing i'm using appropriate?
should i be placing a pointer-to-the-object-being-wrapped as the
gobject private class instead of creating an (otherwise pointless
because i believe it should only contain one member - {Classname}* )
GDOM{Classname}Private struct?
can i pretty much copy the creation style of the JS code generation?
example: for the createElement function in DerivedSources/JSDocument.cpp
do i just... i assume i do pretty much the same thing.
if so, where do i get an ExecState from? _do_ i need one? (i suspect
not but confirmation greatly appreciated).
this is horrendous but fascinating in that... horrified i can't quite
believe how much is going on kind of way. it's really addictive :)
l.
p.s. whoever chose perl as the code generator i will strangle them happily
if ever i meet them, and will sleep happier at night, knowing that there is
one less perl advocate on the planet. once the job's done, of course,
because i might need their advice :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] pywebkitgtk - adding DOM javascript executing and evaluation; next step, addEventListener etc.
folks, hi, i realise it's bad form to reply to your own posts but i thought i'd keep people updated, being more important than worrying about that. _really_ long day but i worked out that yes, Document::addEventListener is the right place, yes, adding this: gboolean webkit_web_frame_add_event_listener(WebKitWebFrame* frame) is reasonable, yes, grabbing the frame-document() is ok, and yes, i now have a printf statement in c-code which prints hacked event callback click when you have called, from pywebkitgtk, main_frame.add_window_event_listener() and subsequently click on the document. i.e. i done it. hooray. next stop is to add in a python function callback to WebFrame.add_window_event_listener, and to work out how that gets called with WebCore::Event. might just do it as gdk signals. this _should_ be quite straightforward. regarding the javascript execution and evaluation, whilst i realise that it's not ideal - to have potentially tens of thousands of snippets of javascript code being executed, as a first cut it'll do nicely, and, whilst ultimately i'll not end up using it - because there will be some lovely DOM functions in c that can be wrapped in python hint hint - that doesn't mean throw away the javascript execution i've added, because you can guarantee it has more uses than wot i want it for. creating and executing random bits of javascript should always be nice for some poor bugger to give themselves a headache over, bless 'em. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] pyjamas-desktop - how to make a desktop pyjamas toolkit
folks, hi, after some thought, i'm rapidly coming to the conclusion that the most practical and beneficial way to implement pyjamas-desktop is to go the whole hog with webkit. that may take some explanation - please bear with me. * google's webkit is a toolkit that looks startlingly similar to a desktop toolkit. * pyjamas is a port of google's webkit to python. * the pyjamas API looks startlingly similar to python-gtk2, python-qt4, wxPython etc. * therefore, logically, it makes sense to have a port of pyjamas which _does_ call e.g. python-gtk2, or python-qt4, or wxPython widget. however - when you get into it, it's the HTML widgets, and some of the more obscure widgets such as the pyjamas HTMLPanel that begin to show up weaknesses in the chosen widget sets. not just because the widget sets don't properly support CSS stylesheets - gtk-css-engine by robsta is a good example of adding CSS support to gtk - it's more fundamental than that. which leaves one other final option: accessing and manipulating the DOM model, directly. i've spoken on irc to brian dash: he mentions that alp toker had been working on exposing the DOM model manipulation up to other programming languages, and that apple's objective-C makes it _already_ possible to manipulate the DOM model - in any programming language - as long as you're using a MAC. the goal of pyjamas-desktop is for pyjamas to be an application development toolkit that is cross-browser, cross-platform _and_ cross-widget-set. so if it's runs on MAC only, that's no good. ultimately, however, irrespective of pyjamas-desktop, it just makes a great deal of sense to provide programmatic DOM manipulation, for other applications. just having another browser, with the examples and demos, well... you can use mozembed or gecko for that kind of thing, and you don't need webkit at all... l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] gtk.HTML class nonexistent [was: Re: [pygtk] Computing optimum size of gtkhtml2.View]
folks, hi, just an update: i was advised kindly to look at pywebkitgtk - which i downloaded and compiled from source, this morning. _wow_ am i dead impressed with this project! the demo browser example ran my javascript-only web site, http://lkcl.net and it _nearly_ managed to run my javascript-only site i'm developing, http://partyliveonline.com - except it segfaulted after login. _wow_ would i have been so impressed if it had worked first time :) the concept of having a standards-compliant browser, integrateable into apps using python... _wow_ :) anyway: i added in pywebkitgtk instead of python-gtkhtml2 and was pleased to find that it worked absolutely perfectly to provide [a missing] gtk.HTML-like widget. what i was _less_ impressed with is that it suffers *exactly* the same flaw that python-gtkhtml2 has: a widget created with pywebkitgtk *cannot* tell you what its width and height is, and so, if you insert it into an app, and the app size shrinks, the HTML - even if it's one line of HTML - gets chopped off. there's no enforcement of HTML content size communicated back to the gtk.Widget container. thus, sadly, pywebkitgtk is as useless as python-gtkhtml2 for doing the simple, simple job of putting HTML as simple as bhello /b into an application. also i haven't checked yet if object_requested is supported in pywebkitgtk or its equivalent - i hope so, because it's absolutely essential functionality . qt4 has support for Rich Text - simple things like b hello /b can be detected and displayed, and the size of the box is enforced as a minimum width and height onto the application. it's _essential_ that GTK have similar such functionality. implementing these features outside of the core gtk widget set - using pygtk2 alone - registers on the awkward to literally impossible scale. l. p.s. for those people on the gtk-devel mailing list, information on the context for this message can be found at: http://advogato.org/person/lkcl and at http://lkcl.net/pyjamas-desktop - i am porting pyjamas - the python-to-javascript compiler - to pygtk2 _and_ pyqt4 _and_ iron-python with gtk-sharp _and_ i will be looking at qyoto, at a later date. see http://lkcl.net/pyjamas-desktop - pygtk2.tgz for progress on the python-gtk2 port. On Thu, Aug 14, 2008 at 7:06 AM, Luke Kenneth Casson Leighton [EMAIL PROTECTED] wrote: ok. thanks sam. to gtk developers: i'm going to have to terminate work on python-desktop's gkt2 widget set until a solution is available: python-gtkhtml3 or other solution. it's simply not ok to have widgets that force you to specify both the width and the height, and if you don't do so, they just... don't work. python-gtkhtml2 views, if you specify only the width, the height remains at zero: that's unacceptable. in gtk-sharp, Gtk.HTML works absolutely fine (iirc correctly) l. On Wed, Aug 13, 2008 at 10:15 PM, Sam Varshavchik [EMAIL PROTECTED] wrote: Luke Kenneth Casson Leighton writes: sam, hi, did you ever receive a reply - or find a solution - to this question? for http://lkcl.net/pyjamas-desktop i'm looking for the way to calculate a sensible size for gtkhtml2.Views, based on the HTML inside. at present, exactly as you probably found, a popup dialog is created... with zero width and height. only by having set the width to a fixed pixel size is the dialog turning out to be 1 pixel high (and 218 pixels wide), and the user application chose that. Nope. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
