On Thu, Aug 14, 2014 at 10:15:54PM +0100, Dominik Vogt wrote:
> On Thu, Aug 14, 2014 at 12:51:33AM +0100, Thomas Adam wrote:
> > > this guy asked about porting mvwm patches to fvwm, and I don't
> > > know what to answer. As you know, I've been inactive in fvwm for
> > > years, and I even missed your fork. Can you tell me a bit about
> > > your project, its goals and what your plans are for the future
> > > relation of fvwm and mvwm?
> >
> > Sure. I need to be careful about calling it a fork, because it's still
> > compatible with fvwm. The reason I've forked it and called it mvwm is
> > to allow me to run the two side-by-side, and that also trying to do this
> > in CVS would have made me cry [0].
>
> Same for me. I really do not want to work with CVS anymore, and
> I'd be happy if we had an fvwm git repository tomorrow. :-)
The closest we have is this:
https://github.com/ThomasAdam/fvwm
But as you and I both know, there's a lot of infrastructure surrounding
this which means putting it in place is more work; there's the
corresponding fvwm-web repo as well which I have on Github somewhere.
Perhaps this is an academic point given some of your points below, but
if a decision is ever made with respect to an interim, and a needed git
repo, the one I reference above is being kept up to date by me whenever
commits to CVS are made.
> > You can have a look here for the TODO file:
> >
> > https://github.com/ThomasAdam/mvwm/blob/master/TODO
>
> I have taken a look, and can provide background information on
> various points. Also, I'm interested in discussing the list and
> helping with the implementation. Do you have already set up a
> place to discuss the "mvwm" work? Ideally, if the plan is to keep
> compatible to the current fvwm at least for a while, it would be
> cool if fvwm-workers gets a copy of the "mvwm" discussions. I
> think the fvwm users should be a part of the renewal process.
I agree, Dominik. I don't have anywhere at all to discuss mvwm things.
Whether that's done on an individual basis with summary emails sent to
fvwm-workers@ periodically, or just on fvwm-workers@ itself, with the
prefix "mvwm" as you're suggesting, I don't mind at all. As long as
using fvwm-workers@ for this isn't seen as "cheeky" in anyway, that'd be
fine with me. If it really bothered anyone, they could set up a filter
to ignore mvwm-specific emails, etc.
> Just two quick comments on points of the TODO list.
>
> 1) Static vs. dynamic linkage
>
> Today, there's really no reason anymore to statically link the
> fvwm library. Back in the days when I vehemently fought for
> keeping static linkage, the library was small, and dynamic linking
> was somewhat unstable. Both is not the case anymore; switching to
> dynamic linking is a good thing today.
Yup, I completely agree with this.
> 2) Parsing
>
> That each command and style does its own parsing is terrible and
> has bothered me for many years. As a first step I would like to
> write a new parser that can be configured to deal with the syntax
> of every existing command and style. The commands can then be
> adapted to the parser one by one, and if we clean up the commands
> one day, the parser should still be usable. Switching to a real
> parser would also remove tons of bugs in the various functions and
> save a lot of code.
>
> And I'd like to start discussing that as soon as possible.
Me too; and this is quite a large topic in my mind. I'm keen to split
off the conversation of this to its own thread (on the proviso we've
worked out where to discuss these things, of course), but suffice it to
say, whatever we come up with on this has to also take into account the
existing commands and the fact that there's so many of them that do the
same thing, with different syntaxes, etc.
I've a pretty clear idea in my mind on what sort of parser I'd use for
this, but I really do want input on this from others, because this
defines a lot more than just commands, it also says things about the
structure of other things, like reusable concepts of referring to
desks/pages/windows, etc., something I'm keen to unify.
> > I've ripped out a lot of the fvwm modules I
> > consider to be passe, perhaps too aggressively.
>
> Many years ago we already concluded that all of the gui-like
> modules (buttons, taskbar, iconman, iconbox, pager etc.) should
> eventually be replaced by a single module (with the provisional
> name "FvwmGui"). In my eyes, it
>
> * combines all the functionality of the obsolete modules,
> * uses colorsets consequently to allow configuring _all_ gui
> elements,
> * can be reconfigured at run time through user interaction (e.g.
> dragging elements to a different spot in the window),
> * can parse all the old module configurations, at least in the
> beginning,
> * can replace all the old modules with symlinks for
> compatibility.
Interesting, thank you.
> > The net result of this is to over time amass no real sweeping changes
> > from fvwm, but to change the underlying things quite a bit. That's
> > really important, because I believe in fvwm.
>
> Ideally, I'd try to keep compatible to fvwm as long as possible.
> Of course that is not possible once we start cleaning up the
> syntax.
Agreed, and there comes a point when that breakage is accepted, and not
maintained---i.e., I'm not going to assume some kind of shim-layer or
anything. When it naturally works out to have broken existing
fvwm-compatibility, that's the point at which we're heading in the right
direction, IMO.
> * What is the relationship between fvwm and mvwm. It is clear
> that once the work starts, fvwm2 is sentenced to an eventual
> death. The question is how to manage the process of replacing
> fvwm2 with the reworked code (mvwm, fvwm3, whatever).
I think I've noted this above, but to be clear, the relationship is that
fvwm continues as it is at the moment, and people are free to work on
it, commit to it, fix bugs, etc. With mvwm, it's a way for us to try
out completely radical ideas, and break fvwm's compatibility,
eventually. As for replacing one against the other, I'm not sure.
I'm keen to note a few things here though:
* The mvwm name is not set in stone, it was just a crappy name from me
differentiate it; so I'm not that hung-up on it. If it sticks, that's
fine, if not, fvwm3, or something else suits me.
* With someone like yourself on board, Dominik, I want mvwm (or whatever
its name is to be) to run like fvwm is now---a fvwm-workers group who
have commit-bit access to the repository, etc. There's questions
about where that should be hosted, etc., and if that's Github for now,
I don't know if that's acceptable to yourself and others?
> * We need a place to get organized and discuss things. Maybe it
> would suffice to simply use fvwm-workers and prefix all rework
> related messages with "MVWM:" or whatever.
See my opening paragraph---I'm happy for out-of-band conversations and
cross-posting to fvwm-workers@, or to just use fvwm-workers@ as long as
that's not going to inconvenience others.
I suppose based on this decision, I'll wait before I (or you) kick-off a
conversation about parsers. I'm looking forward to that!
Thank you, Dominik, this is very encouraging indeed.
To anyone else reading this who has any suggestions, please do speak up.
Kindly,
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)