I think I will not continue this thread anymore, because the arguments
are the same and it seems they do not help. Here is the last attempt.
On 25 Nov 2002 18:55:20 +0100, Dominik Vogt wrote:
>
> On Mon, Nov 25, 2002 at 05:04:48PM +0000, Mikhael Goikhman wrote:
> > On 25 Nov 2002 16:00:29 +0100, Dominik Vogt wrote:
> > >
> > > On Mon, Nov 25, 2002 at 01:53:42PM +0000, Mikhael Goikhman wrote:
> > > > On 25 Nov 2002 12:18:53 +0100, Dominik Vogt wrote:
> > > > > On Fri, Nov 22, 2002 at 10:26:25PM +0000, Mikhael Goikhman wrote:
> > >
> > > > > > > > Key Tab A M SendToModule FvwmProxy Circulate Next (CurrentPage)
> >
> > It works because M_STRING packet contains the context window id as the
> > first parameter. Definitely, it is not the first module using the current
> > window context in fvwm->module and module->fvwm communication.
>
> Whoa, I see it now. Appending "SendToModule FvwmProxy Mark" is
> hard coded. You're not serious about this, are you? What if the
> user wants to do something else but just send "Mark"? This
> severly limits the kinds of functions that can be bound to
> FvwmProxy actions.
Please take a look at another messages where we with Jason discuss just
this. There are several solutions. One is Circulate and CirculateMark.
Why not to make it convenient and easy for a user that in most of cases
wants just marking? And if he wants something else, he don't need to use
FvwmProxy with Circulate for this.
> > > As I said, the internal Next and Prev will be removed as they are
> > > a pointless duplication of code.
> >
> > I don't think Next and Prev should be removed, they are just an intuitive
> > notion to move to the next proxy using some method, say, left to right.
> > But it is really not important for me whether you want to remove anything
> > in the code as long as the interface is the same (read: clean) as now.
>
> Well, perhaps you should think a bit about who does 90% of the
> maintenance. We go happily about adding redundant functionality
> (just the though of what is happening with FvwmWindowLister makes
> me angry). And in the end I do almost all the maintenance.
I don't think we should fight here.
I really like how we with Olivier solve everything in fvwm-themes.
It sometimes happens (very rarely, but still) that we don't agree on
something. Then we keep both solutions. One that he maintains and one
that I maintain. You don't maintain fvwm-menu-* scripts or perllib or
FvwmWindowLister, FvwmPerl and from now on FvwmDebug and FvwmGtkDebug.
So why should you ever be angry if some users and developers are really
happy to have these things?
> > > > Agree that a module communication should be improved in the core.
> > > > But this does not justify a non clean design.
> > >
> > > Oh, come on, the design is very clean, you just don't like it.
> > > It's goal is to make module configuration as simple as possible.
> >
> > Most of the things you do in the core I like very much.
> >
> > But here the design is not clean and makes a module configuration complex.
> > If the authors of FvwmEvent, FvwmTaskBar, FvwmIconMan, FvwmIconBox,
> > FvwmWinList, FvwmAuto that all enable for a user to configure callbacks
> > would use your approach we would now have dozens of global functions like
> > FvwmAutoRaiseFunc, FvwmEventNewDeskFunc or FvwmTaskBarClick1Func.
>
> Yes, exactly. And on the other hand we wouldn't have users
> constantly whining "I want double clicks in module xyz", "why
> can't I just bind any abc to module FvwmFoo". Now tell me, what
> is bad about global functions? They simply work better than the
> feeble attempts to fake them inside the modules.
No, all the modules above do not make feeble attempts to fake them inside.
They simply allow a user to use any function name he wants, not any
hardcoded name.
Global functions are evil for modules.
* problems with name cluttering
* monolithics vus modularity
* problems who and when defines/redefines such functions
* having hundreds of functions for modules that a user does not use
* this disallows more than one implementation of a module
Functions are designed to combine commands, not to write module
configurations. Functions may be bound to module callbacks if a user wants
to combine several commands, but global functions should not be forced.
Otherwise we get one big spaghetti that may seem to be "manageble" for
simple setups, but not for more complex/configurable/dynamical setups.
> > FvwmForm, FvwmGtk, FvwmButtons and FvwmBacker also have many callbacks,
> > but noone thought to use global functions FvwmFormExecuteThisWhenConfirmed
> > or FvwmFormExecuteThisWhenCanceled.
>
> It works out for FvwmProxy because it's an extension of the core,
> that does nothing on its own.
Everything may work with global functions. This does not mean it is the
best solution. I prefer to keep it consistent with how other modules work.
Without inventing any new syntax using specially named global functions.
> > Did you ever think that FvwmProxy like half of our other modules may
> > support aliases? So it is possible to run 2 modules and configure one
> > configuration for one set of keys and another for another set of keys.
> > Then it is immediately clear that global functions like FvwmProxyMarkFunc
> > or FvwmAutoRaiseFunc are bad.
>
> Yes, I actually thought about it. On one hand, running it twice
> make absolutely zero sense,
Of course if you make it depend on global functions it makes zero sense
to run it twice. A user has no a chance.
> on the other hand, as I said before, configuration becomes complex as
> soon as you run it in a non-standard way.
>
> > There are much better solutions that are used in other modules.
>
> The only two modules that I can think of that have a clean
> configuration syntax are FvwmCpp and FvwmM4 and the other modules
> that don't accept module config lines.
Without a fully functional alternative, it is pointless to say that you
don't like all 25 modules that use configuration now.
> > > > > 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.
> > >
> > > Let me rephrase: Overwriting *any* configs that may have been set
> > > by the user is unacceptable. Users will hate it, maintainers will
> > > hate it.
> >
> > Actually the proper solution for this is to be able to send to fvwm a
> > bunch of commands. I thought about this for some time. If a module sends
> > a string that contains more than one line, fvwm should create an anonymous
> > function for these commands and execute it. Or to execute them like within
> > Read/PipeRead.
>
> The command line parser does not allow to separate multiple
> commands and will never do so because it just wasn't planned.
> Many commands just take the rest of the line and treat it as if it
> all belonged to the current command. The right solution is and has
> always been to use complex functions. That's what they were
> designed for.
Then every single module should do the redundant work that fvwm may do.
A module should just send several commands without worrying about
creating any function:
SendText("Beep\nNext (xcalc) Close");
and fvwm should create an anonymous function or run a stream just like
it does now it with Pipe/PipeRead.
> The module interface is already unstable at best. Adding even
> more features that require synchronization is not a good idea.
> Fvwm already freezes way too often because of deadlocks with the
> modules.
fvwm should not do any synchronization with a module to execute
all commands passed in one string.
> > > > > > 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).
> > >
> > > It's not a window list module.
> >
> > It keeps an internal window list and applies some actions to windows.
> > Just like FvwmWindowLister is a window list module although it does not
> > show a permanently visible list of windows.
>
> I don't know how you would work with it, but I would never use the
> WindowListFunc with FvwmProxy because it works totally different
> that the other window listing modules. (I chose a copy of
> WindowListFunc only to not have to worry about it for a moment).
FvwmProxy was designed as a possible WindowList replacement.
A user usually wants the same function in both when a window is selected.
But, anyway, this is only a default that works well.
[snip]
> > > > Overall, I like how clean it is now.
> > >
> > > Well, I don't like it at all as it's user unfriendly and
> > > unnecessarily wastes resources. But I think I said that before.
> > >
> > > Oh, and with the current design it's difficult to bind "Abort" to
> > > a mouse button. You'd have to say
> > >
> > > *FvwmProxy: Action Click2 SendToModule FvwmProxy Abort
> > >
> > > Ugly.
> >
> > Looks acceptably good and modular to me.
>
> Well, if that is your opinion, I think I am maybe working on the
> wrong window manager. I am struggling hard to improve fvwm's
> usability and to clean up the most screwed interfaces, and all I
> ever hear is that the current state is nice and changing it is
> useless.
First, this is not true. I mostly like all your work on the core.
But when you say that some things are screwed (like SendToModule as the
way to send module commands) without any reasons, I can't agree.
But what is your own solution here for 2.6.0? This one:
*FvwmProxy: Click2DoesAbort
? Or maybe this:
Function SetFvwmProxyAbortingProxiesOnClick2
with this global function defined in the Defaults file?
> Fvwm will never grow beyond it's "flexible maybe, but
> too hard to configure" image this way.
I really understand your feelings. But let's postphone this discussion for
3.0. You will see I am the less conservative person ever. The only thing I
worry about is a good extendible design, everyone benefits from it, users
and developers.
Dominik, I am a very reasonable man, you may easily make me fight for your
own design, just present a good one. If I disagree so loudly it means this
design is really bad in my eyes and it worths to look at my arguments.
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]
