Creating a page in wiki is itself a pain. I have a codebase where I
store my small parts of code (Let say I'm testing some functionalities
of wx.ListCtrl). It would be great to have something easy like
worpress special for codes only. Then make categories during making
code posts.
Wordpress is zillions easier than currently wiki CMS.
wxWidgets uses Wikimedia's CMS. I don't know how difficult it is, but
I think it is time for Robin and the crew to make use of easier CMS.
By doing so, many will contibute.
Anyway how about wxPython for python 3
Starting discussing it at least, would be good.
···
On Sep 15, 9:22 pm, C M <cmpyt...@gmail.com> wrote:
On Tue, Sep 15, 2009 at 1:26 PM, Don Dwiggins <ddwigg...@advpubtech.com> wrote:
> 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.I definitely do not know Ajax and such to fully understand this, and
I am highly likely to utter something nonsensical here, but let me
jump in anyway...Maybe I can comment on the last point. I'm not sure why this
"platform" would require dealing with it differently, provided the
mapping from wxPython widgets to the wxPython-in-a-browser
widgets was good enough. E.g., with a wxComboBox, one
should be able to write a regular comboBox in wxPython and
the new approach would know how to draw the comboBox in the
browser, and do the animation of the dropdown, and such.
It seems like what could be good would be a way to "translate"
or compile wxPython code to something like Javascript.
That's why I mentioned Pyjamas, because it is a Python-to-
Javascript compiler, and has its own widget set and AJAX
framework. I could imagine a wxPython-API-to-Pyjamas-widgets
approach, too, such that maybe one could write a regular
wxPython app for the desktop and there could be some way
to automatically allow that to run and create a GUI on a browser,
with the calls to the server being intelligently routed by Pyjamas.
I haven't even tried to use Pyjamas, though, so what I am
spouting here may be totally off base.Che
I think people on the list