Re: dialog enhancements

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> i understand that you simply want to make the common case convenient here,
> however, that's an interface addition, the underlying mechanism, i.e.
> gtk_dialog_append_widget() still has to be exposed in the API.
> that way i can stuff customized widgets into the dialog (e.g. a button
> containing a GnomeForest) and have the basic functionality available
> for bindings.
> the one thing i don't like about your varargs interface:
> 
> dialog = gtk_dialog_new("Title", parent, "OK", "Cancel", NULL);
> 
> is that i don't see how that's supposed to scale to stock widgets,
> do you want to do string comparisions there, or recommend
> gtk_dialog_append_widget() usage? 

The idea here is that it looks for each button name in the 
GtkStockFactory, and if the button is in the stock factory we use a
stock button.

We provide standard stock strings like:
 #define GTK_STOCK_OK "OK" 

If people don't want stock buttons, they have to fall back to
append_widget().

> a better solution to this may be to have a usable stock interface
> (sketched) like:
> 

Look at my stock interface, in the havoc-patches branch, gtkstock.[hc]
gtkiconset.[hc], see what you think.

> typedef enum
> {
>   GTK_STOCK_NONE = 0,
>   GTK_STOCK_CLOSE,
>   GTK_STOCK_OK,
>   GTK_STOCK_CANCEL,
>   GTK_STOCK_EDIT,
>   GTK_STOCK_DELETE,
>   [...]
> } GtkStockType;

An enum is IMO bad, because it can't be extended by the user, and
because it requires the stock factory to contain certain things
reliably (while with GTK_STOCK_OK you can fall back to simply "OK" the
text of the stock #define if required).

The GNOME system works well, it's just the implementation that sucks, 
look how clean it is in gtkstock.[hc]

> and have a varargs intrface like:
> dialog = gtk_dialog_new ("Title", parent,
>                          gtk_stock_create_widget (GTK_STOCK_OK),
>                          gtk_stock_create_widget (GTK_STOCK_CANCEL),
>                          NULL);

I think this is just unacceptably inconvenient. ;-) But if we can't
agree we will need Owen to come in with the tiebreaker vote.

Of course append_widget() should be provided, I agree, but it isn't
the convenience interface...

Also gtk_dialog_new() shouldn't require stock widgets, you should be
able to use non-stock, which means gtk_dialog_new() has to take
action_id parameters... so the following won't work:

> usable as:
> switch (gtk_dialog_run (dialog))
> {
> case GTK_STOCK_OK:
...

> > You could even call it gtk_dialog_quit_run(dialog, return_code); 
> 
> i still don't get it, where would you call this from?
> is this for modal dialogs?
>

(In the new interface this is gtk_dialog_action().)

It's simply a way to emit the "action" signal, which has the effect of
quitting a gtk_dialog_run() if you want, or maybe it triggers your
"action" callbacks.

We can nuke this function if you want, I just expect someone to ask
for it.

> and at that point i wonder what the point in ahving an extra function,
> that just gets rid of the varargs, is...
>

The message dialog does these things:
 - sets title automatically 
 - sets buttons automatically
 - packs a label
 - packs a big question mark or whatever
  
> yes, that's for dialogs that you simply need the user to answer, but
> i think we actually have thre common cases here:
> 1) a dialog that should be quickly answered, e.g. by pressing Return
>    to activate a default Ok button. this we'd want to put aas good at
>    the user's disposal as possible, thus GTK_WIN_POS_MOUSE (done by
>    GTK_DIALOG_POPUP_POS flag)
> 2) a dialog that belongs to a parent window and should be placed
>    centered/above that parent window (e.g. a font selector for a
>    gnumeric cell) according to preference settings (i.e. might be
>    GTK_WIN_POS_MOUSE instead of transient-centered)
> 3) a dialog that belongs to a parent window, bt may stay for a while,
>    not covering up the parent window's contents (like a per-image
>    l&c dialog), placement here is probably best left to the wm.
>

Good summary, as I said in my other message, maybe these should be
GtkWindow flags? I can imagine wanting one of these behaviors for a
window with no action_area for example.

> > Good point, transients should perhaps be destroyed when their parent
> > is destroyed.
> 
> that's not only for transients, this can be virtually any assistance dialog,
> e.g.
> - non-modal adjust-zoom-area dialog for images
> - non-modal edit-properties
> - modal (transient) execute procedure dialog (beast has this)
> - modal (transient) "Really Close?" dialogs
> - non-modal select-current-font dialog
> just to name a few...
>

modal != transient (OK I'm not making them the same) by "transient" I
just mean "has a parent"
  
> > I really want varargs button labels on the end of this. ;-)
> > Maybe with action IDs alternating with the labels.
> 
> look at my writings above, maybe i can persuade you to have generic
> widget pointers for pluggable stock widgets there? ;)
>

OK I think we need Owen to weigh in on this one. ;-)

I just really think gtk_button_new_with_label("Blah") is a lot more 
typing than "Blah"

> > I think we should just have nice packing in GTK also - but we can
> > virtualize the function too. 
> 
> i'm not saying we need GNOME to fix gtk's broken packing, instead
> GNOME should take care of user prefs such as:
>  o  center buttons
>  O  spread buttons out
>  o  left-adjust buttons
>  o  right-adjust buttons
> [x] expand buttons
>

Good, good.
 

OK, so I'm going to virtualize the add_action() function (did I
already say that in the last mail?), and it seems that the major
outstanding issue here is to hash out the GtkStock system, my proposal
here is gtkstock.[hc] gtkiconset.[hc] in the havoc-patches branch.

Also, do we want gtk_dialog_action() to emit the action signal, I'm
happy to nuke this function, just let me know what you think.

Havoc