-
Yeahh ... i didn't know this method for building wx gui ...(class in class in class ...)
And i'm very surprised ... sources looks very nice !
But like u say : it's not natural !
I'm very interested in gui developpment under python
!
I've tested a lot
- wxpython alone (notepad (or boa)): i always use it, but find the "object model" is "not very pythonic"
- wxglade : good idea ... generating python is fast, but very hard to maintain ... xrc are a good idea (like xul/mozilla), but it's not easy to maintain too.
- tkinter : good model object, but a little bit obsolete ... and i don't like tk ;-)
- pygtk : too heavy, but good object model
- wax : (yours) very good "object model" ... but it's hard to find docs/examples ...
recently ... i've tested pythoncard ... and i was totally amazed ! What a beautiful proof of concept ! it miss a lot of things (sizer,tabs,...), but it's really really really easy to build (and maintain !!!) a little gui in a python way !
I think that the perfect tool will be :
" api like wax (with all the power of wxpython inside), and a "pythoncard concept like" to build interface which will be stored in a "xrc/xul like" xml format "
it will be the killer "api builder" on wxpython
-
Hmmm, I also like PythonCard. Now, to be clear about it, I am a real novice dilettante, not a professional programmer and not even a competent programmer I fear; but nonetheless I play around with Python n alot, and of all the GUI tools I have ever tried, PythonCard is the easiest to learn and use.
I can though recognize, from reading this Blog, that Wax is a big improvement in "Pythonicness" over straight old wxPython.
So you raise an interesting idea: Can Wax and PythonCard be used together? I guess they could, but I don't know? In other words, When Using PythonCard, could one also import Wax and use Wax for coding the hand coded parts of a PythonCard program?
-
"""So you raise an interesting idea: Can Wax and PythonCard be used together? I guess they could, but I don't know? In other words, When Using PythonCard, could one also import Wax and use Wax for coding the hand coded parts of a PythonCard program?"""
I'm not sure... maybe for the hand-coded parts. Of course, it would be much more useful if the GUI builder part worked as well. :-) I don't know how difficult it would be to adapt PythonCard so it can use Wax, or to write a new version altogether. Like I mentioned in a previous post, I have great plans for Wax, and the addition of a Wax-friendly GUI builder is one. At this point, I don't know yet how that can be done best... I will have to fix other things first before I can even consider the idea. (Like, adding more controls, cleaning up the API, etc.)
-
I came to see the painful way to build GUIs (declarative style) and I find PythonCard comments, small world I guess.
Just for the record, PythonCard has always supported sizers, just not in the layout building tool, the resourceEditor. You just stick sizer code in your program exactly like you would in a wxPython program and many of the samples and tools show how to do this. Secondly, the wx.Notebook control is wrapped and supported in the resourceEditor and checked into cvs and will be part of release 0.8.1. There is a testNotebook sample in cvs as well if you want to take a look. The nice thing about how it works is that any existing PythonCard background can be turned into a Notebook page simply by changing its class from Background to PageBackground.
PythonCard doesn't use XML for the resource format mostly because there isn't much of an advantage to it over the Python dictionaries and lists it currently uses. I would like to use the XmlResource format natively supported by wxWidgets/wxPython, except that it currently doesn't support some of the initialization PythonCard does and more importantly, I don't have a parser for it that would allow the resourceEditor to read the files; generating them is the easy part. We may figure out how to use it for PythonCard 2.x
As far as Wax is concerned, I haven't looked at it in a long time or close enough to know where they overlap or could benefit from each other. PythonCard is not trying to support everything that you can do with wxPython, it just isn't one of the design goals. Also, I'm not a big fan of code generation and prefer to keep all the layout description seperate from the main source logic, so user code shouldn't be having to create buttons, bind events, etc., that is just noise.
PythonCard is on track now for a 1.0 release pretty soon after wxPython 2.6 becomes available, so at least for 1.0 there aren't going to be many more changes to how the core framework and resources work. A complete upheaval just isn't doable at this point in time.
Anyway, Hans is more than welcome to chime in on the PythonCard-users mailing list with comments and ideas. Once PythonCard 1.0 is done I'll probably take a closer look at Wax.
ka
-
Incidentally, I am planning to add this declarative style to SQLObject pretty soon. It was a central part of FormEncode, which is even more declarative in nature; but it can also be a pain in the butt, especially getting classes where you expect instances. It's probably not too bad if you don't try to be clever (i.e., just test for a class and instantiate if that's what you got); it's attempts at cleverness that caused problems.
In SQLObject I expect it to be simpler, because there's no nested structures and it's an extension of what already happens (where attributes are automatically picked up as columns).
The current level of declaration in SQLObject (where attributes are picked up) hasn't been much of a problem. I think it's important that the declarative technique resolve into an imperative technique; in SQLObject the metaclass collects the attributes, creates the class, then calls cls.addColumn(columnObject). Since .addColumn is a public method, people are free to dynamically create objects, and it's really no harder than the declarative method.
In an older project (FunFormKit), you had to provide all the attribute up-front; technically that doesn't seem like a problem, you just collect all your attributes manually and then create the class, but it confused people. People thought about creating a form, then adding form elements, and this forced them to do it backwards. As a result, people thought of the objects as static. So I've tried to avoid that since then.