Re: dialog convenience API

[Gregory Merchan <merchan phys lsu edu>]

On Thu, May 30, 2002 at 04:02:14PM -0400, Ettore Perazzoli wrote:
> On Wed, 2002-05-29 at 18:43, Havoc Pennington wrote:
> > Ettore Perazzoli <ettore ximian com> writes: 
<snip>

> BTW, given that the HIG suggests specifying the actions in the dialog
> instead of using stock buttons, we also have the problem that the
> dialogs will look ugly a lot of the time because of mixing buttons with
> and without icons.  (This has always been the problem with GNOME.)
> 
> I would be for dropping the icons altogether...

Amen - and for all dialogs.


> > To get around the GtkButtonsType limitation you really need to provide
> > the buttons via varargs, but varargs are already used for the message
> > text format.
> 
> Normally you don't want to have more than five buttons, and the meaning
> of these buttons is already defined according to the HIG.  I.e. you want
> an "action" button, a "cancel" button, and an "alternate action" button,
> plus possibly "help" and "details".

I think Help or Details should be considered as the alternative if they are
present. If four or more buttons are needed, your program probably needs to
be redesigned.


<snip>

> They should always be modal IMHO.

IMO, too. Everyone thinks modal dialogs suck - and on various platforms
they really do. The problem seems to be what is considered a mode. On
Windows (and the Mac, iirc), you get the iconceivably stupid behavior
of locking the window in place obscuring the information you need; but
modality isn't locking windows. Worse, you find modality system-wide
when it isn't the least bit appropriate. (Is it ever? Really?) Slightly
not so bad, you'll have a moveable (and shadeable) modal window that lets
you see whatever was on the screen when it appeared, but it blocks all
activity in the parent window so you can't scroll, select, or copy.
Still less bad is to not make dialogs modal - now, here I mean those
things were OK and Cancel would be applicable even if those labels
are not the best; this excludes things like a Find window and instant-apply
property panels like in the Gimp and now GNOME.

If you're going to present a dialog (read: OK-able or Cancel-able window),
then you should restrict the user's action in the parent window because
it encourages the user moving steadily. The same principle is shown in
wizards - rather than presenting a blank slate (or apache config file)
you create an order which keeps the user involved and informed and thus
the user completes the task more quickly. But the restrictions must
not prevent the user from completing the task or switching to another; so
you shouldn't lock windows or scrollbars or prevent those things which
are often helpful like selecting and copying. If no kind of restriction
would help the user along, then a dialog isn't really appropriate - use
a utility window (e.g., for Find) or a property panel (see Gimp) or
look for a better way to let the user do the work. Finding a better way
sometimes leads to a new model of application; e.g., compare entering
data into a sequence of dialogs to just using a spreadsheet.

Sometimes the best way to let the user do something is found in the system
outside your application.

<snip>
> > > Also, I think gtk_message_dialog_new() should return a non-resizable
> > > dialog by default.
> > 
> > IIRC, originally wasn't done because there is no way to change the
> > default value of an object property in a subclass. Can't be done now
> > as it's an ABI change. (Apps that wanted resizable will break.)
> 
> This sucks, as it means that most apps will just have resizable message
> dialogs.  :-/  The alert API should definitely enforce the
> non-resizability though.

Indeed.


<snip> 
> This has the basic disadvantage of not allowing printf-style
> formatting...  :-(  But if we want to enforce the bold/non-bold
> convention and not have to deal with escaping the markup, I don't see
> any other solution...

The thing I was concerned about when I started this reply. :-)

I think it is very important for consistency and probably accessibilty
to have semantic subclasses of GtkLabel. Having a few simple subclasses
will encourage consistency and will also benefit those not seeing the
text changes. A screen-reader program could use a different tone of voice
when reading the larger or bold text in an alert than when reading the normal
sized text too convey the relative importance. Strings which just label
some control could be distinguished from more informative strings or those
that are just part of a control. E.g.:

  Foo: [___________] [ Bar ]
       Quux baz zud

Here "Foo:" just labels the entry, "Bar" is part of the button (hence, an
issuable command),  and "Quux baz zud" is a caption providing some
helpful information about the entry.

So, some classes, use, and markup might be:

  Class: GtkFieldLabel
    Use: used with entries and lists
 Markup: some thematic color

  Class: GtkCommandLabel
    Use: used on buttons and menu
 Markup: bold

  Class: GtkCaption
    Use: extra info like "Note: Password are case-sensitive"
 Markup: smaller

I know at least the Java HIG has something like this. Making sure
the right classes are available would surely require coordinating
most of the GNOME subprojects.

> Also, these function calls all take several args.  Maybe we could have
> gtk_alert_information_simple() or something, for the cases where you
> just want to set title and text.

Alerts really shouldn't have titles. Titles on alerts provide no useful
information that isn't in the alert text and only distract. Since alerts
are modal and should remain above the parent window, they shouldn't
take up space on the panel window list either.

> 
> -- Ettore

Cheers,
Greg Merchan