Re: FVWM: Deprecating certain Fvwm* modules
So how do you make sure theres consistency with features behaving as they should By fixing bugs? E.g. Thomas' change to titleformat. Weve already seen how bad this can be with... i think its titleformat not showing any number between brackets if theres only one of them on the screen. to me this is a bad thing Hang on -- were you not arguing the exact opposite when you first chipped in on that?
Re: FVWM: Deprecating certain Fvwm* modules
On Thu, Oct 27, 2011 at 09:10:21AM +0100, Harry portobello wrote:
On 26 October 2011 15:45, Bert Geens b...@lair.be wrote:
I'm sure someone(tm) can come up with an FvwmButtons config that looks
and acts like FvwmTaskBar.
i'd want to review it so it is OK - how do i do that? so far
I'll send it to the list.
everything for fvwm is put in cvs without review which i think is bad.
You're mistaken.
Whilst there is no formal process for this, the way FVWM operates is
generally no different to other projects. So let me explain...
Let's say you decided to send a patch or a series of patches to fix/augment
some functionality in FVWM (heh -- that's tickled me for some reason ;P)
which you wanted for inclusion in some future FVWM release, you'd have to
send them to fvwm-workers@ so that the people there who can commit patches
can at least see what they do.
That's the review stage. And certain people have done just that. They just
send the patches to myself rather than the list, although there's zero
difference between the two right now.
Unfortunately though, there are no other active developers who have the time
for such reviews -- and I am one of them. It's a lot of work just keeping
FVWM ticking over, and if you expected me to do that, *and* wait for review
of patches, then this project would have died out about two years ago.
As it happens (and is the case for anyone at FVWM with a commit-bit) they're
generally trusted enough to use their own judgement about what they commit
to CVS and when; the idea being that commits happen once the patches have
been tested, etc. And that's exactly what *I* do. The converse holds true
as well. There's been quite a few instances over my work on FVWM where
I've asked for review/testing -- just go and search the mailing-list
archives (both fvwm@ and fvwm-workers@) for things like fvwm-convert-2.6
and {Icon,Title}Format if you don't believe me.
Now, that's not to say that my own commits are not bug-free. But that's a
different matter, although I can only give you the same guarantee as I
stated above, that I announce certain features ahead of time such that those
who care get a chance to run it. I did that with the TitleFormat patch
series, for instance. No one reported anything to me (regardless of whether
that patch was tested) and I submitted it to CVS when I considered it
working fine.
When we move to Git though [1] this all becomes moot because features will
happen on topic branches which will allow -- no, wait -- force, review of
that topic before it's included in something we ship as a next release.
With CVS that's more difficult due to the workflow you're forced to follow.
So if you think FVWM is without review, you're wrong. It's just more likely
that no one is actively looking at review requests, cares, or has the time
to do any lengthly review. Wait for Git, then it will become more visible.
And before you ask -- yes, module deprecation work aside, I was always going
to be sending out review requests for functional testing, regression
testing, etc. FvwmTaskBar falls in to these categories. It's then up to
you to review it, of course.
Does that answer your question?
-- Thomas Adam
[1] Any day now... Ahem.
Re: FVWM: Deprecating certain Fvwm* modules
Hello Thomas Adam, Am 2011-10-25 09:11:26, hacktest Du folgendes herunter: That's just tough, I'm afraid. That mail checker is all but useless with today's email usage; it doesn't do IMAP for example, and even at the time when it was written, tools which provide its equivalent functionality, such as xbiff, xbuffy, etc., very much existed. They can always be used instead. Right, this is something, which should be removed. Some years ago I tried to make a box, where MiniIcons show up, if I start HIDEN applications (can be defined from Name of Resource/Class), but then had no time. I like to see something Windows use in its taskbar... In terms of FvwmTaskBar itself, that'll be nothing more than a generated set of module lines which wrap around FvwmButtons; FvwmTaskBar itself will be nothing more than a set of module-alias lines for FvwmButtons, where one of its jobs is to swallow FvwmIconMan. Adam, Please can ypu provide a FvwmButtonPanel which allow UN/HIDING using on Mouse-Over. I was never able to configure this... I have to click every time on the FvwmButtonsPanel to let the FvwmButtons show up and hide. Note: I have FvwmButtonsPanel on the Left, Top and Right... Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux Internet Service Provider, Cloud Computing http://www.itsystems.tamay-dogan.net/ itsystems@tdnet Jabber linux4miche...@jabber.ccc.de Owner Michelle Konzack Gewerbe Strasse 3 Tel office: +49-176-86004575 77694 Kehl Tel mobil: +49-177-9351947 Germany Tel mobil: +33-6-61925193 (France) USt-ID: DE 278 049 239 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: Deprecating certain Fvwm* modules
On Thu, Oct 27, 2011 at 07:10:24PM +0200, Michelle Konzack wrote: Hello Thomas Adam, Am 2011-10-22 11:23:49, hacktest Du folgendes herunter: * 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. Removeing is not a very good option for, because I use it all the day... I'm done explaining and justifying this -- removing isn't something I'm doing, but unifying *is*. If this isn't clear from my previous replies on this, you'll have to start asking specific questions, because quite frankly I don't know how to make my stance on this any clearer. * FvwmTaskBar This is a FvwmButtons module swallowing FvwmIconMan. People wanting mail notification can use xbuffy, xbiff, or mail-notification. Ehm, FvwmTaskBar and FvwmButtons are slightly differnt, because if I configure a button Panel it does not unhide automaticaly on Mouse-Over You're quite correct. FvwmTaskBar and FvwmButtons are completely different. If you had said Ehm, FvwmTaskBar and FvwmIconMan are slightly different, I might have understood more what you were saying. But you didn't -- so is this what you meant to say, or do you have an additional point which you've not been able to communicate? But note again that I am not interesting in comparing like-for-like functionality of FvwmTaskBar and FvwmIconMan. There is nothing that FvwmTaskBar does which FvwmIconMan does not do -- albeit with additional help from other modules, which I'll touch on in reply to your concern regarding autohiding. As far as the core functionality is concerned, FvwmTaskBar displays a list of windows. FvwmWinList displays a list of windows. FvwmIconMan displays a list of windows. FvwmIconMan (albeit now a poor choice of name when it doesn't just manage iconified windows at all!) wins against all three. Now, as for autohide, I am not as stupid as to not suggest FvwmButtons as an overriding container for housing both FvwmIconMan and various other tools I deem fit to count as a direct replacement for FvwmTaskBar. Using FvwmButtons here allows for me to have a common point of reference in terms of a window name to be able to manipulate it however I see fit. This would be more challenging were it not swallowed in FvwmButtons due to the fact that I'd be considering disparate applications as unique, especially in terms of autohiding. As for how autohiding is done, there's at least three ways I can think of -- the one I will plump for will be FvwmEvent. But you need not likely concern yourself with *how* that's achieved, just that autohiding will still be possible with the FvwmTaskBar replacement. Also if to click to fast on the Panel, it stuck in the middle and does not more restore. You have to use xkill to kill the FvwmButtons and then it restarts automaticaly from scratch. Irrelevant and something you'd need to mention to me *in context* of your FvwmButtons configuration for me to determine what your problem is. But this has *nothing* to do with anything I've mentioned above. FvwmTaskBar is a fixed part of my Desktops and the ones configured at my customers- I know that. Do not think me as stupid as to not have realised that replacing it is not necessarily a trivial thing. * FvwmWinList This is FvwmIconMan. Hmmm, FvwmWinList ist part of m config since MANY years and evne in the latest version, noting is broken Then you won't notice anything wrong with my replacing it with FvwmIconMan when it's a case of translating geometry settings and colour definitions, will you? All of this, by the way, is utterly moot until I produce something of substance for you all to see. Since code speaks louder than words, just wait to see what I come up with -- and I am serious about that point, BTW. Then you can quibble over minutiae in the time-honoured tradition. What say you? -- 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
On Mon, Oct 24, 2011 at 09:06:42PM +0100, John Latham wrote: So, here's a list of modules I wish to see deprecated, with reasons why: * FvwmCommand * FvwmConsole These two are the only ones on the list I really care about, I use FvwmCommand in my Emacs mode to just execute parts of my config without having to copy/paste to FvwmConsole. But a more direct means to access Fvwm without having to keep the terminal's shortcomings (thinking mainly about maximum command length here) in mind would be even more welcome. Either way, just a heads up to make sure FvwmCommand isn't brushed aside as being unused :) My interpretation was that Thomas is aware these are used, hence the `wait until there is a replacment' intention. But you've now made me wonder so,... ;-) Yes -- there is nothing to be worrying about. Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a `button' which invokes a shell script, that uses FvwmCommand to change desktop, sets up windows for a demo; waits for those windows to be closed and uses FvwmCommand again to put me back on the desk where acroread is running. It's perfectly simple: FvwmCommand goes away along with FvwmCommandS. FvwmConsole becomes a wrapper around something to talk to a domain socket, which itself will become FvwmCommand. Hence to get FvwmConsole's equivalent functionality it will be launchable from a terminal and still have readline support, etc. But please -- can we just stop worrying about this? This has bugger all to do with my original email and it annoys me this has even come up as an issue when I've already stated that it's on my list of things to do, but until I write the required components, it's all moot [1] -- Thomas Adam [1] This isn't directed at just you, John, but everyone else who has has a worrying fit about this.
Re: FVWM: Deprecating certain Fvwm* modules
On Mon, Oct 24, 2011 at 06:54:09PM +0100, Harry portobello wrote: don't know anything about. There's no thought gone in to this and will force users to learn things they didn't need to before. I am also amazed that mail checking is now left up to the user when it's built in to FvwmTaskBar already! So your worry isn't so much that you'll have something which looks like FvwmTaskBar, but that you won't be able to check your mail? That's just tough, I'm afraid. That mail checker is all but useless with today's email usage; it doesn't do IMAP for example, and even at the time when it was written, tools which provide its equivalent functionality, such as xbiff, xbuffy, etc., very much existed. They can always be used instead. But I'd argue that you'd want to use mail-notification or any of the other mail monitoring applications instead. In terms of FvwmTaskBar itself, that'll be nothing more than a generated set of module lines which wrap around FvwmButtons; FvwmTaskBar itself will be nothing more than a set of module-alias lines for FvwmButtons, where one of its jobs is to swallow FvwmIconMan. Now, if you wanted to put your mail checker where your postoffice is, get me an alternative which is meaningful in terms of its replacement, and I'd consider making such a component dynamically available in its config, should it be present on the system. I'll be giving myself extra points for using FvwmForm to wrap up the options for control graphically as well. If you can't do that, then shut up and stop irritating me. You're not contributing anything to this conversation except a lot of stale hot air. -- Thomas Adam
Re: Deprecating certain Fvwm* modules
On Sat, Oct 22, 2011 at 11:23:49AM +0100, Thomas Adam wrote: So, here's a list of modules I wish to see deprecated, with reasons why: I gave my reasons, but I never said how. Perhaps that's more important to some (which confuses me, since implementation aside, why the hell would you care?) so here it is, in-line with my original email. * 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. Oh look, I've already said how. But for those who missed it: FvwmConsole and FvwmCommandS and FvwmConsoleC.pl will be the ones dying, or otherwise replaced; FvwmCommandS and FvwmConsoleC.pl will die, and FvwmConsole is nothng more than a wrapper around FvwmCommand or whatever it is eventually called. Most likely FvwmCommand so as not to break as many configs as I can. * 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. Redacted, since merging this with FvwmM4 is now the most logical thing to do, with very little effort, reducing the code and allowing for any other language potentially to preprocess data if I do this properly. * 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) This one is really important, and I'm surprised no one has picked up on this. There is no direct window anymore to manage icons, but with the style option of IconBox, you can place groups of icons around on the screen. I'm taking this to be all the required functionality from this module as-needed. * 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. Seems I did mention how mail checking would be done; but note that given the all too dynamic nature of this, I will probably very strongly end up writing a little FvwmForm to manage various facets of FvwmTaskBar's replacement. -- Thomas Adam
Re: Deprecating certain Fvwm* modules
On Sun, Oct 23, 2011 at 11:36:14AM +0100, Thomas Adam wrote: On Sat, Oct 22, 2011 at 11:01:43AM -0400, des...@verizon.net wrote: 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. Well, you can use FvwmPerl for this, although the fact that you're not, and that there's already one user of this is enough for me to maintain it for those users. :) Fair enough. I will fix it in due course. Even better is the fact that I've now got an amalgamated version of FvwmM4 [1] and FvwmCpp [2], given that they both do the same thing, except for the interpolation. So this actually makes this easier to maintain overall. :) -- Thomas Adam [1] I'm always surprised at how much FvwmM4 is still used by FVWM users, we've likely got AnotherLevel to thank for that. :) [2] The names of each stay the same, they just become symlinks to a module wrapper dealing with their respective configs.
Re: FVWM: Deprecating certain Fvwm* modules
Harry portobello harryportobe...@gmail.com writes: 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? Deprecating junk is a time honored Fvwm tradition. Reducing the size of the code base helps developers. As it is, Fvwm has grown so large that I can't keep up with the complexity. Anyway, Tom has done the right thing. He made a proposal and now he's getting feedback. -- Dan Espen
Re: FVWM: Deprecating certain Fvwm* modules
On Sat, Oct 22, 2011 at 12:23 PM, 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 These two are the only ones on the list I really care about, I use FvwmCommand in my Emacs mode to just execute parts of my config without having to copy/paste to FvwmConsole. But a more direct means to access Fvwm without having to keep the terminal's shortcomings (thinking mainly about maximum command length here) in mind would be even more welcome. Either way, just a heads up to make sure FvwmCommand isn't brushed aside as being unused :) Kind regards, Bert Geens
Re: FVWM: Deprecating certain Fvwm* modules
So, here's a list of modules I wish to see deprecated, with reasons why: * FvwmCommand * FvwmConsole These two are the only ones on the list I really care about, I use FvwmCommand in my Emacs mode to just execute parts of my config without having to copy/paste to FvwmConsole. But a more direct means to access Fvwm without having to keep the terminal's shortcomings (thinking mainly about maximum command length here) in mind would be even more welcome. Either way, just a heads up to make sure FvwmCommand isn't brushed aside as being unused :) My interpretation was that Thomas is aware these are used, hence the `wait until there is a replacment' intention. But you've now made me wonder so,... ;-) Thomas: I use FvwmCommand alot. E.g. in my pdf lecture slides I can click on a `button' which invokes a shell script, that uses FvwmCommand to change desktop, sets up windows for a demo; waits for those windows to be closed and uses FvwmCommand again to put me back on the desk where acroread is running. Keep up the good work -- it is much appreciated! Thanks, John
Re: Deprecating certain Fvwm* modules
On Sat, Oct 22, 2011 at 11:01:43AM -0400, des...@verizon.net wrote: 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. Well, you can use FvwmPerl for this, although the fact that you're not, and that there's already one user of this is enough for me to maintain it for those users. :) Fair enough. I will fix it in due course. -- 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
On Sat, Oct 22, 2011 at 10:44:17AM -0500, David Fries wrote: 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. Yes, it will be. -- 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
On Sat, 22 Oct 2011 11:23:49 +0100, Thomas wrote: 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. You may want to update the download page on the website, which says: What package should you use? Note that since the days of 2.1.x the second digit of the version number marks a release as a stable release (even number like 2.2.x) or as a development (i.e. alpha or beta) release (odd number like 2.3.4). - http://fvwm.org/download/ Best regards, Adam -- Gav Adam Sjøgren Strik a...@koldfront.dk
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/
