On Thu, Nov 21, 2002 at 11:49:21AM +0100, Dominik Vogt wrote:
> > 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 terminate the proxy session with the "Abort" command instead
> of "Hide".
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'.
> > 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 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.
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?
> > 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?
>
> It's just a duplicate of the equivalent
>
> *FvwmProxy: SelectCommand Function MySelect
>
> we don't need it twice.
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.
> > 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.
>
> Right. The "*FvwmProxy: ..." lines do not need to be in there.
Ok, gone.
> > 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.
>
> 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.
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?
> > 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?
>
> 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.
But are Action Click(1|2|3) defaults ok?
> > 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.
>
> 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 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)
--
_
( \ _ \ /_ / _ _ 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]
