Re: pending stuff in havoc-patches



>  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]