anygui,anydb, any opinions?

[Chris Lambacher]

I think you missed looking at several GUI builders. I have not used a
GUI builder in 5 years that had you nail down positions.

Swing(for Java), GTK, Qt, and wxWidgets(to a lesser degree) all use a
sizer metaphore. You lay out he sizers and put your widgets in
various sizer layouts. This means that the scaling you speak of
above, just works for you. Accordingly GUI builders for these
toolkits work within that model(look at Glade for GTK and wxGlade for
wxWidgets).

I think you need to step out of the age of Motif and MFCs and look at
what modern toolkits and GUI designers have to offer before you start
in on a rant.

-Chris

Are we talking about a drag-and-drop GUI builder?

I am! [...]
I happen to be one - and I *know* I'm not alone - who thinks that building
user interfaces is way too difficult and way too important. It is
particularly frustrating in that we do seem to be moving backwards in this
department.

"What GUI builder should I use", or similar, is a common question on
c.l.python. I'm a curmudgeon, and don't like GUI builders - so I avoid
them. While normally that wouldn't cause me to encourage others to
avoid GUI builders, I think they have a worse problem: they encourage
the delivery of applications without flexible, robust user
interfaces. In short, the help produce inferior applications. While
this isn't strictly a python issue, c.l.python is where I run into it
- so I'm bringing it up here.

Now, I'm not an expert on GUIs, GUI toolkits, or GUI builders. I've
used some of each, and draw my conclusions from that admittedly small
sampling. Possibly there are other samples that don't have the
problems I describe. Part of the point of posting this is to expose
these thoughts to others, and find out what I've overlooked. I'll
return to these points where appropriate.

What the user deserves.

I'm going to take a side trip into what constitutes a robust, flexible
user interface - which is what I believe the user deserves. Please
bear with me. By robust, I mean the user interface should adopt to the
environment it's being run in. Windows that don't fit on the screen
are simply unacceptable - but all to common if you use a very small
screen resolution. By flexible, I man the user should be able to
adjust the UI to suit their viewing conditions - the DPI on the
screen, the viewing distance, and their possibly aging eyesight.

I use two systems with graphical interfaces, and both are a bit out of
the ordinary. You might even call them extreme. One is a 1600x1200
desktop on a 21" monitor viewed from about 18" away. The other is a
640x480 desktop on a 53" monitor viewed from about 10' away. Even
those these are on opposite sides of "normal" users systems, they both
suffer from the same problem - out of the box applications have UI
elements that are unreadably small.

The obvious solution would be for the system to detect all these
environmental factors, and scale the applications
accordingly. However, things like viewing distance and the quality of
my eyesight are hard to detect automatically, and it would be a pain
to have to enter all those things manually. Since the end result of
all these is a single factor - a UI scale factor - a system wide knob
to scale applications would seem to be the solution.

Note that this is *not* an easy thing to do. Anyone who's tried
scaling bit-mapped fonts will tell you you can't simply scale something
and expect it to look good. Scalable fonts have "hints" and other
goodies in them so they look good as you scale the fonts up/down. This
may be why, but most windowing systems don't seem to do provide a
global UI scale knob. X certainly doesn't. Windows has a limited
capability to scale fonts system-wide, but it doesn't work very
well. OSX seems to have a system-wide display DPI setting one can play
with, but it's not clear how well that works. NeWS and NeXT could
probably do this, but would seem to have a negligible to nonexistent
user bases. rio seems capable, but the typical rio UI is ugly even by
my admittedly low standards.

Failing the single system-wide knob, a flexible application should
have allow the user to scale the application with a single knob. This
is hard to do with modern GUI toolkits. I do it by using text for
imagery in the UI, and having a scaling factor that is applied to the
font sizes. While I prefer text to graphics for UI elements, that's a
rant for a different time. I'll concede that such an interface is
probably unacceptable on a modern commercial application - users now
expect graphics. But how many GUI toolkits let you use a scalable
graphics format (SVG, PS, etc) for images in the UI? My predilections
have kept me from looking closely, but I certainly don't recall seeing
any in the GUI toolkits I've looked at.

I claim it's obvious from this what's wrong with GUI builders. But I
want to look at what I, as a developer, want from GUI development
tools before going into details.

What the developer wants.

Ok, what I mean is what *I* want. But I don't think I'm that unusual,
so I'm going to generalize to other developers as well. I'll point out
what has to be different for this generalization to fail.

First, I'm not a graphics designer. While I've studied page layout and
typographical design, and read Tufte's books on design, I'm a *long*
way from being a good graphics designer. I know even less about the
field of human-computer interactions. Hopefully, a good GUI library
will have had people on the development team who do know something
about these fields. In this - the desirable - case, the library should
have more knowledge about good UI design than I happen to posses.

Given that, the more I can depend on the library to do for me - the
less I have to specify - the more likely I am to produce a good UI
with that library. Conversely, the more I have to specify in the GUI
development process, the more likely I am to screw things up. I claim
this statement should hold for most developers, unless they happen to
be experts in the fields of graphics design or human-computer
interactions.

What's wrong with GUI builders.

Ok, *now* we're ready to deal with GUI builders.

The first, and most obvious, thing that GUI builders do is force the
developer to specify an exact position - if not size - for the
graphical elements of the UI. Better GUI libraries don't do
that. Instead they let the developer specify the position as part of
the overall structure, say as "the third button in the second toolbar
from the top", or "one of two buttons in a toolbar running across the
bottom of the window". This latter allows the knowledge of the library
designers to dominate the design, hopefully producing a better UI than
the you get from your typical software developer.

The GUI builder might provide an advantage if it allowed the GUI
design to be cleanly separated from the underlying code, so that a
specialist in UI design could do the graphics design, and then the
developer could come and add the underlying code. However, the GUI
builders I've dealt with require specifying names for the various
elements of the UI, which names should make sense in both
environments. This would seem to defeat such a split design, but I've
never tried it, so I can't say for sure.

Further, look at the kind of interface the GUI builder gives you. The
position of all the elements are nailed down. This makes it hard for
the GUI to adopt to the extremes of display environments that you find
in the wild. The GUI builders I've used made it hard, if not
impossible, to build an application that can scale the GUI to meet the
users needs. In other words, the GUI builder helps build applications
without flexible, robust user interfaces that are inferior to what can
be built using a GUI library.

Typically, I don't find a GUI builder that much faster than a good GUI
library. If I have to specify pixel positing for elements, the builder
will be a win, but if not, then not. So I haven't examined all the GUI
builders in depth. Maybe there's one out there that will let the
application developer scale the GUI when the application is invoked,
and will re-arrange elements of the GUI so they fit on the screen
properly. If so, I'd love to hear about it.

Thank you,
<mike

 

[Paul Rubin]

I think you need to step out of the age of Motif and MFCs and look at
what modern toolkits and GUI designers have to offer before you start
in on a rant.

Yeah, pretty much every fancy web page designer these days uses
graphic tools like Dreamweaver or whatever. It's completely
reasonable to expect something similar for GUI's. I've played around
with Glade for a few minutes and it seems pretty nice, though I
haven't done anything serious with it since my own apps have (so far)
been ok with slapdash-looking tkinter gui's.

 

[Neil Hodgson]

Mike Meyer:

The obvious solution would be for the system to detect all these
environmental factors, and scale the applications
accordingly. However, things like viewing distance and the quality of
my eyesight are hard to detect automatically, and it would be a pain
to have to enter all those things manually. Since the end result of
all these is a single factor - a UI scale factor - a system wide knob
to scale applications would seem to be the solution.

Treating scalability as a matter of magnification is problematic.
User interfaces consist of a mixture of smoothly magnifiable and
discrete aspects. Pixels are discrete (well, almost) and sometimes, such
as at the edge of a button, you need to be able to control whole pixels
to ensure that you get a visible transition rather than a blur. Text is
often unreadable under a certain size so that places a lower bound under
magnification. Often when scaling down, you want to remove elements or
move them onto extra pages or pop-ups. This sort of change generally
requires human intelligence.

The toolkit I am most familiar that does try to be magnifiable is
Windows.Forms and it is also my least favourite currently having
particularly ugly text. To achieve resolution independence Windows.Forms
(and the underlying GDI+) uses sub-pixel positioning as do other recent
rendering libraries. This leads to the possibility of each render of a
particular character being different. For example, in a text editor, if
the font height is 10.5 pixels then two assignment lines
x = 1
y = 0
may display the first '=' legibly with one black line, one white
line and another black line but the second line, offset by .5 pixels
will show a 4 pixel high grey rectangle. Forcing the '=' onto the pixel
grid will distort the text appearance.

Neil

 

[bruno modulix]

Just one teeny little item.

The Python world lacks the phenomenally successful development models
enjoyed by the now ancient Turbo Pascal, Delphi and <gasp> Visual Basic.
AND
If the likes of Visual Basic can have it, then it becomes really, *really*
hard to convince the world that Python is a serious, professional system.

You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
doesn't have it, C++ doesn't have it (in fact most languages doesn't
have it) - and the fact is that C and C++ are usually considered as much
more "serious and professionnal" than VB and the likes.

 

[Thomas Bartkus]

system.

You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
doesn't have it, C++ doesn't have it (in fact most languages doesn't
have it) - and the fact is that C and C++ are usually considered as much
more "serious and professionnal" than VB and the likes.

 

[Thomas Bartkus]

You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
doesn't have it, C++ doesn't have it (in fact most languages doesn't
have it) - and ....

> .... the fact is that C and C++ are usually considered as much
> more "serious and professionnal" than VB and the likes.

Yes but there is another fact that must be considered.
Systems like VB (and the likes) are much more *productive* .

The secret of that particular success has nothing to do with the language
and everything to do with the integrated GUI / IDE available to that
particular (VB) language.

Anything that reduces the overhead involved in producing a
consistent/attractive/idiot proof user interface makes a far more
productive environment.

Thomas Bartkus

 

[James Tanis]

Previously, on Jun 6, Thomas Bartkus said:

# # > You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
# > doesn't have it, C++ doesn't have it (in fact most languages doesn't
# > have it) - and ....
#
# > .... the fact is that C and C++ are usually considered as much
# > more "serious and professionnal" than VB and the likes.
#
# Yes but there is another fact that must be considered.
# Systems like VB (and the likes) are much more *productive* .
#
# The secret of that particular success has nothing to do with the language
# and everything to do with the integrated GUI / IDE available to that
# particular (VB) language.

That's pretty arguable. C/C++ has no shortage of integrated GUI/IDE
available especially if your willing to fork out the same kind of books
that you would need to for VB.

#
# Anything that reduces the overhead involved in producing a
# consistent/attractive/idiot proof user interface makes a far more
# productive environment.
#
# Thomas Bartkus

My 2 cents, I'm much more productive with Python and QT Builder as I
am with VB and those aren't nearly as intergrated as VB's GUI/IDE. A
language's productivity, I believe, rests on how high or low-level the
language and its libraries are. Not just that though, productivity is
also very much affected by the breadth of the libraries available.

Sure, GUI RAD solutions increase development in a very real way, but you
can find an offering for just about every language out there these days.

#
# --
# http://mail.python.org/mailman/listinfo/python-list
#

 

[Thomas Bartkus]

Previously, on Jun 6, Thomas Bartkus said:

# # > You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
# > doesn't have it, C++ doesn't have it (in fact most languages doesn't
# > have it) - and ....
#
# > .... the fact is that C and C++ are usually considered as much
# > more "serious and professionnal" than VB and the likes.
#
# Yes but there is another fact that must be considered.
# Systems like VB (and the likes) are much more *productive* .
#
# The secret of that particular success has nothing to do with the language
# and everything to do with the integrated GUI / IDE available to that
# particular (VB) language.

That's pretty arguable. C/C++ has no shortage of integrated GUI/IDE
available especially if your willing to fork out the same kind of books
that you would need to for VB.

#
# Anything that reduces the overhead involved in producing a
# consistent/attractive/idiot proof user interface makes a far more
# productive environment.
#
# Thomas Bartkus

My 2 cents, I'm much more productive with Python and QT Builder as I
am with VB and those aren't nearly as intergrated as VB's GUI/IDE. A
language's productivity, I believe, rests on how high or low-level the
language and its libraries are. Not just that though, productivity is
also very much affected by the breadth of the libraries available.

When scripting, Windows or Linux, I also am much more productive with
Python.
When automating a process for another human being, I am much more productive
with a RAD tool like VB. The effort involved in creating the user front end
simply overwhelms all the considerable efficiencies of Python.

When I code wxPython, I find I want to use VB to create/model my user
interface. Once I prototype my Windows (Frames!) using VB, I can then xlate
this to wxPython code. What I couldn't do without the VB IDE was visualize
and experiment with the impact of various layouts *before* I lay down code.
It is simply too onerous to experiment by code manipulation and too easy to
swish around visually with a mouse.

When I use a GUI designer like wxGlade, I still find it awkward enough to
merit prototyping with the VB IDE and then mimic the windows I create with
wxGlade.

Sure, GUI RAD solutions increase development in a very real way, but you
can find an offering for just about every language out there these days.

Yes. But the tools available for Python are still primitive compared to RAD
tools like Delphi/Visual Studio. I still don't know enough wxPython to
understand what the barriers are to creating a RAD visual design and
construction tool similar to the Visual Studio environment.
My ravings here are simply the result of a suspicion -

- The suspicion is that the only barrier is the Python (and Linux!)
communities grossly underestimating the value of such an undertaking.
Thomas Bartkus

 

[James Tanis]

Previously, on Jun 6, Thomas Bartkus said:

# # > Previously, on Jun 6, Thomas Bartkus said:
# >
# > # # > # > You mean the "wimp gui builder + db -> ui pipeline" model ? If yes, C
# > # > doesn't have it, C++ doesn't have it (in fact most languages doesn't
# > # > have it) - and ....
# > #
# > # > .... the fact is that C and C++ are usually considered as much
# > # > more "serious and professionnal" than VB and the likes.
# > #
# > # Yes but there is another fact that must be considered.
# > # Systems like VB (and the likes) are much more *productive* .
# > #
# > # The secret of that particular success has nothing to do with the
# language
# > # and everything to do with the integrated GUI / IDE available to that
# > # particular (VB) language.
# >
# > That's pretty arguable. C/C++ has no shortage of integrated GUI/IDE
# > available especially if your willing to fork out the same kind of books
# > that you would need to for VB.
# >
# > #
# > # Anything that reduces the overhead involved in producing a
# > # consistent/attractive/idiot proof user interface makes a far more
# > # productive environment.
# > #
# > # Thomas Bartkus
# >
# > My 2 cents, I'm much more productive with Python and QT Builder as I
# > am with VB and those aren't nearly as intergrated as VB's GUI/IDE. A
# > language's productivity, I believe, rests on how high or low-level the
# > language and its libraries are. Not just that though, productivity is
# > also very much affected by the breadth of the libraries available.
#
# When scripting, Windows or Linux, I also am much more productive with
# Python.
# When automating a process for another human being, I am much more productive
# with a RAD tool like VB. The effort involved in creating the user front end
# simply overwhelms all the considerable efficiencies of Python.
#
# When I code wxPython, I find I want to use VB to create/model my user
# interface. Once I prototype my Windows (Frames!) using VB, I can then xlate
# this to wxPython code. What I couldn't do without the VB IDE was visualize
# and experiment with the impact of various layouts *before* I lay down code.
# It is simply too onerous to experiment by code manipulation and too easy to
# swish around visually with a mouse.
#
# When I use a GUI designer like wxGlade, I still find it awkward enough to
# merit prototyping with the VB IDE and then mimic the windows I create with
# wxGlade.
#
# > Sure, GUI RAD solutions increase development in a very real way, but you
# > can find an offering for just about every language out there these days.
#
# Yes. But the tools available for Python are still primitive compared to RAD
# tools like Delphi/Visual Studio. I still don't know enough wxPython to
# understand what the barriers are to creating a RAD visual design and
# construction tool similar to the Visual Studio environment.
# My ravings here are simply the result of a suspicion -
#
# - The suspicion is that the only barrier is the Python (and Linux!)
# communities grossly underestimating the value of such an undertaking.
# Thomas Bartkus
#

Hmm, it's not that simple though. Unfortunately efforts get spread
among the various projects, wxPython is only one among many. You seem
set on wxPython, and its true, RAD projects based around that toolkit
still seem to be in alpha/beta stages, but that does not go for all the
toolkits. There are no barriers that I know of, but your comparing an
application (vb) that has been 11+ years with one (wxglade) that has
been around what.. maybe three years?

#
#
# --
# http://mail.python.org/mailman/listinfo/python-list
#

 

[Thomas Bartkus]

Previously, on Jun 6, Thomas Bartkus said:

# # >
# >
# > My 2 cents, I'm much more productive with Python and QT Builder as I
# > am with VB and those aren't nearly as intergrated as VB's GUI/IDE. A
# > language's productivity, I believe, rests on how high or low-level the
# > language and its libraries are. Not just that though, productivity is
# > also very much affected by the breadth of the libraries available.
#
# When scripting, Windows or Linux, I also am much more productive with
# Python.
# When automating a process for another human being, I am much more productive
# with a RAD tool like VB. The effort involved in creating the user front end
# simply overwhelms all the considerable efficiencies of Python.
#
# When I code wxPython, I find I want to use VB to create/model my user
# interface. Once I prototype my Windows (Frames!) using VB, I can then xlate
# this to wxPython code. What I couldn't do without the VB IDE was visualize
# and experiment with the impact of various layouts *before* I lay down code.
# It is simply too onerous to experiment by code manipulation and too easy to
# swish around visually with a mouse.
#
# When I use a GUI designer like wxGlade, I still find it awkward enough to
# merit prototyping with the VB IDE and then mimic the windows I create with
# wxGlade.
#
# > Sure, GUI RAD solutions increase development in a very real way, but you
# > can find an offering for just about every language out there these days.
#
# Yes. But the tools available for Python are still primitive compared to RAD
# tools like Delphi/Visual Studio. I still don't know enough wxPython to
# understand what the barriers are to creating a RAD visual design and
# construction tool similar to the Visual Studio environment.
# My ravings here are simply the result of a suspicion -
#
# - The suspicion is that the only barrier is the Python (and Linux!)
# communities grossly underestimating the value of such an undertaking.
# Thomas Bartkus
#

Hmm, it's not that simple though. Unfortunately efforts get spread
among the various projects, wxPython is only one among many.

I realize that. And I wouldn't consider it unfortunate that efforts are
spread amongs various projects. It adds richness to the whole environment
but, yes, it does dilute efforts.

You seem set on wxPython, ...

The attractiveness of wxPython here is that it extends the platform
neutrality of Python to GUI interfaces. On a Windows platform, the work
looks like any other Windows program. On Gnome/Linux, the identical code
fits right into the Gnome desktop scheme. *Big* plus.

But stuck? There is so much going, there is so little time, and I wallow in
ignorance. Justification for my ravings is to coax out the experience of
others. One can't help feeling that one is missing something important
simply because there isn't the time to evaluate everything in depth. And
much of this stuff *needs* to be examined in depth to give it a fair shot.

What neat things am I missing and should be looking at ?

... and its true, RAD projects based around that toolkit
still seem to be in alpha/beta stages, but that does not go for all the
toolkits. There are no barriers that I know of, but your comparing an
application (vb) that has been 11+ years with one (wxglade) that has
been around what.. maybe three years?

Yes. And I'm sorry to sound like I was complaining (but I was
I'm here because MS is well along it's declining years and I've jumped off
the .NET bandwagon. New/wonderful things are no longer forthcoming from
that world. They are in Linux/Python.

Thomas Bartkus

 

[Renato Ramonda]

Thomas Bartkus ha scritto:

The attractiveness of wxPython here is that it extends the platform
neutrality of Python to GUI interfaces. On a Windows platform, the work
looks like any other Windows program. On Gnome/Linux, the identical code
fits right into the Gnome desktop scheme. *Big* plus.

Maybe I'm just nitpicking, but please!

wxWidgets apps look ALMOST native on windows (combobox and similar
widgets are emulated, and look really bad), and they sure _don't_ look
like gnome apps on linux (gtk maybe, except for those custom widgets,
but surely not gnome).

Besides, wx generally catches the look, but almost never the 'feel'.

wx is what you use if you really have no other choice, from my point of
view... I'd honestly prefer to code a _good_ gui with gtk+glade and then
bundle all the package together with py2exe and InnoSetup on windows. It
will not look _native_, but it will look _GOOD_.

Last time I looked wx did not have spacers (vbox, hbox and the like)...
this leads to ugly non resizable vb-style guis, in my experience (just
look at aMule... plain ugly).

And that's not even starting to consider the version mess: try to
install xCHM, Boa Constructor, aMule, VLC and some other app together...
instant madness.

Yes. And I'm sorry to sound like I was complaining (but I was
I'm here because MS is well along it's declining years and I've jumped off
the .NET bandwagon. New/wonderful things are no longer forthcoming from

Then download gtk2.6 and glade for windows and then install pygtk and
code away to your satisfaction! :-D

 

[Tim Roberts]

wxWidgets apps look ALMOST native on windows (combobox and similar
widgets are emulated, and look really bad),

That just isn't true. They use the standard combo box.

Last time I looked wx did not have spacers (vbox, hbox and the like)...
this leads to ugly non resizable vb-style guis, in my experience

wx uses "sizers" to do the same thing. Same purpose, different philosophy.
I find sizers more natural, but people should certainly stick to whatever
makes them comfortable.

And that's not even starting to consider the version mess: try to
install xCHM, Boa Constructor, aMule, VLC and some other app together...
instant madness.

They why would you do it? gvim and wxPython do the job for me. No mess.

 

[Renato Ramonda]

Tim Roberts ha scritto:

That just isn't true. They use the standard combo box.

Then it has changed recently. Mind that most stable apps still use wx2.4

wx uses "sizers" to do the same thing. Same purpose, different philosophy.
I find sizers more natural, but people should certainly stick to whatever
makes them comfortable.

I like sizers too, but in my experience wx apps do not use them. Are
they by chance something that came with the 2.5/2.6 development cycle?
That version is still pretty rare in real world applications.

They why would you do it? gvim and wxPython do the job for me. No mess.

Because i USE a chm reader. And I USE aMule, and I USE a multimedia player.

I'm not talking about developing (don't get confused by my mention of
Boa), I'm talking about using. Only very recently wx introduced a
mechanism to keep different versions in parallel.

 

[Thomas Bartkus]

Thomas Bartkus ha scritto:

Then download gtk2.6 and glade for windows and then install pygtk and
code away to your satisfaction! :-D

I *will* try that.

Thanks
Thomas Bartkus

 

[Renato Ramonda]

Thomas Bartkus ha scritto:

I *will* try that.

On linux you probably have everything installed or a command away, on
windows use this:

http://gladewin32.sourceforge.net/

choosing the development package (that includes gtk _and_ glade), plus

http://www.pcpm.ucl.ac.be/~gustin/win32_ports/pygtk.html

for pygtk. Just choose the right python version, obviously.

 

[flyingfred0]

Tim Roberts ha scritto:




Then it has changed recently. Mind that most stable apps still use wx2.4



I like sizers too, but in my experience wx apps do not use them. Are
they by chance something that came with the 2.5/2.6 development cycle?
That version is still pretty rare in real world applications.

I know sizers are in 2.4; I've been aware of them for quite some time.
But it took awhile for me to learn them well and start using them
religiously. Before that, I'd usually hardcoded positions because it
was easier to get something done that way, but it eventually became a
bitch to maintain.

 

[Thomas Bartkus]

Thomas Bartkus ha scritto:


On linux you probably have everything installed or a command away, on
windows use this:

http://gladewin32.sourceforge.net/

choosing the development package (that includes gtk _and_ glade), plus

http://www.pcpm.ucl.ac.be/~gustin/win32_ports/pygtk.html

for pygtk. Just choose the right python version, obviously.

Thank you Renato!

I'm in the thick of it right now. The challenge is to sort it all out.
wxWidgets<>wxPython<>wxGlade<>Glade<>GTK<>pyGTK<>TKinter<>much more.
This is a complicated soup and the interelationships are not obvious or easy
to sort out.

> On linux you probably have everything installed or a command away ...

Well! - that's the problem!
I'm not going to live long enough to evaluate everything
Thomas Bartkus

 

[Tim Roberts]

Tim Roberts ha scritto:


I like sizers too, but in my experience wx apps do not use them. Are
they by chance something that came with the 2.5/2.6 development cycle?
That version is still pretty rare in real world applications.

Hardly. Sizers have been the primary method of placing multiple controls
in wx for as long as I've been using it, which goes back to 2.3. In fact,
it's hard to create a non-trivial wx app WITHOUT using sizers. All of the
wx GUIs place controls in nested sets of sizers.

 

[Renato Ramonda]

Tim Roberts ha scritto:

Hardly. Sizers have been the primary method of placing multiple controls
in wx for as long as I've been using it, which goes back to 2.3. In fact,
it's hard to create a non-trivial wx app WITHOUT using sizers. All of the
wx GUIs place controls in nested sets of sizers.

Dunno... I'll take your word on this. In my experience though wx apps
have awfully ugly laid out interfaces, often non resizable ones. Maybe
is't only bad luck