Subject: FVWM: Next, Prev, Circulate

From: Dan Niles <[email-masked]>
Date: Wed, 24 Apr 1996 13:47:44 -0500

The Next and Prev commands do not seem to work correctly.
I am only able to cycle trough some of my eligable windows using the Next
and Prev commands.  Also, these commands do not seem to circle.  That is
they hit an end and the other one need to be used.

I did not see this in the BUGS file, so I thought I would report it.

Also, the default .fvwmrc had Circulate commands, which do not do anything.

(By the way, I have fvwm 2.0.42)

Dan Niles
[email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: <[email-masked]> (Charles Hines)
Date: Wed, 24 Apr 1996 15:03:34 -0400

>>>>> "Dan" == Dan Niles <[email-masked]> writes:

Dan> The Next and Prev commands do not seem to work correctly.
Dan> I am only able to cycle trough some of my eligable windows using the Next
Dan> and Prev commands.

Do you have 'CirculateSkip' in any Style commands?

Dan> Also, these commands do not seem to circle.  That is they hit an
Dan> end and the other one need to be used.

Known bug, or rather feature.  I've had request to allow them to
circle, and I'll probably add it as an option to Next & Prev
eventually, which you will find reference to in the TO-DO list.

Dan> I did not see this in the BUGS file, so I thought I would report it.

Dan> Also, the default .fvwmrc had Circulate commands, which do not do
Dan> anything.  (By the way, I have fvwm 2.0.42)

Really?  The one I shipped in 2.0.42 doesn't have them in there, so
you must be getting a default .fvwm2rc from somewhere else or reusing
an old 1.xx .fvwmrc.

Chuck

---

From: <[email-masked]> (Charles Hines)
Date: Wed, 24 Apr 1996 15:57:57 -0400

>> Do you have 'CirculateSkip' in any Style commands?

Dan> Nope. I removed all CirculateSkip and CirculateSkipIcon commands
Dan> to test.  Could you send me some sample lines using Next & Prev
Dan> so I can verify that I have the correct syntax.  Specifically,
Dan> one for cycling all windows, and one for cycling all windows on
Dan> this screen.

The included sample system.fvwmrc & new-system.fvwmrc should be able
to help.  Basically, something like:

Key Next         A       SCM     Next [*] Focus
Key Prior        A       SCM     Prev [*] Focus
Key Next         A       CM      Next [!iconic CurrentScreen] Focus
Key Prior        A       CM      Prev [!iconic CurrentScreen] Focus

*should* work just fine.  I use the first two occasionally and haven't
had any problems with them.  I just tried the latter two, and they
seemed to work ok...whoops, I take that back.  It doesn't seem to be
finding all the ones on the current screen, just the ones I've visited
recently...  This may be the problem.  I'll have to look into that.

Dan> (By the way, I am using FvwmAuto and ClickToFocus.  ClickToFocus
Dan> is not in the current documentation. Is SloppyFocus still
Dan> supported?)

Hm...  I didn't think that FvwmAuto worked too well with
ClickToFocus...

SloppyFocus is still supported (as a Style command, like ClickToFocus
and MouseFocus).  I keep updating the docs as I come across missing
stuff.

Chuck

---

From: Dan Niles <[email-masked]>
Date: Thu, 25 Apr 1996 09:11:16 -0500

> recently...  This may be the problem.  I'll have to look into that.

I have narrowed the problem down.  The only windows that get cycled are ones
that have received focus since fvwm2 was started or restarted.   Also, the
order of cycling changes when you use the mouse to give a window focus. I
personally would prefer the order to remain constant and predictable.

> Hm...  I didn't think that FvwmAuto worked too well with

Works fine, great even.  The current version of FvwmAuto raises a
window when a window receives focus, so they work together well. The
only strange thing is that SloppyFocus is in effect even though not
specified.  This is ok because it is how one would expect ClickToFocus
to work: You click on a window to change focus.

Dan

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 25 Apr 1996 10:17:56 -0400

>> recently...  This may be the problem.  I'll have to look into that.

Dan> I have narrowed the problem down.  The only windows that get
Dan> cycled are ones that have received focus since fvwm2 was started
Dan> or restarted.  Also, the order of cycling changes when you use
Dan> the mouse to give a window focus. I personally would prefer the
Dan> order to remain constant and predictable.

Yeah, I'll have to look into this...  It's still not quite right,
although it is better than 1.xx's circulate function.

>> Hm...  I didn't think that FvwmAuto worked too well with

Dan> Works fine, great even.  The current version of FvwmAuto raises a
Dan> window when a window receives focus, so they work together well. The
Dan> only strange thing is that SloppyFocus is in effect even though not
Dan> specified.  This is ok because it is how one would expect ClickToFocus
Dan> to work: You click on a window to change focus.

Actually what I meant was that ClickToFocus should already be raising
the windows when you click in them, without the help of FvwmAuto.

Chuck

---

From: Kai Grossjohann <[email-masked]>
Date: 25 Apr 1996 17:21:09 +0200

>>>>> On Thu, 25 Apr 1996 09:11:16 -0500, Dan Niles <[email-masked]>
>>>>> said:

  Dan> The only windows that get cycled are ones that have received
  Dan> focus since fvwm2 was started or restarted.

It'd be nice if this were fixed.

  Dan> Also, the order of cycling changes when you use the mouse to
  Dan> give a window focus. I personally would prefer the order to
  Dan> remain constant and predictable.

Well, the fact that Next and Prev behave the way they do was one of
the two reasons for me to choose this window manager!  Therefore,
Chuck will lose a happy user if he changes the fact that Next and Prev
dynamically reorder the window list based on which windows have
received focus recently.

I use the Prev command a lot to go the window I was using before.  In
order not to put off Chuck I won't mention that Microsloth Windows
behaves the same way with Alt-TAB and Alt-Shift-TAB ;-}

kai
-- 
Gleep!

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 25 Apr 1996 11:24:36 -0400

>>>>> "Kai" == Kai Grossjohann <[email-masked]> writes:

Kai> It'd be nice if this were fixed.

Kai> Well, the fact that Next and Prev behave the way they do was one of
Kai> the two reasons for me to choose this window manager!  Therefore,
Kai> Chuck will lose a happy user if he changes the fact that Next and Prev
Kai> dynamically reorder the window list based on which windows have
Kai> received focus recently.

I misspoke somewhat.  This aspect of the behavior is correct, but I
think there needs to be a way to get to ALL of the windows as well.
That's really what I would like to add/fix.

And I wouldn't want to loose any happy users...

Kai> I use the Prev command a lot to go the window I was using before.  In
Kai> order not to put off Chuck I won't mention that Microsloth Windows
Kai> behaves the same way with Alt-TAB and Alt-Shift-TAB ;-}

Thanks for not mentioning that.  ;^)

Tchuss,
Chuck

---

From: Dan Niles <[email-masked]>
Date: Thu, 25 Apr 1996 11:37:50 -0500

grossjoh wrote:

[clip]

> behaves the same way with Alt-TAB and Alt-Shift-TAB ;-}

You have a good point. Perhaps an option to allow fixed ordering.  Barring
such an option, I would say that the current method is best. Provided that
the cycling goes around the top (or bottom) instead of dead-ending. 
Microsloth (shudder) also goes around the end.

Dan