Thomas Adam <tho...@fvwm.org> writes:
> Hey all,
>
> The last time this came up for conversation [0] things were far from ideal. I
> want to have another conversation about this to see whether it's possible to
> state the case why some modules in FVWM should be removed.
>
> As I understand it, FVWM was written with extensibility in mind, and hence
> could be extended through the use of modules. Although the core of FVWM is
> quite a bit larger now (read: some of the things ther could be modules, but
> hey-ho, one for another time), there are at least quite a few modules which
> change FVWM's behaviour.
>
> Long ago when developers were more active, getting the code into FVWM was
> easier, and perhaps more importantly, the maintainability was easier, since
> the author(s) of the code had a vested interest in keeping it alive.
>
> But those days have ended, as far as I am concerned. People have lives, and
> have moved on, or simply don't use FVWM anymore. That's OK, and that's what
> happens with software over time. But the hole it leaves is almost always
> *somebody else's* mess. In this case, right now, that mess is mine.
>
> In looking at FVWM, I'm really trying to tidy up the rough edges. You can see
> my progress in Git. Indeed, to make that easier, an easy win is to *reduce*
> the amount of things which have to be touched by these cleanups. This means
> removing modules.
>
> And let us be clear here, this isn't anything new. We (as developers) know
> there's a lot of old cruft kicking around, but no one has had the balls to
> remove it for fear of breaking things for other users. That's cool, but
> equally, I want that trade-off to always be about what's maintainable,
> long-term.
>
> So to that end, I've started work to deprecate those modules I really do think
> can go, because their functionality is either covered by other FVWM modules,
> or could easily be replaced by readily available third-party tools (where that
> functionality is a minor part of FVWM). So what am I proposing, and why?
> Here's the list, with rationale:
>
> * FvwmDragWell -- never could get this to work. The XDnD specification is
> interesting, but the applications listening to this are also dead.
>
> * FvwmGTK -- GTK1.x is completely deprecated. Goodbye GTK!
>
> * FvwmIconBox -- use the IconBox style for similar grouping of icons.
>
> * FvwmSave / FvwmSaveDesk -- use a session manager. Also, a lot of
> applications don't use WM_COMMAND anymore.
>
> * FvwmTaskBar -- Use FvwmIconMan.
>
> * FvwmTheme -- it's in the core of FVWM.
>
> * FvwmWharf -- use FvwmButtons.
>
> * FvwmWinList -- use FvwmIconMan.
>
> * FvwmTabs -- use 'tabbed' from suckless.
>
> * FvwmWindowMenu -- someone's experiment.
Look in the samples directory.
We configure lots of that stuff.
> As you can see, I've spared FvwmCPP and FvwmM4 for now, but I did break out
> into a cold sweat as to whether they should be removed. I left them in
> because I want to unify them and expand on the idea a little more.
I'm using FvwmCpp but I don't need it anymore.
At one time I was sharing a configuration between
PC and Sun hardware with 8 bit color.
Seemed like a valid use. Not sure if our condition testing
can do the same thing:
#if PLANES > 8
+ TitleStyle LeftJustified\
ActiveUp (\
HGradient 128 2 rgb:FF/00/00 70 rgb:88/00/88 30 rgb:00/00/ff)\
Inactive (\
Solid Navy -- flat)\
ActiveDown (\
HGradient 128 2 rgb:FF/00/00 50 rgb:88/00/88 50 rgb:00/00/ff)
#else
+ TitleStyle LeftJustified ActiveUp (Solid Navy -- flat) \
ActiveDown (Solid Navy -- flat) \
Inactive (Solid grey51 -- flat)
#endif
>
> I've also gone and removed these two directories:
>
> debian/
> rpm/
>
> AFAIAC, these shouldn't be part of a window manager, and it is unreasonable to
> expect maintainers of a window manager to understand package management to any
> degree. All downstream do when they package FVWM is remove these directories
> and replace them with their own (newer) versions, since ours are just left to
> bitrot. If you want to build packages of your own, do so. But it's
> peripheral to FVWM.
>
> Thoughts, comments, and suggestions, please. I'm keen to get the discussion
> moving and come to a consensus. Note that if people really, _really_ want
> these modules, then having these maintained externally to FVWM is easy to do,
> and actively encouraged.
I'm not using anything else you mentioned, so no problem.
But I'm unsure what problem some of them cause just hanging around.
Back when session management became a feature, someone decided we
needed FvwmSave, etc. Never heard a problem reported for it,
so I just ignored it.
Just had an opportunity to look at Fvwm.Org, it looks pretty nice.
I thought we were going to retain the themeing, but I don't see it.
Not a real problem.
--
Dan Espen
