Subject: Re: FVWM: 'Next' window based on coordinates?

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 25 Sep 2002 16:50:20 +0000

On 25 Sep 2002 16:30:00 +0200, Dominik Vogt wrote:
> 
> On Wed, Sep 25, 2002 at 09:03:05AM -0500, Victor Eijkhout wrote:
> > >On Tue, Sep 24, 2002 at 06:16:35AM -0500, Victor Eijkhout wrote:
> > >> How do I cycle through windows so that Next takes the one with next
> > >> highest x coordinate?
> > >
> > >Try the "Direction" command.
> > 
> > Cool. I missed that one reading the man pages.
> > 
> > Btw, I think it would also make sense to base the choice of the 
> > window not on the midpoint but on the edge, for instance left edge if 
> > you specify Direction East. And maybe look at the lowerleft corner if 
> > Direction NorthEast, &c.
> 
> The potential tuning possibilities are endless.  I could easily
> think of a dozen different scoring algorithms or even a custom
> shell script that calculates the score and is called for each
> window.

I feel we often enhance the core and don't enhance/create modules.
This is really the task for a module FvwmCirculate. I would even move
the Direction command to this module along with other scoring
algorithms. FvwmCirculate may setup the compatible syntax if needed:

  AddToFunc Direction
  + I SendToModule FvwmCirculate Direction $*

I may write FvwmCirculate if people need it (but not now).
The circulation may be done either by scripting:

  SendToModule FvwmCirculate Next ScoreFunc $win1->y > $win2->y

or, another example:

  SendToModule FvwmCirculate Prev CondFunc $win->desk == 2

or hardcoding rules:

  SendToModule FvwmCirculate Direction down top-y

Regards,
Mikhael.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 25 Sep 2002 20:12:48 +0200

>   SendToModule FvwmCirculate Direction down top-y

But all that functionality *must* be in the core.  Modules work in
parallel to the core which is fine for some functionality, but
totally unacceptable for the scripting language.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 25 Sep 2002 19:12:29 +0000

> totally unacceptable for the scripting language.

This is not correct. Try for example this:

  AddToFunc PerlEval I SendToModule FvwmPerl eval $*
  Module FvwmPerl

  # beep test 1
  PerlEval $a = "xterm"; command("All ($a) Iconify on")
  Next (xterm, !Iconic) Beep

  # beep test 2
  PerlEval if ($[page.nx] < 10) { command("Schedule 5000 123123 Beep") }
  Deschedule 123123

This does not beep, because PerlEval is fully synchronous.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 26 Sep 2002 16:04:33 +0200

> This does not beep, because PerlEval is fully synchronous.

Well, then what do we need a new module for if the scripting
language can already do this?  And by the way, the performance of
the synchronized module interface is horrible.  It's even horrible
in the non synchronized case, as FvwmEvent has proven time and
again.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]