Re: Programmatically build UI's considered harmful...

I'm back from vacation... I thought I sent this out Tuesday, but I see
it lying in my drafts...

I expect the Glade folks would be happy to add support for more widgets...
This is something that comes up with regularity, as all toolkits
grow more widgets with time..

They already support both stock GTK widgets and Gnome widgets for example

UI builders are not panacea's, but they sure help at the 90% level, in
a bunch of areas we face.

As soon as I get done with the randr stuff I'm in the middle of doing
(hopefully by the end of this week), I'll go at the getting X smaller
department, so we'll have (alot) more space to play with.

                        - Jim

> Sender: gpe-admin@handhelds.org
> From: Nils Faerber <nils@kernelconcepts.de>
> Date: Mon, 19 Aug 2002 18:49:59 +0200
> To: gpe@handhelds.org
> Subject: Re: [Gpe] Programmatically build UI's considered harmful...
> -----
> Just to add one more point/difficulty:
> You are right with the additional abstraction using a GUI builder
> against direct programming (though I think that a subset of those
> problems can very well be addressed by the direct approach ... only when
> you start to completely change the UI upon resize then the additional
> abstraction is needed). But what I originally wanted ... you get into
> trouble when you leave the standard toolkit's road and start to use
> custom widgets like we now have in GPE. Then the GUI designer does not
> help you anymore; at least Glade can't. So I think this approach _could_
> involve higher efforts...
>
> CU
> nils
>
>
> On Mon, 19 Aug 2002 07:40:32 -0700 (PDT)
> <Jim.Gettys@hp.com> wrote:
> > I'd like to lay out the advantages/disadvantages of building UI's
> > directly in languages like C (or python, or whatever) vs. using UI
> > builders (e.g. glade).
> >
> > For building UI's the old way:
> > o somewhat smaller footprint (need to quantify).
> > o lower learning curve, as most people have usually done it this
> > way. o certain apps, maybe 5% of all apps, are beyond what any
> > UI tool can handle (e.g. drawing programs). Even most of their
> > UI can generally built with a UI builder, with only one or a
> > few specialized widgets.
> >
> > Against:
> > o much more work to deal with different display sizes. Right
> > off the bat, we have the two screen rotations, and you can
> > expect that screen sizes will continue to evolve. We also
> > have: - displays like on the Jornada 72x boxes, which are wide
> > and not very high
> > - your laptop (mine is 1400x1050)
> > - Others, from 1024x768 to as high as 4Kx4K.
> > o very seldom do programmers go beyond minimal support for
> > resizing. we need to handle serious UI changes as apps are used
> > (and migrated between) different sized screens (even a simple
> > rotation is a resize). When you have a big screen, often you
> > want to seriously change the UI. o Some people are much better
> > at designing UI's than others (and in fact, some of these are
> > non-programmers). And the UI's can be reworked without having
> > to understand the C code for consistency. Making it possible
> > to have UI folks work on tweaking the UI without messing with
> > the underlying code ends up being a major feature. o I18N is
> > easier: sometimes simple string substituion just doesn't hack
> > it: things don't fit and you have to go tweak the UI to make
> > things fit. The smaller the screen, the more likely this is to
> > occur.
> >
> > So I believe glade/libglade really carry their weight.
> >
> > (Un)fortunately, I'm likely to be out of touch this week and next, so
> > won't be able to add much more to this conversation for a while..
> > - Jim
> >
> >

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
Jim.Gettys@hp.com