Subject: FVWM: focus issue with fvwmtabs

From: Micha Feigin <[email-masked]>
Date: Sun, 18 Jul 2004 21:08:13 +0300

I seem to have a problem with fvwmtabs no catching some focus changes
(or maybe it is layer changes) made by matlab.

I am using matlab with emacs as an editor. Embedding them into fvwmtabs,
when matlab shifts focus to emacs (debug mode or going to an error), I
see emacs going on top (the emacs tab is the one visible), but the tab
shown as active by fvwmtabs is still the matlab one (that is the active
tab according to fvwmtabs is matlab, but the shown tab is emacs).

In order to switch tabs I need to first go to the emacs tab with
fvwmtabs and only then I can switch to other tabs again.

I have no idea where to start looking for the problem on this I'm
afraid. Any hints so I can try to make a fix?
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Scott Smedley <[email-masked]>
Date: Mon, 19 Jul 2004 18:16:50 +1000

> when matlab shifts focus to emacs (debug mode or going to an error)

What do you mean?

> I see emacs going on top (the emacs tab is the one visible), but the tab
> shown as active by fvwmtabs is still the matlab one

For matlab to do this, it would need to do an XMapWindow() on the emacs
window. I've no idea a) how it would know the window id & b) if it
should be allowed to do that.

As matlab isn't free s/w I can't investigate further. Can you reproduce
the problem with another program?

SCoTT. :)

---

From: Micha Feigin <[email-masked]>
Date: Tue, 20 Jul 2004 04:02:33 +0300

> > shown as active by fvwmtabs is still the matlab one

I checked also when not inside fvwmtabs. Emacs will come to the top
when hidden, but the desktop will not change if its not on the same
page. Don't know if it helps.

> should be allowed to do that.

There is some communication between matlab and emacs to allow emacs to
run as the editor. It looks like the command to raise the window is
internal to emacs and is raise-frame. From the emacs help:

raise-frame is an interactive built-in function.
(raise-frame &optional FRAME)

Bring FRAME to the front, so it occludes any frames it overlaps.
If FRAME is invisible, make it visible.
If you don't specify a frame, the selected frame is used.
If Emacs is displaying on an ordinary terminal or some other device which
doesn't support multiple overlapping frames, this function does nothing.

I have no idea how it is implemented (I can try and grep the emacs code
if it will help).

> the problem with another program?

I don't know of any other program that initiates raising windows
automatically like that. Will be happy to try though. Any way to
initiate commands remotely with emacs?

>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.
>

---

From: Dan Espen <[email-masked]>
Date: Mon, 19 Jul 2004 21:15:37 -0400

> initiate commands remotely with emacs?

Assuming XEmacs,
in your .emacs do:

(gnuserv-start)

Then from a command line:

gnudoit '(raise-frame)'

I'm not sure what current versions of emacs need, it's been a while.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Micha Feigin <[email-masked]>
Date: Tue, 20 Jul 2004 18:45:00 +0300

> I'm not sure what current versions of emacs need, it's been a while.

Apparently debian has gnuserv packaged and it works with emacs ;-)

Anyway I tried it and it produces the same behavior.

rxvt and emacs embedded in the same tabber.
>From emacs M-x gnuserv-start
>From rxvt  gnudoit '(raise-frame)'
Now I see the emacs window as the visible one but the active tab is
marked as the rxvt one. Switching tabs changes the tab marked as active
but leaves emacs as the visible window until I switch to the emacs tab,
at which point behavior goes back to normal.

---

From: Scott Smedley <[email-masked]>
Date: Wed, 21 Jul 2004 10:12:31 +1000

> at which point behavior goes back to normal.

That all makes sense now.

FvwmTabs does not currently support windows that map themselves at arbitary
times, but there's no reason why it couldn't. I'll endeavour to implement
it soon. (Might be a while as I'm going on holidays this w/end.)

SCoTT. :)