On Fri, Feb 24, 2012 at 3:44 PM, C Anthony Risinger <[email protected]> wrote: > On Fri, Feb 24, 2012 at 12:48 AM, lkcl luke <[email protected]> wrote: >> >> [...] > > the gobject bindings work fantastic, save a small bug wrt event > handling that i've been working with the webkit team for about 3 weeks
hmmm... that's interesting. are you being told by mark rowe that you must make them incompatible with javascript? is he telling you that you must *not* have Window.setLocation support because there exists the means to set the URL via the webkitgtk functions? is he telling you that you must not have XMLHttpRequest because there exists code for doing HTTP Networking within the main GTK infrastructure? these are not rhetorical or sarcastic questions, i genuinely wish to know the answer because this the insane reasoning that he used which destroyed - and massively delayed - the gobject bindings. > (primarily because i am writing the solution myself, and hence > learning c/c++ meshing). good! > no, they don't use signal handlers, and haven't for over a year. good. perhaps xan actually listened to what i said, after all. and maybe looked at the pythonwebkit code. btw, the acid test - the absolute crucial test - is whether the gobject bindings can be included in other "ports". if they can be included in the webkitqt4 port merely through the addition of say 50 lines of "glue" code, they're ready. > everything is exposed. in fact i am nearing completion of a pyjd > runtime using these bindings, and already have most things -- and some > examples -- running without issue. good! the other thing that's needed is a timer event callback. the use of gobject timers _will_ result in race conditions, and will interfere with the execution order of code. the pythonwebkit code adds an additional timer callback type: the gobject code will need to do likewise. what then happens, when that timer's callback is called, is that the webkit infrastructure ceases all other operations until that callback completes. in the case where gobject timers are (were) used, the webkit thread *continues* execution in *parallel* with the gobject timer callback, and that's where things get into a god-awful mess. l.
