Re: raise frame no go

Re: raise frame no go

[Jan Djärv]

Eli Zaretskii skrev:
>> Date: Thu, 04 Jan 2007 12:42:19 +0100
>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>> Cc: emacs-pretest-bug@gnu.org
>>
>> 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).  If
some version of Metacity hangs, it is no fault of Emacs and should be handeled
as a Metacity bug.

On the other hand, it is late in the game (pretest-wise) and maybe a note in
etc/PROBLEMS is good enough for the release.

Comments?

	Jan D.

Re: raise frame no go

[Richard Stallman]

    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).  If
    some version of Metacity hangs, it is no fault of Emacs and should be handeled
    as a Metacity bug.

    On the other hand, it is late in the game (pretest-wise) and maybe a note in
    etc/PROBLEMS is good enough for the release.

    Comments?

Could you make a note to install the code with a proper timestamp
after the release?

Re: raise frame no go

[Jan Djärv]

Richard Stallman skrev:
>     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).  If
>     some version of Metacity hangs, it is no fault of Emacs and should be handeled
>     as a Metacity bug.
> 
>     On the other hand, it is late in the game (pretest-wise) and maybe a note in
>     etc/PROBLEMS is good enough for the release.
> 
>     Comments?
> 
> Could you make a note to install the code with a proper timestamp
> after the release?

Yes.

	Jan D.

Re: raise frame no go

[Stefan Monnier]

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

Re: raise frame no go

[Mathias Dahl]

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

I just wanted to add to the discussion that Metacity indeed seems to
be buggy. Yesterday I downloaded and compiled a small program called
`xwit' that could "pop" a windo to front. Guess what, the same
behaviour as I get with `raise-frame' in Emacs.

A pity as I am reluctant to change my window manager in Gnome.

Re: raise frame no go

[Mathias Dahl]

"Mathias Dahl" <mathias.dahl@gmail.com> writes:

> I just wanted to add to the discussion that Metacity indeed seems to
> be buggy. Yesterday I downloaded and compiled a small program called
> `xwit' that could "pop" a windo to front. Guess what, the same
> behaviour as I get with `raise-frame' in Emacs.
>
> A pity as I am reluctant to change my window manager in Gnome.

I have now found a work around to my problem. I am building a kind of
command launcher (something similar to this:
http://pyqe.sourceforge.net/) in Emacs and my problem was that I could
not get Emacs to bring the frame where I ask the user for input to the
top. 

To solve my problem I downloaded and compiled a small program called
"devilspie" (http://www.burtonini.com/blog/computers/devilspie). This
tool lies in the background and "listens" for windows that opens, and
in my case I configured it to execute the "focus" action whenever a
certain window created from Emacs opens (my little command launcher
creates a frame with a special name).

Of course, if Metacity and Emacs would play along more nicely I would
not need this extra hack, but as it solves my problem it is no longer
really a problem for me. At least not right now.

Re: raise frame no go

[Jan Djärv]

Stefan Monnier skrev:

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

Agreed, but maybe we should rename focus-frame then, as _NET_ACTIVE_WINDOW 
does more that just focus (i.e. raises also)?

	Jan D.

Re: raise frame no go

[Stefan Monnier]

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

> Agreed, but maybe we should rename focus-frame then, as _NET_ACTIVE_WINDOW
> does more than just focus (i.e. raises also)?

Are you sure it necessarily does a raise also?  Isn't that up to the
window-manager?


        Stefan

Re: raise frame no go

[Jan Djärv]

Stefan Monnier skrev:
>>> OTOH, it seems pretty clear to me now that we should un-obsolete focus-frame
>>> and implement it with _NET_ACTIVE_WINDOW.
> 
>> Agreed, but maybe we should rename focus-frame then, as _NET_ACTIVE_WINDOW
>> does more than just focus (i.e. raises also)?
> 
> Are you sure it necessarily does a raise also?  Isn't that up to the
> window-manager?

The specification doesn't say, so you are right, it is up to the WM.  But all 
WM:s I've seen (KDE, Metacity and Xfwm4) also raises the window to the top.

	Jan D.

Re: raise frame no go

[Stefan Monnier]

>>>> OTOH, it seems pretty clear to me now that we should un-obsolete
>>>> focus-frame and implement it with _NET_ACTIVE_WINDOW.
>> 
>>> Agreed, but maybe we should rename focus-frame then, as _NET_ACTIVE_WINDOW
>>> does more than just focus (i.e. raises also)?
>> 
>> Are you sure it necessarily does a raise also?  Isn't that up to the
>> window-manager?

> The specification doesn't say, so you are right, it is up to the WM.
> But all WM:s I've seen (KDE, Metacity and Xfwm4) also raises the window to
> the top.

Even when using "focus follows mouse"?


        Stefan

Re: raise frame no go

[Jan Djärv]

Stefan Monnier skrev:
>>>>> OTOH, it seems pretty clear to me now that we should un-obsolete
>>>>> focus-frame and implement it with _NET_ACTIVE_WINDOW.
>>>> Agreed, but maybe we should rename focus-frame then, as _NET_ACTIVE_WINDOW
>>>> does more than just focus (i.e. raises also)?
>>> Are you sure it necessarily does a raise also?  Isn't that up to the
>>> window-manager?
> 
>> The specification doesn't say, so you are right, it is up to the WM.
>> But all WM:s I've seen (KDE, Metacity and Xfwm4) also raises the window to
>> the top.
> 
> Even when using "focus follows mouse"?

That is what I use.  However, I can get focused, unraised frames with 
metacity, so focus-frame is more logical.

	Jan D.

Re: raise frame no go

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
>>> The specification doesn't say, so you are right, it is up to the WM.
>>> But all WM:s I've seen (KDE, Metacity and Xfwm4) also raises the
>>> window to the top.
>>
>> Even when using "focus follows mouse"?
>
> That is what I use.  However, I can get focused, unraised frames with
> metacity, so focus-frame is more logical.

I use metacity with f-f-m, and it doesn't raise frames if they get the
focus because of mouse-movement (though I admit metacity is generally
rather overly intrusive in it's actions).

-miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: raise frame no go

[Chris Moore]

Miles Bader <miles@gnu.org> writes:

> I use metacity with f-f-m, and it doesn't raise frames if they get the
> focus because of mouse-movement

It's a user option whether to raise the frames or not.

In Debian it's under:

  Desktop >
   Preferences >
    Windows >
     Window Selection >
      [x] Select windows when the mouse moves over them >
       [x] Raise selected windows after an interval

Re: raise frame no go

[Jan Djärv]

Miles Bader skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>> The specification doesn't say, so you are right, it is up to the WM.
>>>> But all WM:s I've seen (KDE, Metacity and Xfwm4) also raises the
>>>> window to the top.
>>> Even when using "focus follows mouse"?
>> That is what I use.  However, I can get focused, unraised frames with
>> metacity, so focus-frame is more logical.
> 
> I use metacity with f-f-m, and it doesn't raise frames if they get the
> focus because of mouse-movement (though I admit metacity is generally
> rather overly intrusive in it's actions).

There is an auto_raise config option you can set with gconf-editor.  It is off 
by default.

	Jan D.

Re: raise frame no go

[Leo]

On 2007-01-06 12:32 +0000, Jan Djärv wrote:
> Eli Zaretskii skrev:
>>> Date: Thu, 04 Jan 2007 12:42:19 +0100
>>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>>> Cc: emacs-pretest-bug@gnu.org
>
>>>
>>> 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).  If
> some version of Metacity hangs, it is no fault of Emacs and should be handeled
> as a Metacity bug.
>
> On the other hand, it is late in the game (pretest-wise) and maybe a note in
> etc/PROBLEMS is good enough for the release.
>
> Comments?
>
> 	Jan D.

Has this been fixed?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: raise frame no go

[Jan Djärv]

Leo skrev:
> On 2007-01-06 12:32 +0000, Jan Djärv wrote:
>> Eli Zaretskii skrev:
>>>> Date: Thu, 04 Jan 2007 12:42:19 +0100
>>>> From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <jan.h.d@swipnet.se>
>>>> Cc: emacs-pretest-bug@gnu.org
>>>> 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).  If
>> some version of Metacity hangs, it is no fault of Emacs and should be handeled
>> as a Metacity bug.
>>
>> On the other hand, it is late in the game (pretest-wise) and maybe a note in
>> etc/PROBLEMS is good enough for the release.
>>
>> Comments?
>>
>> 	Jan D.
> 
> Has this been fixed?
> 

raise-frame does not do _NET_ACTIVE_WINDOW, but x-focus-frame does.  It would 
be trivial to add, but the latest discussion indicated that people didn't want 
that.  I.e. raise-frame should just do that, raise.  Focus should stay where 
it was.  But for metacity, there is no way to do that.

	Jan D.

Re: raise frame no go

[Leo]

On 2007-09-24 06:53 +0100, Jan Djärv wrote:
>>>> 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).  If
>>> some version of Metacity hangs, it is no fault of Emacs and should be handeled
>>> as a Metacity bug.
>>>
>>> On the other hand, it is late in the game (pretest-wise) and maybe a note in
>>> etc/PROBLEMS is good enough for the release.
>>>
>>> Comments?
>>>
>>> 	Jan D.
>>
>> Has this been fixed?
>>
>
> raise-frame does not do _NET_ACTIVE_WINDOW, but x-focus-frame does.
> It would be trivial to add, but the latest discussion indicated that
> people didn't want that.  I.e. raise-frame should just do that,
> raise.  Focus should stay where it was.  But for metacity, there is
> no way to do that.
>
> 	Jan D.

I will just forget  this bug. Thanks, Jan.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: raise frame no go

[Mathias Dahl]

Leo <sdl.web@gmail.com> writes:

> I want to use emacsclient to bring Emacs frame to the front. I tried
> several functions including raise-frame, x-focus-frame etc, but none
> of them worked. All they do is causing the Emacs frame to flash in
> the taskbar. Any ideas?
>
> This is tested in Gnome 2.16 in Fedora 6.
> Emacs 23: 20061218.

I just wanted to mention that I have the same problem. Running CVS
Emacs as of 2007-01-1 under Mandriva GNU/Linux, using GNOME with its
Metacity window manager. What I do is this:

 $ emacsclient -e "(my-function)"

and my-function is:

(defun my-function ()
 (select-frame-set-input-focus (selected-frame)))

(well, of course it does more than that but...)

Up until today I haven't played with emacsclient under GNU/Linux. I
have just used gnuclient & friends under w32. I am currently coding a
small command/url/hatever launcher in Emacs, and the current behavior
is quite frustrating (when Emacs is not the topmost window).

I see this code in xterm.c:

XTframe_raise_lower (f, raise_flag)
     FRAME_PTR f;
     int raise_flag;
{
  if (raise_flag)
    {
      /* The following code is needed for `raise-frame' to work on
         some versions of metacity; see Window Manager
         Specification/Extended Window Manager Hints at
         http://freedesktop.org/wiki/Standards_2fwm_2dspec

         However, on other versions (metacity 2.17.2-1.fc7), it
         reportedly causes hangs when resizing frames.  */

      /* Lisp_Object frame;
         const char *atom = "_NET_ACTIVE_WINDOW"; */

      x_raise_frame (f);

      /* XSETFRAME (frame, f);
         Fx_send_client_event (frame, make_number (0), frame,
                            make_unibyte_string (atom, strlen (atom)),
                            make_number (32),
                            Fcons (make_number (1),
                                   Fcons (make_number (time (NULL) * 1000),
                                   Qnil))); */
    }
  else
    x_lower_frame (f);
}

Is is that piece of code that fails? My version of metaciy is 2.16.1.

/Mathias

Re: raise frame no go

[Leo]

* Mathias Dahl (2007-01-04 02:34 +0100) said:
  ^^^^^^^^^^^^
> Leo <sdl.web@gmail.com> writes:
>
>> I want to use emacsclient to bring Emacs frame to the front. I tried
>> several functions including raise-frame, x-focus-frame etc, but none
>> of them worked. All they do is causing the Emacs frame to flash in
>> the taskbar. Any ideas?
>>
>> This is tested in Gnome 2.16 in Fedora 6.
>> Emacs 23: 20061218.
>
> I just wanted to mention that I have the same problem. Running CVS
> Emacs as of 2007-01-1 under Mandriva GNU/Linux, using GNOME with its
> Metacity window manager. What I do is this:
>
>  $ emacsclient -e "(my-function)"
>
> and my-function is:
>
> (defun my-function ()
>  (select-frame-set-input-focus (selected-frame)))
>
> (well, of course it does more than that but...)
>
> Up until today I haven't played with emacsclient under GNU/Linux. I
> have just used gnuclient & friends under w32. I am currently coding a
> small command/url/hatever launcher in Emacs, and the current behavior
> is quite frustrating (when Emacs is not the topmost window).
>
> I see this code in xterm.c:
>
> XTframe_raise_lower (f, raise_flag)
>      FRAME_PTR f;
>      int raise_flag;
> {
>   if (raise_flag)
>     {
>       /* The following code is needed for `raise-frame' to work on
>          some versions of metacity; see Window Manager
>          Specification/Extended Window Manager Hints at
>          http://freedesktop.org/wiki/Standards_2fwm_2dspec
>
>          However, on other versions (metacity 2.17.2-1.fc7), it
>          reportedly causes hangs when resizing frames.  */
>
>       /* Lisp_Object frame;
>          const char *atom = "_NET_ACTIVE_WINDOW"; */
>
>       x_raise_frame (f);
>
>       /* XSETFRAME (frame, f);
>          Fx_send_client_event (frame, make_number (0), frame,
>                             make_unibyte_string (atom, strlen (atom)),
>                             make_number (32),
>                             Fcons (make_number (1),
>                                    Fcons (make_number (time (NULL) * 1000),
>                                    Qnil))); */
>     }
>   else
>     x_lower_frame (f);
> }
>
> Is is that piece of code that fails? My version of metaciy is 2.16.1.
>
> /Mathias

Thank you for confirming this bug. I have forwarded to pretest-bugs
list.

Xref: news.gmane.org gmane.emacs.pretest.bugs:16379
Archived-At: <http://permalink.gmane.org/gmane.emacs.pretest.bugs/16379>

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

raise frame no go

[Leo]

Hi there,

I want to use emacsclient to bring Emacs frame to the front. I tried
several functions including raise-frame, x-focus-frame etc, but none
of them worked. All they do is causing the Emacs frame to flash in the
taskbar. Any ideas?

This is tested in Gnome 2.16 in Fedora 6.
Emacs 23: 20061218.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: raise frame no go

[Juanma Barranquero]

On 12/21/06, Leo <sdl.web@gmail.com> wrote:

> I want to use emacsclient to bring Emacs frame to the front. I tried
> several functions including raise-frame, x-focus-frame etc, but none
> of them worked.

I suppose you have `server-raise-frame' set to t (the default), and
are using something like:

  emacsclient --eval "(raise-frame)"

> This is tested in Gnome 2.16 in Fedora 6.

Must be something with your window manager...

> Emacs 23: 20061218.

Have you tried with the CVS HEAD version (Emacs 22.0.92 right now)?

                    /L/e/k/t/u

Re: raise frame no go

[Leo]

* Juanma Barranquero (2006-12-21 02:17 +0100) said:
  ^^^^^^^^^^^^^^^^^^
> On 12/21/06, Leo <sdl.web@gmail.com> wrote:
>
>> I want to use emacsclient to bring Emacs frame to the front. I tried
>> several functions including raise-frame, x-focus-frame etc, but none
>> of them worked.
>
> I suppose you have `server-raise-frame' set to t (the default), 

Yes.

> and are using something like:
>
>  emacsclient --eval "(raise-frame)"

Yes.

>
>> This is tested in Gnome 2.16 in Fedora 6.
>
> Must be something with your window manager...

It is the standard default window manager metacity. How does that
raise-frame work for Emacs with GTK+?

>
>> Emacs 23: 20061218.
>
> Have you tried with the CVS HEAD version (Emacs 22.0.92 right now)?

No. But I suspect it will also happen in 22.0.92.

>
>                    /L/e/k/t/u

Thank you for your help, Juanma.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)