On Mon, Nov 25, 2002 at 11:25:28PM +0000, Mikhael Goikhman wrote:
> 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:
> > 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.
This is futile. You don't even listen to my concerns about
usability, do you?
> > > > 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?
Get real. Nobody is answering bug reports regularly except me,
regardless of the module they are found in. I am extremely
unhappy with all the redundant and a lot of the new code that
appeared in the last year. Maintenance now eats up more than 90%
of my time and I hardly ever get around coding something useful.
I must confess that I am close to quitting fvwm maintenance and
either concentrate solely on new features or begin from scratch.
> > > > > 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.
If you say so. Not that it makes any difference regarding memory
or speed.
[snip]
> > > 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.
Nonsense. As I said - I do not know how often - configuration
just becomes complex in this case. To get a different config for
a second invocation, it's back to cut and paste from the man page.
> > 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.
If you say so.
> > > 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.
I disagree, and I will not allow anything like this into the core
(see above for the reasons).
> > > > > > > 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.
If you say so.
> A user usually wants the same function in both when a window is selected.
If you say so.
> But, anyway, this is only a default that works well.
If you say so.
> > > > > 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.
I say that because fvwm's usability is a catastrophe.
> 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?
Very funny, but not quite related to what I proposed.
*FvwmProxy: Action Click2 FvwmProxy_Abort
> > 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.
I don't think I will see a 3.0 release. With what has happened
since 2.4, I think it's useless even to try cleaning things up.
The task has grow so immensely that I can not believe I ever find
enough time to to this. I don't even get around finishing the
things I started after 2.4.
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]
