emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: [gmane.emacs.help] Re: raise frame no go


From: Jan Djärv
Subject: Re: [gmane.emacs.help] Re: raise frame no go
Date: Fri, 05 Jan 2007 11:08:19 +0100
User-agent: Thunderbird 1.5.0.9 (Macintosh/20061207)



Leo skrev:
* Jan Djärv (2007-01-04 12:42 +0100) said:
  ^^^^^^^^^
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.

Havoc Pennington from Redhat has commented on this bug¹:

"I don't know if it's the problem, but the timestamp sent by that
Emacs code is gibberish, which could break something even if it isn't
the issue here.  (Assuming I understand the Emacs code.)

I don't believe raise-frame is intended to unconditionally work in
metacity, btw. This is legitimate window manager behavior and no spec
requires that the WM unconditionally honors a raise request."


I've added to this bug:

Emacs first sent timestamp 0, but metacity complained about that, so we tried
something else.  The timestamp is not clearly defined in the extended window
manager hints specification.

Note that Emacs in the current CVS (which will be released soon) does not send
_NET_ACTVATE_WINDOW (the code is commented out) as some Metacity version hanged
when we did that.

So currently there is only a call to XRaiseWindow/XFlush.

Is there a way to make Metacity raise windows or shall Emacs just document the
fact that Metacity does not honor XRaiseWindow?


        Jan D.





reply via email to

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