On Thu, Nov 21, 2002 at 09:03:22PM -0800, [EMAIL PROTECTED] wrote:
> 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 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.
> > > 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...
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.
> > > 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 see. I don't care which one is used.
> > > 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?
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.
> > > 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?
Sure.
> > > 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 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.
> 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.
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
> 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
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.
> Modify man page to use a less intrusive sample config (not mine, it sounds)
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]
