Deprecating certain Fvwm* modules
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.)
Re: FVWM: Deprecating certain Fvwm* modules
Hi, On 22 October 2011 11: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. Is this really the right thing to do? Really? How did you come up with this list of depreciated modules to start with? What happens if someone with a config theyve had for ages needs to use a module youve depreciated? Will you personally have to provide the functions of that module in some way? Can you not just leave these modules alone? Harry
Re: FVWM: Deprecating certain Fvwm* modules
Is this really the right thing to do? Really? How did you come up with this list of depreciated modules to start with? What happens if someone with a config theyve had for ages needs to use a module youve depreciated? Will you personally have to provide the functions of that module in some way? Can you not just leave these modules alone? Harry I believe Thomas has anticipated and answered all those questions in his post!
Re: Deprecating certain Fvwm* modules
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.)
Re: Deprecating certain Fvwm* modules
Thomas Adam tho...@fvwm.org writes: * 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. I've been using FvwmCPP for quite a while now. Maybe there is a better way I'm not aware of. I have a series of different Fvwm Themes. I read them like this: Module FvwmCpp -I$FVWM_USERDIR .DecorCurrent The pre-processor statements in the decors are usually testing color depth and sometimes just short cutting: #define BACK 21/B9/FD #define FORE 22/59/E9 DestroyDecor recreate DecorVec AddToDecor DecorVec #if PLANES 9 + TitleStyle Centered ActiveUp (Solid cornflowerblue -- Raised) \\ Inactive (Solid Navy -- Flat) \\ ActiveDown (Solid dimgrey -- Sunk) #else /*edgemid-point center */ + TitleStyle Centered ActiveUp (\\ SGradient 128 2 rgb:BACK 20 rgb:33/33/aa 70 rgb:FORE)\\ Inactive (\\ SGradient 128 2 rgb:BACK 50 rgb:44/44/aa 50 rgb:33/33/77)\\ ActiveDown (\\ SGradient 128 2 rgb:00/77/aa 30 rgb:44/88/aa 70 rgb:88/88/aa) #endif Anyway, if it's broken, I'm not aware of it. -- Dan Espen
Re: Deprecating certain Fvwm* modules
On Sat, Oct 22, 2011 at 11:23:49AM +0100, Thomas Adam wrote: Hello all, 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. FvwmConsole is the one of the list that I use from time to time. I like that it uses my terminal of choice and unlike FvwmTalk (which I suppose I can fall back on) I can cut and paste from the history with multiple lines. I'm curious from a user perspective if the interaction for the planned replacement will be the same? That is run the terminal of my choice and execute Fvwm commands. Because that's what I use it for. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/
