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 PROTECTED]
(/ [EMAIL PROTECTED] [EMAIL PROTECTED]
"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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
