Re: FVWM: The Future of fvwm Development

[David Niklas]

On Fri, 11 Nov 2016 23:13:49 +
Thomas Adam  wrote:

> Hello all,
> 
> For those of you who follow fvwm-workers@ may already know some of
> this, but for those of you who don't, it's worth mentioning what the
> state of fvwm development holds for the future.
> 
> We have been discussing a lot about how we're able to make changes to
> fvwm without breaking it for everyone.  As many will know doubt know,
> fvwm is well-over twenty years old and in some cases it shows, too!
> Trying to bring fvwm up to date with newer technologies, and to even
> make small improvements has a very high barrier to entry, especially
> when trying to maintain backwards compatibility.  Over the years, we've
> had a loyal number of users who have come to rely on a lot of nuances
> and behaviour which we don't necessarily want to take away.
> 
> To that end, the latest stable release (2.6.7) marks the end of the
> line for fvwm2.  This release is unique because it was my opportunity
> to remove all of the modules which I thought were no longer providing
> anything useful (because the functionality no longer exists outside of
> fvwm in certain applications, or because more widely-used modules in
> fvwm provided equivalent/better funtionality).  Indeed, this releases
> also includes a new default configuration.  I hope you find it useful.
> 
> But I suppose it's fair to say that 2.6.7 won't necessarily appeal to
> some of the dyed-in-the-wool types for whom changes is too much, and/or
> cannot live with that really old module which works Just Fine (tm) as
> it is.  Well, that's OK as well, since we also have everything as it
> was before on the 'fvwm2-stable' branch.  So if you want to use things
> like FvwmTaskBar, for example, that's the release you should use.  This
> branch may, occasionally, receive bug-fixes over time, but certainly
> nothing else.
> 
> In fact, I'm not envisaging any further work happening on fvwm2.X at
> all.  So what does this mean for fvwm?  In order for us to continue to
> make larger changes, we need to be able to break backwards
> compatibility and to make a lot of structural changes.  All of this
> goes towards a lot of other changes we'd like to make.  This therefore
> means that we will look at fvwm3 to do this. This will be different to
> fvwm2.
> 
> We're in the process of setting up fvwm3, and there'll be additional
> announcements when this is complete.
> 
> For a reference on the releases, see the following:
> 
> https://github.com/fvwmorg/fvwm#releases
> 
> Any questions, do please ask.
> 
> Kindly,
> Thomas Adam
> 

Not so much a question as a comment.
Many window managers and desktop environments have tried in vain to create
an automatic menu generator without success, I recommend that fvwm does
not attempt to do this, they break very easily over time.

Also, please retain the win95 configuration script, in fact, they ability
to run a simple script to generate a few different common configurations
is a strong point of many WMs.

Thanks,
David

Re: FVWM: [dominik.v...@gmx.de: Removing libstroke support?]

[David Niklas]

On Mon, 17 Oct 2016 23:01:00 tho...@fvwm.org wrote:
> On Mon, Oct 17, 2016 at 10:57:58PM +0100, Dominik Vogt wrote:
> > On Mon, 17 Oct 2016 22:55:56  wrote:
> > 
> > Does anybody really use libstroke support?  It's resonsible for
> > quite some hardly readably code, and I suspect nobody uses it
> > anymore.  If there's a need for mouse gesture or touchpad support,
> > there must certainly be some other library around that does a
> > better job.
> > 
> > Opinions?
> 
> Ditch it.
Same here.