[GUI] More points for the technical discussion

[Glynn Clements]

Wolfgang Jeltsch wrote:

> > > Generally, you only set widget properties programmatically if you  have to
> > > (i.e. because the values are determined dynamically).
> >
> > Yes,yes :) I was not proposing any true API, just arguing that one can
> > abstract over a yesNoCancel dialog window, parametrizing it with the verb to
> > use on macos and kde3 to avoid a "yes/no" question.
> 
> I think the distinction between static values (which don't have to be computed 
> at run-time) and dynamic values (which have to be computed at run-time) is 
> not very natural. It is just like a distinction between squares and 
> rectangles which are not squares.

Huh? Would you build a web site entirely from CGI scripts, even for
static pages?

Static-vs-dynamic is a pretty fundamental programming concept; e.g. 
the distinction between variables and functions in most languages (or
between values and e.g. IORefs in Haskell).

Sure, you *can* make everything dynamic; that doesn't mean that you
should.

> I would prefer if we would handle static 
> values the same way we handle dynamic values. That would mean that certain 
> static values would appear in the source code.

If dynamic values were the norm, that might make sense. But it's
seldom the case for UIs. Most of the time, most of the UI is constant
between program runs, with a few specific properties being determined
dynamically.

> > This does not solve the verb conjugation problem,indeed (how does apple
> > handle it in internationalization?)
> 
> Your approch for the Yes-No-Cancel dialogs was to specify a verb describing 
> the action (e.g., "save") and to let the system produce the button captions. 
> Why shouldn't we just define a function which has the captions of the Yes and 
> the No button directly as arguments? An example application of it could be
>     dialogYesNoCancel "Save" "Don't save" <other arguments>
> which would name the buttons "Save", "Don't save" and "Cancel" on the Mac and 
> "Yes", "No" and "Cancel" on a PC running Windows or KDE (:-)).

Because localisation is a lot easier if all user-visible text is in
one place (and in a place other than the source code).

Xt handles this by using the value of $LANG in the default search path
for resource files; to support multiple languages, you just need to
provide multiple resource files. The end user can even do the
localisation themselves if you don't provide a version for their
language (or you've chosen the wrong variant of the language).

On Windows, user-visible text is stored in a string table resource in
the executable. This has the disadvantage that the end user can't
modify it (although commercial developers may consider that an
advantage), but it still reduces the localisation process to
translating a single text file.

Don't make localisation and customisation the programmer's problem. 
Every real UI toolkit tries to ensure that this gets thrown in for
free.

Don't even make UI layout the programmer's problem unnecessarily. 
Graphical UI builders are widely used. End-user UI modification can be
useful e.g. for special-purpose applications, or educational use.

Most of the time, the only thing that the application logic *really*
needs to know about the UI is that certain widgets exist. If you need
to display a value in a text field, you just need to be able to get a
handle for that widget; you don't need to know anything else about it.

-- 
Glynn Clements <glynn.clements@virgin.net>