[snip]
As there was too much discussion to answer everything explicitly,
let me explain the logic behind the current FvwmProxy setup.
1) ConfigFvwmProxyDefaults contains essential configuratios that
are meant to make the module usable for a beginner. It is
*never* included twice and thus the functions do not have to be
destroyed. Exactly like everything in ConfigFvwmDefaults.
2) In the design I have in mind, FvwmProxy does *nothing* by
itself. Every action is configurable via complex functions.
There are no hard coded function defaults like "Click button 1
= Raise". Instead, there is a set of functions that are called
at various times:
Called by FvwmProxy:
FvwmProxyShowFunc:
executed when the windows are initially shown
FvwmProxyHideFunc:
executed when the windows are removed (implies execution of
FvwmProxySelectFunc)
FvwmProxyAbortFunc:
executed when the the windows are removed
FvwmProxyMarkFunc:
executed when a window is hilighted
FvwmProxySelectFunc:
executed when a window is selected; same default as
WindowListFunc
These functions are *meant* to be modified by an intermediate
user. They are *not* hidden internal FvwmProxy settings but
the correct place to configure module actions. Why? FvwmProxy
needs to store the notion of a selected window in fvwm memory.
This is necessary to make use of the conditional window
selection commands.
When we add different actions for the various mouse buttons,
they should use FvwmProxyMarkFunc. If that is not enough, add
more "Mark" functions, a la FvwmProxyMark2Func, ...Mark3Func
etc. The idea is to keep all action definitions in the same
place.
The normal user is *not* supposed to use the
"*FvwmProxy: ...Command" to configure FvwmProxy. She should
add lines to the complex functions instead.
Called by the user (convenience functions to ease writing
the config):
FvwmProxy_Mark:
mark a window, triggered by fvwm, e.g. by
key f1 a s FvwmProxy_Mark $FvwmProxy_S
FvwmProxy_Circulate:
Use any of the usual window selection commands to mark the
next window. For example:
key f2 a s FvwmProxy_Circulate Next (currentpage)
The idea is that fvwm does the window selection and just
tells FvwmProxy what to do next. This obsoletes the "Next"
and "Prev" logic built into FvwmProxy.
These are convenience functions only. It makes little sense to
modify them.
3) Overriding any settings at module startup is evil. It will
*really* annoy users. Never do this. The only time settings
may be forced is before the config file is read. I agree that
it's not such a hot idea to force configs that are used by
perhaps 10% of the users. It's just that I can't think of a
method to trigger reading the defaults when either the module
is started for the first time, any FvwmProxy config line is
encountered or any of the default config is modiufied.
4) Comparing FvwmProxy with FvwmEvent. That comparison is not
valid. After all, FvwmEvent is a module that is meant for
various magic and scripting tasks. Only experts should try
using it without assistance. FvwmProxy is quite the opposite.
It is a high-level, user friendly GUI module that is supposed
to come with usable and sensible defaults. Even a beginner
should be able to make good use of it. Hence it requires a
nice default configuration. Just writing it in the man page
and telling the user to cut and paste is not good enough.
5) About the individual defaults: The defaults should be chosen
in a way that allows a user to do something useful with
FvwmProxy with the bare minimum of adding two configuration
lines:
AddToFunc StartFunction I Module FvwmProxy
Mouse 1 R M SendToModule FvwmProxy Show
Then:
(M-Click1): Show proxies
(Move mouse): Select a proxy with visual feedback
(Click1): Raise the window and hide the proxies
And perhaps:
(Click2): Lower the window
(Click3): Something
(I know there is still way to go before this works). Of course
we can discuss about the proper defaults, but the module should
be usable with a minimal configuration.
6) Hard coding the defaults. I think they should not be hard
coded in the FvwmProxy executable because some require complex
functions and some do not. This makes configuring it a pain.
For example, if you have this default:
*FvwmProxy: MarkCommand <something>
And the user wants to add "Focus", she has to issue:
AddToFunc MyFvwmProxyRaiseFocus
+ I <something>
+ I Focus
*FvwmProxyMarkCommand: Function MyFvwmProxyRaiseFocus
Note that the user has to look up the current default in the
man page first and add them manually to the new function. With
the current code she can just say:
AddToFunc FvwmProxyMarkFunc
+ I Focus
It is shorter and easier to use. You do not have to look up
any defaults in the man page.
7) My recommendations on the implementation of some new/current
features:
Next/Prev command:
Remove them. With the FvwmProxy_Circulate function they
are no longer necessary. Fvwm does a much better job of
selecting windows as it is mobre versatile and has more
available information.
Click button <n> actions:
Implement them just like the "Mark" command. Add resources
*FvwmProxy: Click<n>Command and default to
*FvwmProxy: Click1Command Function FvwmProxyClick1Func
AddToFunc FvwmProxyClick1Func
+ I Raise
*FvwmProxy: Click2Command Function FvwmProxyClick2Func
AddToFunc FvwmProxyClick2Func
+ I Lower
...
Overall, ad as little functionality to FvwmProxy as possible.
Fvwm has most of the code anyway, so program the actual
behaviour into complex functions. This reduces maintenance of
the module dramatically.
8) The initial idea behind ConfigFvwmDefaults was *not* to include
them from the setup script. The idea was to take the
non-critical default settings from the fvwm source code and put
them in a file that can be modified by the sysadmin. I don't
know what the other ConfigFvwm... files are good for, though.
--
To summarize the crucial point of the discussion:
What Mikhael does not like (correct me if I am wrong) is that
configuration lines (the contents of ConfigFvwmProxyDefaults) that
use up cpu and memory are forced upon every user. I do not like
that either. Present a reliable method to only include these
defaults only when FvwmProxy is actually used and I will use it.
Otherwise we have to weigh resource consumption against ease of
use. I tend to prefer usability here, but I am not decided yet.
Bye
Dominik ^_^ ^_^
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
