On 6/10/09, Tomeu Vizoso <to...@sugarlabs.org> wrote: > Hi Luke, hii tomeu
> > so i just wanted to ask: do you _know_ how many people have been > > looking, for years, for python bindings to XUL? are you _aware_ how > > powerful and how under-appreciated hulahop is? :) the mozilla mailing > > lists and other mailing lists are stuffed with unanswered questions > > dating back to 2006, "how do i use python-xpdom to actually _do_ > > anything???" and you guys just made it... dead-easy. > > > Well, I actually blogged about this recently, though it was syndicated > only by the sugar and gnome planets: > > http://blog.tomeuvizoso.net/2009/01/embedding-mozilla.html > http://blog.tomeuvizoso.net/2009/01/galeon-and-learning.html i tell ya - it's _just_ not getting picked up, because it's very difficult for people to conceptualise this stuff [oh? web browser? that's javascript only, right? huh? what do you _mean_ W3C DOM can be accessed from other programming languages? what's a W3C, anyway, and what does my best friend dominic have to do with it?] and even more difficult for them to find the right search-engine keywords to find it. if python-hulahop was on the mozilla front page, people would start to investigate it and go "coool". > Would be great if more people used hulahop and even took over the > maintenance of the project. Even more if pyxpcom was more actively > maintained. well, the thing is that pyxpcom just "works". it's a meta-project. any extensions to XUL are, i believe, _automatically_ accessible, via the COM interfaces. so it's not like it actually _needs_ any "maintenance" - just the occasional kick up the backside if XUL / Gecko itself undergoes a major overhaul (unlikely). and i believe that hulahop falls into that same category. there's another little project like this - python-htmltmpl - which hasn't had _any_ maintenance work done on it since 2001. reason: it doesn't bloody need it! :) it works, it ain't broke, it does what is needed.... yet people think that it somehow needs... maintenance. ... naah :) > > > i've created a small sample, here: > > http://lkcl.net/pyjamas/pyjamas-xpdom.tgz > > > > run python ./hula.py and it will build a web page purely using DOM > > manipulation in python and also turn the body background green - again > > using DOM manipulation of the body CSS stylesheet. also i think i did > > an event click listener (ContentInvoker) because those are quite > > tricky to get right. > > > > rather painfully, i had to add a timer delay in order to let the page > > settle down (with a blank page) otherwise the DOM isn't ready / > > initialised - i couldn't work out any other way of doing this but i > > understand vaguely what's going on. > > > A progress listener should work, if I understand the issue correctly. See: > > > http://git.sugarlabs.org/projects/browse/repos/mainline/blobs/master/progresslistener.py bing, that's it. and the Download class, too. ok - that _should_ be it. i'm positive i tried it, but hey. will see again when i do the pyjamas-xpdom/hulahop port. thank you. > An check out how we attach the listener to mozilla, there's some > weakref magic going on. ok. > Well, we actually started with mozilla and gtkmozembed, oo dear :) > and though we > have considered adding a webkit backend at some points, nobody had the > time to go for it to the end. > > > > so - the things that were missing from webkit (decent python bindings > > which include DOM-level manipulation) are now available, and you > > could, conceivably, replace XUL with webkit, and still have the level > > of functionality that is available, now (he said... :) > > > What about the other mozilla stuff we use through PyXPCOM? Are there > equivalents in Webkit for all of them? should be (give me some examples i can check) - after all it's a browser engine, it's supposed to be useable to create entire fully-functioning web browsers. loading start/stop signals, console callbacks, progress-bar signals, etc. etc. the only significant thing that's a bit of a pain (added recently, and imo added incomplete/incorrectly) is "open in new window" signal, to which the new URL itself is not handed, and you _have_ to return a new WebKitWebView from it. which is rather restrictive a design. > > lastly i just want to emphasise that if you look at e.g. > > pyjamas-desktop http://pyjd.org you can see that it is possible to > > create an entire desktop widget set API on top of this browser > > technology, that is actually independent of the browser technology > > implementation: it doesn't matter if it's KHTML, xpdom/hulahop or > > pywebkitgtk. and it's clear that browser technology makes for a > > better desktop widget set API than desktop widget set APIs do. gtk > > and qt4 are _crap_ by comparison. > > > Would be interesting to have some sample Sugar activities written > using pyjamas. That would allow us to better compare it to pygtk for > our uses. *sigh* - consider it to be a bit like stopping all development using pygtk and converting everything to pyqt instead (but see right at end - there is a possible way out) the only reason therefore to give it really serious consideration is the fact that pyjamas apps can be compiled to javascript, to run in all major web browsers, but you _really_ have to subdivide the applications along MVC lines, into front-end and back-end, first, using XMLHTTPRequest as the sole exclusive communications mechanism between front-end and back-end. then, if you want, you can replace the web browser with webkit (or with python-hulahop when i've done the port of pyjamas-desktop to hulahop) and thus run the app - unmodified - in pure python. _including_ being able to use python DOM bindings to webkit's XMLHTTPRequest functionality. so yeah - you get that total app agnosticity, browser independence, total widget set agnosticity - but you _have_ to subdivide the app as MVC. one key advantage you get of making the apps browser-capable in this way is that you automatically get that "thin client" capability (albeit, because you'd be running monster amounts of javascript it wouldn't be _that_ thin - 512mb RAM minimum even with webkit). so you'd be in a position to: * have OLPC laptops with no hard drive at all, even only PXE net-booted (from another OLPC laptop!) * have one OLPC laptop be the "server" for other thin-client systems. the back-end running on the OLPC laptop and the front-end (python compiled to javascript) served up to much less capable or even _borrowed_ machines (think 15-year-old pentium III machines) * have one student be able to show another student or a teacher their work, even remotely, simply by giving the other student or the teacher the URL of their work (served from their laptop). lastly... i _was_ going to mention a workaround - a possibility for running gtk under pyjamas, using what luis, a gsoc 2007 student did, which was to create a port of python-gtk2 on top of the pyjamas javascript environment: http://code.google.com/p/pyjamas/wiki/GsocLlpamies but... i just saw (downloaded) sugar-graphics-toolkit, and, actually, yaay! you have an abstraction layer, yaaay! so there is a distinct possibility for just throwing in pyjamas-desktop underneath that. src/sugar/graphics/*.py is only 5,500 lines total. the MVC subdivision could be left for another time: you don't _have_ to restrict the API to use XMLHTTPRequest. so - anyway: long answer to a short wish/question, which clearly illustrates the level at which things could be done - not in the actual apps (unless they too start using gtk direct) but in the core sugar graphics API. l. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel