[jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

Can anyone reproduce this?  The test case involves windowmaker,
which I do not have on my machine.

------- Start of forwarded message -------
From: jonathan.the-seng1@etud.univ-ubs.fr
X-Authentication-Warning: homae.univ-ubs.fr: nobody set sender to jonathan.the-seng1@etud.univ-ubs.fr using -f
Date: Thu, 21 Mar 2002 12:57:26 +0100
To: rms@gnu.org
Subject: bug emacs
X-Originating-IP: 193.50.242.18
X-MIME-Autoconverted: from 8bit to quoted-printable by mercure.univ-ubs.fr id MAA28971
X-MIME-Autoconverted: from quoted-printable to 8bit by pele.santafe.edu id g2LBvfa09247


Bonjour,
J'utlise emacs 20.5.1, de la distribution :
	Red Hat Linux release 6.2 (Zoot)
	Kernel 2.2.14-5.0 on an i686.
Mon window manager est Window Maker 0.61.1 (au cas ou cela est utile)

Je pense avoir trouvé un bug:
Dans window maker, j ai deux emacs qui sont lances
	quand je click sur l'item buffer, files, tools ... dans la barre de menu
	un menu déroulant s'ouvre, et en le laissant afficher, losrque je change 		de
bureau il reste afficher. voila.
En fait, c'est un ami qui m'a dit que je pouvait vous informer de ceci, c'est
vrai que c'est un probleme mineur, mais apperement vous corriger quand meme.
Donc j'espere que ca ne vous prendra pas trop de temps, et que vous trouverez
sans probleme,
(Peut etre que le probleme vient de windowmaker et pas de emacs)
Cordialement jonathan.



- --------------------------------------------------------------------------------
Université de Bretagne sud                               http://www.univ-ubs.fr/
------- End of forwarded message -------

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Robert Marshall]

[cc'ing to rms in case you don't read in the ng]

On Sun, 24 Mar 2002, rms@gnu.org wrote:

> Can anyone reproduce this?  The test case involves windowmaker,
> which I do not have on my machine.
> 
> From: jonathan.the-seng1@etud.univ-ubs.fr
> Subject: bug emacs
> To: rms@gnu.org
> Date: Thu, 21 Mar 2002 12:57:26 +0100
> 
> 
> Bonjour,
> J'utlise emacs 20.5.1, de la distribution :
> 	Red Hat Linux release 6.2 (Zoot)
> 	Kernel 2.2.14-5.0 on an i686.
> Mon window manager est Window Maker 0.61.1 (au cas ou cela est
> utile)
> 
> Je pense avoir trouvé un bug:
> Dans window maker, j ai deux emacs qui sont lances
> 	quand je click sur l'item buffer, files, tools ... dans la
> 	barre de menu un menu déroulant s'ouvre, et en le laissant
> 	afficher, losrque je change de
> bureau il reste afficher. voila.

Yes I can reproduce this (with 0.80 of windowmaker an emacs 21.1),
though it would appear that nothing else I've tried allows you to
change workspace whilst a menu is active.  Emacs allows a workspace
change and the menu stays posted,other apps appear to detect that you
shouldn't be changing w/s in this context


R
-- 
All the slow fish of ignorance
turned toward  the sound
-- Chase Twichell

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

      Emacs allows a workspace
    change and the menu stays posted,other apps appear to detect that you
    shouldn't be changing w/s in this context

I have four questions:

1. What is a workspace?

2. What is the meaning of a workspace change?

3. What action does the user perform to request a workspace change?

4. What do these other apps actually *do* when you take an action
   that tries to perform a workspace change and they think "you shouldn't"
   do that?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Robert Marshall]

On Mon, 25 Mar 2002, Richard Stallman wrote:
>       Emacs allows a workspace
>     change and the menu stays posted,other apps appear to detect
>     that you shouldn't be changing w/s in this context
> 
> I have four questions:
> 
> 1. What is a workspace?
> 

A virtual desktop - a means of having a particular set of applications
in one screen whilst keeping others on another without having to
iconise

> 2. What is the meaning of a workspace change?
> 

Swapping between virtual desktops

> 3. What action does the user perform to request a workspace change?
> 

Ctrl-Alt-leftarrow, Ctrl-Alt-rightarrow, Alt-<workspacenumber>, I
think it's also user configurable (I'm not at my m/c running
windowMaker). You can also click on the 'clip' - a windowmaker icon to
change workspace though I see that the mouse event causes the
windowmanager/emacs problem to not happen - the menu disappears when
the clip is clicked.

I'm not sure which other window managers allow a change of workspace
by use of (only) the keyboard - does bbkeys and blackbox allow this,
surely enlightenment must offer this?

> 4. What do these other apps actually *do* when you take an action
>    that tries to perform a workspace change and they think "you
>    shouldn't" do that?

Nothing at all!

R
-- 
Robert Marshall

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Ralf Fassel]

* "Robert Marshall" <robert@chezmarshall.freeserve.co.uk>
| I'm not sure which other window managers allow a change of workspace
| by use of (only) the keyboard -

fvwm does.  I'm not fluent in french, so I'm not sure I did understand
what the original problem was, but when using emacs' menu-bar, I can
pop-up a menu, then change the workspace via keyboard-shortcuts, and
the menu stays posted on the new workspace while the emacs frame is
gone.  The menu takes effect if I select some entry.

It seems to me that is a question of global grab vs. application
grab.

Other programs seem to issue a global grab while posting the menu, so
the keyboard shortcuts don't reach the window manager, and no Desktop
switching takes place until the menu is unposted.

R'

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    It seems to me that is a question of global grab vs. application
    grab.

    Other programs seem to issue a global grab while posting the menu, so
    the keyboard shortcuts don't reach the window manager, and no Desktop
    switching takes place until the menu is unposted.

It might be good for Emacs to do this--do you know how?

How come the toolkit doesn't do this for all apps if this is the best
thing to do?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Ralf Fassel]

* Richard Stallman
|     Other programs seem to issue a global grab while posting the menu, so
|     the keyboard shortcuts don't reach the window manager, and no Desktop
|     switching takes place until the menu is unposted.
| 
| It might be good for Emacs to do this--do you know how?

A quick grep for `grab' in the emacs source tree points to:

*** emacs-21.2/lwlib/xlwmenu.c~	Mon Apr 30 16:34:54 2001
--- emacs-21.2/lwlib/xlwmenu.c	Wed Mar 27 09:42:04 2002
***************
*** 2121,2127 ****
  		  | PointerMotionHintMask
  		  | ButtonReleaseMask
  		  | ButtonPressMask),
! 		 GrabModeAsync, GrabModeAsync, None,
  		 mw->menu.cursor_shape,
  		 event->time);
    pointer_grabbed = 1;
--- 2121,2127 ----
  		  | PointerMotionHintMask
  		  | ButtonReleaseMask
  		  | ButtonPressMask),
! 		 GrabModeAsync, GrabModeSync, None,
  		 mw->menu.cursor_shape,
  		 event->time);
    pointer_grabbed = 1;

Diff finished at Wed Mar 27 09:45:38

But there seems to be more work necessary, as the patch above only
queues the keys, so that they are processed when the menu is released.
I would expect them to be flushed in some way.

Someone more with more knowledge about X11 should have a look at how
this is usually done.

R'

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stefan Monnier]

>>>>> "Ralf" == Ralf Fassel <ralfixx@gmx.de> writes:
> *** emacs-21.2/lwlib/xlwmenu.c~	Mon Apr 30 16:34:54 2001
> --- emacs-21.2/lwlib/xlwmenu.c	Wed Mar 27 09:42:04 2002
> ***************
> *** 2121,2127 ****
>   		  | PointerMotionHintMask
>   		  | ButtonReleaseMask
>   		  | ButtonPressMask),
> ! 		 GrabModeAsync, GrabModeAsync, None,
mw-> menu.cursor_shape,
event-> time);
>     pointer_grabbed = 1;
> --- 2121,2127 ----
>   		  | PointerMotionHintMask
>   		  | ButtonReleaseMask
>   		  | ButtonPressMask),
> ! 		 GrabModeAsync, GrabModeSync, None,
mw-> menu.cursor_shape,
event-> time);
>     pointer_grabbed = 1;

I think this patch only works around the bug.  The bug is that the
menu does not get unmapped when the main window is unmapped.

Grabbing more is bad in case of crashes so I'd rather avoid doing it
especially since it doesn't seem to be better from a user perspective
(what's the point of preventing the user from sending keyboard commands
to his window-manager) ?


	Stefan

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    I think this patch only works around the bug.  The bug is that the
    menu does not get unmapped when the main window is unmapped.

Switching to a different workspace doesn't unmap the Emacs window,
does it?

    Grabbing more is bad in case of crashes so I'd rather avoid doing it
    especially since it doesn't seem to be better from a user perspective

If it is consistent with most apps, that is a big advantage for the
user.  Consistency is very important in user interfaces.  Grabbing can
be a problem in crashes, indeed.  We could have a flag to disable it
which we who debug Emacs could always set.

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stefan Monnier]

>     I think this patch only works around the bug.  The bug is that the
>     menu does not get unmapped when the main window is unmapped.
> 
> Switching to a different workspace doesn't unmap the Emacs window,
> does it?

It generally does (unless the Emacs window is present in both workspaces).


	Stefan

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    > Switching to a different workspace doesn't unmap the Emacs window,
    > does it?

    It generally does (unless the Emacs window is present in both workspaces).

I am amazed.  I would have expected different workspaces to be implemented
as different screens.

Anyway, if switching workspaces works by unmapping all the windows,
why doesn't it unmap the menu along with all the other windows on the
old workspace?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stefan Monnier]

>     > Switching to a different workspace doesn't unmap the Emacs window,
>     > does it?
> 
>     It generally does (unless the Emacs window is present in both workspaces).
> 
> I am amazed.  I would have expected different workspaces to be implemented
> as different screens.

I don't think you can create new screens without changing the Xserver's
configuration, which a window manager is not in a position to do.

> Anyway, if switching workspaces works by unmapping all the windows,
> why doesn't it unmap the menu along with all the other windows on the
> old workspace?

The menu is not managed by the window-manager (which is one of the
reasons why it doesn't have a border).


	Stefan

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    > Anyway, if switching workspaces works by unmapping all the windows,
    > why doesn't it unmap the menu along with all the other windows on the
    > old workspace?

    The menu is not managed by the window-manager (which is one of the
    reasons why it doesn't have a border).

Ok.  Do you know how to DTRT?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    Someone more with more knowledge about X11 should have a look at how
    this is usually done.

Is there anyone out there who would like to work on this?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stephen Berman]

Ralf Fassel <ralfixx@gmx.de> writes:

> * "Robert Marshall" <robert@chezmarshall.freeserve.co.uk>
> | I'm not sure which other window managers allow a change of workspace
> | by use of (only) the keyboard -
> 
> fvwm does.  I'm not fluent in french, so I'm not sure I did understand
> what the original problem was, but when using emacs' menu-bar, I can
> pop-up a menu, then change the workspace via keyboard-shortcuts, and
> the menu stays posted on the new workspace while the emacs frame is
> gone.  The menu takes effect if I select some entry.
> 
> It seems to me that is a question of global grab vs. application
> grab.
> 
> Other programs seem to issue a global grab while posting the menu, so
> the keyboard shortcuts don't reach the window manager, and no Desktop
> switching takes place until the menu is unposted.

As another datapoint, I have observed a different but perhaps related
problem with Emacs (both 21.2 and 20.7) under KDE (2.2.2): when I
click on a menu bar label in Emacs and then press `Ctrl-TAB' (the
KDE keyboard shortcut to change the virtual desktop/workspace) while
the Emacs menu is displayed, the keyboard locks up.  I haven't been
able to replicate this behavior with other apps in KDE (they simply
block switching of the desktop, as described above).  On the other
hand, it seems similar to a known KDE bug and has a similar
workaround, i.e., clicking on the border of an active window (see
e.g. bugs.kde.org/db/29/29926.html).

--Steve Berman

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    > 4. What do these other apps actually *do* when you take an action
    >    that tries to perform a workspace change and they think "you
    >    shouldn't" do that?

    Nothing at all!

Does the workspace change that you asked for occur, or does the
app prevent it?

If the app prevents it, can you find out how they prevent it?

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stefan Monnier]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
>       Emacs allows a workspace
>     change and the menu stays posted,other apps appear to detect that you
>     shouldn't be changing w/s in this context
> I have four questions:
> 1. What is a workspace?

You can look at it as "a set of windows" with the ability to switch between
those sets.

> 2. What is the meaning of a workspace change?

It means that the window manager unmaps the currently active set
of windows and maps another set.

Maybe what Emacs should do is to unmap any currently displayed menus
whenever the Emacs frame is unmapped.


	Stefan

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Richard Stallman]

    > 1. What is a workspace?

    You can look at it as "a set of windows" with the ability to switch between
    those sets.

I'd heard the term "virtual desktop" but not the term "workspace" for
this.

Many programs have specific terminology.  It would be useful for
people reporting bugs that involve programs other than Emacs to keep
in mind that the rest of us may not be familiar with those programs
and may not know their special terminology.

    Maybe what Emacs should do is to unmap any currently displayed menus
    whenever the Emacs frame is unmapped.

That could be a reasonable approach (if someone knows how to implement
it).  However, if what most apps do is grab and prevent the
workspace-switching commands from working, probably Emacs should do the
same thing, for consistency's sake.

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Ralf Fassel]

* rms@gnu.org (Richard Stallman)
| However, if what most apps do is grab and prevent the
| workspace-switching commands from working, probably Emacs should do
| the same thing, for consistency's sake.

A quick test of programs at my desktop:

OS IRIX 6.5.9, WM fvwm 2.4.5:
Task: pop up a menu, then try to change desktop via keyboard

Netscape 4.79: global grab, no keyboard events passed to WM, no
               queued key processing after menu is unposted.
SGI Audio Control Panel (apanel): dito
wish/Tk 8.3.4: dito
ddd (Qt toolkit): dito
Xscreensaver-demo (gtk toolkit): dito, plus indicates the keys pressed
        in the menu

Emacs 21.2: keyboard events passed to WM, desktop switch occurs, menu
            stays posted separated from emacs frame
Xemacs 21.4.6: keyboard events passed to WM, desktop switch occurs,
            menu stays posted separated from xemacs frame

R'

Re: [jonathan.the-seng1@etud.univ-ubs.fr: bug emacs]

[Stefan Monnier]

>     > 1. What is a workspace?
> 
>     You can look at it as "a set of windows" with the ability to switch between
>     those sets.
> 
> I'd heard the term "virtual desktop" but not the term "workspace" for
> this.

I think (back in the days when I was choosing my window manager, many
years ago), "virtual desktop" referred to the ability to have a desktop
that's larger than your screen and be able to move in it.
"Workspaces" on the other hand are separate areas (typically screen-sized
but can be larger if combined with virtual desktops).
The two concepts are very similar but have slightly different semantics.

Virtual desktops are pretty much standard in most/all window managers
these days, whereas workspaces are a bit less common (they first
appeared in HP Vue's window manager, I believe, at least that's where
the author of ctwm took the idea).


	Stefan