This makes me happy that the only modules I use is FvwmCommand, which is just for quick config tweak-testing without having to reach for the rat.
-- TerryP / Spidey01 Just Another Computer Geek. On Sat, Oct 22, 2011 at 06:23, Thomas Adam <tho...@fvwm.org> wrote: > Hello all, > > This has been a while coming since 2.6.0 was released. But I said at the > time that since there was no longer ever going to be a split between > stable/unstable, and that there was only ever rolling-stable releases, that > there was now never any right time to make changes which have an impact. > > This is one of them. > > Currently, FVWM ships with a number of modules. Some of them are used a > lot > in peoples' configs (such as FvwmButtons, FvwmEvent, etc.) and others are > not so much used -- and indeed some of them have just bitrot. > Unsurprisingly, that's due to confusion as to the need of the module, and > in > some cases the language the module is supporting, because it's no longer > the > "coolest" language to use, or has been pushed back because of another > module > giving functionality. > > So, here's a list of modules I wish to see deprecated, with reasons why: > > * FvwmCommand > * FvwmConsole > * FvwmConsoleC.pl > > These three are on a list to be removed, but the functionality to replace > them (notably getting FVWM to listen on a $DISPLAY socket, for instance) > just isn't there yet. So whilst I don't plan on deprecating them just yet, > I'm aware I'll need to at some point. > > * FvwmCpp > > This one has to go -- no one that I've seen in the years I've been using > FVWM actually has a configuration in CPP anymore. If they do, they've not > noticed it's been broken since FVWM 2.3.X, and no one has fixed that. > > * FvwmDragWell > > The use-case of this doesn't match any application anymore. > > * FvwmIconBox > > Replaced with IconBox style option, although not quite the same as having > an > actual window managing icons (c.f. TWM) > > * FvwmSave > * FvwmSaveDesk > > These two are broken, and a very very poor choice of trying to be a session > manager. Use a session manager if you can with FVWM. > > * FvwmTaskBar > > This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail > notification can use xbuffy, xbiff, or mail-notification. > > * FvwmWharf > > This is FvwmButtons. > > * FvwmWinList > > This is FvwmIconMan. > > Note that I am not interested in someone suddenly jumping out of their > front > door shouting: "I'll do it, I'll do it! I'll maintain this module." > These > modules listed simply do not do their job to the way FVWM works anymore, > and > worse yet, for some of these modules, the applications interacting with > them > don't understand their requests. If people really did care that much, the > problems with these modules would have been addressed long ago were they in > use. > > How do we deprecate these things? Slowly -- I am not about to commit > anything to remove them. There will be a long time in which one module is > deprecated, with there being a transition in FVWM to handle module > information for deprecated modules. > > I will be writing a FvwmDeprecated module stub, and will point the > deprecated modules to it, as they're deprecated. This will do nothing more > than log the fact the module doesn't exist, perhaps using xmessage if it's > installed, etc. Then, over time, as people switch configs, the need for > this will go away. It won't be a permenant arrangement of FVWM, but will > need to be around for some time as people adjust their configs. > Furthermore, as modules are deprecated I will be personally providing > instructions on how to migrate from that module to another, where the > deprecated module has an equivalent functionality. Not all modules > (FvwmSave{,Desk} for instance will not.) > > I won't be beginning work on this just yet -- maybe I'll start it over > Christmas. > > Any questions, please ask. > > -- 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.) > >