Re: FVWM: The Future of fvwm Development
On Fri, 18 Nov 2016 12:18:15 Jaimos Skriletz wrote: > On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > > On Fri, 11 Nov 2016 23:13:49 + > > > > 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
Re: FVWM: The Future of fvwm Development
On 19/11/16 06:22, Dominik Vogt wrote: > It war certainly fun to code. :-) ^ And a fight to debug? ;-) -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature
Re: FVWM: The Future of fvwm Development
On Fri, Nov 18, 2016 at 12:18:15PM -0700, Jaimos Skriletz wrote: > On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > > On Fri, 11 Nov 2016 23:13:49 + > > > > 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 ^_^ ^_^ -- Dominik Vogt
Re: FVWM: The Future of fvwm Development
On Wed, Nov 16, 2016 at 4:43 PM, David Niklas wrote: > On Fri, 11 Nov 2016 23:13:49 + > > 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). > 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
Re: FVWM: The Future of fvwm Development
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: The Future of fvwm Development
On Tue, Nov 15, 2016 at 10:30:10AM +0100, Harald Dunkel wrote: > On 11/12/2016 07:59 AM, Marco Maggi wrote: > > > > 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 I agree with all of that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt