Re: dialog iteration

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes:
> 
> you've already lost source compatibility with changing the
> action_area container type. 

I haven't, because GtkHBox has no interface, it's all via GtkBox.
(Yes someone might have some weird GTK_IS_HBOX() code, but it seems
fairly unlikely.)

> GtkDialog is currently so limited,
> that we really shouldn't care about source compatibility that
> much, but rather provide a sane API and a comprehensive Changes
> log (of course, we can still simply rename the new API like
> i did with gtk_aux_dialog(), but aparently you didn't chose
> that route).
> 

I just think it's a lot nicer to have a single dialog widget called
GtkDialog, instead of having to say "use GtkAuxDialog, GtkDialog is
old cruft." Keeps the toolkit a lot cleaner --> thus simpler to learn.
 
Already the docs can be made to seem a lot simpler if we remove all
the crufty stuff.

GtkDialog compatibility really isn't hurting anything I don't think.
It may change some small details.

> uhm, i think part of the confusion here is with what "Close"
> actually means. widgets get shown, hidden and destroyed, i think
> we shouldn't deviate from that terminology. so you can simply
> say:
> "Dialogs will be hidden automatically upon activation of a
> button, if hide_on_activate is passed as TRUE in
> gtk_dialog_add_action_widget().
> Dialogs created with GTK_DIALOG_DESTROY_ON_HIDE will be
> automatically destroyed when hidden."
>

Good, this works for me. So I simply gtk_widget_destroy() in a "hide"
callback. That's simple. I like it.

The problem is this: if you don't use DESTROY_ON_HIDE, and you don't
modify delete_event, when gtk_dialog_run() returns you don't know if
the dialog has been finalized. ;-)
 
This is one of the original reasons for the "close" signal.

> shouldn't be cut. too many applications already "cache" dialog

I think caching is useless (dialogs aren't expensive to create)...

> creation, and it's also convenient to preserve dialog contents
> across multiple invokations (such as the current directory

But this is a good point, that's a compelling argument for allowing
the hide behavior.
  
> i agree that this should depend on the user prefs, still, like
> i outlined in my previous mail, you'll want to support popups
> at the cursor position to have short lived query dialogs ("Really
> Close?") be quickly answered.
>

I would like to somehow make this a semantic flag - like
GTK_DIALOG_SHORT_LIVED or something - with the meaning of that also
user-configurable, if it's configurable at all.

Maybe what we should have is:
 typedef enum {
   GTK_DIALOG_SHORT_LIVED, /* super-quick button-click */
   GTK_DIALOG_TRANSIENT,   /* preferences dialog, etc. */
   GTK_DIALOG_PERSISTENT   /* Layers and channels */
 } GtkDialogType;
 
But I'm not convinced - it seems to me that SHORT_LIVED and TRANSIENT
should maybe behave the same way - doesn't it confuse and slow down
users if they have to see where the dialog is coming up, instead of
unconsciously learning that all dialogs come up centered over the
parent window?

Well for most naive users the slow part about a dialog is noticing it,
reading it, and deciding what to click, not moving the mouse over to it.

Anyway I guess if we have the semantic flags then users can configure
this.

I wonder if it should be a GtkWindow flag instead though, so you can
get the user-configured behavior for custom dialogs in addition to
dialogs done with GnomeDialog.

> gtk doesn't actually use inline docs over the place and i don't think
> inconsistently adding them in random places is a good idea. instead,

OK, Owen said something about wanting to use inline docs. Whatever you
want to use...

> ok, some notes on the implementation.
> first, you setup add and remove handlers on the action area,
> this is an evil thing, if people actually add widgets

OK, I agree I think.
  
> static gboolean
> gtk_dialog_delete_event (GtkWidget *dialog,
>                          GtkEvent  *event)
> {
>   gtk_dialog_hide (dialog);
>   
>   return TRUE;
> }
>

I specifically avoided this because it breaks delete_event handling in
old code. (Well, I don't seem to connect to delete_event at all in my
CVS version, I don't know if it's the same as what I posted.)

However this default handler is definitely required if we want to
support the DESTROY_ON_HIDE flag.
    
>   do
>     {
>       GDK_THREADS_LEAVE ();
>       g_main_iteration (TRUE);
>       GDK_THREADS_ENTER ();
>     }
>   while (GTK_WIDGET_VISIBLE (dialog));
>   

This isn't semantically the same as my gtk_dialog_run(), note that
mine _always_ exits when an action occurs, even if the action didn't
close the dialog. I agree this is a simpler implementation if 
we want the different behavior. I don't know anything about the
threads stuff, isn't Owen fixing that in 1.4 anyway?


So, remaining issues:
 - Should SHORT_LIVED, PERSISTENT, etc. be GtkWindow flags?
 - Should gtk_dialog_run() return only when the widget is hidden, 
   or also when "action" is emitted?
 - Is it OK to break old code with the default delete_event 
   handler that hides the dialog instead of destroying it?

On to your other email...

Havoc