FVWM: The Future of fvwm Development

[Marco Maggi]

for those of you who don't, it's worth mentioning what the state of fvwm
development holds for the future.

I am a long time fvwm user, and I have not touched my ".fvwmrc" in years
because it just works. Despite that: IMHO it is fine to move forward.

I do not follow the devel mailing list. There is a single very
selfish request I have: continue to allow fvwm to fully configure the
use of the keyboard (I have fvwm intercept the function keys (F1, ...)
to do stuff for me, and it is my killer feature).

One thing I have desired in the past is a more flexible, structured
and clean format for the configuration file. I do not like to push
people into doing work, but what about using an extension language? Is
Lua core small enough?

Thanks for all the work on fvwm.

[Harald Dunkel]

Post by Marco Maggi
I do not follow the devel mailing list. There is a single very
selfish request I have: continue to allow fvwm to fully configure the
use of the keyboard (I have fvwm intercept the function keys (F1, ...)
to do stuff for me, and it is my killer feature).

I would second that, but my 3 top level wishlist items would be:

- please don't make the taskbar mandatory
- please don't make dbus mandatory
- keep it simple

Sorry to say, but in the last few years I have seen so many valuable
projects making a turn into a weird direction. I wouldn't like to see
this happen to fvwm.


Regards
Harri

[Dominik Vogt]

Post by Harald Dunkel

Post by Marco Maggi
I do not follow the devel mailing list. There is a single very
selfish request I have: continue to allow fvwm to fully configure the
use of the keyboard (I have fvwm intercept the function keys (F1, ...)
to do stuff for me, and it is my killer feature).

- please don't make the taskbar mandatory
- please don't make dbus mandatory
- keep it simple

I agree with all of that.

Ciao

Dominik ^_^ ^_^

[David Niklas]

On Fri, 11 Nov 2016 23:13:49 +0000

Hello all,
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.
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

[Jaimos Skriletz]

Post by David Niklas
On Fri, 11 Nov 2016 23:13:49 +0000
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.

Fvwm already provides such ability. The core of fvwm provides users with a
configuration syntax to build menus and fvwm also provides a way for things
to be scripted. So really an automatic menu generator is just a script that
outputs the configuration syntax of fvwm.

Within the core of fvwm is the method to build menus using the configuration
syntax (which is one of the things that is planed to change in the future of
fvwm) and create some sort of menu object that fvwm displays to the user.

Independent of that is the ability to write scripts to generate menus. These
can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build a
wallpaper menu as mentioned in the manpage, to more complicated perl
and now python scripts: fvwm-menu-desktop, fvwm-menu-directory,
fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm.
On top of that you can write you own scripts to automatically generate menus
on your system.

So this ability is already there and I think done in a nice way. In the core it
is just the ability to configure menus (including dynamic ones that are
generated when they are opened) and via fvwms ability to work with scripts,
you can additionally use a script to generate menus.

Yes the scripts sometimes break and need updated, but they are not internal
to fvwm and are only optional for those who want to use them (and maybe fix them
when standards evolve).

Post by David Niklas
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.

This is already gone. Fvwm now provides a default config as a starting point
for users who don't want to write one from scratch. But Fvwm is more a wm
that provides a user with the ability to configure their own setup. Examples
are probably better given through some other means, such as the wiki.

jaimos

[Dominik Vogt]

Post by Jaimos Skriletz

Post by David Niklas
On Fri, 11 Nov 2016 23:13:49 +0000
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.

Fvwm already provides such ability. The core of fvwm provides users with a
configuration syntax to build menus and fvwm also provides a way for things
to be scripted. So really an automatic menu generator is just a script that
outputs the configuration syntax of fvwm.
Within the core of fvwm is the method to build menus using the configuration
syntax (which is one of the things that is planed to change in the future of
fvwm) and create some sort of menu object that fvwm displays to the user.
Independent of that is the ability to write scripts to generate menus. These
can be from simple shell scripts, for i in wallpappers/*.jpg; do ... to build a
wallpaper menu as mentioned in the manpage, to more complicated perl
and now python scripts: fvwm-menu-desktop, fvwm-menu-directory,
fvwm-menu-headlines and fvwm-menu-xlock are all scripts provided by fvwm.
On top of that you can write you own scripts to automatically generate menus
on your system.
So this ability is already there and I think done in a nice way.

Thanks, it's nice to see that people appreciate this work, and
that MissingSubmenuFunction and DynamicPopupAction still work as
they should as they always have. It war certainly fun to code. :-)

Ciao

Dominik ^_^ ^_^

[Stuart Longland]

Post by Dominik Vogt
It war certainly fun to code. :-)

^^^^^

And a fight to debug? ;-)

[d***@mail.com]

On Fri, 18 Nov 2016 12:18:15

Post by Jaimos Skriletz

Post by David Niklas
On Fri, 11 Nov 2016 23:13:49 +0000
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.

Fvwm already provides such ability. The core of fvwm provides users
with a configuration syntax to build menus and fvwm also provides a way
for things to be scripted. So really an automatic menu generator is
just a script that outputs the configuration syntax of fvwm.
Within the core of fvwm is the method to build menus using the
configuration syntax (which is one of the things that is planed to
change in the future of fvwm) and create some sort of menu object that
fvwm displays to the user.

And that is a fine ability.

Post by Jaimos Skriletz
Independent of that is the ability to write scripts to generate menus.
These can be from simple shell scripts, for i in wallpappers/*.jpg;
do ... to build a wallpaper menu as mentioned in the manpage, to more
complicated perl and now python scripts: fvwm-menu-desktop,
fvwm-menu-directory, fvwm-menu-headlines and fvwm-menu-xlock are all
scripts provided by fvwm. On top of that you can write you own scripts
to automatically generate menus on your system.

And this is where things break.
Let me clarify my objection:
Not every program has a *.desktop file, nor is the said file always
correct or well written. This is most often because development has
stopped on the project for whatever reason. I think it's certainly in
good taste to help out these projects, but often times that means that
one distro has a menu entry and the next does not.
It also often times occurs that a menu should have more depth to it and
so a huge amount of programs get stuck on one tab.
And then there are the entries that don't belong where they are, like
photorec in the media/image/picture section when it is a disk recovery
program...

Post by Jaimos Skriletz
So this ability is already there and I think done in a nice way. In the
core it is just the ability to configure menus (including dynamic ones
that are generated when they are opened) and via fvwms ability to work
with scripts, you can additionally use a script to generate menus.
Yes the scripts sometimes break and need updated, but they are not
internal to fvwm and are only optional for those who want to use them
(and maybe fix them when standards evolve).

Post by David Niklas
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.

This is already gone. Fvwm now provides a default config as a starting
point for users who don't want to write one from scratch. But Fvwm is
more a wm that provides a user with the ability to configure their own
setup. Examples are probably better given through some other means,
such as the wiki.

I can't object to the logic, but as a former windowz user I must say that
having to configure literally *everything* at once to get anything near
the look and feel you want (let alone understand it all), is very daunting
and takes months.
Hence, it is often a good idea to provide some sort of pre-built variety
in configs.

Sincerely,
David