On Mon, Apr 9, 2012 at 6:49 PM, Bhuvan Krishna <[email protected]> wrote: > Dear lkcl, > > I admire and respect the tremendous amount of work you have put in > pyjamas along with others.
thanks. > Thanks for the quick reply with links that > gave me more confidence that i can do it (It is challenging though). :) > As > asked i will try my best. I already installed pyjamas and pyjd on > windows (from git source) and also tested the example apps that came > with the source code of pyjamas using pyjd they all were working fine > except 1 or 2 because of the lack of a server i guess. ah. could you be more specific about what you tested, which versions, which browsers etc. because we're _just_ going through a release test. > You got the point > that i wanted to make, that the transparency effect which is achieved in > google gadgets ( I will try with the solutions that you gave and do a > more indepth research on it). yeah it basically means depending on the window manager for various things. which reminds me: would you like to help create a python-based window manager that uses pyjamas desktop as the actual "window manager"? that way, it would actually be possible to just have transparent widgets... as pyjd applications or javascript! i started this project 2 or so years ago - http://sf.net/projects/pyjdwm - it involves using a very very very basic NPAPI plugin which tells pyjd what its X-windows ID is. applications can be fired up into that X-window. the key here is to "re-parent" the application, but you can ONLY do that when running as the root window... hence the requirement to do this as an actual window manager. > webkit > -------- > > I thought that since webkit is used by chrome i guessed that the engine > will be available on windows when you install chrome. yes, but that's not enough. there's no python bindings to it. webkit is heavily customised, and does not have a generic (easily-accessible) API. even worse, the various APIs that *are* available are either a) incomplete b) insufficient c) *different* from the standard javascript functions. for pyjd to work on top of an engine, the WHOLE COMPLETE HTML5 API WITHOUT EXCEPTION WITHOUT FAIL WITHOUT DISCREPANCIES WITHOUT CHANGES FROM THE STANDARD DE-FACTO JAVASCRIPT API *must* be available. as that's a few thousand functions and tens of thousands of properties, it's a big damn job. if you're missing access to timers, there's no point, because substituting a timer API such as the w32 one or the pygtk2 one results in segfaults due to race conditions. if you're missing HTTPRequest, there's no point, because using standard networking libraries won't interact with the engine, properly (event handling such as onxmlhttprequest) and, again, result in threading problems and race conditions. if you're missing a single property or a function, there's no point, because someone somewhere will want that function in their code. so it really does have to be all or nothing, and that's a hell of a committment of time and effort. l.
