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.)
>
>
