Re: pending stuff in havoc-patches

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp@redhat.com> writes:

> Hi,
> 
> Some of this has been posted before, some might be new, I don't
> remember everything. I forgot to tag HEAD when branching
> havoc-patches, which is causing me pain.
> 
> 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)

If we add these, they should definitely be in GtkWindow. Is the
idea then that if window_position == GTK_WIN_POS_NONE, then
the position type (center, mouse, center_always, center_on_parent),
would be determined from the semantic type? (I'm not sure
what to call that property - maybe window_kind?)

I'd generally be in favor of this idea - I think it nicely balances
user and application configurability with getting the right default
behavior.

>   - 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 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've thought about this a bit, and I think the most convenient
behavior is that during the course of gnome_dialog_run(), clicking the
close button or hitting escape should cause gtk_dialog_run() to
return -1 but neither close nor hide the dialog.

That is, the default delete event handler for GtkDialog should check
to see if its called during an invocation of gtk_dialog_run(), and
if so, simply terminate the gtk_dialog_run() and return -1.
(Should it also emit ::action with an action of -1? I'm not sure.)

In other cases, the default event handler should return FALSE, to
simulate normal GtkWindow behavior.

This has the advantage of:

 - Causing things to work properly for gtk_dialog_run() in the normal  
   case
 - Keeping compatibility with the old behavior and normal GtkWindow
   behavior in other cases.

The main downside is that it is a slight extra complication, but my
opinion is that it is the kind of complication that will make sense
if you need to know.
 
>   - Do we want the gtk_dialog_action() signal-emission function

I would say we need either that, or:

 gtk_dialog_run_stop (GtkDialog *dialog, gint return_value);

Which doesn't emit ::action and simply terminates the main loop.
Calling it gtk_dialog_action() and emitting the action signal may
be more intuitive.

> Already-agreed-upon changes in gtkdialog.[hc]:
[...]
>   - virtualize add_action

Looking over the old mails I don't see Tim's justification for this...
why? (It reminds me unpleasently of ::add_accelerator; virtualization
for the sake of virtualization that locks in the implementation.)

> I haven't done these yet, I'll do all the changes at once after I know
> the full set of changes.
> 
> 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.

Yes. You can't write a proper GTK+ application without having to write
this widget.
 
> GtkStatusbar
> ===
> 
> I hacked it to allow a context_id of 0; this is only a matter of
> removing g_return_if_fail(). The purpose of the change is to allow
> using the statusbar without worrying about get_context_id(), etc.
[...]

Fine with me.

Regards,
                                                   Owen