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. 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'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. Kindly, Thomas Adam [0] http://thread.gmane.org/gmane.comp.window-managers.fvwm.general/6946
