Re: [Sugar-devel] Browse and the move to WebKit
[mozilla people, please feel free to skip to the bottom of this, for the conclusion - the rest is detail] right: i've just learned something very exciting: one of the pyjamas contributors, a very intelligent individual, anthony, has been working with the webkit-gtk team to create a gobject-introspection port of pyjamas-desktop. he has a number of the examples already working. to emphasise the significance of this: * the damaged event handling which was added in by the webkit gtk team 3 years ago (without design consultation, after mark rowe ordered the removal of the original fully-working event handling without good justification) has been removed. the new event handling infrastructure is, i gather, no longer dependent *at all* on gobject signals. it should be along the exact same lines as the pythonwebkit bindings: a direct callback, directly called from the webkit event infrastructure. that means that event callbacks will no longer result in race conditions, instability and so on, which i warned you about, last week. * anthony has direct first-hand experience of what's needed to make the gobject bindings actually useful and useable. he will therefore be able to explain to the webkit-gtk team why mark rowe's under-informed objections to various absolutely essential features are, in fact, absolutely essential. in the intervening years (!! i can't quite get over the fact that the original work was done in 2008...) the webkit-gtk team may have actually encountered some of the problems themselves. the bottom line is that i have much more confidence in the webkit-gobject bindings, thanks to anthony's involvement, that anthony can help the webkit-gtk team to stabilise the webkit-gobject bindings, through the use of pyjamas-desktop as a massively-comprehensive 100% code-coverage testing environment. it is therefore *not* my recommendation that the OLPC team revert to the use of python-hulahop for their web browser activity. this effectively leaves the python-hulahop code completely orphaned, and only relevant to the pyjamas-desktop xulrunner port. the question is, therefore: is it useful for the mozilla foundation to have a second test environment - by way of having the pyjamas-desktop xulrunner port still active? the reason i ask is because as has been demonstrated by that window focus bug, it looks like there's some memory corruption which has been completely missed, thanks to the narrow drive of the mozilla foundation to concentrate exclusively on firefox releases. but if the testing via hulahop was included on a regular basis, by the mozilla foundation, then it is not hard to conclude that that memory corruption bug would have been noted and fixed much earlier. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
You was replying a thread from Jun/2011. In this time the developers worked in a Browse version based in webkit. Gonzalo On Tue, Feb 21, 2012 at 4:06 AM, lkcl luke luke.leigh...@gmail.com wrote: http://trac.webkit.org/wiki/WebKit2 ok: one of the issues that i ran into on the original (flawed) webkit-gobject development work, as well as the ports of pythonwebkit to gtk and directfb, was quite how integrated the whole thing had to be. there are now something like *eight* separate language bindings to webkit (including at least two javascript ones), each of which is in a separate state of development and even present *different* versions of the same underlying DOM API. it would appear that webkit2 has injected bundles which is a stupid way of saying you can install a shared library dynamically into webkit using dlopen. basically this means that it will at some point be able to - *without* having any dependency or *any* interaction with the webkit team - add language bindings and other features to webkit. i strongly, strongly, strongly advise the OLPC team to WAIT until such time as such code has been written, before proceeding with the use of webkit in OLPC. of course you are entirely free to do whatever you find to be most useful to you, choosing instead to learn for yourselves why webkit1's gobject introspection bindings are fundamentally flawed and spending significant time doing so. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Tue, Feb 21, 2012 at 11:10 AM, Gonzalo Odiard gonz...@laptop.org wrote: You was replying a thread from Jun/2011. In this time the developers worked in a Browse version based in webkit. yes. i'm aware of that. i strongly recommend reverting the changes made. read what i wrote. actually read what i wrote. please read what i have written. allow me to repeat it because it appears that you have not read what i have written. it says subtle instabilities will result as a direct consequence of fundamental design flaws in the webkit gobject bindings. it also says excessive memory usage and CPU usage will also result. webkit with gobject introspection is *NOT* ready for public usage as it is fundamentally flawed. as i am the *DESIGNER* of the webkit gobject introspection bindings who has followed their progress i know what i am talking about. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
I have read you. You don't need repeat. In first place, is really bad have this information now, and not 8 months ago, a lot of work was spent porting Browse to webkit, and the result is no so bad like you say. Of course, only few developers are using it, then do not have a real field use. The decision to move to webkit was based in: * the number of problems with gecko * many other projects using webkit. In general more clients for a library, means more eyes and more bugs solved. * all the other comments in this thread... Gonzalo On Tue, Feb 21, 2012 at 11:51 AM, lkcl luke luke.leigh...@gmail.com wrote: On Tue, Feb 21, 2012 at 11:10 AM, Gonzalo Odiard gonz...@laptop.org wrote: You was replying a thread from Jun/2011. In this time the developers worked in a Browse version based in webkit. yes. i'm aware of that. i strongly recommend reverting the changes made. read what i wrote. actually read what i wrote. please read what i have written. allow me to repeat it because it appears that you have not read what i have written. it says subtle instabilities will result as a direct consequence of fundamental design flaws in the webkit gobject bindings. it also says excessive memory usage and CPU usage will also result. webkit with gobject introspection is *NOT* ready for public usage as it is fundamentally flawed. as i am the *DESIGNER* of the webkit gobject introspection bindings who has followed their progress i know what i am talking about. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
[summary to brendan and chris: chris, brendan, hi, i'm cc'ing you on this because the OLPC team have been forced into making a decision to move away from using xulrunner technology, as a direct result of the decision made to reduce python-xpcom to third party status: it's taken this long for the lack of support from the mozilla foundation for this code to fall by the wayside, and catching up is going to be a complete bitch. unfortunately, the replacement code being used, webkit with gobject bindings - which i designed - was revision 0.0 and has severe fundamental design flaws which the OLPC team will *only* encounter much much later down the road, by which time it will be too late for them to back out of]. On Tue, Feb 21, 2012 at 3:17 PM, Gonzalo Odiard gonz...@laptop.org wrote: I have read you. ok, good. sorry, you didn't say that, earlier. you don't need repeat. good! In first place, is really bad have this information now, and not 8 months ago, well... tough. i wasn't consulted or informed of the decision, yet those people who are on the olpc sugar-devel mailing list will have seen my contributions and discussions some time back, discussing the fact that pyjamas-desktop uses hulahop, and how incredibly grateful i was - am - that the OLPC team went to the trouble of writing hulahop. so it was only pure chance that i encountered the discussion at all. a lot of work was spent porting Browse to webkit, and the result is no so bad like you say. gonzalo: despite saying that you've read what i wrote, you're telling me that you haven't absorbed what i wrote. i said that - and this is from direct first-hand experience - that it is *only* when you have applications that are a bit larger than simpull web pagizzz that you end up with crashes and instability. Of course, only few developers are using it, then do not have a real field use. preciselyy. whereas the pyjamas-desktop project has 100% code-coverage of EVERY feature present in the DOM bindings, and thus if there is even the slightest error or even one tiny, tiny function missing, the problems are encountered pretty much within 5 minutes of testing. usually it's enough to run the Helloworld.py example, KitchenSink.py example, the JSONRPC example, the Mail example and the SVGCanvas example. that pretty much covers about 99.5% of the functionality, in under 5 minutes. The decision to move to webkit was based in: * the number of problems with gecko * many other projects using webkit. In general more clients for a library, means more eyes and more bugs solved. in general, yes, but in general means for a nice, easy, simple library which doesn't require gigabytes of source code downloads, doesn't involve having to know TWELVE separate and distinct programming technologies in order to even get to grips with the code, let alone understand what's involved in the design decisions behind the gobject bindings. the number of people in the world who actually understand the issues involved is one: me (because i designed the code, and the successor bindings, pythonwebkit). the number of people in the world who have the intelligence to be able to fix these MASSIVELY complex issues is about three, possibly four. the number of people _listening_ to what i'm saying is however zero, and the number of offers of money to _fix_ the problems is also zero. now, if this (pythonwebkit or hulahop) was sponsored by the mozilla foundation, or by google, it would be fine, because you could have someone paid to sit for 3-4 weeks to fix and maintain the code (either the hulahop code or the gobject bindings) ... but that isn't the case, here, is it? the mozilla foundation *deliberately* moved pyxpcomext to 3rd party status - that was a decision taken by brendan because he misunderstood the importance of python-xpcom, believing it to be solely and exclusively useable inside the python script language=python plugin for firefox. that plugin was a complete bitch to maintain for win32: the only people with the resources to tackle its compilation were novell, and even they gave up after succeeding once and only once to get xulrunner 1.8 up and running. so *if* that was the *only* usage for python-xpcom, then the experiment and the money spent on that experiment would have been a sensible declaration of failure because the number of people who _actually_ install python as a whopping 10 *MEGABYTE* plugin into firefox across multiple platforms in order to be able to do script language=python is very, very small. unfortunately, though, there was a crossover point where the existence of the python-xpcom code (NOT the pycomext plugin) encouraged the OLPC team to create hulahop, which provided as you know the means to do python embedding from a declarative programming perspective *not* a script language=python perspective *and* provided the critical, critical DOM interaction from python by simultaneously allowing access to the NS XPCOM
Re: [Sugar-devel] Browse and the move to WebKit
Note: Resent (as I needed to subscribe to sugar-devel). On 12-02-21 02:32 PM, lkcl luke wrote: pyxpcom is still actively maintained by toddw (activestate). I'm not clear on what sugar/olpc actually desire here: the pyxpcom code works about as well as it ever did. there are only two versions still running that people can actively use, that have been confirmed as working: * python-xpcom with xulrunner 1.9.1 (and 1.9.2) - the changes made which broke things were the xpcom interface changes. i'm extremely grateful to todd for getting xpcom up-and-running again but it's taken this long for it to happen! * python-xpcom with xulrunner 9.0. this i tested with pyjamas-desktop last week: it works as perfectly as it ever did (with only one outstanding bug for code that's not really properly paid attention to, out of thousands of functions and properties that's not bad! the function i'm referring to is Canvas2D DrawImage. it just... doesn't work, period.) PyXPCOM supports all XulRunner versions from 1.9.1 through to XulRunner 9.0 - versions are tagged in hg here: http://hg.mozilla.org/pyxpcom/tags Komodo is the prime example of an application using PyXPCOM successfully, using versions 1.9.1, 2.0.0 and currently using 7.0.0 in Komodo 7. For Canvas DrawImage problem - it looks like PyXPCOM does not support the optional_argc IDL/xpcom setting. This should get a bug report it, as I'd imagine it's fixable in pyxpcom. On Tue, Feb 21, 2012 at 7:59 PM, Brendan Eichbren...@mozilla.com wrote: so, to summarise: * python-xpcom not being part of mozilla-central is causing python-xpcom to be out of sync (for example that massive PRBool - bool update) The Mozilla applications (Firefox, Thunderbird, ...) do not use the Pyxpcom code - so I don't think they should have to maintain it. The Mozilla code is changing fast nowadays, and it shouldn't have to wait on smaller projects like Pyxpcom to become compatible. Pyxpcom has not been updated for Mozilla central (XulRunner 11+) yet. Komodo (ActiveState) has plans for continued Pyxpcom use, so I'm sure that it will get updated some time in the future. If anyone else has need of it sooner - they too can fix the Pyxpcom code and contribute the changes back... this is how Open Source projects work. * python-xpcom is middleware so *cannot* have comprehensive tests Note that Pyxpcom does have it's own set of tests to test the Python XPCOM functionality: http://hg.mozilla.org/pyxpcom/file/3856dbd68d5d/xpcom/test so being middleware is not a testing problem. Cheers, Todd ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
hi todd, thanks for responding here.
On Tue, Feb 21, 2012 at 11:41 PM, Todd Whiteman to...@activestate.com wrote:
PyXPCOM supports all XulRunner versions from 1.9.1 through to XulRunner 9.0
- versions are tagged in hg here:
http://hg.mozilla.org/pyxpcom/tags
... but debian has *already* moved on beyond xulrunner 9.0. the
opportunity to compile a version of xpcom and hulahop that can be
released at the same time as firefox - and uses the same shared
xulrunner library - has already gone.
Komodo is the prime example of an application using PyXPCOM successfully,
using versions 1.9.1, 2.0.0 and currently using 7.0.0 in Komodo 7.
yes but it's maintained as an entirely separate version of
xulrunner, which is compiled for installation in a completely separate
location. i.e. if you install komodo i believe you get something like
/usr/lib/komodo/xulrunner-7 *not* /usr/lib/xulrunner-7/{libraries}
so yes this is a solution - have
For Canvas DrawImage problem - it looks like PyXPCOM does not support the
optional_argc IDL/xpcom setting. This should get a bug report it, as I'd
imagine it's fixable in pyxpcom.
yes. i started looking at what would be involved - the optional_argc
is a flag that goes into the type library: flags get picked up by
pyxpcom and i did track down that yes, that bit of the flag is simply
completely ignore in pyxpcom. however that shouldn't be a problem: it
*should* be possible to just specify all 9 args (in the DrawImage
case) but even there i am _still_ getting error invalid return
results.
anyway this is OT... slightly... ok it's not quite OT, but it's
getting into detail.
On Tue, Feb 21, 2012 at 7:59 PM, Brendan Eichbren...@mozilla.com wrote:
so, to summarise:
* python-xpcom not being part of mozilla-central is causing
python-xpcom to be out of sync (for example that massive PRBool -
bool update)
The Mozilla applications (Firefox, Thunderbird, ...) do not use the Pyxpcom
code - so I don't think they should have to maintain it. The Mozilla code is
changing fast nowadays,
yes. that's causing problems. it's too fast for distributions to
keep up, and it's too fast for non-funded, non-full-time,
non-fully-paid-up-employee-supported projects to be able to cope with.
it's worth reiterating that the OLPC team have got so sick of this
situation that the key developer responsible for the web browser
activity pulled the plug on mozilla-foundation-sponsored technology.
to reiterate: mozilla foundation technology will *not* be present in,
nor will it ever be endorsed by, OLPC.
and it shouldn't have to wait on smaller projects
like Pyxpcom to become compatible.
smaller projects?? i'm not very impressed by the view that says that
smaller projects which utilise mozilla foundation technology are
quotes unimportant.
where exactly should the line be drawn? what qualifies as a smaller
project, such that the mozilla foundation does not care one bit about
whether it works or does not work?
if someone would like to write an official explanation for posting on
the pyjamasdev mailing list, that the official position of the mozilla
foundation is that they are entirely on their own and, as python
programmers with no c and c++ experience whatsover they must download
tens of megabytes of source code and must learn to compile it
themselves _and_ maintain the release cycle on it, i'll be happy to
forward it on. i ain't writing it.
Pyxpcom has not been updated for Mozilla central (XulRunner 11+) yet. Komodo
(ActiveState) has plans for continued Pyxpcom use, so I'm sure that it will
get updated some time in the future. If anyone else has need of it sooner -
they too can fix the Pyxpcom code and contribute the changes back... this is
how Open Source projects work.
yehhhs they could *if* they had the time and/or money to do
so, _and_ the skillset to tackle *more* technology areas than are
covered by *TEAMS* of full-time-funded people [the mozilla foundation
fully-paid-up employees].
the skillset required to take this on really is larger than that
which even those people who normally contribute to mozilla are used
to. not only do you have to know the xulrunner codebase, but also you
have to know python, you have to know GTK, you have to know how XPCOM
works, you have to have a vague understanding that it's similar to
microsoft COM.
to expect the average programmer to be able to just... randomly take
that on for fun and for free is just nuts, todd!
i mean... i can't quite believe what you're suggesting here [i'm
speaking rhetorically here, allow me a little leeway, ok? :) ]
* python-xpcom is middleware so *cannot* have comprehensive tests
Note that Pyxpcom does have its own set of tests to test the Python XPCOM
functionality:
http://hg.mozilla.org/pyxpcom/file/3856dbd68d5d/xpcom/test
so being middleware is not a testing problem.
ok, the problem is this: xpcom's testing covers xpcom codepaths. as
middleware, it tests the
Re: [Sugar-devel] Browse and the move to WebKit
On Fri, Feb 17, 2012 at 5:07 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-02-17 at 05:33am, Luke Kenneth Casson Leighton wrote: better news: i've just confirmed that: a) the removal of js_push_context and pop context was a spurious error, those functions are now restored, confirmed as compiling and existing (untested) b) the usual critical pyjamas-desktop tests, Helloworld, JSONRPCExample, KitchenSink and Mail all have the exact same behaviour as they used to, way back before the xpcom API breakage [where we all had to wait for todd whiteman to update pyxpcom] this is really really good news because it means that the people who have been keeping an eye on the debian packaging of hulahop and have been going arse! it's fecked! quite a lot will now be happy that it all works, and i am confident that within a few weeks/months people will be able to do apt-get install pyjamas-desktop python-hulahop again and have it all work. This is indeed quite exciting. Looking at your patch now and hopefully able to release a working Hulahop for Debian. ok. right, update: * hulahop works perfectly with xulrunner 9.0 * hulahop compiles with no modifications for xulrunner 10.0.0 but segfaults (two bugs) * hulahop _and_ xpcom require updates (PRBool-bool) for xulrunner 10.0.2 but segfaults (two bugs) * hulahop and xpcom with xulrunner 11 i haven't yet investigated the first bug is solved by compiling with --disable-jemalloc the second bug is related to window focus, and appears to either be solved for later versions ( 10.0.2) or is still under investigation: with the disconnect between the various trees and releases it's hard to tell without assistance from the mozilla team which patches are current, relevant etc. bottom line is: if you can live with xulrunner 9, it works perfectly, and is quite recent. and it's a lot better than webkit1. i really cannot stress enough how much webkitgtk with gobject introspection looks ok from the outside but is actually fundamentally flawed at the design level. you are entirely free to completely ignore this advice and entirely free to do whatever is most useful to you. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
http://trac.webkit.org/wiki/WebKit2 ok: one of the issues that i ran into on the original (flawed) webkit-gobject development work, as well as the ports of pythonwebkit to gtk and directfb, was quite how integrated the whole thing had to be. there are now something like *eight* separate language bindings to webkit (including at least two javascript ones), each of which is in a separate state of development and even present *different* versions of the same underlying DOM API. it would appear that webkit2 has injected bundles which is a stupid way of saying you can install a shared library dynamically into webkit using dlopen. basically this means that it will at some point be able to - *without* having any dependency or *any* interaction with the webkit team - add language bindings and other features to webkit. i strongly, strongly, strongly advise the OLPC team to WAIT until such time as such code has been written, before proceeding with the use of webkit in OLPC. of course you are entirely free to do whatever you find to be most useful to you, choosing instead to learn for yourselves why webkit1's gobject introspection bindings are fundamentally flawed and spending significant time doing so. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 12-02-17 at 05:33am, Luke Kenneth Casson Leighton wrote: better news: i've just confirmed that: a) the removal of js_push_context and pop context was a spurious error, those functions are now restored, confirmed as compiling and existing (untested) b) the usual critical pyjamas-desktop tests, Helloworld, JSONRPCExample, KitchenSink and Mail all have the exact same behaviour as they used to, way back before the xpcom API breakage [where we all had to wait for todd whiteman to update pyxpcom] this is really really good news because it means that the people who have been keeping an eye on the debian packaging of hulahop and have been going arse! it's fecked! quite a lot will now be happy that it all works, and i am confident that within a few weeks/months people will be able to do apt-get install pyjamas-desktop python-hulahop again and have it all work. This is indeed quite exciting. Looking at your patch now and hopefully able to release a working Hulahop for Debian. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
Daniel Drake dsd at laptop.org writes: There have been various discussions in the past suggesting a move from mozilla to webkit for the Browse activity and related components, but I've never really been convinced: there is always a cost to switching, and convincing-looking numbers from webkit supporters tended to be countered with convincing-looking numbers from mozilla supporters. daniel, hi, it's just been brought to my attention just how fed up the mozilla foundation's codebase has become. i'm the lead developer of pyjamas, and have been tracking the situation as it goes from bad to worse to just completely f*g useless for quite some time. as of xulrunner-1.9.1, there was one outstanding bug which, if it had been fixed as described in the bugreport just below, would have made the use of hulahop absolutely perfect for pyjamas-desktop... ok, not absolutely perfect, but passably so. https://bugzilla.mozilla.org/show_bug.cgi?id=502234 as you can see, a decision was made to go with a solution which made the code _worse_ to work with. a band-aid, made out of ignorance rather than intelligent evaluation and decision-making, that actually broke python-xpcom. there appears to be within the mozilla foundation an insanity that says we are gods, javascript is our lord and saviour, any other programming language or the use of any other programming language can go take a running jump. i'm further deeply disappointed and angered to hear that you have found evidence that embedding of the gecko / xulrunner engine is _also_ prevented, prohibited and actively discouraged. it begs the question, what the bloody hell are the mozilla foundation playing at?? anyway - leaving that aside, i thought you should know that yes there is an alternative option in the form of webkit, but that it is equally fraught. all in all i think that the free software community is completely and utterly failing to get with the picture with respect to browser engine technology, and that it is pretty ironic that MSHTML (microsoft's web browser engine technology) just works out-of-the-box and yet the U.S. Dept of Justice and the E.U. Monopolies and Mergers Commission tried to force microsoft *not* to have MSHTML pre-installed. anyway - end that, allow me to outline what's possible with what's already out there. === WebKit === What I'd like to do now is spec out a project for someone to take on, moving Browse to WebKit in a way that can be clearly justified for the community. But, WebKit is totally new to me so I have many open questions. Can anyone help me answer them? I'll be collecting the results into a wiki page (to form the above spec). 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? yes. Does it work well when embedded? Do the developers support it being embedded? no they do not. mark rowe applied evasive dictatorship - bullying and technical goal-post moving that was shown later to be thoroughly hypocritical, allowing identical code which he earlier rejected with unreasonable arguments failing completely to even read counter-arguments or explanations as to why particular decisions had been taken. if you have the time, you can see evidence of his shockingly-bad behaviour here: http://bugs.webkit.org/show_bug.cgi?id=16401 the outcome of what he did has had severe knock-on ramifications as the webkitgtk code which is now in the webkit main tree has severe technical flaws that i am banned i.e. actively prevented and prohibited from discussing, outlining and helping with, on both bugs.webkit.org and also the webkit-dev mailing list. i have been posting various descriptions to help give hints to help fix some of these issues under accounts named webkit censorship bypass but the level of technical expertise is sufficiently high in order to fix these issues that they are dismissed as ramblings and are completely ignored. the consequences are that there are fundamental flaws in both webkitgtk and pywebkitgtk which cannot be fixed without some serious redesign work that will take the inexperienced webkitgtk developers several weeks to understand, and several weeks to implement. Does anyone have experience here? yes. The name WebKit makes it sound nice and modular, and the fact that WebKit itself isn't a browser would seem to support these arguments, but it would be nice being able to argue this on a more solid basis. ok. it's good... but... the code has been developed piece-meal. the mainline webkit tree has gobject bindings support, through which you can use gobject introspection to have python bindings on top of that... ... but the gobject bindings themselves (which are to the DOM) are... well, they're shit basically. and i can say that, because i wrote them. they were the first version, and you know what first version code is like. it's where you learn how to do
Re: [Sugar-devel] Browse and the move to WebKit
Marco Pesenti Gritti marco at marcopg.org writes: On 21 June 2011 23:23, Daniel Drake dsd at laptop.org wrote: You could have been even more convincing if you had used this API: http://webkitgtk.org/reference/index.html (yes, its webkit1, but it looks excellent from a GTK perspective, and a breath of fresh air after seeing what mozilla put you through with hulahop etc!) The reason I posted an example of the cross platform API is that I think it's what really set it apart from gtkmozembed. We would be using (directly or indirectly) the same API everyone else is using which means 1 it will be complete, 2 it will be stable, 3 it will be maintained by the core webkit developers. a word of caution: the core webkit developers do not like to receive input from free software developers: you are entirely at their mercy. they seek to gain complete control over the codebase. if your code does not fit with what they have dictated it shall do, your project is in jeapordy if you become dependent on them. this may sound really... bizarre, but it is direct experience. i worked extremely hard to create the webkit gobject bindings (which you have been discussing and i see using) and mark rowe worked extremely hard to destroy the efforts to make them available in a useful and useable form. unfortunately, mark rowe's efforts succeeded, and the free software community has lost the benefit of my experience and efforts to bring you useful and useable gobject bindings, for which i deeply apologise. it will be years before the damage done by mark rowe is fully comprehended. So, let me see if my understanding lines up with yours. WebKit2 provides an API specification, and all of the different frontends (Qt/GTK/...) implement that API, with only the minor tweaks needed to make it fit in to the platform? Yes. In your example, WKViewCreate() must have been provided as a GTK-specific thing, as it returns a GtkWidget. And the other platforms would provide their own platform-specific implementation? Yes. If I understand it correctly, the webkitgtk developers are aiming to provide both options. First, the cross-platform API implemented to return a GTK+ widget (looks like they've made great progress there). Secondly, a refresh of the GObject-style API, implemented based on top of that cross-platform API. This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 Do you agree with that interpretation? That's also my understanding. As you suggest I do plan to get closer to the upstream development to really get a grip on this, but firstly, I'd be interested in your opinion on 2 further points: 1. If my understanding above is correct, do you think Browse should go with the cross-platform API, or the upcoming GObject-style one? I went back and forward on this. I was annoyed about introducing an extra layer (compared to direct python bindings of the cross-platform API), since there is already plenty of them in that stack. Though I think I'm now pretty convinced using the GObject API is the best approach for Sugar. It's more practical because there are people working on GObject but not direct python bindings. that's incorrect. i wrote the direct python bindings over a year ago: http://www.gnu.org/software/pythonwebkit the gobject bindings approach is fundamentally flawed and unfortunately you will not find this out until you begin to try *significant* usage of the DOM. the number of _actual_ projects that make significant usage of python DOM bindings to webkit, in the world, is a total of one (1) application: pyjamas-desktop. even in the microsoft world, the total number of actual projects that actually make comprehensive (100%) use of python COM bindings to MSHTML (Trident) is one (1) - pyjamas-desktop. i spoke to eric of the microsoft IE team about 2 years ago and he expressed surprise at what had been done, and confirmed that never, in his entire career working with IE, had anything quite so comprehensive as pyjamas-desktop ever been done. and it's necessary! you simply cannot have javascript-equivalent python bindings to the DOM that are not fully without fail absolutely cast-iron guaranteed without one single exception absolutely and 100% identical _to_ the javascript bindings. this was where the shit hit the fan when creating the gobject bindings to webkit, because mark rowe decided SIEG HEIL! I AM GOD! YOU WILL OBEY MY WHIM AND I HAVE DICTATED THAT YOU ARE AN IGNORAMUS WHO NEEDS TO BE TAUGHT A LESSON and unfortunately every free software project that tries to use the gtk gobject bindings will encounter serious fundamental problems as a result of his bullying. More flexible because you could use it from any language with gobject-introspection bindings. More consistent with the rest of the stack. really - don't do it. see the message earlier. i'm sorry i didn't
Re: [Sugar-devel] Browse and the move to WebKit
https://bugzilla.mozilla.org/show_bug.cgi?id=728055 success! http://lkcl.net/hulahop/ ok, for a given definition of success :) i had to comment out the js_push_context and js_pop_context (could not be arsed to deal with those) - you might find that you have to put in some #includes for spidermonkey, and if you ask nicely on this bugreport you may get an answer: https://bugzilla.mozilla.org/show_bug.cgi?id=728115 please can i advise you to get onto that bugreport (728055) and say thank you to josh matthews for kindly pointing out the existence of XRE_InitEmbedding2? other changes i made include: * removing calls to set up NS_XPCOM_COMPONENT_REGISTRY * changing #include and reference to nsIDOMWindow2 to just nsIDOMWindow * commenting out the javascript push and pop. other than that, it works! amazing. and this is with the standard debian packaging for xulrunner-9.0-dev out of debian/testing as of yesterday. yes, that _includes_ python-xpcom (aka pyxpcom). now. can i strongly STRONGLY recommend that you cease the use of webkit and return to using hulahop? you are entirely free to completely ignore this advice, and to see how far it gets you to be using webkit with gobject introspection. actually, in some ways it would be incredibly useful an exercise because you will then have a clear idea of the serious and fundamental flaws that are inherent in webkit's gobject bindings. i will be more than happy to help accelerate the OLPC projects' understanding of the situation, as long as you agree to release a public and detailed technical description of the issues encountered onto the webkit-dev mailing list. preferably without mentioning where you got the advice from, because the webkit developers will treat you like shit if you even mention my name. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
better news: i've just confirmed that: a) the removal of js_push_context and pop context was a spurious error, those functions are now restored, confirmed as compiling and existing (untested) b) the usual critical pyjamas-desktop tests, Helloworld, JSONRPCExample, KitchenSink and Mail all have the exact same behaviour as they used to, way back before the xpcom API breakage [where we all had to wait for todd whiteman to update pyxpcom] this is really really good news because it means that the people who have been keeping an eye on the debian packaging of hulahop and have been going arse! it's fecked! quite a lot will now be happy that it all works, and i am confident that within a few weeks/months people will be able to do apt-get install pyjamas-desktop python-hulahop again and have it all work. yeAHHH! :) l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 22 June 2011 12:54, Marco Pesenti Gritti ma...@marcopg.org wrote: On 21 June 2011 23:23, Daniel Drake d...@laptop.org wrote: 2. In order to get Browse, Help and Wikipedia up and running on webkit, do you see the need for a hulahop equivalent? Or some kind of sugar-level web widget abstraction? Or just direct calls into webkit. I'm not sure. I think hulahop in principle is pretty much equivalent to WebKitGtk + PyGi. In practice though I suspect there are going to be differences on the amount of code required to write something like Wikipedia and Help. If it's too much, people will just cut/paste the whole Browse, which I think we should avoid. The way I would approach it, is to first port Browse basing it directly on WebKitGtk. Then port Help or Wikipedia and see if it make sense to share code. If it's generic enough to be upstreamed we should try to. If it's sugar specific, adding it to sugar-toolkit would probably make sense (a common toolbar implementation for example?). In my porting of Browse from hulahop to pywebkitgtk, the code got a lot smaller. WebKit's API is in fact much nicer and much more complete than what hulahop offers, the latter requiring direct XPCOM usage. No need for a hulahop-webkit. On 22 June 2011 19:02, Daniel Drake d...@laptop.org wrote: The biggest finding that came from outside this thread is that if Browse is to move to pygi to access webkit, the Sugar python bits that it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So we have a prerequisite on sugar (or at least parts of it?) being moved to gtk3/pygi first. Just nitpicking, but gtk2/pygi is a perfectly good option as well, and it may even work with sugar-toolkit (depending on the status of python-gobject and sugar-toolkit). In the worst case, gtk2/pygi would have to be used with a port of sugar-toolkit to pygi. There is no need to bother with gtk3. Also, it'll be much easier to move Surf from pygtk2/pywebkitgtk to gtk2/pygi than to gtk3/pygi anyway. On 23 June 2011 13:16, Marco Pesenti Gritti ma...@marcopg.org wrote: On 22 June 2011 19:02, Daniel Drake d...@laptop.org wrote: I think this is exciting and definitely a good area to explore, but at this point I'm trying to keep it separate from the rescue Browse operation. I outlined the reasoning here: http://wiki.sugarlabs.org/go/Features/WebKit I totally agree with you there. I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 June 2011 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: Just nitpicking, but gtk2/pygi is a perfectly good option as well, and it may even work with sugar-toolkit (depending on the status of python-gobject and sugar-toolkit). According to a conversation I had with Tomeu and J5 (pygi developers), pygi introspection to gtk2 libraries does not work well and is unsupported. Also, mixing pygi with pygtk is impossible and will fall over immediately. According to them, pure gtk3 is the only solution. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 June 2011 14:10, Daniel Drake d...@laptop.org wrote: On 24 June 2011 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: Just nitpicking, but gtk2/pygi is a perfectly good option as well, and it may even work with sugar-toolkit (depending on the status of python-gobject and sugar-toolkit). According to a conversation I had with Tomeu and J5 (pygi developers), pygi introspection to gtk2 libraries does not work well and is unsupported. Also, mixing pygi with pygtk is impossible and will fall over immediately. According to them, pure gtk3 is the only solution. Hmm, that's quite different from my last talk with them. I was told that gtk2 is fine and that since py-gi is based on pygobject, there's a chance it might work with pygtk2. Not having gtk2 support is quite nasty, and it changes a lot of plans. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 Jun 2011, at 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. I didn't mean integration of the HTML activities stuff with Sugar but integration (inclusion) of the HTML activities stuff in the Sugar platform. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 June 2011 15:13, Marco Pesenti Gritti ma...@marcopg.org wrote: On 24 Jun 2011, at 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. I didn't mean integration of the HTML activities stuff with Sugar but integration (inclusion) of the HTML activities stuff in the Sugar platform. Right. But that first requires a sugar-web-toolkit to exist :) The way I see it, after one such toolkit has been written, it can be decided whether or not to bundle it with Sugar. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 Jun 2011, at 15:56, Lucian Branescu lucian.brane...@gmail.com wrote: On 24 June 2011 15:13, Marco Pesenti Gritti ma...@marcopg.org wrote: On 24 Jun 2011, at 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. I didn't mean integration of the HTML activities stuff with Sugar but integration (inclusion) of the HTML activities stuff in the Sugar platform. Right. But that first requires a sugar-web-toolkit to exist :) The way I see it, after one such toolkit has been written, it can be decided whether or not to bundle it with Sugar. I don't see it any differently, I'm not sure if/where we are disagreeing :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 22 June 2011 19:02, Daniel Drake d...@laptop.org wrote: I think this is exciting and definitely a good area to explore, but at this point I'm trying to keep it separate from the rescue Browse operation. I outlined the reasoning here: http://wiki.sugarlabs.org/go/Features/WebKit I totally agree with you there. I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 21 June 2011 23:23, Daniel Drake d...@laptop.org wrote: You could have been even more convincing if you had used this API: http://webkitgtk.org/reference/index.html (yes, its webkit1, but it looks excellent from a GTK perspective, and a breath of fresh air after seeing what mozilla put you through with hulahop etc!) The reason I posted an example of the cross platform API is that I think it's what really set it apart from gtkmozembed. We would be using (directly or indirectly) the same API everyone else is using which means 1 it will be complete, 2 it will be stable, 3 it will be maintained by the core webkit developers. So, let me see if my understanding lines up with yours. WebKit2 provides an API specification, and all of the different frontends (Qt/GTK/...) implement that API, with only the minor tweaks needed to make it fit in to the platform? Yes. In your example, WKViewCreate() must have been provided as a GTK-specific thing, as it returns a GtkWidget. And the other platforms would provide their own platform-specific implementation? Yes. If I understand it correctly, the webkitgtk developers are aiming to provide both options. First, the cross-platform API implemented to return a GTK+ widget (looks like they've made great progress there). Secondly, a refresh of the GObject-style API, implemented based on top of that cross-platform API. This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 Do you agree with that interpretation? That's also my understanding. As you suggest I do plan to get closer to the upstream development to really get a grip on this, but firstly, I'd be interested in your opinion on 2 further points: 1. If my understanding above is correct, do you think Browse should go with the cross-platform API, or the upcoming GObject-style one? I went back and forward on this. I was annoyed about introducing an extra layer (compared to direct python bindings of the cross-platform API), since there is already plenty of them in that stack. Though I think I'm now pretty convinced using the GObject API is the best approach for Sugar. It's more practical because there are people working on GObject but not direct python bindings. More flexible because you could use it from any language with gobject-introspection bindings. More consistent with the rest of the stack. 2. In order to get Browse, Help and Wikipedia up and running on webkit, do you see the need for a hulahop equivalent? Or some kind of sugar-level web widget abstraction? Or just direct calls into webkit. I'm not sure. I think hulahop in principle is pretty much equivalent to WebKitGtk + PyGi. In practice though I suspect there are going to be differences on the amount of code required to write something like Wikipedia and Help. If it's too much, people will just cut/paste the whole Browse, which I think we should avoid. The way I would approach it, is to first port Browse basing it directly on WebKitGtk. Then port Help or Wikipedia and see if it make sense to share code. If it's generic enough to be upstreamed we should try to. If it's sugar specific, adding it to sugar-toolkit would probably make sense (a common toolbar implementation for example?). The hardest case are activities which implement their content view in html and the rest using native widgets. Just some thoughts: * I'm not really convinced about using the web page exclusively as a DOM tree and try to manipulate it outside the sandbox. I'm not going to elaborate much on that to not digress, suffice to say that you wouldn't be able to use stuff like the canvas with that approach. * I like the idea of activities based exclusively on the web stack, using a local nodejs server to communicate with the system, but it's a lot of work. Using the cross platform API to write the viewer would be the most sensible approach, so it doesn't really affect Browse anyway. http://marcopg.org/2011/06/12/html-activities/ * Injecting javascript is a bit of an hack but it might be a practical/low cost solution. WebKitGtk doesn't seem to have something like iOS stringByEvaluatingJavaScriptFromString but it looks like it should be easy to add. I'm not sure about browser - application communication, maybe we could use window.postMessage and some hooks in WebKitGtk to listen to those. It could even be abstracted as sendMessage/addMessageListener kind of API, in both directions, using json messages. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 15 June 2011 05:58, Daniel Drake d...@laptop.org wrote: There have been various discussions in the past suggesting a move from mozilla to webkit for the Browse activity and related components, but I've never really been convinced: there is always a cost to switching, and convincing-looking numbers from webkit supporters tended to be countered with convincing-looking numbers from mozilla supporters. But now I believe there is a new reason for the switch to WebKit: necessity. Aside from just Web browsers, how about supporting HTML5/JS activities more directly? Karma[0] looks very cool[1], but unfortunately it looks like a dormant project. I think we can create a lot of potential[2] by integrating WebKit into Sugar, rather than just having a Web browser on top. Sridhar [0] http://wiki.sugarlabs.org/go/Karma [1] http://karma.sugarlabs.org/ [2] http://www.dhanapalan.com/blog/2011/06/23/html5-in-sugar/ Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 22 June 2011 12:54, Marco Pesenti Gritti ma...@marcopg.org wrote: I'm not sure. I think hulahop in principle is pretty much equivalent to WebKitGtk + PyGi. In practice though I suspect there are going to be differences on the amount of code required to write something like Wikipedia and Help. If it's too much, people will just cut/paste the whole Browse, which I think we should avoid. The way I would approach it, is to first port Browse basing it directly on WebKitGtk. Then port Help or Wikipedia and see if it make sense to share code. If it's generic enough to be upstreamed we should try to. If it's sugar specific, adding it to sugar-toolkit would probably make sense (a common toolbar implementation for example?). Thanks for your input on this. I've summarised all the collected info so far here: http://wiki.sugarlabs.org/go/Features/WebKit The biggest finding that came from outside this thread is that if Browse is to move to pygi to access webkit, the Sugar python bits that it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So we have a prerequisite on sugar (or at least parts of it?) being moved to gtk3/pygi first. The hardest case are activities which implement their content view in html and the rest using native widgets. Just some thoughts: I think this is exciting and definitely a good area to explore, but at this point I'm trying to keep it separate from the rescue Browse operation. I outlined the reasoning here: http://wiki.sugarlabs.org/go/Features/WebKit Thanks! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
The biggest finding that came from outside this thread is that if Browse is to move to pygi to access webkit, the Sugar python bits that it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So we have a prerequisite on sugar (or at least parts of it?) being moved to gtk3/pygi first. Why do not you implement the new Browse in C/C++? It would have three advantages: 1. It could reuse an existing WebKit browser's code. 2. It would not depend on incomplete/unmaintained python bindings. 3. It would be fast. At least it would not use 60M of python runtime memory per process. Of course it would require reimplementing some simple toolbar and children would not be able to look into the browser's codebase (only though the web) but I think it would be an interesting option to consider. At least the 3. point could be important enough for the most used application in Sugar... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
2011/6/22 NoiseEHC noise...@freemail.hu: Why do not you implement the new Browse in C/C++? Sugar is developed as a Python-based platform. It would have three advantages: 1. It could reuse an existing WebKit browser's code. 2. It would not depend on incomplete/unmaintained python bindings. 3. It would be fast. At least it would not use 60M of python runtime memory per process. The implementation plan I propose tackles all of those points. I am proposing that webkit is embedded into an application, so it is an existing browser, not a new one. If you think things like managing back/forward would be difficult, take a quick look at the webkitgtk API and think again. Or look at the webkit minibrowser. The push for pygi means no depending on python bindings that need maintenance. The move to pygi is expected to drop memory usage and improve startup time. Of course it would require reimplementing some simple toolbar and children would not be able to look into the browser's codebase (only though the web) but I think it would be an interesting option to consider. At least the 3. point could be important enough for the most used application in Sugar... Yes, it would be a huge drop in maintainability, and the maintainance problem is exactly why I dragged myself into this problem. Unless you are proposing that all of Sugar moves to C as a base; that may have its merits but is a separate discussion, and not one I'm going to get involved with. Feel free to start a new thread / Feature page. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
Unless you are proposing that all of Sugar moves to C as a base; that may have its merits but is a separate discussion, and not one I'm going to get involved with. Feel free to start a new thread / Feature page. I am not proposing anything. I just showed an option that no one considered. I mean that I thought that no one considered... :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 14 June 2011 23:52, Marco Pesenti Gritti ma...@marcopg.org wrote: On 14 June 2011 20:58, Daniel Drake d...@laptop.org wrote: 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? Does it work well when embedded? Do the developers support it being embedded? With WebKit2, this all you need to load a web page into a GtkBox WKViewRef web_view = WKViewCreate(WKContextGetSharedProcessContext(), 0); WKPageLoadURL(WKViewGetPage(web_view), WKURLCreateWithUTF8CString(PAGE_URL)); gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(web_view), TRUE, TRUE, 0); gtk_widget_show(GTK_WIDGET(web_view)); You could have been even more convincing if you had used this API: http://webkitgtk.org/reference/index.html (yes, its webkit1, but it looks excellent from a GTK perspective, and a breath of fresh air after seeing what mozilla put you through with hulahop etc!) WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic. In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. So, let me see if my understanding lines up with yours. WebKit2 provides an API specification, and all of the different frontends (Qt/GTK/...) implement that API, with only the minor tweaks needed to make it fit in to the platform? In your example, WKViewCreate() must have been provided as a GTK-specific thing, as it returns a GtkWidget. And the other platforms would provide their own platform-specific implementation? This is nice from a cross-platform perspective, but I do really like what has been done with WebKit1: http://webkitgtk.org/reference/index.html i.e. they have provided a really nice fully GObject-style API that lets you put a web browser in your app. For those of us who are experienced with glib/gobject/GTK+ and do all our other work with those technologies, this API is probably preferable to the cross-platform one, simply because it is more familiar from the outset. If I understand it correctly, the webkitgtk developers are aiming to provide both options. First, the cross-platform API implemented to return a GTK+ widget (looks like they've made great progress there). Secondly, a refresh of the GObject-style API, implemented based on top of that cross-platform API. This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 Do you agree with that interpretation? As you suggest I do plan to get closer to the upstream development to really get a grip on this, but firstly, I'd be interested in your opinion on 2 further points: 1. If my understanding above is correct, do you think Browse should go with the cross-platform API, or the upcoming GObject-style one? 2. In order to get Browse, Help and Wikipedia up and running on webkit, do you see the need for a hulahop equivalent? Or some kind of sugar-level web widget abstraction? Or just direct calls into webkit. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
2. In order to get Browse, Help and Wikipedia up and running on webkit, do you see the need for a hulahop equivalent? Or some kind of sugar-level web widget abstraction? Or just direct calls into webkit. From the point of view of the activity, Wikipedia and Help are using the same code of Browse. There are other activities like SocialCalc trying to use more interaction between python and dom/javascript, but are a pile of hacks. I think there are work in webkit2 to implement DOM, but I don't know if is merged in F15. Right now you can execute javascript, but to get a value is also a hack (changing the title and getting the value from the python property) You can see this in the read activity in epubview/widgets.py Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 17 June 2011 18:13, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Jun 17, 2011 at 1:00 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Not in a while. Earlier builds on Ubuntu were very unstable and buggy. Just installed on F15 - will try out. I also saw crashes with WebKit-based epiphany when I tried it a few months ago, but those issues do seem to be fixed now. I switch to Epiphany on my F15 desktop in response to this episode and haven't seen any crashes so far - I'm very happy with it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: With WebKit2, this all you need to load a web page into a GtkBox So that's my understanding of WebKit -- it's easily embeddable. I am not sure whether the API is as complete or as good as we want it. IOWs, it's likely not a trivial job to get a good polished result. Just from using the various webkit-based browsers in existence in recent Fedoras and Ubuntus -- while both Safari and Webkit are outstanding (and backed by large dev teams), Surf limited but workable (a few versions back, need to test latest!...) everything else has been very unstable and disappointing. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 17 June 2011 17:51, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: With WebKit2, this all you need to load a web page into a GtkBox So that's my understanding of WebKit -- it's easily embeddable. I am not sure whether the API is as complete or as good as we want it. I think the WebKit2 API must be complete or Apple wouldn't have been able to build Safari on the top of it. What I'm not sure is if the gtk backend implementation is complete/polished enough. IOWs, it's likely not a trivial job to get a good polished result. Absolutely not trivial. It would be probably quicker to get a working browser by forking firefox or chrome, but then maintenance would be quite a burden. Just from using the various webkit-based browsers in existence in recent Fedoras and Ubuntus -- while both Safari and Webkit are outstanding (and backed by large dev teams), Surf limited but workable (a few versions back, need to test latest!...) everything else has been very unstable and disappointing. Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Fri, Jun 17, 2011 at 1:00 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Not in a while. Earlier builds on Ubuntu were very unstable and buggy. Just installed on F15 - will try out. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Browse and the move to WebKit
There have been various discussions in the past suggesting a move from
mozilla to webkit for the Browse activity and related components, but
I've never really been convinced: there is always a cost to switching,
and convincing-looking numbers from webkit supporters tended to be
countered with convincing-looking numbers from mozilla supporters.
But now I believe there is a new reason for the switch to WebKit: necessity.
=== Mozilla ===
First, why I've become convinced that Mozilla is no longer a viable
option in the face of alternatives:
I've been looking at a bug where Browse can't pass the focus from a
normal GTK+ widget to a text input field inside the hulahop browser
window. I think this bug was added in xulrunner-1.9.2 (over v1.9.1).
We are not the only ones to conclude that embedding xulrunner-1.9.2
into your own app is totally broken:
https://bugzilla.mozilla.org/show_bug.cgi?id=533245
Until xulrunner-2.0, mozilla provided a gtkmozembed widget within
mozilla, a GTK+ widget that you could use to trivially embed a
Mozilla-based web browser window to your GTK+ app. We didn't use it
(presumably because it was a bit simplistic) but our hulahop
equivalent had a lot in common and was no doubt built from knowledge
of gtkmozembed.
Mozilla have now removed gtkmozembed altogether because it was
unmaintained and doesn't represent the direction we
want for embedding in general yet I've been looking and I can't find
any example which *do* represent what they want. If they did want to
influence the right direction on people they should provide good
examples.
But the clear message from
http://groups.google.com/group/mozilla.dev.embedding/msg/98cb5d92e48f5d01
is that embedding isn't a concern for Mozilla and they acknowledge
that it hasn't been given the support it deserves. They are taking
steps to make embedding actively harder and actively discourage
against using mozilla in this way:
https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
Also, the mindset in which mozilla is developed seems to sit a long
way out of our traditional open-source ecosystem (where we aren't
bugged by problems like DLL hell). They have gone in the direction
that enables you to build and install a mozilla-using application
without having mozilla installed. The mozilla stuff can then be
located at runtime and used. Here are the hoops they now put us
through as of xulrunner-2.0, enabling this approach (which is of
little use for us and just seems ridiculous):
We want to call the function XRE_InitEmbedding() inside libxul. This
is the first thing you need to do if you want to embed mozilla in
another app.
XRE_InitEmbedding has been removed from the mozilla public headers, so
we have to go into the mozilla source so that we can include the
definition in our own code. Found it:
typedef nsresult (__cdecl *XRE_InitEmbeddingType)(nsILocalFile
*aLibXULDirectory,
nsILocalFile *aAppDirectory,
nsIDirectoryServiceProvider *aAppDirProvider,
nsStaticModuleInfo const *aStaticComponents,
PRUint32 aStaticComponentCount);
Next problem: nsStaticModuleInfo doesn't exist in Mozilla public
headers either. As its just a pointer that we don't use (we pass
NULL), lets just make it void.
typedef nsresult (__cdecl *XRE_InitEmbeddingType)(nsILocalFile
*aLibXULDirectory,
nsILocalFile *aAppDirectory,
nsIDirectoryServiceProvider *aAppDirProvider,
const void *aStaticComponents,
PRUint32 aStaticComponentCount);
Next problem: this function is alive and present in libxul but doesn't
exist in the regular symbol table! So we need to use some Mozilla
magic to find it:
XRE_InitEmbeddingType XRE_InitEmbedding;
static const struct nsDynamicFunctionLoad kXRESymbols[] = {
{ XRE_InitEmbedding, (NSFuncPtr*) XRE_InitEmbedding },
{ nsnull, nsnull }
};
XPCOMGlueLoadXULFunctions(kXRESymbols);
Now XRE_InitEmbedding will be set and we can call it like a function.
Is this feeling long winded yet?
There's more! XPCOMGlueLoadXULFunctions() isn't present in libxul!
Because remember, our app can't link against libxul at all. So where
does it come from?
It comes from libxpcomglue, a static library shipped by xulrunner
which we must statically link against, including it wholly inside our
app.
Now, after jumping through many hoops, we can finally call a function
inside the library we are interested in. Now we just have to get
through the run-time bugs such as focus issues which have spent months
unfixed in mozilla-central...
The combination of the fact that mozilla embedding has been neglected
over the years, is currently broken and is now actively discouraged,
and the fact that general use and design of the library sits way
outside of our open-source norms means that I've lost faith in this
being a good option for us
Re: [Sugar-devel] Browse and the move to WebKit
I'm not a developer so some of what I write is here say but from what I know of from following various upstream. On Tue, Jun 14, 2011 at 8:58 PM, Daniel Drake d...@laptop.org wrote: There have been various discussions in the past suggesting a move from mozilla to webkit for the Browse activity and related components, but I've never really been convinced: there is always a cost to switching, and convincing-looking numbers from webkit supporters tended to be countered with convincing-looking numbers from mozilla supporters. But now I believe there is a new reason for the switch to WebKit: necessity. === Mozilla === First, why I've become convinced that Mozilla is no longer a viable option in the face of alternatives: snip The combination of the fact that mozilla embedding has been neglected over the years, is currently broken and is now actively discouraged, and the fact that general use and design of the library sits way outside of our open-source norms means that I've lost faith in this being a good option for us (and I've got so frustrated by this episode that I've changed web browser on my desktop system as well). Would a skinned version of Firefox Mobile work for what is needed? === WebKit === What I'd like to do now is spec out a project for someone to take on, moving Browse to WebKit in a way that can be clearly justified for the community. But, WebKit is totally new to me so I have many open questions. Can anyone help me answer them? I'll be collecting the results into a wiki page (to form the above spec). 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? Does it work well when embedded? Do the developers support it being embedded? Yes. Its used by yelp (gnome help) and various other applications and libraries. Eclipse embeds it in SWT and a number of mail clients use it for html mail rendering (I think Claws uses it). Does anyone have experience here? The name WebKit makes it sound nice and modular, and the fact that WebKit itself isn't a browser would seem to support these arguments, but it would be nice being able to argue this on a more solid basis. In theory it should be nice an modular, the JS is a separate component for example. Details of all the components are here: http://trac.webkit.org/wiki/HackingGtk 2. What is the state of Surf? This is the existing webkit-based browser for Sugar. Does it work well? Is it reliable? What are the gaping holes? It works, we're shipping it in SoaSv5. 3. What is the safe of pywebkitgtk in F14, F15, F16? This is the backend library used by Surf, right? Is this still the right answer for creating a webkit-based app using Python + GTK? Does it work well on Fedora 14, or do we need a newer distro? It works with Surf on F-14 (yum install sugar-surf for a quick test) but I have no idea of the state of it. Looking at the rpm changelog in Fedora 1.1.6 is the current release in Fedora, current as of Aug 2009, although 1.1.8 is in F-15 as of March. Looking at the 1.4.x release that ships with F-15 it looks like there's gobject introspection support has been added so I suggest that for a new project that might be the best way to go for python support. Tomeu might be the best person to reply to that point though. F-14 ships 1.3.10. Looking at the changelogs I suspect we're stuck on that version due to requirements on libsoup. There's issues with the version in F-14 in that it doesn't support TLS and a number of other things (not sure exactly what else though). I remember at one point there being some pretty key problems with pywebkitgtk causing Surf development to halt. What were these issues and have they been overcome? I suspect the solution is to use introspection instead. The support seems complete since the release of 1.4.x stable release in F-15. IIRC those pywebkitgtk-related problems were going to be solved with a move to GObject introspection, which wasn't mature back in that timeframe. But it is mature and usable now. But does this require us to move to GTK+-3? I don't believe it does. In F-14 and F-15 there's both webkitgtk and webkitgt3 releases. Does WebKit/webkitgtk work for both GTK+-2 and GTK+-3? Any pros/cons of one over the other? There's 2 different builds of them in both F-14 and F-15. The gtk3 linked version in both releases trails behind the gtk2 release, I don't believe that's due to lack of support for gtk3 but rather someone hasn't kept the releases in sync. Not a complete answer but should give you a start. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 14 June 2011 21:35, Peter Robinson pbrobin...@gmail.com wrote: Would a skinned version of Firefox Mobile work for what is needed? No, as we need collaboration, journal access, etc. But (I didn't include this argument as I lost the link) this response matches what I read from mozilla developers: if you want to build a mozilla-based product, fork the mozilla codebase and write your application inside there. Not a viable option for us, and again, way outside our norms... Thanks for the webkit info - indeed a good start! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Tue, Jun 14, 2011 at 4:42 PM, Daniel Drake d...@laptop.org wrote: On 14 June 2011 21:35, Peter Robinson pbrobin...@gmail.com wrote: Would a skinned version of Firefox Mobile work for what is needed? No, as we need collaboration, journal access, etc. But (I didn't include this argument as I lost the link) this response matches what I read from mozilla developers: if you want to build a mozilla-based product, fork the mozilla codebase and write your application inside there. I did work on that; you can certainly make a firefox extension that supports collaboration, journal access, etc. My firefox activity did some of what's necessary. Firefox can speak dbus, etc. That said, I had first-hand experience w/ a project which switched from embedded mozilla to webkit, and I can testify that the performance improvement was indeed significant. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 14 June 2011 20:58, Daniel Drake d...@laptop.org wrote: 2. What is the state of Surf? This is the existing webkit-based browser for Sugar. Does it work well? Is it reliable? What are the gaping holes? It works reasonably well. I couldn't implement cookies for example, because that requires libsoup bindings. libsoup folks recommended I use pygi. There are a few other gaps in functionality. Surf is forked from Browse a few versions back (I think 119). Some new features could be backported from newer Browse, but overall I consider the Surf codebase in a reasonable state, just incomplete. 3. What is the safe of pywebkitgtk in F14, F15, F16? This is the backend library used by Surf, right? Is this still the right answer for creating a webkit-based app using Python + GTK? Does it work well on Fedora 14, or do we need a newer distro? I remember at one point there being some pretty key problems with pywebkitgtk causing Surf development to halt. What were these issues and have they been overcome? pywebkitgtk is unmaintained, and its author has moved to pygi. Switching to pygi shouldn't be hard at all from what I've seen, it's an almost entirely automated process. IIRC those pywebkitgtk-related problems were going to be solved with a move to GObject introspection, which wasn't mature back in that timeframe. But it is mature and usable now. But does this require us to move to GTK+-3? pygi itself is much more mature, indeed. However, last year there were significant problems with using sugar-toolkit together with pygi, since sugar-toolkit uses (used?) static bindings. I don't know what the status is now, the issues may no longer exist. iirc, part of the reason pygi was merged in pygobject was to better support static bindings based on pygobject. It doesn't require moving to GTK3, which is entirely orthogonal to pygi afaik. Does WebKit/webkitgtk work for both GTK+-2 and GTK+-3? Any pros/cons of one over the other? I don't know about the state of their GTK3 port, but I believe they're working on it. On 14 June 2011 22:05, C. Scott Ananian csc...@laptop.org wrote: On Tue, Jun 14, 2011 at 4:42 PM, Daniel Drake d...@laptop.org wrote: On 14 June 2011 21:35, Peter Robinson pbrobin...@gmail.com wrote: Would a skinned version of Firefox Mobile work for what is needed? No, as we need collaboration, journal access, etc. But (I didn't include this argument as I lost the link) this response matches what I read from mozilla developers: if you want to build a mozilla-based product, fork the mozilla codebase and write your application inside there. I did work on that; you can certainly make a firefox extension that supports collaboration, journal access, etc. My firefox activity did some of what's necessary. Firefox can speak dbus, etc. Yes, if mozilla is desired, the way to go is to extend xulrunner, not embed it. An alternative chrome and a couple of extensions for sugar integration would provide that. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 14 June 2011 20:58, Daniel Drake d...@laptop.org wrote: 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? Does it work well when embedded? Do the developers support it being embedded? With WebKit2, this all you need to load a web page into a GtkBox WKViewRef web_view = WKViewCreate(WKContextGetSharedProcessContext(), 0); WKPageLoadURL(WKViewGetPage(web_view), WKURLCreateWithUTF8CString(PAGE_URL)); gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(web_view), TRUE, TRUE, 0); gtk_widget_show(GTK_WIDGET(web_view)); Quite an improvement over mozilla :) More importantly, from http://trac.webkit.org/wiki/WebKit2 WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic. In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. A couple of important points here: 1 The API is stable, something that mozilla never guaranteed even between minor releases. 2 The API is the same every other WebKit2 based browser will be using, it's not a special, incomplete subset of the API for embedders (I would say that was the crux of the problem with gtkmozembed). My main worry is not about embeddability really but about the quality of the gtk specific bits. I'm not sure I trust libsoup for example. Motorola and Igalia are working on those http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/ It would probably be a good idea to talk with them about status/plans. Testing MiniBrowser should be interesting too, it builds very easily on F15. Hope that helps, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
