Subject: GUI Patterns

From: Shlomi Fish <[email-masked]>
Date: Mon, 3 Jun 2002 09:04:28 +0300 (IDT)

Those who use a lot of GUI Programs know that there are some common
patterns in them. Many of which are not abstracted into an API by GUI
libraries such as Gtk+, Qt, the Win32 API, MFC, wxWindows, etc. Nor should
they, as these libraries should be flexible enough to allow you to design
any GUI you'd like out of the most basic widgets. But, wouldn't it be cool
if you had an API above them that would abstract such patters?

Examples, off the top of my head:

1. Disabled/enabled controls in a dialog. In everywhere I saw, if checkbox
X disables or enables some of the controls below it, then the disabling
logic has to be hard-coded into the program.

2. A selection of items out of a list. Usually implemented as two
list-boxes with a left arrow, right arrow (and up arrow and down arrow if
appropriate). But there isn't such a predefined control.

3. A scroll-bar that is synchornized with an edit-box displaying the exact
numeric value.

And naturally there are more.

Do you know of any libraries offering such pre-defined meta-widgets? Any
for Linux?

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Jun 2002 10:42:13 +0300

Shlomi Fish <[email-masked]> writes:

> Do you know of any libraries offering such pre-defined meta-widgets? 
> Any for Linux?

I am not a GUI programmer, but don't the things that you describe
(parts of dialogues and options enabled/disabled etc) go deeper than
GUI? E.g. don't they imply an underlying state machine that governs
what should be disabled/enabled in each state? 

Or am I misreading the question?

-- 
Oleg Goldshmidt | [email-masked] 
"A sense of the fundamental decencies is parceled out unequally at birth."

---

From: "Nadav Har'El" <[email-masked]>
Date: Mon, 3 Jun 2002 10:51:10 +0300

> Do you know of any libraries offering such pre-defined meta-widgets? Any

When the library is OO-like, even if the language itself is not OO, you
can create such mega-widgets, which will look and behave like one widget
but will ultimately be composed from several seperate built-in widgets.

You can do that in Motif using the Xt framework (but keep a psychologist
on retainer, you're going to need one if you program in Xt/Motif...), and
it is even more natural in Tk and [incr Tcl] (the OO version of TCL, those
who know TCL will appreciate the pun on C++'s name); The most well known
Tk mega-widget set is the [incr Widgets], see
	http://incrtcl.sourceforge.net/iwidgets/

A short quote from that site:
  "[incr Widgets] offers a strong object-oriented foundation which addresses
   the need for a flexible and extensible mega-widget set. Its usage replaces
   common widget combinations with higher level abstractions, simplifying
   code, reducing errors, increasing readability, adding productivity, and
   promoting a singular look-and-feel."

I assume similar things are doable in Qt and maybe even Gtk, but I never
looked into it (I have to admit that though I have a lot of experience in
GUI programming, I'm a little behind-the-times because it's been a few
years since I wrote a GUI).

-- 
Nadav Har'El                        |        Monday, Jun 3 2002, 23 Sivan 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Someone offered you a cute little quote
http://nadav.harel.org.il           |for your signature? JUST SAY NO!

---

From: "Nadav Har'El" <[email-masked]>
Date: Mon, 3 Jun 2002 11:12:49 +0300

> what should be disabled/enabled in each state? 

Not really. Modern GUI design is based not on a state machine (also called
"modal" design, because the UI is based on entering various modes, e.g.,
see Vi) but rather on callbacks. The UI is presented on the screen, and
when something happens (e.g., a user clicks on some button) an appropriate
callback function is called and does some predetermined task (which might
depend also on what goes on in the rest of the application). If the button
is "disabled" (e.g., grayed out), a user will not be able to click on it
and the callback will never be called - the application doesn't need to
to remember such a thing in some special hidden "state" variable. The
application does need to implement callbacks correctly: for example, before
a file is loaded into an editor, the "save" and "close" buttons may
be grayed out (or absent altogether); When a file is loaded, e.g. as
a callback from the "Load" button, this callback will ungray the "save"
and "close" buttons. The "close" callback will gray out these buttons
again. I think what Shlomi was after was some framework under which you
can keep all these decisions in one place (object, in OO speak) instead
of spreading it around in the various callbacks for different objects (in
this example, for load and close).

By the way, if anyone is curious why modern GUIs are callback-based rather
than modal - well, while keeping complicated hidden "state" variables and
logic by the computer is possible, keeping it in the human brain is much
harder. A human (especially those of the genus Homo Sapiens Newbicus) 
tends to forget what state the program is in, and which kinds of operations
are valid in this state. A callback-based GUI solves this problem, because
all operations are run by clicking (or some other method of interaction)
on some visible on-screen control, each of which in turn runs its callback
to do the desired work.
For the finest example (in my opinion) of an (almost) mode-less GUI, see
the Palm Pilot. There you (ideally) don't even have the mode of "which
application I'm in" -  at any point you can switch between applications,
turn of the machine, and so on, and then go back to the application which
is (ideally, but not always in practice) exactly like you left it.

-- 
Nadav Har'El                        |        Monday, Jun 3 2002, 23 Sivan 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |"Outlook not so good." Wow! That magic 8-
http://nadav.harel.org.il           |ball knows everything! So, what about IE?

---

From: Oleg Goldshmidt <[email-masked]>
Date: 03 Jun 2002 11:43:36 +0300

"Nadav Har'El" <[email-masked]> writes:

> for example, before a file is loaded into an editor, the "save" and
> "close" buttons may be grayed out (or absent altogether); When a
> file is loaded, e.g. as a callback from the "Load" button, this
> callback will ungray the "save" and "close" buttons. The "close"
> callback will gray out these buttons again.

That's what I meant: while the action performed when a button is
pressed is implemented via a callback, the GUI must have a way to
determine whether or not "save" and "close" should be disabled, and
that depends on state... What am I missing?

---

From: "Nadav Har'El" <[email-masked]>
Date: Mon, 3 Jun 2002 11:56:53 +0300

> that depends on state... What am I missing?

There's generally no added "state": whenever the "close" callback is
called, it will (in addition to other stuff) disable the "save" and
"close" buttons. If that operation would not make sense (because no
file is loaded) the user would not have been able to cause this callback
to run in the first place, because sometime earlier the "close" button
would have been disabled (e.g., by an earlier "close" operation).

This means that all state is visible to the user. Many times this is not
possible to do completely, so the program still keeps some hidden state.
But the less there is such hidden state, the more user-friendly (and
un-Unix-ish) the GUI is considered.

-- 
Nadav Har'El                        |        Monday, Jun 3 2002, 23 Sivan 5762
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |The space between my ears was
http://nadav.harel.org.il           |intentionally left blank.

---

From: Shlomi Fish <[email-masked]>
Date: Tue, 18 Jun 2002 14:17:43 +0300 (IDT)

>    promoting a singular look-and-feel."

From my impression these meta-widgets are not exactly what I was looking
for. I was looking for a widget that will abstract some of the
functionality and behaviour of the GUI, while these widgets address mostly
look and feel and a bit more.

Regards,

	Shlomi Fish

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

---

From: guy keren <[email-masked]>
Date: Wed, 19 Jun 2002 02:03:28 +0300 (EET DST)

> look and feel and a bit more.

if you look at glade, you'll see that there are some such widgets in both
gtk and gnome. it begins with simple ones (gtk_clist), goes to the
file-selection dialog (which also supports navigating the file system,
creating and deleting directories, renaming files....), and goes to
calendar widget, and up to a 'gnome application' widget, which sets up the
menu bar, toolbar, status line and application area.

it is true that much more can be done, provided one has enough experience
with GUI programming, that they can make the interfaces of such composite
classes - general enough, to not limit their users to the point where
they'll dump the class and roll their own.

-- 
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy