Re: [Nautilus-list] some eel patching

[Darin Adler <darin bentspoon com>]

on 11/1/01 9:32 AM, Havoc Pennington at hp redhat com wrote:

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

Is there a way to enhance the results you get with older dumber WMs without
damaging the ability of newer better WMs to do it perfectly?
 
>>> +    (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?

I meant that it was OK to apply the patch, and then I'd remove it after the
fact. But you are welcome to remove it instead. I think that would be even
better. Someone will have to make the changes to Nautilus, but that won't be
a big deal. Especially if you do that part too :-)

> 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.)

Great.

>>> +    (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.

This worries me a bit. I don't think that users will know which windows are
GtkDialogs and which are non-GtkDialogs. And in Nautilus, I was hoping that
a single key would work to close any window.

But I guess we can make this change and see if this is a real issue in
practice. I find it nearly impossible to reason correctly about human
interface decisions when looking from the bottom up like this.

    -- Darin