Re: raise-frame doesn't work in Fedora Core 4

Re: raise-frame doesn't work in Fedora Core 4

[Johan Bockgård]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I have only the knowledge that Fedora Core 4 uses the metacity
> window manager, sorry.

Indeed `raise-frame' does not work for me in Metacity 2.10.0 (under
Ubuntu).

-- 
Johan Bockgård

raise-frame doesn't work in Fedora Core 4

[Kenichi Handa]

I've just got a report saying that the problem reported here:

http://www.archivum.info/emacs-devel@gnu.org/2005-06/msg01570.html

is not yet fixed.

The contents is this:

>>>>> In the emacs-pretest-bug list, Katsumi Yamaoka wrote:

> I did them in the Fedora Core 4 platform.  Since `raise-frame'
> does nothing in this platform, I'm trying to advise it to be
> replaced with `delete-frame' and `make-frame' as follows:

That `raise-frame' didn't work was a life-and-death problem for
me.  For instance, I couldn't make the Emacs frame (which was
existing but was lowered behind the other frames) pop to the
front using `C-x 5 b'.

Now I realized I can use the program called `wmctrl'[1] to solve
the problem.  Here's an new advice:

(defadvice raise-frame (after make-it-work (&optional frame) activate)
  "Make it work."
  (call-process
   "wmctrl" nil nil nil "-i" "-R"
   (frame-parameter (or frame (selected-frame)) 'outer-window-id)))

It's enough for me, though `wmctrl' does the overkill; `raise-frame'
doesn't always put the input focus on the frame as far as I know,
but `wmctrl' behaves like `select-frame-set-input-focus'.  Anyway,
it suggests that the function that `wmctrl' provides can be
incorporated into Emacs, doesn't it?  I would very much appreciate
someone achieving it.  I have only the knowledge that Fedora Core 4
uses the metacity window manager, sorry.

[1] http://sweb.cz/tripie/utils/wmctrl/


---
Kenichi Handa
handa@m17n.org

Re: raise-frame doesn't work in Fedora Core 4

[Katsumi Yamaoka]

Thanks Handa-san for following this up.

>>>>> In <E1GerXw-00068h-00@etlken> Kenichi Handa wrote:

> I've just got a report saying that the problem reported here:

> http://www.archivum.info/emacs-devel@gnu.org/2005-06/msg01570.html

> is not yet fixed.

> The contents is this:

>> I did them in the Fedora Core 4 platform.  Since `raise-frame'
>> does nothing in this platform,...

It does nothing also in Fedora Core 5.

Masatake YAMATO once tried to fix this and offered a patch to me
on 9 Sep 2005.  I tried it with Emacs CVS then and confirmed it
enabled `raise-frame' to perform.  I would very much appreciate
someone looking into it.  Here it is:

*** xterm.c	Sun Aug 28 04:13:33 +0900	1.873
--- xterm.c	Fri Sep 09 02:33:55 +0900	
***************
*** 8492,8497 ****
--- 8492,8524 ----
    if (f->async_visible)
      {
        BLOCK_INPUT;
+ 
+       {
+ 	/* See _NET_ACTIVE_WINDOW in
+ 	   http://freedesktop.org/wiki/Standards_2fwm_2dspec */
+ 	XEvent event;
+ 
+ 	event.xclient.type = ClientMessage;
+ 	event.xclient.serial = 0;
+ 	event.xclient.send_event = True;
+ 
+ 	event.xclient.message_type = XInternAtom(FRAME_X_DISPLAY (f), 
+ 						 "_NET_ACTIVE_WINDOW", 
+ 						 False);
+ 	event.xclient.window = FRAME_OUTER_WINDOW (f);
+ 	event.xclient.format = 32;
+ 	event.xclient.data.l[0] = 1; /* source indication */
+ 	event.xclient.data.l[1] = 0; /* timestamp */
+ 	event.xclient.data.l[2] = 0; /* requestor's currently active window */
+ 	event.xclient.data.l[3] = event.xclient.data.l[4] = 0;
+ 
+ 	XSendEvent(FRAME_X_DISPLAY (f), 
+ 		   DefaultRootWindow (FRAME_X_DISPLAY (f)), 
+ 		   False, 
+ 		   SubstructureRedirectMask | SubstructureNotifyMask,
+ 		   &event);
+       }
+ 
        XRaiseWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f));
        XFlush (FRAME_X_DISPLAY (f));
        UNBLOCK_INPUT;

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Katsumi Yamaoka skrev:
> Thanks Handa-san for following this up.
> 
>>>>>> In <E1GerXw-00068h-00@etlken> Kenichi Handa wrote:
> 
>> I've just got a report saying that the problem reported here:
> 
>> http://www.archivum.info/emacs-devel@gnu.org/2005-06/msg01570.html
> 
>> is not yet fixed.
> 
>> The contents is this:
> 
>>> I did them in the Fedora Core 4 platform.  Since `raise-frame'
>>> does nothing in this platform,...
> 
> It does nothing also in Fedora Core 5.
> 
> Masatake YAMATO once tried to fix this and offered a patch to me
> on 9 Sep 2005.  I tried it with Emacs CVS then and confirmed it
> enabled `raise-frame' to perform.  I would very much appreciate
> someone looking into it.  Here it is:
> 
> *** xterm.c	Sun Aug 28 04:13:33 +0900	1.873
> --- xterm.c	Fri Sep 09 02:33:55 +0900	
> ***************
> *** 8492,8497 ****
> --- 8492,8524 ----
>     if (f->async_visible)
>       {
>         BLOCK_INPUT;
> + 
> +       {
> + 	/* See _NET_ACTIVE_WINDOW in
> + 	   http://freedesktop.org/wiki/Standards_2fwm_2dspec */
> + 	XEvent event;
> + 
> + 	event.xclient.type = ClientMessage;
> + 	event.xclient.serial = 0;
> + 	event.xclient.send_event = True;
> + 
> + 	event.xclient.message_type = XInternAtom(FRAME_X_DISPLAY (f), 
> + 						 "_NET_ACTIVE_WINDOW", 
> + 						 False);
> + 	event.xclient.window = FRAME_OUTER_WINDOW (f);
> + 	event.xclient.format = 32;
> + 	event.xclient.data.l[0] = 1; /* source indication */
> + 	event.xclient.data.l[1] = 0; /* timestamp */
> + 	event.xclient.data.l[2] = 0; /* requestor's currently active window */

I think we must fill this in with the X window of the frame that is raised.  I 
don't think it does the right thing if many frames are open.

There is alot in this spec Emacs doesn't do, we have to review it after the 
release.  But I guess this patch is OK, if active window is added.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Stefan Monnier]

> + 	/* See _NET_ACTIVE_WINDOW in
> + 	   http://freedesktop.org/wiki/Standards_2fwm_2dspec */
> + 	XEvent event;
> + 
> + 	event.xclient.type = ClientMessage;
> + 	event.xclient.serial = 0;
> + 	event.xclient.send_event = True;
> + 
> + 	event.xclient.message_type = XInternAtom(FRAME_X_DISPLAY (f), 
> + 						 "_NET_ACTIVE_WINDOW", 
> + 						 False);
> + 	event.xclient.window = FRAME_OUTER_WINDOW (f);
> + 	event.xclient.format = 32;
> + 	event.xclient.data.l[0] = 1; /* source indication */
> + 	event.xclient.data.l[1] = 0; /* timestamp */
> + 	event.xclient.data.l[2] = 0; /* requestor's currently active window */
> + 	event.xclient.data.l[3] = event.xclient.data.l[4] = 0;
> + 
> + 	XSendEvent(FRAME_X_DISPLAY (f), 
> + 		   DefaultRootWindow (FRAME_X_DISPLAY (f)), 
> + 		   False, 
> + 		   SubstructureRedirectMask | SubstructureNotifyMask,
> + 		   &event);
> +       }
> + 
>         XRaiseWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f));
>         XFlush (FRAME_X_DISPLAY (f));
>         UNBLOCK_INPUT;

Is there some documented rationale for this wm-spec thingy?
I mean, why on earth should the window-manager need more than "XRaiseWindow"
to figure out that the window should be brought on top?


        Stefan

Re: raise-frame doesn't work in Fedora Core 4

[Jan D.]

Stefan Monnier skrev:

> Is there some documented rationale for this wm-spec thingy?
> I mean, why on earth should the window-manager need more than "XRaiseWindow"
> to figure out that the window should be brought on top?

Activate doesn't have to mean raise.  It usually mean uniconify, focus and 
possibly raise if the WM manager wants it.  If you have several workspaces, 
you can have different active windows in each one of them.  Here is the (very 
brief) rationale from freedesktop:

   Rationale: XSetInputFocus is not sufficient, since the window may be
   hidden on another virtual desktop ( in that case XSetInputFocus
   fails with a BadWindow error )

But I'm not sure exactly why this is needed.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Stefan Monnier]

>> Is there some documented rationale for this wm-spec thingy?
>> I mean, why on earth should the window-manager need more than "XRaiseWindow"
>> to figure out that the window should be brought on top?

> Activate doesn't have to mean raise.  It usually mean uniconify, focus and
> possibly raise if the WM manager wants it.  If you have several workspaces,
> you can have different active windows in each one of them.  Here is the
> (very brief) rationale from freedesktop:

>   Rationale: XSetInputFocus is not sufficient, since the window may be
>   hidden on another virtual desktop ( in that case XSetInputFocus
>   fails with a BadWindow error )

> But I'm not sure exactly why this is needed.

I don't understand: AFAICT the OP's problem is that `raise-frame' does not
actually raise the frame.  But `raise-frame' calls XRaiseWindow, which seems
like it should raise the frame, don't you think?
XSetInputFocus seems unrelated (especially since `raise-frame' doesn't call
it AFAIK).

In other words, to me it seems that if `raise-frame' requires this
_NET_ACTIVE_WINDOW footwork to work, it's a bug either in the WM or in the
wm-spec: `XRaiseWindow' should do just what it says, i.e. raise the window.
But maybe there's a rationale for this, so it's just a misfeature needed for
some odd reason.  In that case I'd be interested to hear what's the reason
(and if the reason has to do with input-focus, I'll need more info to
understand what's the relationship with raise-frame).


        Stefan

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    Now I realized I can use the program called `wmctrl'[1] to solve
    the problem.  Here's an new advice:

    (defadvice raise-frame (after make-it-work (&optional frame) activate)
      "Make it work."
      (call-process
       "wmctrl" nil nil nil "-i" "-R"
       (frame-parameter (or frame (selected-frame)) 'outer-window-id)))

That is an ugly solution.  How does the wmctrl program actually do
this?

      I have only the knowledge that Fedora Core 4
    uses the metacity window manager, sorry.

Does this use of wmctrl work correctly with other window managers?

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    Masatake YAMATO once tried to fix this and offered a patch to me
    on 9 Sep 2005.

It looks like perhaps that patch does, directly, what wmctrl does.
Could someone check?

Re: raise-frame doesn't work in Fedora Core 4

[Masatake YAMATO]

> Is there some documented rationale for this wm-spec thingy?
> I mean, why on earth should the window-manager need more than "XRaiseWindow"
> to figure out that the window should be brought on top?

I couldn't find the answer for this question. Therefore 
I didn't submit the patch here by myself.

I'm still interesting this bug. People who meet this
bug, could you tell me the window manager you are using and emacs
bulid-time configuration about GUI toolkit: gtk+, athena, lucid or
motif. 

I think I don't have enough to submit new patch before releasing
the new version.

(
 People who can read Japanese, do C-s XRaiseWindow in  

       https://www.codeblog.org/blog/jet/200601.html

 Yamaoka-san, I'm sorry that I could not keep my word.
)

Masatake

Re: raise-frame doesn't work in Fedora Core 4

[Katsumi Yamaoka]

>>>>> In <20061101.125007.59471538.jet@gyve.org>
>>>>>	Masatake YAMATO wrote:

> (
>  People who can read Japanese, do C-s XRaiseWindow in

>        https://www.codeblog.org/blog/jet/200601.html

>  Yamaoka-san, I'm sorry that I could not keep my word.
> )

Thank you very much for the work.  I've put the copy of your
diary page as

http://www.jpl.org/tmp/200601.html

so that non-Japanese people can read it with the aid of the web
translator.  To use the Excite translator for example, visit

http://www.excite.co.jp/world/english/web/

, put the url in the URL: window, check the bullet of the right
side (there are two bullet under the URL: window), and push the
submit button which is at the right side of the URL: window.

Regards,

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Stefan Monnier skrev:
needed.
> 
> I don't understand: AFAICT the OP's problem is that `raise-frame' does not
> actually raise the frame.  But `raise-frame' calls XRaiseWindow, which seems
> like it should raise the frame, don't you think?
> XSetInputFocus seems unrelated (especially since `raise-frame' doesn't call
> it AFAIK).
> 
> In other words, to me it seems that if `raise-frame' requires this
> _NET_ACTIVE_WINDOW footwork to work, it's a bug either in the WM or in the
> wm-spec: `XRaiseWindow' should do just what it says, i.e. raise the window.
> But maybe there's a rationale for this, so it's just a misfeature needed for
> some odd reason.  In that case I'd be interested to hear what's the reason
> (and if the reason has to do with input-focus, I'll need more info to
> understand what's the relationship with raise-frame).

I agree, XRaiseWindow should do just that.

The rationale I've seen is the one I sent.  It is actually from a draft of the 
spec, newer versions don't have any rationale at all.  It is a pity 
freedesktop specifies all this new stuff without giving any clue whatsoever as 
what it is for.  On the other hand, it may just be another instance of 
"metacity does strange things".  It would not be the first time.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Richard Stallman skrev:
>     Now I realized I can use the program called `wmctrl'[1] to solve
>     the problem.  Here's an new advice:
> 
>     (defadvice raise-frame (after make-it-work (&optional frame) activate)
>       "Make it work."
>       (call-process
>        "wmctrl" nil nil nil "-i" "-R"
>        (frame-parameter (or frame (selected-frame)) 'outer-window-id)))
> 
> That is an ugly solution.  How does the wmctrl program actually do
> this?

It figures out the current desktop (i.e. if you have more than one 
workspace/desktop) by inspecting the property _NET_WM_DESKTOP or 
_WIN_WORKSPACE on the root window.  It then switches the window to the current 
desktop by sending a client message _NET_CURRENT_DESKTOP.  Finally it 
activates the window by sending the client message _NET_ACTIVE_WINDOW.

So it does more than the patch sent erlier in this thread.

> 
>       I have only the knowledge that Fedora Core 4
>     uses the metacity window manager, sorry.
> 
> Does this use of wmctrl work correctly with other window managers?

It works with window managers that understand and comply with the newest 
freedesktop Window Manager Specification 
(http://freedesktop.org/wiki/Standards_2fwm_2dspec), i.e. Metacity (Gnome), 
KWin (KDE), xfwm4 (xfce) and other newer window managers.  There is a list on 
the web page.  Certainly not with older VM:s like twm and mwm.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Richard Stallman skrev:
>     Masatake YAMATO once tried to fix this and offered a patch to me
>     on 9 Sep 2005.
> 
> It looks like perhaps that patch does, directly, what wmctrl does.
> Could someone check?

As I said in another message, wmctrl does more (i.e. moves the window to the 
current desktop/workspace).  But after that, it is identical.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Stefan Monnier]

>     Masatake YAMATO once tried to fix this and offered a patch to me
>     on 9 Sep 2005.

> It looks like perhaps that patch does, directly, what wmctrl does.
> Could someone check?

In either case, I think we should first make sure this is not a bug in the
window manager rather than in Emacs.  To me at least, it sounds like a plain
bug in the window-manager.


        Stefan

Re: raise-frame doesn't work in Fedora Core 4

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>   Rationale: XSetInputFocus is not sufficient, since the window may be
>>   hidden on another virtual desktop ( in that case XSetInputFocus
>>   fails with a BadWindow error )
>
> I don't understand: AFAICT the OP's problem is that `raise-frame' does not
> actually raise the frame.  But `raise-frame' calls XRaiseWindow, which seems
> like it should raise the frame, don't you think?
> XSetInputFocus seems unrelated (especially since `raise-frame' doesn't call
> it AFAIK).
>
> In other words, to me it seems that if `raise-frame' requires this
> _NET_ACTIVE_WINDOW footwork to work, it's a bug either in the WM or in the
> wm-spec: `XRaiseWindow' should do just what it says, i.e. raise the window.
> But maybe there's a rationale for this, so it's just a misfeature needed for
> some odd reason.  In that case I'd be interested to hear what's the reason
> (and if the reason has to do with input-focus, I'll need more info to
> understand what's the relationship with raise-frame).

If you really want to know the answer, the logical thing is to ask at
wm-spec-list@gnome.org (to post to that list you need to subscribe at
wm-spec-list-request@gnome.org, or subscribe to the no-traffic list
post-only@gnome.org).  If you want to summarize the situation and ask
the folks there, that'd be great.

(Though my money is on "misfeature needed for some odd reason"; I
think we should just apply the patch if it demonstrably works,
especially since it shouldn't have any harmful effects.)

Re: raise-frame doesn't work in Fedora Core 4

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> (and if the reason has to do with input-focus, I'll need more info
>> to understand what's the relationship with raise-frame).
>
> If you really want to know the answer, the logical thing is to ask
> at wm-spec-list@gnome.org (to post to that list you need to
> subscribe at wm-spec-list-request@gnome.org, or subscribe to the
> no-traffic list post-only@gnome.org).  If you want to summarize the
> situation and ask the folks there, that'd be great.
>
> (Though my money is on "misfeature needed for some odd reason"; I
> think we should just apply the patch if it demonstrably works,
> especially since it shouldn't have any harmful effects.)

Yup.  Emacs central is just not the place where we want window manager
bugs tested and reported.  It's better for our reputation and nerves
if we just pass the buck.  It is a lesson I keep getting as a project
manager.  You don't get points for insisting that another program
should follow its specs when nobody else does.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    It figures out the current desktop (i.e. if you have more than one 
    workspace/desktop) by inspecting the property _NET_WM_DESKTOP or 
    _WIN_WORKSPACE on the root window.  It then switches the window to the current 
    desktop by sending a client message _NET_CURRENT_DESKTOP.  Finally it 
    activates the window by sending the client message _NET_ACTIVE_WINDOW.

What part of this is really right to do, here?
Is it right to move the window to the current desktop?
It seems strange to me that raise-frame would do that.

Would it be hard to code this in C?

    > Does this use of wmctrl work correctly with other window managers?

    It works with window managers that understand and comply with the newest 
    freedesktop Window Manager Specification 
    (http://freedesktop.org/wiki/Standards_2fwm_2dspec), i.e. Metacity (Gnome), 
    KWin (KDE), xfwm4 (xfce) and other newer window managers.  There is a list on 
    the web page.  Certainly not with older VM:s like twm and mwm.

What happens if you do this (via wmctrl or directly) and you're using
an older wm?  Does it do any harm?

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    In either case, I think we should first make sure this is not a bug in the
    window manager rather than in Emacs.  To me at least, it sounds like a plain
    bug in the window-manager.

Can we find an Xpert who is in a position to say?

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Richard Stallman skrev:
>     It figures out the current desktop (i.e. if you have more than one 
>     workspace/desktop) by inspecting the property _NET_WM_DESKTOP or 
>     _WIN_WORKSPACE on the root window.  It then switches the window to the current 
>     desktop by sending a client message _NET_CURRENT_DESKTOP.  Finally it 
>     activates the window by sending the client message _NET_ACTIVE_WINDOW.
> 
> What part of this is really right to do, here?

I think sending the _NET_ACTIVE_WINDOW is correct here according to the new 
specification.

> Is it right to move the window to the current desktop?

It depends on how we want raise-frame to behave.  Do we want Emacs to switch 
the frame to the current desktop or not?  To not switch is the current 
implementation so if we want to change I suggest next release.

> It seems strange to me that raise-frame would do that.
> 
> Would it be hard to code this in C?

No, it is simple.  It is actually doable from lisp also (with an X11 enabled 
Emacs).  The lisp drag-and-drop code for example sends client messages all the 
time.

> 
>     > Does this use of wmctrl work correctly with other window managers?
> 
>     It works with window managers that understand and comply with the newest 
>     freedesktop Window Manager Specification 
>     (http://freedesktop.org/wiki/Standards_2fwm_2dspec), i.e. Metacity (Gnome), 
>     KWin (KDE), xfwm4 (xfce) and other newer window managers.  There is a list on 
>     the web page.  Certainly not with older VM:s like twm and mwm.
> 
> What happens if you do this (via wmctrl or directly) and you're using
> an older wm?  Does it do any harm?

No, it becomes a noop.  The client message gets sent to the root window but 
since nobody (i.e. the window manager) isn't listening for it, nothing more 
happens.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Richard Stallman skrev:
>     In either case, I think we should first make sure this is not a bug in the
>     window manager rather than in Emacs.  To me at least, it sounds like a plain
>     bug in the window-manager.
> 
> Can we find an Xpert who is in a position to say?
> 

Not claiming to be an Xpert, but IMHO the behaviour is a bit surprising.  If 
you follow ICCCAM it does not say a WM may intercept XRaiseWindow.  But on the 
other hand, it does not say a WM can't do that either.

The new spec on the other hand, do say a WM may choose to ignore 
XRaiseRequests.  It says that to really get it raised, one should use 
_NET_RESTACK_WINDOW.

A side note, _NET_ACTIVATE_WINDOW does more that XRaiseWindow.  If your window 
is on another workspace/desktop, XRaiseWindow does nothing. 
_NET_ACTIVATE_WINDOW on the other hand (at least with Gnome/Metacity), 
switches to that desktop/workspace and then does what XRaiseWindow does.
In contrast to what wmctrl -R does, it moves the window to the current 
desktop/workspace and then raises it.

Additionally, there are new states for windows besides 
Normal/Withdrawn/Iconified.  There are shaded windows (only the title bar is 
shown) also.  _NET_ACTIVATE_WINDOW works with these as well.

I think XRaiseWindow does not work with windows that are on 
desktops/workspaces that aren't the current one, so I guess some WM:s choose 
to ignore all XRaiseWindow requests just to avoid trouble.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Richard Stallman skrev:
>
> I think sending the _NET_ACTIVE_WINDOW is correct here according to
> the new specification.
>
>> Is it right to move the window to the current desktop?
>
> It depends on how we want raise-frame to behave.  Do we want Emacs
> to switch the frame to the current desktop or not?  To not switch is
> the current implementation so if we want to change I suggest next
> release.

If the frame was iconified previously, switching it to the current
desktop would warrant a user-configurable option, I think (defaulting
to "off").  If it was _not_ iconified previously, I think it would be
very wrong to change the overall window configuration by moving frame
around.

>> What happens if you do this (via wmctrl or directly) and you're
>> using an older wm?  Does it do any harm?
>
> No, it becomes a noop.  The client message gets sent to the root
> window but since nobody (i.e. the window manager) isn't listening
> for it, nothing more happens.

Sounds like something we should likely do then.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: raise-frame doesn't work in Fedora Core 4

[Stefan Monnier]

> I think XRaiseWindow does not work with windows that are on
> desktops/workspaces that aren't the current one,

It does work: it changes the stacking order so that next time you visit
a workspace where that window is visible, it will be in front of
the others.

> so I guess some WM:s choose to ignore all XRaiseWindow requests just to
> avoid trouble.

That's a bug.


        Stefan

Re: raise-frame doesn't work in Fedora Core 4

[Stefan Monnier]

>>> (and if the reason has to do with input-focus, I'll need more info
>>> to understand what's the relationship with raise-frame).
>> 
>> If you really want to know the answer, the logical thing is to ask
>> at wm-spec-list@gnome.org (to post to that list you need to
>> subscribe at wm-spec-list-request@gnome.org, or subscribe to the
>> no-traffic list post-only@gnome.org).  If you want to summarize the
>> situation and ask the folks there, that'd be great.
>> 
>> (Though my money is on "misfeature needed for some odd reason"; I
>> think we should just apply the patch if it demonstrably works,
>> especially since it shouldn't have any harmful effects.)

Maybe not "harmful", but it does change the semantics since it fiddles
with focus.

> Yup.  Emacs central is just not the place where we want window manager
> bugs tested and reported.  It's better for our reputation and nerves
> if we just pass the buck.  It is a lesson I keep getting as a project
> manager.  You don't get points for insisting that another program
> should follow its specs when nobody else does.

Agreed.  I'm not opposing the patch, I just want to make sure that we pass
along the fact that there's a bug, and the patch should include a comment to
the effect that it's a workaround for a bug in window-manager <foo>, version
<bar>.


        Stefan

Re: raise-frame doesn't work in Fedora Core 4

[Chip Coldwell]

On Tue, 31 Oct 2006, Kenichi Handa wrote:
>
>>>>>> In the emacs-pretest-bug list, Katsumi Yamaoka wrote:
>
>> I did them in the Fedora Core 4 platform.  Since `raise-frame'
>> does nothing in this platform, I'm trying to advise it to be
>> replaced with `delete-frame' and `make-frame' as follows:
>
> That `raise-frame' didn't work was a life-and-death problem for
> me.  For instance, I couldn't make the Emacs frame (which was
> existing but was lowered behind the other frames) pop to the
> front using `C-x 5 b'.

I haven't been able to locate a bug for this in bugzilla.redhat.com.
I'm coming late to this thread -- did you try the emacs-22.0.90
pretest?  M-x raise-frame works for me on Fedora Core 5 with this
version.  I've built some test rpms for FC-5 and FC-6 and put them
here:

http://people.redhat.com/coldwell/bugs/emacs/176171/

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426

Re: raise-frame doesn't work in Fedora Core 4

[Chip Coldwell]

On Thu, 2 Nov 2006, Chip Coldwell wrote:
>
> I haven't been able to locate a bug for this in bugzilla.redhat.com.
> I'm coming late to this thread -- did you try the emacs-22.0.90
> pretest?

Now that I have had a chance to digest this thread, I realize that
this was a stupid question.  Please ignore.

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    Yup.  Emacs central is just not the place where we want window manager
    bugs tested and reported.  It's better for our reputation and nerves
    if we just pass the buck.  It is a lesson I keep getting as a project
    manager.  You don't get points for insisting that another program
    should follow its specs when nobody else does.

However, it does make a difference to us whether this patch
would be wrong for other window managers.

Re: raise-frame doesn't work in Fedora Core 4

[Richard Stallman]

    > What happens if you do this (via wmctrl or directly) and you're using
    > an older wm?  Does it do any harm?

    No, it becomes a noop.  The client message gets sent to the root window but 
    since nobody (i.e. the window manager) isn't listening for it, nothing more 
    happens.

Then by all means we should make it send the proper messages.

    It depends on how we want raise-frame to behave.  Do we want Emacs to switch 
    the frame to the current desktop or not?  To not switch is the current 
    implementation so if we want to change I suggest next release.

I don't think Emacs should move the window to a different desktop
merely because the code thinks it should be raised.  That's would be
too drastic, an interference with the user's window layout.

However, selecting the desktop which contains that window,
as you've said _NET_ACTIVATE_WINDOW does, is good.

Re: raise-frame doesn't work in Fedora Core 4

[Jan D.]

Stefan Monnier skrev:
>> I think XRaiseWindow does not work with windows that are on
>> desktops/workspaces that aren't the current one,
> 
> It does work: it changes the stacking order so that next time you visit
> a workspace where that window is visible, it will be in front of
> the others.
> 
>> so I guess some WM:s choose to ignore all XRaiseWindow requests just to
>> avoid trouble.
> 
> That's a bug.

I agree fully, but given the project (metacity) and its former willingness to
respond to "old style" WM interactions (i.e. not in the new spec), I doubt it
is useful to raise a bug.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Jan D.]

Jan Djärv skrev:

> A side note, _NET_ACTIVATE_WINDOW does more that XRaiseWindow.  If your
> window is on another workspace/desktop, XRaiseWindow does nothing.
> _NET_ACTIVATE_WINDOW on the other hand (at least with Gnome/Metacity),
> switches to that desktop/workspace and then does what XRaiseWindow does.
> In contrast to what wmctrl -R does, it moves the window to the current
> desktop/workspace and then raises it.
> 
> Additionally, there are new states for windows besides
> Normal/Withdrawn/Iconified.  There are shaded windows (only the title
> bar is shown) also.  _NET_ACTIVATE_WINDOW works with these as well.
> 

Again I spoke too soon.  Metacity does unshade, but xfwm4 does not.  metacity
also moves the window to the current desktop if it isn't there.  So the
behaviour is (as always) WM dependent.

	Jan D.

Re: raise-frame doesn't work in Fedora Core 4

[Jan D.]

Katsumi Yamaoka skrev:

> Masatake YAMATO once tried to fix this and offered a patch to me
> on 9 Sep 2005.  I tried it with Emacs CVS then and confirmed it
> enabled `raise-frame' to perform.  I would very much appreciate
> someone looking into it.  Here it is:

I've checked in a slightly different patch that does the same thing.  Please
try it.

	Jan D.

> 
> *** xterm.c	Sun Aug 28 04:13:33 +0900	1.873
> --- xterm.c	Fri Sep 09 02:33:55 +0900	
> ***************
> *** 8492,8497 ****
> --- 8492,8524 ----
>     if (f->async_visible)
>       {
>         BLOCK_INPUT;
> + 
> +       {
> + 	/* See _NET_ACTIVE_WINDOW in
> + 	   http://freedesktop.org/wiki/Standards_2fwm_2dspec */
> + 	XEvent event;
> + 
> + 	event.xclient.type = ClientMessage;
> + 	event.xclient.serial = 0;
> + 	event.xclient.send_event = True;
> + 
> + 	event.xclient.message_type = XInternAtom(FRAME_X_DISPLAY (f), 
> + 						 "_NET_ACTIVE_WINDOW", 
> + 						 False);
> + 	event.xclient.window = FRAME_OUTER_WINDOW (f);
> + 	event.xclient.format = 32;
> + 	event.xclient.data.l[0] = 1; /* source indication */
> + 	event.xclient.data.l[1] = 0; /* timestamp */
> + 	event.xclient.data.l[2] = 0; /* requestor's currently active window */
> + 	event.xclient.data.l[3] = event.xclient.data.l[4] = 0;
> + 
> + 	XSendEvent(FRAME_X_DISPLAY (f), 
> + 		   DefaultRootWindow (FRAME_X_DISPLAY (f)), 
> + 		   False, 
> + 		   SubstructureRedirectMask | SubstructureNotifyMask,
> + 		   &event);
> +       }
> + 
>         XRaiseWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f));
>         XFlush (FRAME_X_DISPLAY (f));
>         UNBLOCK_INPUT;
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: raise-frame doesn't work in Fedora Core 4

[Katsumi Yamaoka]

>>>>> In <454B04F9.6030806@swipnet.se> Jan D. wrote:

> I've checked in a slightly different patch that does the same thing.  Please
> try it.

I'm sorry for the late reply.  Now it works great.  Thanks a lot.

Re: raise-frame doesn't work in Fedora Core 4

[Katsumi Yamaoka]

Hi again,

I recalled this bug has not been solved yet.

>>>>> Katsumi Yamaoka wrote:

> For instance, I couldn't make the Emacs frame (which was
> existing but was lowered behind the other frames) pop to the
> front using `C-x 5 b'.

I'm now in Fedora 7 that I update everyday.  It runs the metacity
window manager and the problem seems to happen only with LUCID
(not GTK) Emacs on it.  The concrete way to reproduce this bug is:

1. Start Emacs with the -Q option.
2. Type `C-x 5 b *Messages* RET'.
   Now there are two Emacs frames as follows:
+-------------+
|             |
|     +--------------+
|     |              |
|  *sc|              |
+-----|              |
      |  *Messages*  |
      +--------------+
3. Select the *scratch* frame by the mouse.
+-------------+
|             |
|             |------+
|             |      |
|  *scratch*  |      |
+-------------+      |
      |  *Messages*  |
      +--------------+
4. Type `C-x 5 b *Messages* RET' in the *scratch* frame.
   But the *Messages* frame is neither raised nor focused.

Jan Djärv wrote to me a half year ago in:
http://www.mail-archive.com/emacs-pretest-bug@gnu.org/msg11474.html

> See http://bugzilla.gnome.org/show_bug.cgi?id=392889.  My last comment
> was that we may enable _NET_ACTIVATE_WINDOW, but it has been postponed
> to after the release.

The problem I brought up then seems to have been solved now.
However, it seems to be likely different from this.  The whole
thread that contain this article is:

http://news.gmane.org/group/gmane.emacs.devel/thread=61471/force_load=t

Regards,

Re: raise-frame doesn't work in Fedora Core 4

[Jan Djärv]

Katsumi Yamaoka skrev:
> Hi again,
> 
> I recalled this bug has not been solved yet.
> 
>>>>>> Katsumi Yamaoka wrote:
> 
>> For instance, I couldn't make the Emacs frame (which was
>> existing but was lowered behind the other frames) pop to the
>> front using `C-x 5 b'.
> 
> I'm now in Fedora 7 that I update everyday.  It runs the metacity
> window manager and the problem seems to happen only with LUCID
> (not GTK) Emacs on it.  The concrete way to reproduce this bug is:
> 
> 1. Start Emacs with the -Q option.
> 2. Type `C-x 5 b *Messages* RET'.
>    Now there are two Emacs frames as follows:
> +-------------+
> |             |
> |     +--------------+
> |     |              |
> |  *sc|              |
> +-----|              |
>       |  *Messages*  |
>       +--------------+
> 3. Select the *scratch* frame by the mouse.
> +-------------+
> |             |
> |             |------+
> |             |      |
> |  *scratch*  |      |
> +-------------+      |
>       |  *Messages*  |
>       +--------------+
> 4. Type `C-x 5 b *Messages* RET' in the *scratch* frame.
>    But the *Messages* frame is neither raised nor focused.

Metacity ignores most focus and raise requests.  It does honor
_NET_ACTIVE_WINDOW.  However, Emacs only does _NET_ACTIVE_WINDOW for
x-focus-frame, not raise-frame.  Why Gtk+ differs I don't know.  Probably it
sets some property behind the scenes that Xt does not.

	Jan D.