Subject: FvwmProxy role

From: [email-masked]
Date: Wed, 20 Nov 2002 15:57:53 -0800

For starters, what I'm looking to configure is quite different.
But that's good.  If we can get a couple fairly diverse setups going,
that should hopefully make it better prepared for whatever people will want
to throw at it.

My vision is such:
Hold Alt:
	proxies appear, no iconized or listskip windows
Press mouse buttons on proxies repeatly:
	browse through windows by raising and lowering them
Release Alt:
	proxies go away

Since I have no title bars, Alt also gives me a quick look at what
I've got, and whether my VIM files are modified or not.  Even with
title bars, this would show all the obscured titles too. I'll tap
Alt just for it's own sake.

To me, alt-tab is secondary.  While I'll certainly set it up, it's
not really in my habit.  With my tiny HH keyboard, I can move my mouse
nearly without lifting my wrist.  Alt-tab-tab-tab just takes more time
and attention.

The Config file looks very manacing, but I'll concede that you win on the
ability to use core Next/Prev functions.  Not really because of the code
redundancy issue, but by configurability.  I'll just have to make sure the
ordering is something reasonable (left-to-right?), not seemingly arbitrary
like the creation order.  I'd like to trim it down some.

First of all, I don't think there should be a default FvwmProxySelectFunc.
What if I don't want to raise or I don't want the mouse to move.
Then I have to DestroyFunc and start from scratch.  Undoing defaults
sounds very distasteful.
Can we just have FvwmProxy call FvwmProxyMarkFunc with a special ID
(is 0 used?) when ever Show/Hide/Abort is called?  Then we could drop
those three, at least the default UnsetEnv calls.  We might need something
more in the Circulate function.

The simple properties I added are the same as internal defaults, so we can
dump those.

As for the syntactic sugar, I kinda like

AddToFunc MySelect
+ I WindowId $w Raise
+ I WindowId $w WarpToWindow 50 50

*FvwmProxy: Action  Select  Function MySelect

over an implied function to add to.  Is my recent infatuation with
the Action syntax misplaced?

Referencing the previous email:
2) I don't see WindowListFunc in ConfigFvwmWinList or it's man page.
Not in the man page for FvwmWindowLister either.  I hope that isn't
the convention we intend to follow.

3)  Unless I'm missing something, no one is suggesting overriding
user settings.  I think things like width should have defaults in
the module if no one has set it in any config.  I don't see any good
reason for simple properties in the ConfigProxy file.

4) If the default behavior is to do nothing, then I don't really
see any problem with supplying a cut&paste in the man page.
I'd much prefer that to a config file the naive user may not enen know about.
I really want to trim down the demonstrated config so that it isn't
a big deal.

5) If we agreed on everything, we wouldn't need .rc files at all.
But this is way different than my vision.  For one thing, I usually
have very little exposed root window.  I want to tap a key instead of
waving the mouse around searching for a bit of background.
But I think it'll take more than 2 or 3 of us to determine a sample
of the fvwm community.  If my case is absurd to the majority, I'll
have no problem being a carefully configured odd case, as long as I
actually can configure it.

6) Mouse actions should have defaults.  This is how WinList does it
and it seems to work fine.  Now for FvwmProxy_Circulate, I'm guessing
most people need to cut&paste the keyboard config explicitly if they want
to use Alt-Tab anyhow, so what's two more lines?
Since you have to start from scratch anyhow if you want to remove any
part of the default, I'd much prefer to very clearly spell out the
default in the man page and people can build their own versus manipulating
through additions to something they don't see.  What if the naive user is
assumming that FvwmProxyMarkFunc is a blank placeholder or don't realize
that the AddToFunc doesn't clear the elusive defaults.

7a) Ok, as long as Next order is reasonable and we can make
FvwmProxy_Circulate into something pretty.

7b) Conceptually, yes, but I would prefer following syntax by precendent:

*FvwmProxy: Action Click1 Raise

8) I don't think I added any Module without reading the man page first.
I'd lean towards just the man page.  Now if there's a global .fvwm2rc
that the sysadmin can edit, by all means.  I would be surprised if this
happens much.  I expect two groups.  Either nearly all defaults or tweak
every detail, all on a per-user basis.  Personally, I don't know anyone
using fvwm2 who isn't a compulsive tweaker.  Defaulters probably just stay
with KDE (not that I want to alienate the curious).

-- 
  _
 ( \      _  \    /_ /  _ _  Jason Weber                  (503) 380-7424
  \|(\/)()))  \/\/(-/_)(-/(  Infinite Monkeys Inc.        Aloha, Oregon
  //                         http://www.imonk.com/baboon  [email-masked]
 (/     [email-masked]        [email-masked]

     "Canister contains at least 50% recycled material; 15%
      post-consumer content."
   -- Pringles Fat-Free (side of can)
--
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: Thu, 21 Nov 2002 11:49:21 +0100

> nearly without lifting my wrist.  Alt-tab-tab-tab just takes more time

Yeah, I prefer to use "Alt-cursorkey" with the Direction command
too.  It's much faster and more intuitive.

> ability to use core Next/Prev functions.

Actually, that is why I put this all in the defaults file.  The
normal user should not have to worry about it but can just add his
commands to the predefined functions.  Except the select function
that is.  It is currently just a copy of WindowListFunc.

> Not really because of the code

Then terminate the proxy session with the "Abort" command instead
of "Hide".  

> more in the Circulate function.

The env var must be already set when the Circulate function is
called.  The stored window id is taken as the starting point for
the conditional command.  The env var is used to communicate the
currently hilighted window to fvwm so the circulation commands can
work with it.

> the Action syntax misplaced?

It's just a duplicate of the equivalent

  *FvwmProxy: SelectCommand Function MySelect

we don't need it twice.

> Referencing the previous email:

Please quote the mails you are referring to.  It is very tredious
to cross read two emails.

> the convention we intend to follow.

Too much to doo in too little time.  We document everything, but
not necessarily while we are fiddling with the design.

> user settings.

Mikhael suggested that.

> I think things like width should have defaults in

Right.  The "*FvwmProxy: ..." lines do not need to be in there.

> I really want to trim down the demonstrated config so that it isn't

The point is that the average user should be able to use the
module without worrying about configs at all.  And just think of
the default config file as the built-in default in a separate
file.  The situation is no different if the defaults are hard
coded, except that you then can not change the defaults easily as
a sysadmin.

[snip]

> to use Alt-Tab anyhow, so what's two more lines?

Well, as a user, I would understand what

  key f1 x y someaction

does, but I would not understand why I need

  AddToFunc foobar
  + I SetEnv FvwmProxy_S $w

The latter is not user friendly.

> that the AddToFunc doesn't clear the elusive defaults.

Of course this will all be explained in detail in the man page,
with clear instructions what to do if you want to start from
scratch.  By the way, the naive user can safely assume that
FvwmProxyMarkFunc is an 'empty' placeholder that has some internal
logic to make sure the ...Circulate function can be used.

> FvwmProxy_Circulate into something pretty.

I don't think it needs to be pretty.  Simply explain the interface
in the man page.  It is quite easy to understand.

> with KDE (not that I want to alienate the curious).

Keep in mind that we want to make using fvwm easier in the future.

Bye

Dominik ^_^  ^_^

---

From: Peter McAlpine <[email-masked]>
Date: Thu, 21 Nov 2002 09:21:29 -0500

> 	browse through windows by raising and lowering them
[snip^3]

I gave FvwmProxy a shot... and this config had me running 'KillModule
FvwmProxy' before you can say "emacs". Binding something to the Alt
key makes zero sense to me.

-peter
-- 
Peter McAlpine
[email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Nov 2002 04:04:07 +0000

> too.  It's much faster and more intuitive.

Just a note, several browsers, editors and other programs use
Alt-cursorkeys.

Of course, this can't be important when we want to own the _whole_
Alt button. :-)

>   *FvwmProxy: SelectCommand Function MySelect

Jason wants "Action Select" syntax to be _instead_ of SelectCommand
syntax. For me either one may work.

> not necessarily while we are fiddling with the design.

I will mention that WindowListFunc is used in FvwmWindowLister.

> > 3)  Unless I'm missing something, no one is suggesting overriding

I am not quite sure what does this mean. I would never suggest to override
user settings without an explicit command from a user.

> Right.  The "*FvwmProxy: ..." lines do not need to be in there.

Ohh...

Dominik, let's continue with the same meaning of all our Config* files.
They are examples, so they should include one example "*FvwmProxy: ..."
configuration. If you want to force some file to be executed (although
you should first describe why this is needed at all), name it differently.

> coded, except that you then can not change the defaults easily as

I am a bit disappointed why you still insist on the module defaults to be
defined in a file that uses fvwm functions that should be read on the fvwm
startup. It is so clear to me that this is a plain wrong design.

I am not speaking about missing DestroyFunc in this file, I am not
speaking about this file removed by an accident and a module staying
without defaults. I am speaking about 3 things, each of which would
warrant we don't continue with this bad design.

  1) Loading essential module configuration when fvwm is loaded is not
     different than loading part of IE when Windows is loaded even if a
     user never uses IE, but only Mozilla, Netscape or Opera.
     This may not a very fair comparision, but this is what happens.

  2) By adding several functions as an essential part of the module they
     become the part of the module. Now the question is this. What should
     a user do to change the defaults? To use HideCommand or to change
     FvwmProxyHideFunc? Both are the parts of the module and both are used
     to define the "hide" action.

  3) Suppose a user decided not to use HideCommand and to change
     FvwmProxyHideFunc. Now he does not have any default, he can't revert
     to the default behaviour, because the defaults are not hardcoded.
     The module knows nothing about its own defaults, so it can't restore
     them by a user request.

I already posted a solution to this. There are defaults hardcoded in
FvwmProxy.c, so the following command may restore the default:

  *FvwmProxy: HideCommand

There are no functions that a user should destroy and recreate. Not even
FvwmProxySelectFunc, it's not needed, because unlike WindowListFunc there
is SelectCommand (or Action Select) here. He simply uses, say:

  *FvwmProxy: SelectCommand WindowListFunc $w

If you want several sets of defaults there is an option or a dynamical
command that sets (by a user request) several predefined actions at once.

Actually, I think the design should be even simplier. There is no global
state using SetEnv, the marked window is just stored in the module, then
instead of "FvwmProxy_Circulate Next (CurrentPage)" a user just uses:

  SendToModule FvwmProxy Circulate Next (CurrentPage)

and the module resends "Next (CurrentPage) SendToModule FvwmProxy $$w"
with the marked window context (or null context if no marked window).

Then I don't see a reason to have ShowCommand, HideCommand, AbortCommand
and MarkCommand at all, there is nothing useful to configure here.

[snip]

Regards,
Mikhael.

---

From: [email-masked]
Date: Thu, 21 Nov 2002 21:03:22 -0800

> Then terminate the proxy session with the "Abort" command instead

No, let me rephrase.  Let's say I only wanted Select to raise and I didn't
want it to move the mouse.  Or the other way around.  If I didn't want
anything at all, well yeah, I can abort.  But I might want a subset of the
"suggested" Select plus a little of my own choosing.  Personally, I like
'WarpToWindow 50 50' better than 'WarpToWindow 5p 5p'. In this particular
case, I can just tack it on and you never notice the first one.
But generally, that won't always work, like if I wanted 'don't raise'.

> currently hilighted window to fvwm so the circulation commands can

Hmm, my understanding of fvwm conditionals is pretty much nothing.
So by "can I" I really mean can I.  I'm guessing ...

	AddToFunc FvwmProxy_Circulate
	+ I WindowId $[FvwmProxy_S] $0 $1 FvwmProxy_Mark
	+ I CondCase (Error) $0 $1 FvwmProxy_Mark

means on the given window do $0..., if that fails because the var is undefined,
then do a $0... without any context.

I propose this be modified so that it also checks that the FvwmProxy_S is not
some special case.  Hmm, if I write a windowid of None to fvwm, what do I get
for $w.  If that doesn't fly, we can send it rootwindow since it will never
really get a proxy.  So,

if(id is undefined OR id == rootwindow) do non-specific $0...
else WindowId $[FvwmProxy_S] $0...

In that case we can dump those three functions, right?

>   *FvwmProxy: SelectCommand Function MySelect

No, I meant just one.  I was saying that I liked the Action syntax that
I saw in other modules and thought it was prettier then a lot of
SetThisCommand, SetThatCommand.

> Right.  The "*FvwmProxy: ..." lines do not need to be in there.

Ok, gone.

> coded, except that you then can not change the defaults easily as

For the FvwmProxy_Circulate, I see the point, but I still lean towards
cut&paste over obscurity.

Do you have objection to pulling the Select config out and letting the
user define it all himself, with some manpage guidance?

> The latter is not user friendly.

But are Action Click(1|2|3) defaults ok?
 
> logic to make sure the ...Circulate function can be used.

FvwmProxy_Circulate and FvwmProxyMarkFunc, maybe.  I guess that includes
FvwmProxy_Mark, which is just simplifying FvwmProxy_Circulate.
Would you even mention them in the man page, or just tell people to
define their Select function, mouse actions and key bindings.

The external state env-variable still has me a little agitated.  There's gotta
be a better way to use the real Next (or from the addendum response,
the proposed ScanWindow).

I like the idea to distill off all the functionailty that the core
can supply.  That's good.  But something's still a little amiss.

As for Direction, take three big windows dividing the screen in thirds left
to right.  Add a little small window on the bottom, centered about 2 thirds
to the right.  Doing Direction East from the second big window goes to the
third big window, completely ignoring the little window.  With Next/Prev,
even if Prev was the reverse of Next, creation order tweaked by focus
order is pretty much the appearance of random.

On the Alt key, I'm wondering why Alt-anything is not passed through
if fvwm uses the Alt.  Is it policy that anything fvwm uses is never
passed through but other fvwm bindings can still use alt-something if
Alt is used.  If so, all this should be optional.  There's no logical reason
why if some fvwm module is spying the alt state why any mundane X app
shouldn't be seeing their Alt sequences.  And if there is a conflict, maybe
it's probably better that they both occur and I can say "oops, better fix
that" then to be banging on my keyboard because the menu shortcuts on
my WP never do what the manual says.

TODO, in my view:
Have a revelation on how to use core Next/Prev/ScanWindow without env var
Add ScanWindow to fvwm core
Investigate why Alt blocking occurs in fvwm core, maybe add optionality
Modify man page to use a less intrusive sample config (not mine, it sounds)

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Nov 2002 10:42:51 +0100

[snip]

> I will mention that WindowListFunc is used in FvwmWindowLister.

Off topic:  what are actually the plans for that module?  I
thought we had agreed on *recuding* the number of window listing
modules.  Now it just looks like we get another of these modules
without the internal WindowList going away (?)

> user settings without an explicit command from a user.

You said something about letting FvwmProxy install these defaults
and put a warning in the man page that they are overwritten each
time the module is started.

> you should first describe why this is needed at all), name it differently.

ConfigFvwmDefaults is no example, it is an essential part of fvwm
startup to provide the defaults documented in the man page.
Before this file was added, the lines were hard coded in fvwm.c.
ConfigFvwmProxyDefaults works exactly the same.

> and MarkCommand at all, there is nothing useful to configure here.

Sure, this would all work, and almost nobody would be able to use
FvwmProxy because it can be configured only by experts.  Enough
said, do what you want with the module, I will retire from any
further module design.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Nov 2002 11:07:44 +0100

> But generally, that won't always work, like if I wanted 'don't raise'.

Then you have to do the same you have to do if you don't like the
WindowListFunc default.  Destroy the function and write your own.

> else WindowId $[FvwmProxy_S] $0...

This can only be done by an external program.  Fvwm has no way
to compare strings.

> In that case we can dump those three functions, right?

They are there mostly for completeness.  If any of the FvwmProxy
internal actions is represented by a complex function, all others
should be too.

> SetThisCommand, SetThatCommand.

I see.  I don't care which one is used.

> user define it all himself, with some manpage guidance?

Yes, actually I have strong objections agains forcing the user to
cut-and-paste.  That excludes at least 90% of all users from ever
using that module.  Just consider this:  you install a new program
you want to try and see it you can use it.  But when you start it
for the first time is print out a message:

  The developers of xyw could not agree on a sensible default
  behaviour.  Please follow the instructions in the man page to
  write a configuration file, then run xyz again.

I don't know what you would do, but I would immediately deinstall
the program and forget about it within five minutes.

> But are Action Click(1|2|3) defaults ok?

Sure.

> can supply.  That's good.  But something's still a little amiss.

As Mikhael suggested, it is possible to do without the external
state variable.  But only at the cost of sending twice as many
module messages:

  With SetEnv:

    "Mark xyz" -> module
    "Function FvwmProxyMarkFunc" -> fvwm

  Without SetEnv:

    "Next (currentpage)" -> module
    "Next (currentpage)" -> fvwm
    "Mark xyz" -> module
    "Function FvwmProxyMarkFunc" -> fvwm

As the module interface is extremely slow, I weigh performance
over a nice configuration here.

> Alt is used.  If so, all this should be optional.

Unfortunately, there is no reliable way to pass it.  When you
press a key with a binding, fvwm automatically grabs control of
the keyboard.  This takes away the focus from the application that
had it before.  Many applications refuse to process keyboard input
when they do not have the focus.  You can't do anything about this
in fvwm.

> There's no logical reason

> Investigate why Alt blocking occurs in fvwm core, maybe add optionality

I am perfectly aware why it happens - I just don't know what to do
about it.  The problem is that fvwm needs to grab the keyboard
while waiting for a key release.  Now, when a menu is opened, all
key presses are rerouted to the menu and the main loop never
notices that the key was released.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Nov 2002 12:32:01 +0000

> without the internal WindowList going away (?)

FvwmWindowLister currently does grouping by regular expressions.
It has a configurable format like "%m%n%t%t(+%x+%y) - Desk %d".
It will do submenus optionaly and other configurable things.
I think it may be easily supported. WindowList should not go away.

> time the module is started.

I just said that some private function _FvwmProxyPrivateFunc that should
not be described in the man page may be overwritten if such function is
needed (it is not needed). :)

> ConfigFvwmProxyDefaults works exactly the same.

You are right, sorry, it is already called ConfigFvwmProxyDefaults and not
ConfigFvwmProxy like other example configurations.

> > and the module resends "Next (CurrentPage) SendToModule FvwmProxy Mark $$w"

Actually it may be just "Next (CurrentPage) SendToModule FvwmProxy Mark",
because M_STRING already contains the context window as the first
argument.

> said, do what you want with the module, I will retire from any

In my suggestion there are no *Command options and no functions, just
SelectCommand or as Jason suggested "Action Select".
ConfigFvwmProxyDefaults file is not needed.

Please describe the functionality that would be missing. I don't see any.
Both "FvwmProxy_Circulate Next (CurrentPage)" and "SendToModule FvwmProxy
Circulate Next (CurrentPage)" are equally intuitive (or not intuitive) for
a user.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Nov 2002 14:35:54 +0100

> On 22 Nov 2002 10:42:51 +0100, Dominik Vogt wrote:

[SNIP SNIP SNIP]

> SelectCommand or as Jason suggested "Action Select".

Reducing the number of configurable actions limits flexibility
severely.  When you don't have a "Mark" command, the module
response must be hard coded.  The same is true for any actions
that should be run when the proxies are closed or aborted.

> Circulate Next (CurrentPage)" are equally intuitive (or not intuitive) for

I never said functionality would be missing.  I said inexperienced
users will not be able to run FvwmProxy.  Exactly like they are
not able to run FvwmEvent, FvwmForm, FvwmScript or FvwmButtons.

The config just too complex.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Nov 2002 14:48:47 +0000

> The config just too complex.

In this case I don't think that hardcoding the hide/show/mark/abort
functionality is bad or will reduce any functionality. But maybe I am
missing some usage. This is why I would like you to describe any missing
practical (not theoretical) usage if this configurablity is dropped.

My intend is not to make FvwmProxy harder to use or configure or be less
functional. Quite an opposite.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 22 Nov 2002 10:04:50 -0500

[SNIP SNIP SNIP]
> The config just too complex.

I think FvwmForm is an exception.
The 4 example forms should be easy for any user
to run.  Making minor modifications shouldn't be too hard either.

Creating additional forms is pretty hard, which is probably your
point.  No argument there.

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

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Nov 2002 17:00:57 +0100

> practical (not theoretical) usage if this configurablity is dropped.

Let's assume we have mark, unmark, hide, show, abort and select
commands (note that an unmark action does not exist yet).  Let's
further assume the user wants:

  Alt-Tab:  mark* next window, unmark* last window
  -Alt:  Select currently marked window, close proxies.

  * mark = bring window to the top of the top level layer
    unmark = lower window to default layer

With the predefined functions in ConfigFvwmProxyDefaults (plus
the hypothetical unmark function):

  key tab a m FvwmProxy_Circulate Next (currentpage)
  key -Meta a a SendToModule FvwmProxy Hide
  AddToFunc FvwmProxyMarkFunc
  + I Raise
  + I Layer <some options>
  AddToFunc FvwmProxyUnmarkFunc
  + I Layer <some options>

Note that the user only needs some knowledge about key bindings
(basics) and how to add something to an existing functions (also
basics).  Even a beginner should understand most of the config -
perhaps not the SendToModule part (which may be hidden in another
function FvwmProxy_Hide).

With hard coded defaults:

  key tab a m My_Circulate Next (currentpage)
  key -Meta a a SendToModule FvwmProxy Hide
  *FvwmProxy: MarkCommand Function MyMarkFunc
  *FvwmProxy: UnmarkCommand Function MyUnmarkFunc
  AddToFunc MyMarkFunc
  + I SetEnv FvwmProxy_S $w
  + I Raise
  + I Layer <some options>
  AddToFunc MyUnmarkFunc
  + I Layer <some options>
  AddToFunc My_Mark
  + I SendToModule FvwmProxy mark $w
  AddToFunc My_Circulate
  + I WindowId $[FvwmProxy_S] $0 $1 My_Mark
  + I CondCase (Error) $0 $1 My_Mark

You see the difference?  In the latter case the user has to worry
about the internal communication between fvwm and the module which
makes it very difficult to understand.  Even I get confused by the
complexity.  With that, the user has to learn how to write
complete fvwm functions, configure a module, read the man page and
copy the contents of the default functions into her config file.
At the same time she will hopefully not get confused by all the
abstract stuff from the documentation.

And just imagine what happens when you try to join the _Mark and
the _Circulate functions into a singe one.  I had to split them
because they require no less than *seven* '$' characters before
the 'w'.

Things may become a bit easier without keeping the marked window
id in fvwm, but also slower.

I'd really welcome a way that allows to have a nifty, easy to
understand default configuration and not requiring to enforce the
config at fvwm startup for every user.  It's okay if configuring
the module becomes rather complex when doing tricky things.  The
most inexperienced user should be able to

 - add something to select and mark easily
 - hide and show the proxies without configuring more than a key
   or mouse binding.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Nov 2002 17:13:29 +0000

>  - hide and show the proxies without configuring more than a key

It seems like you don't get or ignore my suggestion. With it your
configuration above is as trivial as:

  Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage)
  Key -Meta A A SendToModule FvwmProxy Hide

This is enough for most of the users.

And if you think it makes sense to do something else (except for
hilightling the proxy) on the "mark", the module may still have 2 options
MarkCommand and UnmarkCommand (that are by default Nop).

  *FvwmProxy: MarkCommand Layer +1
  *FvwmProxy: UnmarkCommand Layer -1

Regards,
Mikhael.

---

From: [email-masked]
Date: Fri, 22 Nov 2002 13:27:59 -0800

>   *FvwmProxy: UnmarkCommand Layer -1

So, this would mean that Circulate implies a Show if not shown.
That's fine by me.  These two lines are easy to explain on the man page.

I really like this how clean this looks.  How slow is "slow" for using two
messages vs one?  I don't want to neglect older HW, for which fvwm lightness
is even more appealing.  Even if each message takes 100ms, we're only going
from one to two.  I remember in another module I was prototyping, I was
streaming tons of move commands, perhaps a dozen for each step of a mouse
drag.  I would naively expect that a couple messages would be less time than
it takes to redraw two proxies.

So does this scenario mean no FvwmProxyDefaults, or is Action Select set
to a secret _FvwmProxyDefault which is not generally appended to, but outright
replaced.  So I might have, for my unpopular config, something like

Key Alt_L       A   N   SendToModule    FvwmProxy   Show
Key -Alt_L      A   A   SendToModule    FvwmProxy   Hide
Key Escape      A   M   SendToModule    FvwmProxy   Abort
Key Tab         A   M   SendToModule    FvwmProxy   Circulate Next (CurrentPage)
Key Tab         A   SM  SendToModule    FvwmProxy   Circulate Prev (CurrentPage)

*FvwmProxy: Action  Select  MySelect

AddToFunc MySelect
+ I WindowId $w Raise

I would probably use a condition more like (AcceptsFocus,CurrentDesk,!Sticky),
but that's just me.  Or I guess that would be CirculateHit, which I'll try.
And I would like to use ScanWindow East South and ScanWindow West North instead
of Next/Prev, given that ScanWindow is approved for inclusion to the core.

The Action syntax gives us a neat little internal table of defaults which
may be the equivalent of

*FvwmProxy: Action  Select  Function _FvwmProxySelectDefault
*FvwmProxy: Action  Mark    Nop
*FvwmProxy: Action  UnMark  Nop
*FvwmProxy: Action  Click1  Raise
*FvwmProxy: Action  Click2  Nop
*FvwmProxy: Action  Click3  Lower

Do we need the reactionary Actions Show and Hide if the config is the one
feeding us those in the first place?

Instead of _FvwmProxySelectDefault, we can define the conglomeration of
commands into the hard defaults.  Is there a one-liner syntax like:

*FvwmProxy: Action  Select  Iconify off; FlipFocus; Raise; WarpToWindow 5p 5p

  _

---

From: [email-masked]
Date: Fri, 22 Nov 2002 13:27:58 -0800

AddToFunc MySelect
+ I WindowId $w Raise

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 22 Nov 2002 22:26:25 +0000

On 22 Nov 2002 13:27:59 -0800, [email-masked] wrote:
> > With it your configuration above is as trivial as:
> > 
> I really like this how clean this looks.  How slow is "slow" for using
> two messages vs one?  I don't want to neglect older HW, for which fvwm
> lightness is even more appealing.  Even if each message takes 100ms,
> we're only going from one to two.  I remember in another module I was
> prototyping, I was streaming tons of move commands, perhaps a dozen for
> each step of a mouse drag.  I would naively expect that a couple
> messages would be less time than it takes to redraw two proxies.

I don't think it is slow. Probably 100 bytes transfered over already open
pipes vus 50 bytes transfered plus expanding and executing a complex
function. A slowness should not be an argument here.

> to a secret _FvwmProxyDefault which is not generally appended to, but
> outright replaced.  So I might have, for my unpopular config, something
> like
> 
> 

You may consider to do it this way instead:

  *FvwmProxy: Action  Select  WindowListFunc $w
  *FvwmProxy: Action  Mark
  *FvwmProxy: Action  UnMark

Actually [this is off topic] I think WindowListFunc was not designed well.
It should not get a window id as the first parameter, but should be
executed in a window context. Then all conditionals like ThisWindow should
work nicely if needed. Its default definition would be:

  AddToFunc WindowListFunc
  + I Iconify off
  + I FlipFocus
  + I Raise
  + I WarpToWindow 5p 5p

that is much more intuitive than the current:

  AddToFunc WindowListFunc
  + I WindowId $0 Iconify off
  + I WindowId $0 FlipFocus
  + I WindowId $0 Raise
  + I WindowId $0 WarpToWindow 5p 5p

The modules should send "Silent WindowListFunc" with the window context.
I don't know whether it's good to change the WindowListFunc interface now.
I would try to do this even this means those who redefined the default
WindowListFunc, should do it again.

> feeding us those in the first place?

I don't think there is a real need for Show/Hide/Abort callbacks and even
Mark/UnMark. But I don't care here.

> *FvwmProxy: Action  Select  Iconify off; FlipFocus; Raise; WarpToWindow 5p 5p

This is exactly WindowListFunc. I think WindowListFunc is a good default
for Select and it does not require any hidden _FvwmProxySelectDefault.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Nov 2002 12:18:53 +0100

> > >   Key -Meta A A SendToModule FvwmProxy Hide

Actually, the proper key name is Meta_L.

> > two messages vs one?

Four insted of two.

> >  I don't want to neglect older HW, for which fvwm
> > each step of a mouse drag.

> >  I would naively expect that a couple

That is not the point here.  Redrawing is done by the X server
which can handle any amount of incoming data at any speed.

> function. A slowness should not be an argument here.

Then perhaps you should do some profiling of the module interface.
Its performance is horrible.  The performance of this one module
isn't this interesting here, but it adds to the overall
communication.  Thus it further increases the chance of pipe
overflows and modules being killed due to timeouts.  My machine is
certainly not slow, but it does have these problems when I start
more than just a few modules.

> > outright replaced.

Overwriting configs that may have been set by the user is a
shooting offense.

> >  So I might have, for my unpopular config, something like
> > 

Actually, the proper key name is Meta_L unless you have set up
your X server in a non standard way.

[snip]

> > *FvwmProxy: Action  Select  Iconify off; FlipFocus; Raise; WarpToWindow 5p 5p

No, that does not work in other modules and it does not work in
this.  Fvwm does not guarantee to execute these commans in a
single batch.  Other things might be done in between.  For
example, the focus might be switched.

> for Select and it does not require any hidden _FvwmProxySelectDefault.

I think that is no valid reason for recycling WindowListFunc in
FvwmProxy by default.  It should still has its own copy of the
function for readability.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Nov 2002 12:29:13 +0100

[snip]

> This is enough for most of the users.

This does not address above usage scenario at all.

>   *FvwmProxy: UnmarkCommand Layer -1

Actually, I chose an example that needs two commands as the mark
function on purpose.  Then, your approach does not work anymore
and you are back at writing the horrible complex functions I
posted.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 25 Nov 2002 13:53:42 +0000

> > > >   *FvwmProxy: UnmarkCommand Layer -1

(in another message:)
> and you are back at writing the horrible complex functions I

This approach does work well and it is less horrible than others.
A user is not limited to any function name, he may reuse his own
functions like MyRaiseOn and MyRaiseOff if he wants.

> > > I really like this how clean this looks.  How slow is "slow" for using

Only if a user decides that internal Next/Prev are not good for him.
In the default situation there is the same number of messages.

> which can handle any amount of incoming data at any speed.

fvwm should also be capable to perform such simple task as calling the
Next function and sending the window id to a module. If it is not capable
it just pointless to discuss any module communication at all regardless of
the number of requests (1 or 2) from a module.

> more than just a few modules.

Agree that a module communication should be improved in the core.
But this does not justify a non clean design.

> Overwriting configs that may have been set by the user is a

We never spoke about overriding user configs, only for supplying a default
when no user config (Action Select in this case) was supplied.

> your X server in a non standard way.

I didn't change anything like this myself and here are my results:

% xmodmap -pm -pk | egrep 'Meta|Alt'
mod1        Alt_L (0x40),  Alt_R (0x71)
     64         0xffe9 (Alt_L)  0xffe7 (Meta_L)
    113         0xffea (Alt_R)  0xffe8 (Meta_R)

> function for readability.

If we already have a global function WindowListFunc, it is consistent to
use it as the default for all window list modules, not just the core.
(And it is actually used in at least 3 modules now).

The FvwmProxy man page should explain how to set the Select action.
Having something different to define (another global function) instead
of configuring the Select action is confusing.

Overall, I like how clean it is now. Of course I agree with your notes
about complying with the common code style.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Nov 2002 16:00:29 +0100

> > > > >   Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage)

By the way, this does not work at all.  How would FvwmProxy know
about the window that was matched with "Next"?  The correct line
is this:

  Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage) SendToModule FvwmProxy Mark $$$$$$$w

(give or take a few '$'s)

> This approach does work well and it is less horrible than others.

Please take a look at the "Key Tab ..." line above and say that
again.

> functions like MyRaiseOn and MyRaiseOff if he wants.

I find forcing the user to fiddle with commands like
"SendToModule" unacceptable.

> In the default situation there is the same number of messages.

As I said, the internal Next and Prev will be removed as they are
a pointless duplication of code.  And when you originally posted
your example you said that FvwmProxy would echo the command sent
to it to fvwm.

[snip]

> the number of requests (1 or 2) from a module.

Fvwm should have a stable module interface, but it doesn't.
Unless we rewrite it, we have to live with the limitations.

> But this does not justify a non clean design.

Oh, come on, the design is very clean, you just don't like it.
It's goal is to make module configuration as simple as possible.

> when no user config (Action Select in this case) was supplied.

Let me rephrase:  Overwriting *any* configs that may have been set
by the user is unacceptable.  Users will hate it, maintainers will
hate it.

[snip]

> (And it is actually used in at least 3 modules now).

It's not a window list module.

> of configuring the Select action is confusing.

Thank you!  This is exactly what my approach prevents for a
beginner.  For a beginner, there is never a reason to change the
configured module action.  Instead, the complex function is
changed.  With the function-less default, a function has to be
used in addition to the moduele resource almost immediately for
any non-standard use.

> Overall, I like how clean it is now.

Well, I don't like it at all as it's user unfriendly and
unnecessarily wastes resources.  But I think I said that before.

Oh, and with the current design it's difficult to bind "Abort" to
a mouse button.  You'd have to say

  *FvwmProxy: Action Click2 SendToModule FvwmProxy Abort

Ugly.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 25 Nov 2002 17:04:48 +0000

> (give or take a few '$'s)

It works because M_STRING packet contains the context window id as the
first parameter. Definitely, it is not the first module using the current
window context in fvwm->module and module->fvwm communication.

> Please take a look at the "Key Tab ..." line above and say that

As you wish: It is clean and less horrible than others.
Like the man page states, it is:

> "SendToModule" unacceptable.

I can't agree here. It is intuitive to send commands to modules, like
start, stop, show, hide. We just should worry these commands are clean.

> a pointless duplication of code.

I don't think Next and Prev should be removed, they are just an intuitive
notion to move to the next proxy using some method, say, left to right.
But it is really not important for me whether you want to remove anything
in the code as long as the interface is the same (read: clean) as now.

> And when you originally posted

I said this about the Circulate messages only.

I think Jason understood me. Together with the idea that the user should
not worry about something that a module should worry about, i.e. adding
the actual command to be recent back: "SendToModule FvwmProxy Mark".

> Unless we rewrite it, we have to live with the limitations.

So it is better not to have something than to have it in a spaghetti form.

> It's goal is to make module configuration as simple as possible.

Most of the things you do in the core I like very much.

But here the design is not clean and makes a module configuration complex.
If the authors of FvwmEvent, FvwmTaskBar, FvwmIconMan, FvwmIconBox,
FvwmWinList, FvwmAuto that all enable for a user to configure callbacks
would use your approach we would now have dozens of global functions like
FvwmAutoRaiseFunc, FvwmEventNewDeskFunc or FvwmTaskBarClick1Func.

FvwmForm, FvwmGtk, FvwmButtons and FvwmBacker also have many callbacks,
but noone thought to use global functions FvwmFormExecuteThisWhenConfirmed
or FvwmFormExecuteThisWhenCanceled.

Did you ever think that FvwmProxy like half of our other modules may
support aliases? So it is possible to run 2 modules and configure one
configuration for one set of keys and another for another set of keys.
Then it is immediately clear that global functions like FvwmProxyMarkFunc
or FvwmAutoRaiseFunc are bad.

There are much better solutions that are used in other modules.

> by the user is unacceptable.  Users will hate it, maintainers will

Actually the proper solution for this is to be able to send to fvwm a
bunch of commands. I thought about this for some time. If a module sends
a string that contains more than one line, fvwm should create an anonymous
function for these commands and execute it. Or to execute them like within
Read/PipeRead.

> It's not a window list module.

It keeps an internal window list and applies some actions to windows.
Just like FvwmWindowLister is a window list module although it does not
show a permanently visible list of windows.

> used in addition to the moduele resource almost immediately for

See above how other modules solved this.

>   *FvwmProxy: Action Click2 SendToModule FvwmProxy Abort

Looks acceptably good and modular to me.
It is possible to make it shorter:

  *FvwmProxy: InternalAction Click2 Abort

But I am not sure adding alternative ways to achieve one thing is needed.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 25 Nov 2002 18:55:20 +0100

> window context in fvwm->module and module->fvwm communication.

Whoa, I see it now.  Appending "SendToModule FvwmProxy Mark" is
hard coded.  You're not serious about this, are you?  What if the
user wants to do something else but just send "Mark"?  This
severly limits the kinds of functions that can be bound to
FvwmProxy actions.

[snip]

> in the code as long as the interface is the same (read: clean) as now.

Well, perhaps you should think a bit about who does 90% of the
maintenance.  We go happily about adding redundant functionality
(just the though of what is happening with FvwmWindowLister makes
me angry).  And in the end I do almost all the maintenance.

> the actual command to be recent back: "SendToModule FvwmProxy Mark".

Shudder.

> FvwmAutoRaiseFunc, FvwmEventNewDeskFunc or FvwmTaskBarClick1Func.

Yes, exactly.  And on the other hand we wouldn't have users
constantly whining "I want double clicks in module xyz", "why
can't I just bind any abc to module FvwmFoo".  Now tell me, what
is bad about global functions?  They simply work better than the
feeble attempts to fake them inside the modules.

> or FvwmFormExecuteThisWhenCanceled.

It works out for FvwmProxy because it's an extension of the core,
that does nothing on its own.

> or FvwmAutoRaiseFunc are bad.

Yes, I actually thought about it.  On one hand, running it twice
make absolutely zero sense, on the other hand, as I said before,
configuration becomes complex as soon as you run it in a
non-standard way.

> There are much better solutions that are used in other modules.

The only two modules that I can think of that have a clean
configuration syntax are FvwmCpp and FvwmM4 and the other modules
that don't accept module config lines.  

> function for these commands and execute it. Or to execute them like within

The command line parser does not allow to separate multiple
commands and will never do so because it just wasn't planned.
Many commands just take the rest of the line and treat it as if it
all belonged to the current command.  The right solution is and has
always been to use complex functions.  That's what they were
designed for.

The module interface is already unstable at best.  Adding even
more features that require synchronization is not a good idea.
Fvwm already freezes way too often because of deadlocks with the
modules.

> show a permanently visible list of windows.

I don't know how you would work with it, but I would never use the
WindowListFunc with FvwmProxy because it works totally different
that the other window listing modules.  (I chose a copy of
WindowListFunc only to not have to worry about it for a moment).

> See above how other modules solved this.

Yes, I know how other modules solved this:  they didn't.  They are
simply hell to configure for a beginner.

> Looks acceptably good and modular to me.

Well, if that is your opinion, I think I am maybe working on the
wrong window manager.  I am struggling hard to improve fvwm's
usability and to clean up the most screwed interfaces, and all I
ever hear is that the current state is nice and changing it is
useless.  Fvwm will never grow beyond it's "flexible maybe, but
too hard to configure" image this way.

> But I am not sure adding alternative ways to achieve one thing is needed.

Huh?  Who is adding alternative ways to what?

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 25 Nov 2002 23:25:28 +0000

I think I will not continue this thread anymore, because the arguments
are the same and it seems they do not help. Here is the last attempt.

> severly limits the kinds of functions that can be bound to

Please take a look at another messages where we with Jason discuss just
this. There are several solutions. One is Circulate and CirculateMark.

Why not to make it convenient and easy for a user that in most of cases
wants just marking? And if he wants something else, he don't need to use
FvwmProxy with Circulate for this.

> me angry).  And in the end I do almost all the maintenance.

I don't think we should fight here.

I really like how we with Olivier solve everything in fvwm-themes.
It sometimes happens (very rarely, but still) that we don't agree on
something. Then we keep both solutions. One that he maintains and one
that I maintain. You don't maintain fvwm-menu-* scripts or perllib or
FvwmWindowLister, FvwmPerl and from now on FvwmDebug and FvwmGtkDebug.
So why should you ever be angry if some users and developers are really
happy to have these things?

> feeble attempts to fake them inside the modules.

No, all the modules above do not make feeble attempts to fake them inside.
They simply allow a user to use any function name he wants, not any
hardcoded name.

Global functions are evil for modules.

  * problems with name cluttering
  * monolithics vus modularity
  * problems who and when defines/redefines such functions
  * having hundreds of functions for modules that a user does not use
  * this disallows more than one implementation of a module

Functions are designed to combine commands, not to write module
configurations. Functions may be bound to module callbacks if a user wants
to combine several commands, but global functions should not be forced.
Otherwise we get one big spaghetti that may seem to be "manageble" for
simple setups, but not for more complex/configurable/dynamical setups.

> that does nothing on its own.

Everything may work with global functions. This does not mean it is the
best solution. I prefer to keep it consistent with how other modules work.
Without inventing any new syntax using specially named global functions.

> make absolutely zero sense,

Of course if you make it depend on global functions it makes zero sense
to run it twice. A user has no a chance.

> on the other hand, as I said before, configuration becomes complex as
> soon as you run it in a non-standard way.
> 

Without a fully functional alternative, it is pointless to say that you
don't like all 25 modules that use configuration now.

> always been to use complex functions.  That's what they were

Then every single module should do the redundant work that fvwm may do.
A module should just send several commands without worrying about
creating any function:

  SendText("Beep\nNext (xcalc) Close");

and fvwm should create an anonymous function or run a stream just like
it does now it with Pipe/PipeRead.

> Fvwm already freezes way too often because of deadlocks with the

fvwm should not do any synchronization with a module to execute
all commands passed in one string.

> > > > > > This is exactly WindowListFunc. I think WindowListFunc is a
> > > > > > good default for Select and it does not require any hidden
> > > > > > _FvwmProxySelectDefault.
> > > > > 
> > > > If we already have a global function WindowListFunc, it is
> > > > consistent to use it as the default for all window list modules,
> > > > not just the core. (And it is actually used in at least 3 modules
> > > > now).
> > > 

FvwmProxy was designed as a possible WindowList replacement.
A user usually wants the same function in both when a window is selected.
But, anyway, this is only a default that works well.

[snip]

> useless.

First, this is not true. I mostly like all your work on the core.
But when you say that some things are screwed (like SendToModule as the
way to send module commands) without any reasons, I can't agree.

But what is your own solution here for 2.6.0? This one:

  *FvwmProxy: Click2DoesAbort

? Or maybe this:

  Function SetFvwmProxyAbortingProxiesOnClick2

with this global function defined in the Defaults file?

> Fvwm will never grow beyond it's "flexible maybe, but

I really understand your feelings. But let's postphone this discussion for
3.0. You will see I am the less conservative person ever. The only thing I
worry about is a good extendible design, everyone benefits from it, users
and developers.

Dominik, I am a very reasonable man, you may easily make me fight for your
own design, just present a good one. If I disagree so loudly it means this
design is really bad in my eyes and it worths to look at my arguments.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 26 Nov 2002 11:17:37 +0100

> FvwmProxy with Circulate for this.

This is futile.  You don't even listen to my concerns about
usability, do you?

> happy to have these things?

Get real.  Nobody is answering bug reports regularly except me,
regardless of the module they are found in.  I am extremely
unhappy with all the redundant and a lot of the new code that
appeared in the last year.  Maintenance now eats up more than 90%
of my time and I hardly ever get around coding something useful.
I must confess that I am close to quitting fvwm maintenance and
either concentrate solely on new features or begin from scratch.

> configurations.

If you say so.  Not that it makes any difference regarding memory
or speed.

[snip]

> to run it twice. A user has no a chance.

Nonsense.  As I said - I do not know how often - configuration
just becomes complex in this case.  To get a different config for
a second invocation, it's back to cut and paste from the man page.

> don't like all 25 modules that use configuration now.

If you say so.

> it does now it with Pipe/PipeRead.

I disagree, and I will not allow anything like this into the core
(see above for the reasons).

> FvwmProxy was designed as a possible WindowList replacement.

If you say so.

> A user usually wants the same function in both when a window is selected.

If you say so.

> But, anyway, this is only a default that works well.

If you say so.

> way to send module commands) without any reasons, I can't agree.

I say that because fvwm's usability is a catastrophe.

> with this global function defined in the Defaults file?

Very funny, but not quite related to what I proposed.

  *FvwmProxy: Action Click2 FvwmProxy_Abort

> 3.0.

I don't think I will see a 3.0 release.  With what has happened
since 2.4, I think it's useless even to try cleaning things up.
The task has grow so immensely that I can not believe I ever find
enough time to to this.  I don't even get around finishing the
things I started after 2.4.

Bye

Dominik ^_^  ^_^