Re: FVWM: The Future of fvwm Development

[Dominik Vogt]

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

[Jaimos Skriletz]

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

[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: The Future of fvwm Development

[Dominik Vogt]

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

Re: FVWM: The Future of fvwm Development

[Harald Dunkel]

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

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

Re: FVWM: The Future of fvwm Development

[Marco Maggi]

Thomas Adam wrote:

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

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