Re: pending stuff in havoc-patches
- From: Federico Mena Quintero <federico helixcode com>
- To: gtk-devel-list gnome org
- Subject: Re: pending stuff in havoc-patches
- Date: Fri, 28 Apr 2000 15:17:33 -0500
> GtkDialog
> ===
>
> Outstanding questions so I can finish this:
>
> - Should SHORT_LIVED, PERSISTENT, etc. be GtkWindow flags?
> (These are semantic "types" of window, so we can make
> GTK_WIN_POS_MOUSE etc. user-configurable)
Isn't this policy? Or is it part of the wm-spec?
> - Should gtk_dialog_run() return only when the widget is hidden,
> or also when "action" is emitted?
Only when action is emitted. It should be up to the user to hide the
dialog afterwards:
dialog = gtk_dialog_new();
... fill it with widgets ...
result = gtk_dialog_run (dialog); /* modally! */
if (result != CANCEL && result != CLOSE) {
... fetch dialog data ...
}
... destroy or hide the dialog...
... use the data ...
If you want non-modal operation, you should just gtk_widget_show() the
dialog and wait for some signal from it when it is closed or a dialog
button is clicked. Again, if it is closed it should NOT hide itself;
it should be left to the user. The user should just have to connect
to a single "action" signal; that thing should wrap the delete_event
and button clicks.
The CLOSE result value should be provided by the library; CANCEL and
all others should be left to the user. CLOSE is not the same as
CANCEL; you may want simple, Mac-like dialog boxes with only the
window manager's Close button.
> - Is it OK to break old code with a default delete_event
> handler in GtkDialog that hides the dialog instead of destroying it?
> (This breakage is required in order to permit the
> only-hide-on-click behavior, otherwise gtk_dialog_run() can result
> in a dialog with an unknown reference count that might be 0)
I think leaving the hiding/destroying stuff up to the dialog is bad
API design. It should be left up to the user.
> GtkMessageDialog
> ===
>
> A convenience widget that:
>
> - sets title automatically
> - sets buttons/action_id automatically
> - packs a label
> - packs a big question mark icon or whatever
>
> Qt, Motif, etc. all have this widget, I think it's useful.
> Need a yes/no on its inclusion.
This defines UI policy. This does not belong in GTK+.
On the other hand, GnomeMessageBox could use some API loving.
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]