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

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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.

[fvwmorg/fvwm] 798983: Remove sample\.fvwmrc

2016-05-31 Thread GitHub 
  Branch: refs/heads/ta/deprecate
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 79898382bfa7c8361679f06a1cbcb6d0b2f85ecd
  
https://github.com/fvwmorg/fvwm/commit/79898382bfa7c8361679f06a1cbcb6d0b2f85ecd
  Author: Thomas Adam 
  Date:   2016-05-31 (Tue, 31 May 2016)

  Changed paths:
M Makefile.am
M configure.ac
R sample.fvwmrc/.cvsignore
R sample.fvwmrc/DecorMwm
R sample.fvwmrc/DecorWin95
R sample.fvwmrc/Makefile.am
R sample.fvwmrc/decor_examples
R sample.fvwmrc/new-features
R sample.fvwmrc/system.fvwm2rc
R sample.fvwmrc/system.fvwm2rc-sample-1
R sample.fvwmrc/system.fvwm2rc-sample-2
R sample.fvwmrc/system.fvwm2rc-sample-95

  Log Message:
  ---
  Remove sample\.fvwmrc

These configuration examplea are old, and reflect an almost by-gone era of
FVWM.  Instead, should people want some example, these can be found
out-of-tree in the likes of fvwm-themes or fvwm-crystal.

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

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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...

2016-05-31 Thread 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

[fvwmorg/fvwm] 574e27: Remove references to Setup forms/script

2016-05-31 Thread GitHub 
  Branch: refs/heads/ta/deprecate
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 574e273d2f6471e2041ece41e67513da0ded8bd9
  
https://github.com/fvwmorg/fvwm/commit/574e273d2f6471e2041ece41e67513da0ded8bd9
  Author: Thomas Adam 
  Date:   2016-06-01 (Wed, 01 Jun 2016)

  Changed paths:
R fvwm/ConfigFvwmSetup
M fvwm/Makefile.am
M fvwm/fvwm.c
R modules/FvwmForm/FvwmForm-Setup.in
M modules/FvwmForm/Makefile.am
R modules/FvwmScript/Scripts/FvwmScript-Setup95.in
M modules/FvwmScript/Scripts/Makefile.am
R modules/FvwmScript/Scripts/fvwm-script-setup95.pl
R modules/FvwmScript/Scripts/system.fvwmrc

  Log Message:
  ---
  Remove references to Setup forms/script

No longer should we try and "help" the user generate a barebones configuration
file.  This is better done through other, more maintainable, means.


  Commit: 06f1e70819135e66b764071e2b6e7efd0aaf86cd
  
https://github.com/fvwmorg/fvwm/commit/06f1e70819135e66b764071e2b6e7efd0aaf86cd
  Author: Thomas Adam 
  Date:   2016-06-01 (Wed, 01 Jun 2016)

  Changed paths:
M INSTALL.fvwm
M Makefile.am
R vms/README
R vms/config.h
R vms/fvwmrc.dat
R vms/make_fvwm.mms
R vms/vms.c
R vms/vms.h
R vms/vms_shareables.opt

  Log Message:
  ---
  Remove references to VMS

This hasn't been used in years.


  Commit: 1619ad5f5353229bc61bb4ea63229f725393a104
  
https://github.com/fvwmorg/fvwm/commit/1619ad5f5353229bc61bb4ea63229f725393a104
  Author: Thomas Adam 
  Date:   2016-06-01 (Wed, 01 Jun 2016)

  Changed paths:
M Makefile.am
M configure.ac
R debian/.cvsignore
R debian/ChangeLog
R debian/Makefile.am
R debian/README.Debian
R debian/conffiles
R debian/control.in
R debian/copyright
R debian/dirs
R debian/docs
R debian/fvwm.menu
R debian/fvwm.menu-method
R debian/postinst
R debian/postrm
R debian/prerm
R rpm/.cvsignore
R rpm/ChangeLog
R rpm/Makefile.am
R rpm/fvwm.spec.in

  Log Message:
  ---
  Remove debian/ and rpm/ directories

The package-specific mechanisms to build FVWM for deployment on Debian or
RPM-based Linux distributions are best left to the packagers themselves.
Having this is in FVWM isn't helpful to the packagers, and arguably has
nothing to do with window management.

For those developers who don't even have a Linux platform, maintaining these
files is impossible.


Compare: https://github.com/fvwmorg/fvwm/compare/79898382bfa7...1619ad5f5353

[fvwmorg/fvwm] db6543: Remove references to GTK

2016-05-31 Thread GitHub 
  Branch: refs/heads/ta/deprecate
  Home:   https://github.com/fvwmorg/fvwm
  Commit: db65432642674c23bc4d1ee075be6986a69810c9
  
https://github.com/fvwmorg/fvwm/commit/db65432642674c23bc4d1ee075be6986a69810c9
  Author: Thomas Adam 
  Date:   2016-06-01 (Wed, 01 Jun 2016)

  Changed paths:
M INSTALL.fvwm
M acinclude.m4
M bin/fvwm-config.in
M bin/fvwm-menu-desktop.in
M bin/fvwm-perllib.in
M configure.ac
M doc/modules.html
R modules/FvwmDebug/FvwmGtkDebug.1
R modules/FvwmDebug/FvwmGtkDebug.in
M modules/FvwmDebug/Makefile.am
M perllib/FVWM/Module.pm.in
R perllib/FVWM/Module/Gtk.pm
R perllib/FVWM/Module/Gtk2.pm
M perllib/FVWM/Module/Makefile.am
M perllib/FVWM/Module/Toolkit.pm
M perllib/General/FileSystem.pm
M tests/perl/README
R tests/perl/module-gtkflash
R tests/perl/module-gtkwinlist
M tests/perl/show-commands

  Log Message:
  ---
  Remove references to GTK

No longer used.  GTK is so old it's not even packaged anymore.  GTK2 support
from perllib is something which is flaky at best, and if it's wanted for the
future, should be reworked to use Gtk3.

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

2016-05-31 Thread 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