Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Thomas Adam]

On Thu, Jun 09, 2016 at 06:20:22PM -0600, Jaimos Skriletz wrote:
> On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam  wrote:
> 
> > On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote:
> > Any lasting objections before this is merged and we can move onto the next
> > phase with is introducing a default configuration?
> >
> >
> ​I have some ideas on a default configuration I was working on, but then
> got side tracked with work.
> 
> I may have time in 2-3 weeks I could put into cleaning my configuration I
> was working on, if some help is needed with creating a default
> configuration.

That's fine.  I'll kick this off in a bit, and you can pitch in with ideas
when you're able.

> members of #fvwm) about what should be in the default config is still
> around as that would be useful to look at.

Was I involved with this?  Can you tell me a bit more about it?

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Jaimos Skriletz]

On Thu, Jun 9, 2016 at 4:45 AM, Thomas Adam  wrote:

> On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote:
> Any lasting objections before this is merged and we can move onto the next
> phase with is introducing a default configuration?
>
>
​I have some ideas on a default configuration I was working on, but then
got side tracked with work.

I may have time in 2-3 weeks I could put into cleaning my configuration I
was working on, if some help is needed with creating a default
configuration.

​There will of course be some questions/discussion on what should be in the
default, but I'll save this for when I have time and another thread.

I was also curious if the document that was created many years ago (by
members of #fvwm) about what should be in the default config is still
around as that would be useful to look at.

jaimos



​

​

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Thomas Adam]

On Fri, Jun 03, 2016 at 02:21:51AM +0100, Thomas Adam wrote:
> We put in place something different.  We've had proposals about that in the
> past (Nick Fortune).  I'm wanting to hear from others about what that might
> look like.

Call for last orders, Gentlemen...

Any lasting objections before this is merged and we can move onto the next
phase with is introducing a default configuration?

Kindly,
Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Thomas Adam]

On Thu, Jun 02, 2016 at 09:08:24PM -0400, Dan Espen wrote:
> What they gain, and what it was meant for, is new users curious about
> Fvwm.  Without a config, the casual user will get no where
> and most likely look somewhere else.
> The WM came up and you couldn't even create a window.
> Previous to the Setup Form, we would tell a new user to
> copy/rename the provided sample to get going.
> 
> With your changes, we don't even provide a sample.

Not yet, no.  But again, I consider the this case of having no config to be
less of a problem.

Leaving it with the changes I'm proposing means it is easier to put in place
something else that will provide a default configuration, whatever that may
be.

> > 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.
> 
> Not clear what you mean here.
> 
> Are the multiple files the sample and the Form in the modules directory
> or
> do you mean the potentially multiple files created by the setup form?
> 
> Pretty easy to fix the later.

Your first point.

> So, there is still a question in my mind about how we expect
> a new user to have a user friendly introduction to Fvwm.

We put in place something different.  We've had proposals about that in the
past (Nick Fortune).  I'm wanting to hear from others about what that might
look like.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...Setup Form

[Dan Espen]

Thomas Adam  writes:

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

Simple enough to fix.

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

Well, "*lock" was meant to handle all known clock programs.
Still works for me.

XTerm/rxvt still works for me too, but "*term" might be a good addition.

I use xmag as opposed to all the other magnifiers.

But when I put those apps in there, all anyone could expect
is that they were the apps I was familiar with.  More could be added,
but I suspect EWMH hints covers some of those bases now.

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

What they gain, and what it was meant for, is new users curious about
Fvwm.  Without a config, the casual user will get no where
and most likely look somewhere else.
The WM came up and you couldn't even create a window.
Previous to the Setup Form, we would tell a new user to
copy/rename the provided sample to get going.

With your changes, we don't even provide a sample.

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

Solaris is SunOS (5).
But I admit I've been using Fvwm from even before the Solaris branding.

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

Agree.

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

Not clear what you mean here.

Are the multiple files the sample and the Form in the modules directory
or
do you mean the potentially multiple files created by the setup form?

Pretty easy to fix the later.

> Dan, does this help explain things?  If it does, I'm keen to move this forward
> sooner rather than later.

Allow me to kibbutz as you go.

> [0] I'm an OpenBSD user myself.

Fedora here.
I can see something called "AnotherLevelUp":

http://www.cs.man.ac.uk/~jtl/ALU/

but I don't see it in the repositories.

I get:

[root@home ~]# dnf provides */.fvwm2rc
Error: No Matches found

So, there is still a question in my m

Re: Deprecation: Let's talk once more about removing $STUFF...

[Viktor Griph]

2016-05-19 17:18 GMT+02:00 Thomas Adam :
> As I understand it, FVWM was written with extensibility in mind, and hence
> could be extended through the use of modules.  Although the core of FVWM is
> quite a bit larger now (read: some of the things ther could be modules, but
> hey-ho, one for another time), there are at least quite a few modules which
> change FVWM's behaviour.
>
> Long ago when developers were more active, getting the code into FVWM was
> easier, and perhaps more importantly, the maintainability was easier, since
> the author(s) of the code had a vested interest in keeping it alive.
>
> But those days have ended, as far as I am concerned.  People have lives, and
> have moved on, or simply don't use FVWM anymore.  That's OK, and that's what
> happens with software over time.  But the hole it leaves is almost always
> *somebody else's* mess.  In this case, right now, that mess is mine.

I definitely see you point - and agree that what FVWM should do is to
provide a stable module interface that could support modules. The
modules themselves would not have to be maintained by FVWM developers
and should neither have to follow the release cycle of FVWM. If
someone has an urge to see one of the modules you are removing to
survived it is no problem for that person to set up a separate
repository and maintaining that module outside of the core FVWM.

I'm one of many only FVWM developers who lurk in the shadows. I follow
the mailing lists, but have not been using FVWM myself for some time
since I'm stuck with Windows development at work, and mostly use my
home PC for surfing or gaming, so I've drifted away from X
development. If I'm ever getting back I'm sure I'll need to spend some
time at updating my config files since I'm quite sure Ive been using
FvwmTabs.

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, Jun 02, 2016 at 11:25:22PM +0200, Thomas Funk wrote:
> On 06/02/2016 10:53 PM, Thomas Adam wrote:
> > Perl is my $DAYJOB, I'm more than capable.  It's just low on my list.
> I don't want to offend you with my offer ... I'm only want to relieve you

Oh, not at all.  But there's a lot more to it than just shoe-horning in a
replacement.  For starters:

* Transition away from 5.004 as the minimum version;
* Update the code to use 5.14 at least:
- Do away with subroutine prototypes;
- "use vars" is deprecated;
- "use parent", rather than manipulating @ISA/Exporter directly;
- "use warnings/strictures" everywhere;
* Don't rely on the crappy command generation stuff from FVWM releases to feed
  the perl API ""abstraction"" as we have it now (deprecate create-constants
  and create-commands).

The API needs a lot more thought, and actually needs a redesign, since there's
a very tightly coupling between the FVWM internals and how perllib is designed
to operate.  This is a much larger change but would therefore allow other
modules to operate more transparently with FVWM, without being tied into it.

I'll add these points to the TODO file.

Do not let me discourage you from thinking about this, but I don't want to
just see a GTKx->GTK3 drop-in replacement.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 06/02/2016 10:53 PM, Thomas Adam wrote:

Perl is my $DAYJOB, I'm more than capable.  It's just low on my list.

I don't want to offend you with my offer ... I'm only want to relieve you

But hey, no prob ...

Best,
Thomas

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, Jun 02, 2016 at 10:50:50PM +0200, Thomas Funk wrote:
> That's not completely true because Gtk3-Perl isn't that stable as Gtk2-perl.
> That's the point why I decided to use Gtk2-perl for SimpleGtk2 [0]. There're
> not much examples and documentation available as for Gtk2-perl. Gtk3-perl 
> starts
> to get better but Gtk2 will be the defacto Gtk GUI toolkit for the next years.

It's transitional.  A lot of things are moving from GTK2 -> GTK3, and we
should do the same.  Now.  That means removing GTK2 AFAIAC, since it was
almost never used.  If you've got an example for something which you're using,
that's nice.  It will mean you'll be able to use GTK3 as well.

> > Since perllib was maintained by one person, I don't hold out much hope at 
> > all
> > that someone will come along and do that.  It could very well be me at some
> > point.
> 
> I would help you to maintain fvwm-perlib as you like. I think I have enough
> experience with it.

Perl is my $DAYJOB, I'm more than capable.  It's just low on my list.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 06/02/2016 10:39 PM, Thomas Adam wrote:

It has to transition to GTK3.  Otherwise it's just as stale as GTK1.x is now
in terms of how well it has not been maintained.


That's not completely true because Gtk3-Perl isn't that stable as Gtk2-perl.
That's the point why I decided to use Gtk2-perl for SimpleGtk2 [0]. There're
not much examples and documentation available as for Gtk2-perl. Gtk3-perl starts
to get better but Gtk2 will be the defacto Gtk GUI toolkit for the next years.


Since perllib was maintained by one person, I don't hold out much hope at all
that someone will come along and do that.  It could very well be me at some
point.


I would help you to maintain fvwm-perlib as you like. I think I have enough
experience with it.

Kindly,
Thomas

[0] http://thomasfunk.github.io/SimpleGtk2/files/SimpleGtk2-pm.html
--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, Jun 02, 2016 at 10:35:48PM +0200, Thomas Funk wrote:
> I'm using its code as a base for a Fvwm module to use SimpleGtk2 for my
> Fvwm-Nightshade GUIs invoked by Fvwm. It isn't a problem for me that you have
> removed it but it shows very nice how to create a module derived from
> FVWM::Module::Toolkit. Therefore you should put it back.

It has to transition to GTK3.  Otherwise it's just as stale as GTK1.x is now
in terms of how well it has not been maintained.

Since perllib was maintained by one person, I don't hold out much hope at all
that someone will come along and do that.  It could very well be me at some
point.

Until that point, it's gone.

http://search.cpan.org/~tsch/Gtk3-0.009/lib/Gtk3.pm

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 06/02/2016 09:50 PM, Thomas Adam wrote:

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.


It's sometimes nice to setup a bare config with the most important modules
like FvwmPager and FvwmIconMan. From that point of view this mechanism is
nice.


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.


Btw. you've removed FvwmGtk2 module which is a standalone module which only
provides the possibility to create a Gtk2 application as a Fvwm module.

I'm using its code as a base for a Fvwm module to use SimpleGtk2 for my
Fvwm-Nightshade GUIs invoked by Fvwm. It isn't a problem for me that you have
removed it but it shows very nice how to create a module derived from
FVWM::Module::Toolkit. Therefore you should put it back.


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.


I've started with that some years ago as you know and perhaps this config [0]
could be a good start for a new configuration.

Best,
Thomas

[0] https://github.com/ThomasFunk/Fvwm-Default-Config
--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

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.

Re: Deprecation: Let's talk once more about removing $STUFF...

[Dan Espen]

Thomas Adam  writes:

> On Tue, May 31, 2016 at 08:44:23PM -0400, Dan Espen wrote:
>> If you want to open this can of worms, I think some streamlining might
>> be in order, that's up to you.  I think it's a very good thing that Fvwm
>> has at least a minimal way to create a working configuration without
>> resorting to overblown theming engines mentioned above.
>
> Thanks, Dan.
>
> Having done as you suggested, I've come to the conclusion that all of this can
> go, so I have indeed opened up the can of worms.  ;)  Why?  Well, irrespective
> of whether we should link to something external or not, all of the means by
> which I can end up with a config from FVWM is outdated.  The files themselves
> haven't been maintained in a long time, and it shows as well.
>
> I like the intent of what the Fvwm{Form,Scripts} were getting at, but they're
> two very different ways of trying to do the same thing.  If we want to
> introduce something again, we can do, easily, but we should go back to the
> drawing board about it.
>
> If I have no configuration file (fvwm -f /dev/null) then I'm now presented
> with something very bare-bones indeed.  I think that's OK.  From what I've
> seen a lot of Linux distros (Debian, RPM) have their own config which they
> ship, so the changes of a user being landed in the land of grey and black is
> slimmer than it was.
>
> So for now, all of it has gone.  If we want to pick up from where the old
> FvwmScript/FvwmForm tried to, then we can do, and now we have a clean slate to
> do so.

You started out to eliminate unused modules.
In this case FvwmTaskBar.
This particular module should be eliminated because FvwmButtons+some
other modules is a better choice.  Do we have a good example of a
working taskbar built that way?  Shouldn't we?

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.

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.

Since you are primary developer, feel free to ignore me on this.
As I said, not a big deal to me.

-- 
Dan Espen

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Tue, May 31, 2016 at 08:44:23PM -0400, Dan Espen wrote:
> If you want to open this can of worms, I think some streamlining might
> be in order, that's up to you.  I think it's a very good thing that Fvwm
> has at least a minimal way to create a working configuration without
> resorting to overblown theming engines mentioned above.

Thanks, Dan.

Having done as you suggested, I've come to the conclusion that all of this can
go, so I have indeed opened up the can of worms.  ;)  Why?  Well, irrespective
of whether we should link to something external or not, all of the means by
which I can end up with a config from FVWM is outdated.  The files themselves
haven't been maintained in a long time, and it shows as well.

I like the intent of what the Fvwm{Form,Scripts} were getting at, but they're
two very different ways of trying to do the same thing.  If we want to
introduce something again, we can do, easily, but we should go back to the
drawing board about it.

If I have no configuration file (fvwm -f /dev/null) then I'm now presented
with something very bare-bones indeed.  I think that's OK.  From what I've
seen a lot of Linux distros (Debian, RPM) have their own config which they
ship, so the changes of a user being landed in the land of grey and black is
slimmer than it was.

So for now, all of it has gone.  If we want to pick up from where the old
FvwmScript/FvwmForm tried to, then we can do, and now we have a clean slate to
do so.

Kindly,
Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Dan Espen]

Thomas Adam  writes:

> On Tue, May 31, 2016 at 04:58:57PM -0400, Dan Espen wrote:
>> Fvwm uses FvwmTaskBar, for example in file:
>> 
>> sample.fvwmrc/system.fvwm2rc-sample-95
>> 
>> Those uses need to be eliminated before the module goes.
>
> Thanks.  Removed the whole lot, in favour of out-of-tree configurations via
> fvwm-{themes,crystal}, etc.

I think you missed the part where Fvwm's built in menu creates an Fvwm95
type configuration.  (It uses the files you just removed.)

Take a look at:

fvwm/modules/FvwmScript/Scripts/FvwmScript-Setup95

Look further and you'll find the other files in sample.fvwmrc
are used too.

Let me make some comments here.

Long ago I created the FvwmSetup Form.
When Win95 came out, everyone wanted to go there.
When FvwmScript-Setup95 was created, I was less than happy
because the Script and Form went in 2 different directions.

Sadly, I had other things on my mind and didn't do much about it.

If you want to open this can of worms, I think some streamlining might
be in order, that's up to you.  I think it's a very good thing that Fvwm
has at least a minimal way to create a working configuration without
resorting to overblown theming engines mentioned above.

I suggest a recursive grep to find out where those files are used
or perhaps mentioned in the documentation.

-- 
Dan Espen

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jason Weber]

> > I still have FvwmWinList on a button in case I get some rogue window
> > that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.

> I'd consider that a bug in FvwmProxy, in which case, please fix it.
> FvwmWinList is going the way of the Dodo...

I think "suppression" is a better description than "bug".  Right now,
I can see that I have no proxy for conky, gnome-panel, and FvwmPager.
I think it is because they are sticky.  You can also turn off proxies for
all
iconified windows.  I don't know why you would want to, so I guessing
that was a feature request.

FvwmPager and FvwmProxy are the only modules I use all the time.

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:30 PM, Thomas Funk  wrote:

> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>
>>
>> On 19 May 2016 4:18 p.m., "Thomas Adam" > tho...@fvwm.org>> wrote:
>>  >
>>  > Hey all,
>>  >
>>  > The last time this came up for conversation [0] things were far from
>> ideal.  I
>>  > want to have another conversation about this to see whether it's
>> possible to
>>  > state the case why some modules in FVWM should be removed.
>>
>> Anyone?
>>
>> Thomas Adam
>>
>> Perhaps you shouldn't remove FvwmTaskBar for the moment until someone
> creates a replacement
> with FvwmPager/FvwmIconman.
>
>
​Just remove FvwmTaskBar, there has been ample warning that this was going
to happen. There will be some fall back and it is my guess this is the one
that will get missed the most, but no need to keep it around and it isn't
like waiting is going to make it any less of an issue, I just expect to
hear various issues with it once fvwm 2.6.7 starts to get pushed into repos
of downstream oses.

jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Tue, May 31, 2016 at 2:46 PM, Jason Weber  wrote:

>
> I still have FvwmWinList on a button in case I get some rogue window
> that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.
>
>
​You can also use WindowList and get a list of all the windows (under
certain conditions) in a menu which will serve as a replacement for
FvwmWinList if needed.​


​jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Tue, May 31, 2016 at 01:46:55PM -0700, Jason Weber wrote:
> > I'll leave CPP and M4 for now as I'd like to try something with them.
> 
> Is there something we're supposed to be using to replace FvwmM4?

No.

> Also, I am quietly watching to make sure you don't mention any module
> I am critically dependent on.  We are still out here even when we're silent.
> If you are about to remove something or make a substantial change,
> just make sure to use an appropriately provocative subject line.

I've been more than conservative in my decisions, so I don't think there's too
much to worry about there.

> I still have FvwmWinList on a button in case I get some rogue window
> that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.

I'd consider that a bug in FvwmProxy, in which case, please fix it.
FvwmWinList is going the way of the Dodo...

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Tue, May 31, 2016 at 04:58:57PM -0400, Dan Espen wrote:
> Fvwm uses FvwmTaskBar, for example in file:
> 
> sample.fvwmrc/system.fvwm2rc-sample-95
> 
> Those uses need to be eliminated before the module goes.

Thanks.  Removed the whole lot, in favour of out-of-tree configurations via
fvwm-{themes,crystal}, etc.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jason Weber]

> I'll leave CPP and M4 for now as I'd like to try something with them.

Is there something we're supposed to be using to replace FvwmM4?
I set it up in my .fvwm2rc 25 years ago and it seems to still be working
fine.
As far as I recall, it is just include(), define(), ifdef(), and ifelse().

Also, I am quietly watching to make sure you don't mention any module
I am critically dependent on.  We are still out here even when we're silent.
If you are about to remove something or make a substantial change,
just make sure to use an appropriately provocative subject line.

I still have FvwmWinList on a button in case I get some rogue window
that FvwmProxy doesn't represent, but, honestly, it isn't a big deal.

Re: Deprecation: Let's talk once more about removing $STUFF...

[Dan Espen]

Thomas Adam  writes:

> On 31 May 2016 9:31 p.m., "Thomas Funk"  wrote:
>>
>> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>>
>>>
>>> On 19 May 2016 4:18 p.m., "Thomas Adam"  > wrote:
>>> >
>>> > Hey all,
>>> >
>>> > The last time this came up for conversation [0] things were far
> from ideal. I
>>> > want to have another conversation about this to see whether it's
> possible to
>>> > state the case why some modules in FVWM should be removed.
>>>
>>> Anyone?
>>>
>>> Thomas Adam
>>>
>> Perhaps you shouldn't remove FvwmTaskBar for the moment until
> someone creates a replacement
>> with FvwmPager/FvwmIconman.
>
> It's already present in the form of FvwmButtons and FvwmIconMan.
> There's nothing to do, other than to point people at relevant
> implementations. Fvwm-{themes,crystal} notwithstanding, and this is
> not a reason to delay such a thing.
>
> No one has been able to assess the impact of this, and hence I'd say,
> the loss of FvwmTaskbar is not going to be missed. Even if were, it's
> still easily mitigated. 

Fvwm uses FvwmTaskBar, for example in file:

sample.fvwmrc/system.fvwm2rc-sample-95

Those uses need to be eliminated before the module goes.

-- 
Dan Espen

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On 31 May 2016 9:31 p.m., "Thomas Funk"  wrote:
>
> On 05/31/2016 09:30 PM, Thomas Adam wrote:
>
>>
>> On 19 May 2016 4:18 p.m., "Thomas Adam" > wrote:
>>  >
>>  > Hey all,
>>  >
>>  > The last time this came up for conversation [0] things were far from
ideal.  I
>>  > want to have another conversation about this to see whether it's
possible to
>>  > state the case why some modules in FVWM should be removed.
>>
>> Anyone?
>>
>> Thomas Adam
>>
> Perhaps you shouldn't remove FvwmTaskBar for the moment until someone
creates a replacement
> with FvwmPager/FvwmIconman.

It's already present in the form of FvwmButtons and FvwmIconMan. There's
nothing to do, other than to point people at relevant implementations.
Fvwm-{themes,crystal} notwithstanding,  and this is not a reason to delay
such a thing.

No one has been able to assess the impact of this, and hence I'd say, the
loss of FvwmTaskbar is not going to be missed. Even if were, it's still
easily mitigated.

Thomas Adam

> All others (FvwmDragWell, FvwmGTK, FvwmIconBox, FvwmSave / FvwmSaveDesk,
FvwmTheme, FvwmWharf,
> FvwmWinList, FvwmTabs, FvwmWindowMenu) should be removed if code is
broken, deprecated or
> replaceable.
>
>
> -- Thomas --
>
> --
> --
> "Two things are infinite: the universe and human stupidity; and I'm not
sure about the the universe."   --   Albert Einstein
>

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Funk]

On 05/31/2016 09:30 PM, Thomas Adam wrote:


On 19 May 2016 4:18 p.m., "Thomas Adam" mailto:tho...@fvwm.org>> wrote:
 >
 > Hey all,
 >
 > The last time this came up for conversation [0] things were far from ideal.  
I
 > want to have another conversation about this to see whether it's possible to
 > state the case why some modules in FVWM should be removed.

Anyone?

Thomas Adam


Perhaps you shouldn't remove FvwmTaskBar for the moment until someone creates a 
replacement
with FvwmPager/FvwmIconman.

All others (FvwmDragWell, FvwmGTK, FvwmIconBox, FvwmSave / FvwmSaveDesk, 
FvwmTheme, FvwmWharf,
FvwmWinList, FvwmTabs, FvwmWindowMenu) should be removed if code is broken, 
deprecated or
replaceable.


-- Thomas --

--
--
"Two things are infinite: the universe and human stupidity; and I'm not sure about 
the the universe."   --   Albert Einstein

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On 19 May 2016 4:18 p.m., "Thomas Adam"  wrote:
>
> Hey all,
>
> The last time this came up for conversation [0] things were far from
ideal.  I
> want to have another conversation about this to see whether it's possible
to
> state the case why some modules in FVWM should be removed.

Anyone?

Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, May 19, 2016 at 01:07:26PM -0400, Dan Espen wrote:
> Seemed like a valid use.  Not sure if our condition testing
> can do the same thing:
> 
> #if PLANES > 8
> + TitleStyle LeftJustified\
> ActiveUp (\
>   HGradient 128 2 rgb:FF/00/00 70 rgb:88/00/88 30 rgb:00/00/ff)\
> Inactive (\
>   Solid Navy -- flat)\
> ActiveDown (\
>   HGradient 128 2 rgb:FF/00/00 50 rgb:88/00/88 50 rgb:00/00/ff)
> #else
> + TitleStyle  LeftJustified ActiveUp (Solid Navy -- flat) \
>   ActiveDown (Solid Navy -- flat) \
>   Inactive (Solid grey51 -- flat)
> #endif

Yes.  As in:

+ I Test (EnvIsSet PLANES) DoSomethingIfPlanesSet
+ I TestRc (NoMatch) DoSomethingIfPlanesNotSet

I'll leave CPP and M4 for now as I'd like to try something with them.

So, the question is, should I merge these deprecations to master?

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, May 19, 2016 at 08:27:54PM +0200, Stefan Blachmann wrote:
> Personally I'd rather prefer to keep FvwmWinList as I use it myself
> and am not really eager spend time to modify my config, as I use it as
> a sort of life saver rarely only when I lost track where a particular
> window is.

I'm afraid you're in the minority here.  Learning how to use FvwmIconMan in
preference is not too dissimilar and would be down to you to figure out.
Should you want help with that, ask, but I'd expect you to have tried
yourself, to at least work out what you're personally after first of all.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, May 19, 2016 at 11:57:17AM -0600, Jaimos Skriletz wrote:
> ​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be
> used instead, but my experience is FvwmIconMan was not easy to create a
> config that behaved like the simple FvwmTaskBar, and I still think many are
> using this because it is so much easier to configure than FvwmIconMan for a
> TaskBar (despite it is also buggy, I still see it used a lot).
> 
> I think removing this will cause some (or maybe more than some) discussion
> on the main fvwm mailing list once people notice it is gone who have been
> using it, including some not so happy fvwm users.

So I'm not interested in this.  If necessary a configuation using FvwmButtons
and FvwmIconMan can be written for this.  But I won't be doing it unless it's
really a popular thing, and even then, pointing people to fvwm-themes would
do.  There's a few examples in there.

But I won't be doing this at all upfront.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Thomas Adam]

On Thu, May 19, 2016 at 01:07:26PM -0400, Dan Espen wrote:
> I'm not using anything else you mentioned, so no problem.
> But I'm unsure what problem some of them cause just hanging around.

They're not used, and are bit-rotting.  Almost all of the Fvwm modules I've
listed here fall into the category.

> Back when session management became a feature, someone decided we
> needed FvwmSave, etc.  Never heard a problem reported for it,
> so I just ignored it.

That's because they're unusable.  They rely on WM_COMMAND which a lot of newer
applications (those which aren't the arcane native X ones) don't use that
XHint, and hence FvwmSave can do nothing for them.

What I'm hearing here is you're not opposed to the idea.

Thanks.

-- Thomas Adam

Re: Deprecation: Let's talk once more about removing $STUFF...

[Stefan Blachmann]

In addition to what Jaimos said, at least in my impression FvwmWinList
is still being used much. I saw it in quite a few out-of-the-box fvwm
configs supplied by various linux and other unixoid OS distros. So I
guess dropping it could cause some work for maintainers etc. Thus I
think Jaimos' idea of at least providing a config guiding how to
replace it with FvwmIconMan quickly is very good. Perhaps this would
save many people some time studying the man page etc.

Personally I'd rather prefer to keep FvwmWinList as I use it myself
and am not really eager spend time to modify my config, as I use it as
a sort of life saver rarely only when I lost track where a particular
window is.

And finally I would like to thank Thomas and all others for the
greatly appreciated work to improve FVWM!

On 5/19/16, Jaimos Skriletz  wrote:
> On Thu, May 19, 2016 at 9:18 AM, Thomas Adam  wrote:
>
>>
>> * FvwmTaskBar -- Use FvwmIconMan.
>>
>>
> ​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be
> used instead, but my experience is FvwmIconMan was not easy to create a
> config that behaved like the simple FvwmTaskBar, and I still think many are
> using this because it is so much easier to configure than FvwmIconMan for a
> TaskBar (despite it is also buggy, I still see it used a lot).
>
> I think removing this will cause some (or maybe more than some) discussion
> on the main fvwm mailing list once people notice it is gone who have been
> using it, including some not so happy fvwm users.
>
> My suggestion is in order to remove FvwmTaskBar we should provide a config
> that will provide something similar FvwmTaskBar using FvwmIconMan that
> people can just take and slightly modify. This way when someone comes to
> the list (or irc) and starts saying where did my FvwmTaskBar go, we can
> just point them to a config and they can be on their way.
>
>
>> I've also gone and removed these two directories:
>>
>> debian/
>> rpm/
>>
>> AFAIAC, these shouldn't be part of a window manager, and it is
>> unreasonable to
>> expect maintainers of a window manager to understand package management
>> to
>> any
>> degree.  All downstream do when they package FVWM is remove these
>> directories
>> and replace them with their own (newer) versions, since ours are just
>> left
>> to
>> bitrot.  If you want to build packages of your own, do so.  But it's
>> peripheral to FVWM.
>>
>
> ​I can't speak for the rpm/ directory, but I know that in debian the
> directory is removed by the debian maintainer and replaced by his own that
> fits the modern debian standards, passes all the package auditing tools,
> etc.​
>
> ​I also think that if someone wanted to build their own custom .deb, the
> debian/ is outdated enough that it shouldn't be used.
>
> If someone really wanted to build their own .deb over using the one
> provided by debian I would suggest pointing them at debian_helper. This can
> autogenerate a simple debian/ dir that is probably better than the one
> provided by fvwm and is fairly automatic. I could look into writing up a
> little doc on how to do this.​ The other option is to just use the debian/
> from the debian source package, but then you have to deal with debian
> patches.
>
>
> Those are my two cents,
>
> jaimos
>

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 11:07 AM, Dan Espen  wrote:

> Just had an opportunity to look at Fvwm.Org, it looks pretty nice.
> I thought we were going to retain the themeing, but I don't see it.
> Not a real problem.
> ​
>

​Being a static site and only using html and javascript it makes being able
to switch themes not as practical as it was when the site was php (also
makes the site way easier to maintain and update).​ So the initial build of
the new site was just to remove the php and use a static site builder
(jekyll) to build the site with a single theme.

I still had in my mind that themes would be nice to change. I built the
site using mostly css, so a simple change to the theme is to just change
the css file, but this requires three things.

​1) Someone to build a new theme .css file.
2) Figuring out how to use javascript to load the correct .css file.
3) Deal with any issues that arise. Even though I tried to do everything
with .css, more than just the .css files
may need to be modified when trying to write a new theme to get it to work
correctly.

So as of now (and mostly likely for a while) there won't be themes. But
they could be added if someone wanted to invest the time.

jaimos​

Re: Deprecation: Let's talk once more about removing $STUFF...

[Jaimos Skriletz]

On Thu, May 19, 2016 at 9:18 AM, Thomas Adam  wrote:

>
> * FvwmTaskBar -- Use FvwmIconMan.
>
>
​I do agree that FvwmTaskBar should be deprecated and FvwmIconMan should be
used instead, but my experience is FvwmIconMan was not easy to create a
config that behaved like the simple FvwmTaskBar, and I still think many are
using this because it is so much easier to configure than FvwmIconMan for a
TaskBar (despite it is also buggy, I still see it used a lot).

I think removing this will cause some (or maybe more than some) discussion
on the main fvwm mailing list once people notice it is gone who have been
using it, including some not so happy fvwm users.

My suggestion is in order to remove FvwmTaskBar we should provide a config
that will provide something similar FvwmTaskBar using FvwmIconMan that
people can just take and slightly modify. This way when someone comes to
the list (or irc) and starts saying where did my FvwmTaskBar go, we can
just point them to a config and they can be on their way.


> I've also gone and removed these two directories:
>
> debian/
> rpm/
>
> AFAIAC, these shouldn't be part of a window manager, and it is
> unreasonable to
> expect maintainers of a window manager to understand package management to
> any
> degree.  All downstream do when they package FVWM is remove these
> directories
> and replace them with their own (newer) versions, since ours are just left
> to
> bitrot.  If you want to build packages of your own, do so.  But it's
> peripheral to FVWM.
>

​I can't speak for the rpm/ directory, but I know that in debian the
directory is removed by the debian maintainer and replaced by his own that
fits the modern debian standards, passes all the package auditing tools,
etc.​

​I also think that if someone wanted to build their own custom .deb, the
debian/ is outdated enough that it shouldn't be used.

If someone really wanted to build their own .deb over using the one
provided by debian I would suggest pointing them at debian_helper. This can
autogenerate a simple debian/ dir that is probably better than the one
provided by fvwm and is fairly automatic. I could look into writing up a
little doc on how to do this.​ The other option is to just use the debian/
from the debian source package, but then you have to deal with debian
patches.


Those are my two cents,

jaimos

Re: Deprecation: Let's talk once more about removing $STUFF...

[Dan Espen]

Thomas Adam  writes:

> Hey all,
>
> The last time this came up for conversation [0] things were far from ideal.  I
> want to have another conversation about this to see whether it's possible to
> state the case why some modules in FVWM should be removed.
>
> As I understand it, FVWM was written with extensibility in mind, and hence
> could be extended through the use of modules.  Although the core of FVWM is
> quite a bit larger now (read: some of the things ther could be modules, but
> hey-ho, one for another time), there are at least quite a few modules which
> change FVWM's behaviour.
>
> Long ago when developers were more active, getting the code into FVWM was
> easier, and perhaps more importantly, the maintainability was easier, since
> the author(s) of the code had a vested interest in keeping it alive.
>
> But those days have ended, as far as I am concerned.  People have lives, and
> have moved on, or simply don't use FVWM anymore.  That's OK, and that's what
> happens with software over time.  But the hole it leaves is almost always
> *somebody else's* mess.  In this case, right now, that mess is mine.
>
> In looking at FVWM, I'm really trying to tidy up the rough edges.  You can see
> my progress in Git.  Indeed, to make that easier, an easy win is to *reduce*
> the amount of things which have to be touched by these cleanups.   This means
> removing modules.
>
> And let us be clear here, this isn't anything new.  We (as developers) know
> there's a lot of old cruft kicking around, but no one has had the balls to
> remove it for fear of breaking things for other users.  That's cool, but
> equally, I want that trade-off to always be about what's maintainable,
> long-term.
>
> So to that end, I've started work to deprecate those modules I really do think
> can go, because their functionality is either covered by other FVWM modules,
> or could easily be replaced by readily available third-party tools (where that
> functionality is a minor part of FVWM).  So what am I proposing, and why?
> Here's the list, with rationale:
>
> * FvwmDragWell -- never could get this to work.  The XDnD specification is
>   interesting, but the applications listening to this are also dead.
>
> * FvwmGTK -- GTK1.x is completely deprecated.  Goodbye GTK!
>
> * FvwmIconBox -- use the IconBox style for similar grouping of icons.
>
> * FvwmSave / FvwmSaveDesk -- use a session manager.  Also, a lot of
>   applications don't use WM_COMMAND anymore.
>
> * FvwmTaskBar -- Use FvwmIconMan.
>
> * FvwmTheme -- it's in the core of FVWM.
>
> * FvwmWharf -- use FvwmButtons.
>
> * FvwmWinList -- use FvwmIconMan.
>
> * FvwmTabs -- use 'tabbed' from suckless.
>
> * FvwmWindowMenu -- someone's experiment.

Look in the samples directory.
We configure lots of that stuff.

> As you can see, I've spared FvwmCPP and FvwmM4 for now, but I did break out
> into a cold sweat as to whether they should be removed.  I left them in
> because I want to unify them and expand on the idea a little more.

I'm using FvwmCpp but I don't need it anymore.
At one time I was sharing a configuration between
PC and Sun hardware with 8 bit color.

Seemed like a valid use.  Not sure if our condition testing
can do the same thing:

#if PLANES > 8
+ TitleStyle LeftJustified\
ActiveUp (\
  HGradient 128 2 rgb:FF/00/00 70 rgb:88/00/88 30 rgb:00/00/ff)\
Inactive (\
  Solid Navy -- flat)\
ActiveDown (\
  HGradient 128 2 rgb:FF/00/00 50 rgb:88/00/88 50 rgb:00/00/ff)
#else
+ TitleStyle  LeftJustified ActiveUp (Solid Navy -- flat) \
  ActiveDown (Solid Navy -- flat) \
  Inactive (Solid grey51 -- flat)
#endif

>
> I've also gone and removed these two directories:
>
> debian/
> rpm/
>
> AFAIAC, these shouldn't be part of a window manager, and it is unreasonable to
> expect maintainers of a window manager to understand package management to any
> degree.  All downstream do when they package FVWM is remove these directories
> and replace them with their own (newer) versions, since ours are just left to
> bitrot.  If you want to build packages of your own, do so.  But it's
> peripheral to FVWM.
>
> Thoughts, comments, and suggestions, please.  I'm keen to get the discussion
> moving and come to a consensus.  Note that if people really, _really_ want
> these modules, then having these maintained externally to FVWM is easy to do,
> and actively encouraged.

I'm not using anything else you mentioned, so no problem.
But I'm unsure what problem some of them cause just hanging around.
Back when session management became a feature, someone decided we
needed FvwmSave, etc.  Never heard a problem reported for it,
so I just ignored it.

Just had an opportunity to look at Fvwm.Org, it looks pretty nice.
I thought we were going to retain the themeing, but I don't see it.
Not a real problem.

-- 
Dan Espen