Re: FVWM: The Future of fvwm Development

On Fri, 18 Nov 2016 12:18:15
Jaimos Skriletz <[email protected]> wrote:

> On Wed, Nov 16, 2016 at 4:43 PM, David Niklas <[email protected]> wrote:
> > 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.

> 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...

> 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).
>
> > 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