C M wrote:
Online demos? A real *demo*, meaning you could interact with the controls,
would be a lot of work--it would really be a translation of wxpython into
javascript, thereby making a web-based way to do wxPython. That would
be great, and maybe could be done using pyjamas or something, but I would
think it would be a major thing to pull off (though certainly welcome).
I agree with both parts of the last sentence. I've written several wxPython apps, and am now up to my elbows in a web app using ExtJS for the browser side. What follows is essentially a bit of fantasizing on my part about how something roughly like ExtJs could become the "native widgets" wrapped by wxWidgets/wxPython. If the subject interests you, follow along, otherwise skip it.
I'll focus on ExtJs because that's the broswer-side application framework I'm familiar with. The normal interaction between an ExtJs app and the "back end" (database, middle tier, filesystem, or whatever) is via Ajax requests; in effect, the framework code usually maintains control of the user interface, even though asynchronously.
So, let's imagine that ExtJs components mapped cleanly to wx widgets. We could define a set of Ajax requests corresponding to the ExtJs component APIs, and on the server side, map these to the wx widgets. This mapping would be done by a framework or library, which could be embedded in a web server (or an application that, under the covers, includes a server that handles the needed HTTP/Ajax requests.
Don't take the last paragraph too seriously -- it's a gross oversimplification of what would really have to be done, and it's full of holes. I'm sort of using ExtJs here as an "existence proof".
If someone were to undertake this, they'd probably create a JS infrastructure that implements something closer to the wx API, with the intent that an application developer would write little, if any JS.
Maybe the best way to think of this is by analogy to the X Window system, where the application communicates with its GUI via a remote protocol, and the GUI lives in an X window server. In this case, the "window server" would the browser, and the communication protocol would be wx-specific, but based on XHR.
Someone undertaking this would likely run into issues that would be hard to resolve cleanly, arising from the serious differences between an application running in an OS, interacting with the user via the OS-supplied GUI, and an application interacting via a browser over HTTP.
It might be necessary to give up on the "platform independent" goal -- wx application developers would have to deal with this "target platform" differently. Perhaps its real utility would lie in the ability for an experienced wx app developer to use most of what he already knows in writing his first web app, and in easing the task of migrating a wx-based desktop app to a web environment.
For what it may be worth,
···
--
Don Dwiggins
Advanced Publishing Technology