Re: GUI builders considered harmful (Was: anygui, anydb, any opinions?)

[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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI builders considered harmful (Was: anygui, anydb, any opinions?)

[Paul Rubin]

Chris Lambacher <[EMAIL PROTECTED]> writes:
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: GUI builders considered harmful (Was: 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

On 6/5/05, Mike Meyer <[EMAIL PROTECTED]> wrote:
> "Thomas Bartkus" <[EMAIL PROTECTED]> writes:
> > "Paul Rubin"  wrote in message
> >> 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 looki

Re: GUI builders considered harmful (Was: anygui, anydb, any opinions?)

[Jeff Epler]

On Sun, Jun 05, 2005 at 02:38:16PM -0500, Mike Meyer wrote:
[...]
> 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.
[...]

Certainly some---or even most---builders work like this.  But there's no
reason that a GUI GUI builder can't work in terms of the more
sophisticated layout algorithms that are available in most modern GUI
toolkits.

I've written a GUI builder for Tcl/Tk (some old versions live at
http://unpy.net/~jepler/nf/ but they're very out of date).  The core of
the application is the part that can write Tcl source code to regenerate
the screen as it's currently displayed.

The user can either use graphical tools like "insert widget", "show
properties", "pack earlier/later", "automatically add accelerator keys",
or script the thing by typing in Tcl.  Want to use the grid manager?
Fine, go ahead.  The graphical interface to the grid command may be
poor, but the commandline interface works great.  When things are as you
want them, just "save", and you can trivially "source" the resulting Tcl
code from your Tcl/Tk app.

I'm not trying to evangelize Tcl/Tk above any other language/toolkit,
but I am saying that by pairing an interpreted language with a GUI
toolkit, you can get a powerful GUI builder that instantly has top-notch
scrptability and also the guarantee that you can use the powerful
features of the GUI toolkit.  

I didn't do a survey of existing software before writing mine, but I
don't know of another builder that takes this kind of approach.  I
wonder why not.

Jeff


pgpMiqACxrAvI.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

GUI builders considered harmful (Was: anygui,anydb, any opinions?)

[Mike Meyer]

"Thomas Bartkus" <[EMAIL PROTECTED]> writes:
> "Paul Rubin"  wrote in message
>> 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 thes