Re: dialog enhancements
- From: Havoc Pennington <hp redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: dialog enhancements
- Date: 01 Apr 2000 07:36:06 -0500
Tim Janik <email@example.com> 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
We provide standard stock strings like:
#define GTK_STOCK_OK "OK"
If people don't want stock buttons, they have to fall back to
> 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,
> } 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),
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
We can nuke this function if you want, I just expect someone to ask
> 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,
> - 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
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.
] [Thread Prev