emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raise frame no go


From: Stefan Monnier
Subject: Re: raise frame no go
Date: Sun, 07 Jan 2007 10:45:40 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

>>> Metacity (the default Gnome window manager)  is a complete mess when it
>>> comes  to raise frame.  Some versions works, some don't.  Some require
>>> the code  below, some don't.  In some configurations (i.e. focus on
>>> click vs. focus on  mouse) raise frame works, in some raise frame
>>> don't work.
>>> 
>>> We must give up on creating workarounds for Metacity, and just tell
>>> people  that metacity is buggy.  Ufortunately they have to figure out
>>> a workaround for  themselves and their specific verion/configuration
>>> of metacity.
>> 
>> How about writing an entry for etc/PROBLEMS about this?

> In the bug created by Leo, http://bugzilla.gnome.org/show_bug.cgi?id=392889,
> the recommendation from the Gnome people seems to be that we use
> _NET_ACTIVE_WINDOW but with a proper timestamp (this was wrong in Emacs).

This recommendation is wrong, I believe.  It seems based on the idea that
`raise-frame' should change the focus, whereas that's not the purpose of
raise-frame.  If you look at the docstring, you'll see that raise-frame
should really not do anything more than call XRaiseWindow:

   Bring frame to the front, so it occludes any frames it overlaps.

I.e. the "raise" is only meant to make the frame more visible, not to give
it focus.

OTOH, it seems pretty clear to me now that we should un-obsolete focus-frame
and implement it with _NET_ACTIVE_WINDOW.

> If some version of Metacity hangs, it is no fault of Emacs and should be
> handeled as a Metacity bug.

Of course.  And if raise-frame makes the icon blink in the dock rather than
raising the frame, it's not a bug either: it's a Metacity (mis)feature.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]