Re: [Nautilus-list] some eel patching

[Havoc Pennington <hp redhat com>]

Darin Adler <darin bentspoon com> writes: 
> Does gtk_window_present handle both workspace and area? If it does, then I
> want to just remove eel_gtk_window_present. The only reason I didn't do this
> before is that I thought that the eel one still did a bit more than the GTK
> one.

This issue is up to the window manager when using the new WM spec. GTK
just sends a "present the window" request.

In any case, if gtk_window_present() is wrong, let's just file a bug
report on it.

> 
> > +    (eel_get_current_event_time): simplify using GTK 2 features
> 
> I'll remove this and change clients to use gtk directly.
> 
> > +    (eel_drag_set_icon_pixbuf): simplify using GTK 2 features
> 
> I'll remove this and change clients to use gtk directly.

Does this mean I should apply the patch, then you'll remove it, or I
should remove it, then apply the patch?
 
> > +    (EEL_STANDARD_BUTTON_PADDING): remove, should fix in GTK if we are
> > +    going to fix it
> > +    (eel_gtk_button_set_standard_padding): make a no-op, should fix in
> > +    GTK
> 
> This change seems just plain wrong to me. If we don't need the call, we
> should remove it. But I'm not happy with making that decision without
> looking at why and where the call was used before.
> 
> I agree with the sentiment that this should go, but just neutering it at the
> eel level seems wrong to me. Lets remove it from the places it's used, then
> delete it.

OK, I can probably do that. Let me see if I can get Nautilus to build.
(I'll look at this stuff tonight, my eel patch is at home.)

> 
> > +    (eel_gtk_button_auto_click): make it do nothing, GTK does this for
> > +    you now
> 
> Should be removed rather than neutered. An doesn't it need to do
> gtk_widget_activate rather than nothing, if we're trying to neuter
> it?

Yes, sounds likely.

> 
> > +    (eel_gtk_window_set_up_close_accelerator): make it whine if you
> > +    use it on GtkDialog, since that breaks the standard GtkDialog
> > +    close accelerators
> 
> Would you be willing to explain this a bit more?

GtkDialog has a close accelerator now, which is configurable by the
"key theme" - it's wrong to set some other close accelerator, it will
override the key theme, or worse, potentially try to close the dialog
twice.

GtkDialog doesn't currently have Ctrl+w as this function does, I don't
remember why we did that (I do remember discussing it), but whichever
way we go, it's configurable via key theme, and should be the same
across all apps.

Havoc