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 participate in this discussion earlier when it was first underway: i simply didn't know that this discussion was even taking place. > > 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. other than the fundamental programming errors and subtle flaws, yes. > The hardest case are activities which implement their content view in > html and the rest using native widgets. this is why, approximately 2 years ago, i recommended that the OLPC project turn the entire SUGAR environment on its head, and convert whole-sale to pyjamas-desktop. when the native widgets *are* HTML/DOM-based widgets, there *is* no such problem. however, with access to the python-DOM, there is at least some tricks that you can play, such as creating python callbacks that respond to events on the bits of HTML (mouse-over, mouse-click) etc. i can show you how to do that *without* having to have the pyjamas-desktop infrastructure, but please for god's sake don't use the gobject-introspection code to try it, you *will* end up with an unstable application. > 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. it's actually fun :) > 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. yyyyes you caaaaan :) take a look at pyjamas Canvas widget. ok, it depends what you mean by "canvas" - if you mean SVG Canvas as in HTML5 SVG DOM-controlled Canvas, yes you can. > * 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. not if you convert everything to be a client-server architecture using JSONRPC it isn't. i also recommended this (2 years ago) in the proposal. > * Injecting javascript is a bit of an hack but it might be a > practical/low cost solution. no, it is not a "bit of a hack", it is the absolute worst possible thing that you could even remotely possibly consider. it's a one-way trap, basically. there is no way to get the execution results back out, except by *shudder* polling bits of hidden DOM that you store the results of the execution of whatever javascript functions were called. > WebKitGtk doesn't seem to have something > like iOS stringByEvaluatingJavaScriptFromString but it looks like it > should be easy to add. yeah... it's not. ok, it is - but then you have to convert the return result into something meaningful in python. the projects that i know of that have done this are pyv8 and python-spidermonkey. pyv8 uses libboost to help with the conversion (including exceptions, amazingly!) and python-spidermonkey is much less mature, but is functional. > I'm not sure about browser -> application > communication, DOM events. pythonwebkit allows you to drop python callbacks onto *any* event type, from onload at the document level to onresize at the window level to onclick and even onxmlhttprequest AJAX responses. it's actually quite straightfoward, but you have to really think "outside the box", where the box is "javascript is god, javascript is isolated, javascript is the world" and start realising that through pythonwebkit there are 350 DOM objects now available to you, with over 3,000 DOM functions and over 20,000 DOM properties and approximately 100 different types of events. > 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. JSON messages (in a hidden iframe!) was how i envisaged being able to communicate with javascript in pyjamas-desktop. it's tricky as hell though. l. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel