On 25 Nov 2002 12:18:53 +0100, Dominik Vogt wrote:
>
> On Fri, Nov 22, 2002 at 10:26:25PM +0000, Mikhael Goikhman wrote:
> > On 22 Nov 2002 13:27:59 -0800, [EMAIL PROTECTED] wrote:
> > >
> > > On Fri, Nov 22, 2002 at 05:13:29PM +0000, Mikhael Goikhman wrote:
> > > > With it your configuration above is as trivial as:
> > > >
> > > > Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage)
>
> > > > Key -Meta A A SendToModule FvwmProxy Hide
>
> Actually, the proper key name is Meta_L.
>
> > > >
> > > > This is enough for most of the users.
> > > >
> > > > And if you think it makes sense to do something else (except for
> > > > hilightling the proxy) on the "mark", the module may still have 2
> > > > options
> > > > MarkCommand and UnmarkCommand (that are by default Nop).
> > > >
> > > > *FvwmProxy: MarkCommand Layer +1
> > > > *FvwmProxy: UnmarkCommand Layer -1
(in another message:)
> Actually, I chose an example that needs two commands as the mark
> function on purpose. Then, your approach does not work anymore
> and you are back at writing the horrible complex functions I
> posted.
This approach does work well and it is less horrible than others.
A user is not limited to any function name, he may reuse his own
functions like MyRaiseOn and MyRaiseOff if he wants.
> > > So, this would mean that Circulate implies a Show if not shown.
> > > That's fine by me. These two lines are easy to explain on the man page.
> > >
> > > I really like this how clean this looks. How slow is "slow" for using
> > > two messages vs one?
>
> Four insted of two.
Only if a user decides that internal Next/Prev are not good for him.
In the default situation there is the same number of messages.
> > > I don't want to neglect older HW, for which fvwm
> > > lightness is even more appealing. Even if each message takes 100ms,
> > > we're only going from one to two. I remember in another module I was
> > > prototyping, I was streaming tons of move commands, perhaps a dozen for
> > > each step of a mouse drag.
>
> > > I would naively expect that a couple
> > > messages would be less time than it takes to redraw two proxies.
>
> That is not the point here. Redrawing is done by the X server
> which can handle any amount of incoming data at any speed.
fvwm should also be capable to perform such simple task as calling the
Next function and sending the window id to a module. If it is not capable
it just pointless to discuss any module communication at all regardless of
the number of requests (1 or 2) from a module.
> > I don't think it is slow. Probably 100 bytes transfered over already open
> > pipes vus 50 bytes transfered plus expanding and executing a complex
> > function. A slowness should not be an argument here.
>
> Then perhaps you should do some profiling of the module interface.
> Its performance is horrible. The performance of this one module
> isn't this interesting here, but it adds to the overall
> communication. Thus it further increases the chance of pipe
> overflows and modules being killed due to timeouts. My machine is
> certainly not slow, but it does have these problems when I start
> more than just a few modules.
Agree that a module communication should be improved in the core.
But this does not justify a non clean design.
> > > So does this scenario mean no FvwmProxyDefaults, or is Action Select set
> > > to a secret _FvwmProxyDefault which is not generally appended to, but
> > > outright replaced.
>
> Overwriting configs that may have been set by the user is a
> shooting offense.
We never spoke about overriding user configs, only for supplying a default
when no user config (Action Select in this case) was supplied.
> > > So I might have, for my unpopular config, something like
> > >
> > > Key Alt_L A N SendToModule FvwmProxy Show
> > > Key -Alt_L A A SendToModule FvwmProxy Hide
>
> Actually, the proper key name is Meta_L unless you have set up
> your X server in a non standard way.
I didn't change anything like this myself and here are my results:
% xmodmap -pm -pk | egrep 'Meta|Alt'
mod1 Alt_L (0x40), Alt_R (0x71)
64 0xffe9 (Alt_L) 0xffe7 (Meta_L)
113 0xffea (Alt_R) 0xffe8 (Meta_R)
> > This is exactly WindowListFunc. I think WindowListFunc is a good default
> > for Select and it does not require any hidden _FvwmProxySelectDefault.
>
> I think that is no valid reason for recycling WindowListFunc in
> FvwmProxy by default. It should still has its own copy of the
> function for readability.
If we already have a global function WindowListFunc, it is consistent to
use it as the default for all window list modules, not just the core.
(And it is actually used in at least 3 modules now).
The FvwmProxy man page should explain how to set the Select action.
Having something different to define (another global function) instead
of configuring the Select action is confusing.
Overall, I like how clean it is now. Of course I agree with your notes
about complying with the common code style.
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]
