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: 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: 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: 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
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!
