On 6/14/10 1:00 PM, lkcl wrote: > On Jun 14, 7:30 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote: >> On 6/14/10 11:47 AM, lkcl wrote: >> wx has two separate containment hierarchies. The first is a >> hierarchical, parent->child relationship. This is what a lot of people >> think is its layout: but its not. It has nothing to do with layout, but >> instead its more about event propagation. > > oh crap, yeah, i forgot about that. event propagation rules. darn > it. y'know what? forget it - i might as well, seriously, help > implement an entire modern web browser in python, and use that.
In practice its a non-issue; the parent->child hierarchy with rare exception mirrors the sizer layout hierarchy, the latter is just more dense. And only some kinds of events propagate by default. Its really not that big of a deal. If you want to hear when someone clicks a button, you can bind to that button an event handler (very like JavaScript). Or, if you want, you can bind a handler to the window, and catch -all- button events (*), and decide what you want to do based on what button was pressed. I almost never do this. Only "command" events propagate. Those that represent a discrete user action: a button press, clicking on a radio button, hitting 'enter' in a text control, a right click. Stuff like that. But you don't have to treat it like a propagating event-- I almost never do-- and you can instead just add a handler onto the object itself. The rest of the more abstract events (mouseover, etc) you have to bind the handler to the object itself. >> It makes >> regular "seeming" application/client-based user interfaces, right? Are >> those all entirely, once run, 100% JavaScript (post-compilation)? > > nope not in the slightet - the javascript is literally out the > window, bypassed entirely. that same application you had which was > the input to the pyjsbuild compiler "pyjsbuild Hello.py"? you just... > run it! just like a pygtk2, pyqt4 or python-wx app: Ahh. Interesting. >> If so, Desktop at least isn't useful to me. :( I can't access omniORB >> with it :) > > yeahh, you can... but then if you actually wanted it to be a web app > as well, you'd be hosed (unless you want to create a browser plugin / > extension which can talk omniORB!) > > what we typically recommend is that _even_ though you're going to run > the application "desktop" - as pure python - you still use JSONRPC [or > XmlHTTPRequest if JSONRPC is overkill]. so, _even_ though it's a > desktop application, you still run a local 127.0.0.1 web service (even > python -m SimpleCGIServer.py will do the job!) > > rick's article is highly illustrative on all these points: > http://www.ibm.com/developerworks/web/library/wa-aj-pyjamas/ Hmm. Depending on just how rich of a UI is possible, this is a slightly compelling idea. Right now, I have to essentially maintain two separate code-bases: the desktop client and the web application. In my scenario, both are actually lightweight (though not truly thin) clients to a master application server existing Elsewhere, that does the heavy lifting and manages all its users. Being able to take a code base and provide it to users as a traditional-seeming desktop application that works desktopy for them, with-- it sounds like-- two separate processes, one which is Python and is "serving" data, and more importantly accessing the MCP and getting instructions and doing its "lightweight" local lifting-- and another which is just a UI that communicates to that local server? Then one would run basically the same code on a server to allow remote access on some internet-accessible server, that sounds like what you're implying is possible? This time the server is still there, but the client UI is converted into pure JS and shipped to the persons machine. That sounds too good to be true. I sort of have to be reading too much into what you're saying. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
