Question on opinions...

wxPython Users
21

Chris,

We've wrestled with a similar set of decisions.

Two thoughts:

1. You may want to take a look at Dabo which provides a higher level
framework *and* design tools built on top of wxPython. Dabo is open
source and very actively maintained. I love this framework, but it
currently ties you to wxPython.
http://dabodev.com

-OR-

2. Abstract your GUI layouts to the point where they can be entirely
data driven and then write 'drivers' that translate your GUI layouts to
different GUI frameworks. This is the route we've decided to go. We're
in proof-of-concept stage, experimenting with 'drivers' for HTML and
Tkinter based interfaces. There are obviously some trade-offs here in
that (for example) Tkinter doesn't support a wx.aui component (somewhat
achievable with jQuery in an HTML environment), but we think there may
be enough "good enough" functionality across GUI frameworks for us to
deliver professional looking (commercial quality) user interfaces with
this approach. Note: Python 2.7/3.1 support for Tile (ttk) makes Tkinter
a real contender as a GUI framework.

Malcolm

22

Let me first state where I’m comings from: I use the Python Dabo framework
daily. I’m sure many of you are familiar with Dabo and the fact that it is
based on wxPython.

Dabo has a GUI designer (ClassDesigner.py) that many use for WYSIWYG. It

creates a XML file that is later read and produces code for the display at run
time. It can use sizers or not. It’s easy to use and has many advantages
over other wxPython WYSIWYG designers. That said I don’t use it.

I hand code my displays and I use sizers. I will not go into all the reasons
behind me handing coding displays accept to say that Dabo makes it so easy
that it seems silly not too. I truly suggest that you review Dabo for version

2.0. (BTW nothing in Dabo prevents you from using wxPython directly and you
are not required to use any of the database features).

I’d also suggest that you review pySide. If you are not aware the QT
framework has a very good WYSIWYG designer (maybe the best I’ve seen) that can

be used with pySide (or pyQT). PySide has just released it’s 1.0 Beta and it
includes support of QML. Because of all these features it might be the best
solution moving forward toward your 2.0.

Johnf

23

Let me tell you, sizers are evil. They bloat your code,
Actually, Sizers are very easy to use in my opinion, I haven’t done an app of your size, but I have found BoxSizers to be adequate for all my layout needs, and if I want to “nudge” a widget over a few pixels I use :

sizer.Add(wx.Size(10))

or something similar. I have never used any other type of sizer. Try out http://spinecho.ze.cx/ for the learn sizers script, and http://www.wiki.wxpython.org/BoxSizerFromTheGroundUp for some up to date information on using the BoxSizer.

···

–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!

24

I took one of my most complicated forms and tried to replicate it in
wxFormBuilder last night. After an hour of yelling and cursing at
sizers (which wxFormBuilder REQUIRES), I managed to get a form that
roughly looks and feels like what I had originally made.

Two problems became VERY evident VERY fast.
1. wxFormBuilder is meant to be used for wxWidgets and not wxPython.
Oh, it will generate Python code, but any widgets that are unique to
wxPython are not supported. And for the controls it DOES support, it
seems to be a subset of the entire wxWidgets control library.

Okay, so...what about extending its support for controls?

2. The only way to extend its functionality is to write .DLL
libraries in C++ to add new widgets...and I'm not certain it's
possible to mix native python widgets into C++ code in any SANE
fashion.

(uhhh...3. It doesn't allow you to define foreground and background
colors outside of its hardcoded palette.

4. Font changes do not propagate through children like they should,
so each widget added must have a font specifically set, which is a
PITA.)

I will say that I think wxFormBuilder is very slick, and easy to get
into with only a small learning curve. However, it's simply no good
for anything more than toy applications in wxPython. It's certainly
better than wxGlade, which is just completely broken.

Chris.

···

On Fri, 26 Nov 2010 11:20:16 +0100, werner <wbruhin@free.fr> wrote:

On 26/11/2010 08:20, Chris Spencer wrote:

Nevermind. I'm an idiot.

Chris.

On Fri, 26 Nov 2010 02:08:45 -0500, Chris Spencer >> <cspencer@cinci.rr.com> wrote:

I downloaded the latest version, built a test frame and a couple of
buttons. Then I hit "Generate Code" and got a .cpp file. So, if it
is possible to generate wxPython code, what magic spell do I need to
invoke to make wxFormBuilder do it?

My version of wxFormBuilder is 3.1.70 which is, to my knowledge, the
latest version.

Chris.

On Fri, 26 Nov 2010 07:27:29 +0100, Toni Ruža<gmr.gaf@gmail.com> >>> wrote:

On Fri, 26 Nov 2010 02:48:55 +0100, Chris Spencer<cspencer@cinci.rr.com> >>>> wrote:

So, when I look for GUI builders, I eliminate those that depend on XRC
files. wxFormBuilder, therefore, is out.

wxFormBuilder does not depend on XRC files, the latest version can
generate python.

I've been using the betas for some time now and I'm way more satisfied
with it then with any of the other contenders.

Would be interested to hear your experience with this and how it allows
the handling of none predefined widgets.

Werner

25

And I have used this technique from time to time. I know how to add
widgets for myself. But why should everyone replicate my work to get
the additional controls added to wxPython in the past 5 years or so?

Would you not agree that it's better for a small group of people to
add these controls and then release a Boa Constructor version with
them integrated in?

Frankly, I don't use Boa as a code editor or debugger. I have other
much more evolved code editors for that. What I do use Boa for is
it's (as far as I am concerned) unmatched GUI creation ability.

But it is showing its age. Rust is creeping in. And it's not keeping
up with the increasing control density of wxPython. And I don't think
Riann (for WHATEVER reason) is willing/able to keep maintaining it.

I've often thought of making my own GUI creation tool, like Visual
Studio's. The amount of effort to get from zero to useful is beyond
my ability to devote time to it. However, BOA is 90% there already. I
can spend the time helping to polish it up and bring it current with
wxPython 2.9.

It's sad to see such a fantastic tool become, essentially,
abandonware.

Chris.

···

On Fri, 26 Nov 2010 10:46:55 +0100, werner <wbruhin@free.fr> wrote:

Adding new widgets can be done in two ways, either via the plug-in
support, see e.g. FlatNotebook-plug-in.py which I think I started and
Riaan fixed it up so it really worked;-) or via the "companions" support
see the sub-folder with the same name in Boa.

Werner

26

I actually played around for a week on concepts for data driven GUI
creation. One thing I tried that showed promise was using a text file
to roughly define where things go on the screen, with mnemonics that
point to control properties in an .ini file format. In very very
SIMPLE terms, it'd look like this:

"""
First Name:<fn > Middle Initial:<mi> Last Name:<ln >
Date of Birth:<dob > Gender: <gnd >

#this would go on until you have a full personal data form]

···

On Fri, 26 Nov 2010 11:28:55 -0500, python@bdurham.com wrote:

Chris,

We've wrestled with a similar set of decisions.

2. Abstract your GUI layouts to the point where they can be entirely
data driven and then write 'drivers' that translate your GUI layouts to
different GUI frameworks. This is the route we've decided to go. We're
in proof-of-concept stage, experimenting with 'drivers' for HTML and
Tkinter based interfaces. There are obviously some trade-offs here in
that (for example) Tkinter doesn't support a wx.aui component (somewhat
achievable with jQuery in an HTML environment), but we think there may
be enough "good enough" functionality across GUI frameworks for us to
deliver professional looking (commercial quality) user interfaces with
this approach. Note: Python 2.7/3.1 support for Tile (ttk) makes Tkinter
a real contender as a GUI framework.

Malcolm

---
[fn]
control=wx.TextCtrl
BackgroundColour=wx.Colour(255,255,255)

[mi]
control=wx.TextCtrl
MaxLength=1
BackgroundColour=wx.Colour(255,255,255)
KeyPressed=OnKeyPressed #name of the function accepting the event

[ln]
.....
"""

The program would read the text file and create the screen and any
needed Bind statements to event handlers. It'd be a subclass of
Panel.

class wxTextFormPanel(wx.Panel):

I ran into a couple of issues.
1. Proportional fonts do not take the same space, so calculating
proper positioning on the screen for static text labels was incredibly
hard. 'iiii' takes a HELL of a lot less width than 'wwww' in
proportional fonts. I worked around this (kinda) by giving static
text fields the width and height of the number of characters in the
string multiplied by the GetTextExtent of "W", and then
right-justifying and centering the text within that box. Except for a
few edge cases it worked okay.

2. The real problem was parsing controls with multiple columns and
rows, for things like ListCtrls. The code for this became so hairy
that I decided to delete what I had and start over. There MUST be an
elegant way to do it that I haven't discovered yet. If you format the
text representation the right way, it's easy to parse, but here's the
edge case...
"""
List of Something:<lc Some other control:<soc >
sneaky ctrl:<sc> Even another control:<eac >
                         > And another control:<aac >
"""
as you can see, the intention is to have the list control (lc) have a
proportional width of 6 and a proportional height of 3. But parsing
out the boundaries with sneaky control on line two is just hairy.

I like my code to be clean and elegant. So far I haven't been able to
come up with a clean and elegant solution for this.

But if I can solve this, I will not only use it in future versions of
my product, but also release the source code of wxTextFormPanel so
others can use it.

Chris.

27

Apart from the fact that you are probably right in that
wxFormBuilder is better than wxGlade (like with Dabo I much
mourn the fact that there are no official Debian packages
which prevents us from using either with GNUmed).

OTOH we've developed an effective and fairly satisfying
workflow using wxGlade to develop a GNUmed GUI. It's a
somewhat unrefined tool but if you use it within its limits
it serves just fine.

Shibui, I suppose :wink:

Karsten

···

On Fri, Nov 26, 2010 at 02:34:34PM -0500, Chris Spencer wrote:

I will say that I think wxFormBuilder is very slick, and easy to get
into with only a small learning curve. However, it's simply no good
for anything more than toy applications in wxPython. It's certainly
better than wxGlade, which is just completely broken.

--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

28

Would you mind posting a screenshot or something of one of these complicated forms? I’d like to see how hard it would be to replicate with some sizers. Thanks!

···

On Fri, Nov 26, 2010 at 1:34 PM, Chris Spencer cspencer@cinci.rr.com wrote:

I took one of my most complicated forms and tried to replicate it in

wxFormBuilder last night. After an hour of yelling and cursing at

sizers (which wxFormBuilder REQUIRES), I managed to get a form that

roughly looks and feels like what I had originally made.

Two problems became VERY evident VERY fast.

  1. wxFormBuilder is meant to be used for wxWidgets and not wxPython.

Oh, it will generate Python code, but any widgets that are unique to

wxPython are not supported. And for the controls it DOES support, it

seems to be a subset of the entire wxWidgets control library.

Okay, so…what about extending its support for controls?

  1. The only way to extend its functionality is to write .DLL

libraries in C++ to add new widgets…and I’m not certain it’s

possible to mix native python widgets into C++ code in any SANE

fashion.

(uhhh…3. It doesn’t allow you to define foreground and background

colors outside of its hardcoded palette.

  1. Font changes do not propagate through children like they should,

so each widget added must have a font specifically set, which is a

PITA.)

I will say that I think wxFormBuilder is very slick, and easy to get

into with only a small learning curve. However, it’s simply no good

for anything more than toy applications in wxPython. It’s certainly

better than wxGlade, which is just completely broken.

Chris.

–

Mike Driscoll

Blog: http://blog.pythonlibrary.org

29

Right now we are on the cusp of coming out of our release candidate
series. In the next month or two we will be doing a large marketing
push. This includes a webpage, which will have not only screenshots,
but "tutorial" videos (which will act as live demonstrations for
interested buyers).

Until then, I'm under a pretty strict NDA. I can't even tell you what
my software DOES yet. But I can tell you that it's the end product of
a single developer over the space of 3 years, using wxPython. It's
also designed inside-out for touchscreen operations. If Android ever
gets Python/wxPython *and* iPad-like devices, we will port to there as
well.

I'm very excited about it, and I want to share what not just Robin,
but the whole of the wxPython community has helped me accomplish. It
will just take a little while longer.

Chris.

···

On Fri, 26 Nov 2010 16:17:32 -0600, Mike Driscoll <mike@pythonlibrary.org> wrote:

Would you mind posting a screenshot or something of one of these complicated
forms? I'd like to see how hard it would be to replicate with some sizers.
Thanks!

--
-----------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

30

Could you elaborate a bit on your experience?

I have used wxGlade for quite a while and I find it pretty stable.
However, I use sizers and I have less than 50 dialogs in my apps.

Martin

···

On Thu, 25 Nov 2010 22:28:34 -0500 Chris Spencer <cspencer@cinci.rr.com> wrote:

Okay, just tried wxGlade and it's a buggy piece of trash. Any other
ideas?

31

It just blows up with innumerable exceptions...especially on the
wx.NO_3D tag. I think it needs to be updated for wxPython 2.9.

Chris.

···

On Fri, 26 Nov 2010 23:47:14 +0100, Martin Manns <mmanns@gmx.net> wrote:

On Thu, 25 Nov 2010 22:28:34 -0500 >Chris Spencer <cspencer@cinci.rr.com> wrote:

Okay, just tried wxGlade and it's a buggy piece of trash. Any other
ideas?

Could you elaborate a bit on your experience?

I have used wxGlade for quite a while and I find it pretty stable.
However, I use sizers and I have less than 50 dialogs in my apps.

Martin

32

Well, that’s probably true. 2.9 is barely a month old though.

···

On Fri, Nov 26, 2010 at 5:22 PM, Chris Spencer cspencer@cinci.rr.com wrote:

It just blows up with innumerable exceptions…especially on the

wx.NO_3D tag. I think it needs to be updated for wxPython 2.9.

Chris.

–

Mike Driscoll

Blog: http://blog.pythonlibrary.org

33

Chris,

Adding new widgets can be done in two ways, either via the plug-in
support, see e.g. FlatNotebook-plug-in.py which I think I started and
Riaan fixed it up so it really worked;-) or via the "companions" support
see the sub-folder with the same name in Boa.

Werner

And I have used this technique from time to time. I know how to add
widgets for myself. But why should everyone replicate my work to get
the additional controls added to wxPython in the past 5 years or so?

Totally agree.

If you done any as plug-in's can you please post them to the Boa list as those anyone can just drop into the plug-in folder and they would be usable - o.k. they still won't make it into the next release until ....

Would you not agree that it's better for a small group of people to
add these controls and then release a Boa Constructor version with
them integrated in?

Frankly, I don't use Boa as a code editor or debugger. I have other
much more evolved code editors for that.

What are you using? Wing IDE or?

   What I do use Boa for is
it's (as far as I am concerned) unmatched GUI creation ability.

But it is showing its age. Rust is creeping in. And it's not keeping
up with the increasing control density of wxPython. And I don't think
Riann (for WHATEVER reason) is willing/able to keep maintaining it.

I won't speak for Riaan (I am pretty sure he is old enough for that:-) ) but I am sure he cares but real live is just getting too much in the way for our liking - i.e. he is very very busy on protects which pay his food and roof etc and just doesn't have enough time to spend on Boa.

I don't see anyone beside Riaan who is totally familiar with Boa and so a "restart" without him does not make much sense. I hope he will react to my post in reaction to this thread on the Boa list.

I've often thought of making my own GUI creation tool, like Visual
Studio's. The amount of effort to get from zero to useful is beyond
my ability to devote time to it. However, BOA is 90% there already. I
can spend the time helping to polish it up and bring it current with
wxPython 2.9.

We really should take this Boa discussion onto the Boa list before others here get feed up with us.

It's sad to see such a fantastic tool become, essentially,
abandonware.

I would very much regret if Boa would be totally abandoned.

Werner

···

On 26/11/2010 20:43, Chris Spencer wrote:

On Fri, 26 Nov 2010 10:46:55 +0100, werner<wbruhin@free.fr> wrote:

34

Use sizers;-) and this problem goes away. Serious I don't see how I could do my application with fixed position, how would you deal just with the position issues coming from I18N stuff.

It took me a long time to get an o.k. handle on sizers and as mentioned elsewhere I still only get about 70-80% of my layouts right without getting a lot more grey hair.

Werner

···

On 26/11/2010 21:05, Chris Spencer wrote:

On Fri, 26 Nov 2010 11:28:55 -0500, python@bdurham.com wrote:

Chris,

We've wrestled with a similar set of decisions.

2. Abstract your GUI layouts to the point where they can be entirely
data driven and then write 'drivers' that translate your GUI layouts to
different GUI frameworks. This is the route we've decided to go. We're
in proof-of-concept stage, experimenting with 'drivers' for HTML and
Tkinter based interfaces. There are obviously some trade-offs here in
that (for example) Tkinter doesn't support a wx.aui component (somewhat
achievable with jQuery in an HTML environment), but we think there may
be enough "good enough" functionality across GUI frameworks for us to
deliver professional looking (commercial quality) user interfaces with
this approach. Note: Python 2.7/3.1 support for Tile (ttk) makes Tkinter
a real contender as a GUI framework.

Malcolm

I actually played around for a week on concepts for data driven GUI
creation. One thing I tried that showed promise was using a text file
to roughly define where things go on the screen, with mnemonics that
point to control properties in an .ini file format. In very very
SIMPLE terms, it'd look like this:

"""
First Name:<fn> Middle Initial:<mi> Last Name:<ln>
Date of Birth:<dob> Gender:<gnd>

#this would go on until you have a full personal data form]

---
[fn]
control=wx.TextCtrl
BackgroundColour=wx.Colour(255,255,255)

[mi]
control=wx.TextCtrl
MaxLength=1
BackgroundColour=wx.Colour(255,255,255)
KeyPressed=OnKeyPressed #name of the function accepting the event

[ln]
.....
"""

The program would read the text file and create the screen and any
needed Bind statements to event handlers. It'd be a subclass of
Panel.

class wxTextFormPanel(wx.Panel):

I ran into a couple of issues.
1. Proportional fonts do not take the same space, so calculating
proper positioning on the screen for static text labels was incredibly
hard. 'iiii' takes a HELL of a lot less width than 'wwww' in
proportional fonts.

35

A web based or browser based application would be nice, but I haven’t come across a framework which provides powerful widgets out of the box, e.g. things like notebook/multipane stuff or even better aui in a browser.

What about qooxdoo?

···

–
Alexei Vinidiktov

36

Impressive!

But JavaScript and I would like to stay in the Python world.

Werner
···

On 27/11/2010 14:08, Alexei Vinidiktov wrote:

      A web based or browser based application would be nice, but I

haven’t come across a framework which provides powerful
widgets out of the box, e.g. things like notebook/multipane
stuff or even better aui in a browser.

What about qooxdoo?

37

We really should take this Boa discussion onto the Boa list before others

Sure, let's move it there. That is the gmane list, here, yes?:
http://news.gmane.org/group/gmane.comp.ide.boa-constructor.user/last=

(is that the site from where you usually access it?)

Che

38

Hi Che,

We really should take this Boa discussion onto the Boa list before others

Sure, let's move it there. That is the gmane list, here, yes?:
http://news.gmane.org/group/gmane.comp.ide.boa-constructor.user/last=

Yes, but you don't want the "/last=" stuff at the end, link should be:
http://news.gmane.org/gmane.comp.ide.boa-constructor.user

(is that the site from where you usually access it?)

I have it defined in Thunderbird as a news list, i.e.:

news://news.gmane.org:119/gmane.comp.ide.boa-constructor.user

This is a members only list (due to spam problems), so for posts to go through without moderator approval you have to join the list on sourceforge (gmane is just a mirror news list generator). If you post as non member it will take a bit longer until your post shows up, but shouldn't be more then 24 hours or so.

Werner

···

On 27/11/2010 16:44, C M wrote:

39

Since I haven't heard it mentioned yet... I'll put in a plug for
wxDesigner. I had a small applet to write earlier this year, and
after trying wxGlade and Boa Constructor (and possibly another one two
packages whose names I've forgotten), I found that wxDesigner was most
intuitive and easy-to-use for me. (Boa Constructor kinda came in
second, in my mind, and wxGlade was third.)

It's perhaps not super actively maintained (i.e., no major new
features lately), but it does get small improvements from time to
time: http://www.wxdesigner-software.de/ . It's not free, but it
certainly is cheap.

---Joel Koltner

40

Chris.

If you stand back and view the entire issue I think you will see that form creation requires a great amount of effort, no matter what. You can you use sizers, yourself, which is a heck of a lot of work, or, you can use a form builder in which a heck of a lot of man-hours went into creating it. Boa’s maintenance was probably dropped due to the author’s exhaustion !

To pick up and maintain something like Boa requires (a) dedicated expert(s) willing to devote a horrendous amount of time to it. You are in the applications development business, not the wxPython form builder tool business.

Sizers may or may not be evil, but they are a PITA to code. Apparently, the authors that created the sizers were obviously experts in geometry management, but were somewhat lacking in the API “ease-of-use” department. I have a serious pet peeve about the inane API for BoxSizers, in general. But, experts in geometry management and API ergonomics are very, very rare. Finding someone who is expert in those two areas who is willing to write a thorough, easy-to-understand tutorial about his own creations is darn near impossible ! But, this is true in every technical field there is, not simply wxPython.

Who, or what group of wxPython developers is willing to invest tens of thousands of man-hours of development for a good (in all senses) wxPython form builder and then just give it away FREE ? After all, everyone needs to eat.

As for Dabo, I can’t comment on its use. But, notice that it is from a .COM site (http://dabodev.com/), meaning that they sell something or other, which I don’t know what. So, Dabo may be free, but its development is being commercially financed. As with many “free” tools from .COMs, one day they may decide that Dabo won’t be free any more and users must pay to get it. Or, the company is bought out and the new owner will require that it must be bought to get support and updates. We’ve all seen this happen too many times. If Dabo is to remain free, then it must be offered on the http://dabadev.ORG web site. There is no such site, yet. Consider that Python and wxPython come from .ORG web sites. Yes, I know there are notable exceptions for some great Python and wxPython add-on packages coming from commercial developers.

Have another look at the BoxSizer, especially the “DivideAndConquer” wiki page. Creating a manageable and rational sizer/container hierarchies is the key to form creation while keeping your sanity. When this is done maintenance becomes relatively easy.

wxPython Wiki Tutorial:

http://wiki.wxpython.org/BoxSizerFromTheGroundUp

Ray

···

On Fri, Nov 26, 2010 at 6:22 PM, Chris Spencer cspencer@cinci.rr.com wrote:

It just blows up with innumerable exceptions…especially on the
wx.NO_3D tag. I think it needs to be updated for wxPython 2.9.

Another option is to fork Boa Constructor and maintain it myself, but
I don’t have the time to do that AND maintain a commercial project AND
develop its successor at the same time.