On 21 Nov 2002 11:49:21 +0100, Dominik Vogt wrote:
>
> On Wed, Nov 20, 2002 at 03:57:53PM -0800, [EMAIL PROTECTED] wrote:
> > 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.
>
> Yeah, I prefer to use "Alt-cursorkey" with the Direction command
> 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. :-)
> > The Config file looks very manacing, but I'll concede that you win on the
> > 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
> > 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".
>
> > 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.
>
> > 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.
Jason wants "Action Select" syntax to be _instead_ of SelectCommand
syntax. For me either one may work.
> > Referencing the previous email:
>
> Please quote the mails you are referring to. It is very tredious
> to cross read two emails.
>
> > 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.
>
> Too much to doo in too little time. We document everything, but
> 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
> > user settings.
>
> Mikhael suggested that.
I am not quite sure what does this mean. I would never suggest to override
user settings without an explicit command from a user.
> > 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.
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.
> > 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.
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.
--
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]
