-
Option #4: Other people start using Wax, and contribute new controls, documentation, etc.
Okay, so it's never certain that this will happen, but it's a possibility. I'd love to work on a project in Wax, and if I ever get around to it I'll do my best to help out with documentation and maintenance.
-
""" Option #4: Other people start using Wax, and contribute new controls, documentation, etc."""
The problem is that there are strict guidelines for new code. An even bigger problem is that these guidelines aren't mentioned anywhere. :-/
One thing I will need to do is to make it easier for people to contribute things. First of all, it needs to be clear what's already there and what's not. Second, I need to make clear what standards new code must adhere to. (It's actually no big deal, but I want to have a "Pythonic" API, whatever that means...)
So, this is something I will need to work on (assuming I will choose #1).
Maybe a mailing list will make it easier to discuss (new or existing) features as well.
Anyway, thanks for your support.
-
If anyone else is already using Wax, then you should set up the SF project. Then at least they'll have the opportunity to be self-supporting, whether or not they take that opportunity.
Database controls as part of a GUI always seems weird to me, though I guess I've never used a system (like Delphi or Qt) that offered this. It seems much more sensible to use some intermediate API, which a database could also fulfill. Even better if you can find an existing API like this (one that is higher level than the DB API).
But it's hard. In a lot of ways it can be better for everyone to give up early than to let a project slog along indefinitely. OTOH, most high-level Python GUI projects are in the same place you are. There needs to be *something* -- working with plain wxPython (or Tkinter or whatever) feels very crude to me. It reminds me of the web framework situation in Python as well, where there's lots of frameworks, and everyone makes their own, and most aren't very popular, and new users have no clear choice (except for annoying low-level modules like cgi), and the situation just sucks. It's not clear how to get out of that.
Whatever the future of Python GUI work is, it can't be solved by just you. You may have the skill, but individuals just don't have the staying power, especially if it's an after-hours task. So you either have to build a group of developers that can support the project, or join a group that already exists, or take on a more modest goal that can reach "completion" (since no GUI framework can ever be complete).
-
For me the biggest issue is that wax doesn't offer anything. Sure it is more Pythonic than wxPython, but wxPython isn't *that* difficult or verbose. The learning curve to do anything with wax/wxPython is far greater than the curve once you are up and running with either, especially once you talk about non-trivial stuff such as preferences, clipboards, printing, drag and drop etc. Quite simply wxPython is good enough in IMNSHO.
I think the effort would be far better placed with small incremental changes in wxPython getting it to go in the same direction as wax was heading.
-
"""For me the biggest issue is that wax doesn't offer anything. Sure it is more Pythonic than wxPython, but wxPython isn't *that* difficult or verbose."""
That is a matter of opinion, I guess... wxPython isn't unreasonably difficult, but it sure has a number of annoyances, like those pesky IDs, that just don't belong in a Python program. And then there's sizer hell. I would (and do) use Wax for that alone.
As for the learning curve of Wax, I will need to work to make it easy to learn and start using.
-
Even though you have strict guidelines, you still have option #4 as Matt suggested. I agree with you that there might not be too much help by other on coding itself, but others can help on many other aspect of wax development for instance Matt will glad to help you with documentation, I will be glad to do a comprehensive demo like wxPython, help on linux debugging and will start using on some future projects so that I can suggest you some real life shortcomings of wax. Some other can help on website and installation.
As always, keep us inform about your decision.
-
"""For me the biggest issue is that wax doesn't offer anything. Sure it is more Pythonic than wxPython, but wxPython isn't *that* difficult or verbose."""
When people will see demo example written in wxpython and wax, they will see themself.
wax is one the most programmer friendly GUI development toolkit I have ever seen.
If you go with option #1, I agree that you don't need GUI builder right away (if ever). IMHO, gui should be part of program and should be built inside program to capture dynamic nature of program and programming language.
-
If you use wxPython 2.5 then you never need to use ids. And the complexity for gui stuff is dealing with layouts, sub-classing, class vs display hierarchy etc. Understanding those is hard for many people. Expressing them is the least of your worries.
I don't count "hello world" demos as good examples. Lets see something like a text editor coded in wax and in wxPython and see how different they really are.
-
Another argument I would make is that wax is not radical enough. Instead of sugar coating the wxPython api, what about removing the distinction between design mode and run mode. How about any user at any time can hit a button and edit the UI they are seeing while the program is running. They should be able to move widgets around, see what other ones are available and connect/link them in any way they see fit.
That will bring value to the programmer since users can have the UI any way they want, and also answers why you would need a data component as mentioned in your proposal.
There is the XML stuff for wxPython but it doesn't scale beyond the trivial. For example try adding your own widget and see how easy it is to work with the designers. It is notable that the wxPython demo doesn't use the XML stuff.
A user should be able to make something like the wxPython demo providing the programmer supplied the base components. Data sources should be viewable AND editable in listboxes, text boxes, grids and anything else suitable.
-
When I used wxpython wax seemed like a great idea, but now that wxpython 2.5 is not supported in any linux distro I switched to gtk, and it feels a lot better. In windows it is running great and in linux it is so well supported. And after some getting used to, glade really helps to design good interfaces. I'm much more interested in Simpleglade now than I am with wax. So why am I saying this? Just to remind everyone that maybe the problem with wax is that it simply don't work in linux (because wxpython 2.5 doesn't) and that gtk is becoming more mainstream and is a lot easier to use than pure wxpython (2.4 at least) for the things I am doing.
-
We I have looked over the source code and demo's and I think that it's a very ingenous frame work. I like the way events work which is a very big problem. Also It's been a little while since I looked but using python properties you can make things much more seemless.
Instead of
widget.setX(99)
it would be
widget.x=99
Which I feel is more readable. In addition this would shrink the API to a much easier to remember quantity.
I have been disappointed that you don't have a SF project so I could get the CVS and offer some pachtes.
Mostly however I would be willing to volunteer for the website and documentation. Please email me when you move forward
-
A more pythonic GUI framework built on a servicable GUI framework just does not have much likelihood of longterm success in my opinion particularly given the pace that wxpython is evolving. It would benefit the python community more to assist in improvements in wxpython (or PyGTK or any other framework that is usable but could stand improvement).
-
I'm not here to start some dogmatic debate. The facts are that Linux has a small market share -- even smaller when it comes to desktop apps. It seems Apple is gaining in the Desktop area more that Linux is. With that as a given, WxPython is the only GUI framework that looks even half-way decent on Windows (plus it looks OK on Mac OS).
The problem with WxPython? It's a thin wrapper around the C++ API. And that seems to be all that it plans to be. This isn't news, we all know it. But it's not pythonic, so I may as well use C++.
That all leads back to Wax. I've been using it for awhile now. It has a very clean, pythonic, API. I enjoying using it, and it makes creating GUIs very straight forward and enjoyable. Personally speaking -- which is what all technology discussions boil down to -- I think Wax is something very worthy of further development. I would be willing to help out wherever I'm needed.
-
FWIW, I have been keeping an eye on Wax now for a while. Most of my stuff is done server-side, where a gui would be a distraction. However, I have always wanted to try wax when I get to the "Do a GUI program" self-improvement project. I would be sad to see it go.
From a reading perspective, I like the Wax APIs better than many other GUI toolkits I have seen, but I have always been concerned that the wxpython coverage was not broad enough. If wax ramped up to a full-fledged project, I would happily use it.
My thoughts, for .02 canadian.
-
Wax is awesome. But bigest problem of wax is wxPython. It's terrible, even terrible that PyGTK2.
May be it's a good idea, may be you need to switch to pygtk or even pyqt for Wax?