On Thu, Jun 02, 2016 at 03:07:27PM -0400, Dan Espen wrote:
> In the case of FvwmForm and the Setup Form, I think you've eliminated
> something that I remember at least one poster using. It's not the
> best part of Fvwm, but the Setup Form gets a certain class of users
> from befuddled to a working start. It's not a big deal for me
> but I don't see that removing it gains anything. I don't agree
> that it was outdated.
It is outdated for two reasons alone:
1. The syntax alone is arcane by FVWM's standards. For instance:
Next [*] ...
versus:
Next (...)
2. The list of applications (via menus or Style lines) are from the arc, and
no longer reflect the de facto set of programs typically installed along
with most distributions. The only outliers I can think of here might be a
few of the major BSDs.
Both the above tell me that FVWM has rested on its laurels for far too long.
Those people who do decide to use the mechanism of what the Setup forms
provide, clearly can't be relying on much. So what do they gain by using
these configs? Maybe it's the FvwmButtons configuration? I can't say, but
I'd guess that over anything else.
> I have no idea what the distros do. I started as a SunOS user
> and a sense of loyalty makes me want to continue to serve those
> users.
That's rather cute, but SunOS died a long time ago, especially since Solaris
pretty much took over that market even by the time I poked around such
machines. I just can't justify supporting that kind of idea any more.
> Since you are primary developer, feel free to ignore me on this.
> As I said, not a big deal to me.
That's humbling that you'd see me as such, but I am by no means ignoring you,
rather I'm trying to open your eyes to what most of the other players are
doing, and hence how the applications that typically came with
SunOS/Solaris/BSD are in the minority, as are the number of users of those
systems/applications as well.
It always comes back down to what's realistically maintainable, and what
*should* be maintainable by those developers who choose to work on FVWM. Part
of that is about setting expectations on the remit of FVWM as a window
manager, and the environment it is typically deployed in. For that, we have
to look towards the common set of Linux distributions, more than anything else
[0].
This entire set of work did indeed start with deprecating modules, and that's
fine. What this has proven to me (with your helpful guidance) is that we can
go further in the efforts I've started, because of certain modules being
deprecated. As far as the internal configuration goes, and having FVWM
provide its own set of values to the user in the case where they have no
config, should be a clean slate for those people(s) who wish to work on such a
thing. This is what I see as a good provision, and although that might be
seen as heavy-handed, the impact in the long-term will be beneficial.
So given all of that, I'm inclined to proceed---but I am not personally
interested in providing a new configuration myself, but I am willing to offer
mentoring and help to people who want to work on this, as I have a better idea
on how to do that which isn't as invasive as it has been in the past in terms
of spreading out over multiple files. Should anyone want to chat about this,
I'm all ears.
Dan, does this help explain things? If it does, I'm keen to move this forward
sooner rather than later.
Kindly,
-- Thomas Adam
[0] I'm an OpenBSD user myself.
