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

[fvwmorg/fvwm] 59be5a: TODO: add section for perllib

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 59be5aedd7ba55e2aa1887f4bb356588934ce0f8
  
https://github.com/fvwmorg/fvwm/commit/59be5aedd7ba55e2aa1887f4bb356588934ce0f8
  Author: Thomas Adam 
  Date:   2016-06-02 (Thu, 02 Jun 2016)

  Changed paths:
M TODO.md

  Log Message:
  ---
  TODO: add section for perllib

Make some observations on how to improve perllib.

[fvwmorg/fvwm] 0cb90a: Merge pull request #7 from fvwmorg/ta/todo

[GitHub]

  Branch: refs/heads/ta/todo
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 0cb90aa0a2015691e964b5de6aeba9411286e1a6
  
https://github.com/fvwmorg/fvwm/commit/0cb90aa0a2015691e964b5de6aeba9411286e1a6
  Author: Thomas Adam 
  Date:   2016-06-02 (Thu, 02 Jun 2016)

  Changed paths:
M TODO.md

  Log Message:
  ---
  Merge pull request #7 from fvwmorg/ta/todo

TODO: Fix formatting


  Commit: 59be5aedd7ba55e2aa1887f4bb356588934ce0f8
  
https://github.com/fvwmorg/fvwm/commit/59be5aedd7ba55e2aa1887f4bb356588934ce0f8
  Author: Thomas Adam 
  Date:   2016-06-02 (Thu, 02 Jun 2016)

  Changed paths:
M TODO.md

  Log Message:
  ---
  TODO: add section for perllib

Make some observations on how to improve perllib.


Compare: https://github.com/fvwmorg/fvwm/compare/e227684aa587...59be5aedd7ba

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 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: Questions how to contribute to fvwmorg.github.io

[Thomas Adam]

On 2 Jun 2016 5:27 p.m., "Thomas Funk"  wrote:
>
> On 06/02/2016 06:09 PM, Thomas Adam wrote:
>>
>> You should read my previous emails on documentation to this list.
>
>
> you refer to
https://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15756.html ?

Yes.

>
>> You should look at:
>>
>> manpages/fvwm.rst
>
>
> So the preferred format is rst, right?

Yes.

Thomas Adam

Re: Questions how to contribute to fvwmorg.github.io

[Thomas Funk]

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

You should read my previous emails on documentation to this list.


you refer to 
https://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15756.html ?


You should look at:

manpages/fvwm.rst


So the preferred format is rst, right?

Re: Questions how to contribute to fvwmorg.github.io

[Thomas Adam]

On 2 June 2016 at 17:06, Thomas Funk  wrote:
> No prob. Which documents you've meant? the manpages in bin ? Or others?
> If so, how should I added the files? For example fvwm.bug.1.in ... create
> a new one named fvwm.bug.md.in?

You should read my previous emails on documentation to this list.

You should look at:

manpages/fvwm.rst

Everything remains as-is for now, including module man pages,

> Another question is if there're some manpages which aren't important enough
> to convert (e.g. fvwm.bug.1.in ;-) )?

See above.

-- Thomas Adam

Re: Questions how to contribute to fvwmorg.github.io

[Thomas Funk]

On 06/02/2016 05:49 PM, Thomas Adam wrote:

On 2 June 2016 at 16:38, Thomas Funk  wrote:

Hi Jaimos,

I want to implement the missing 'allCommands' and the linkings in
fvwm.man to the website. I've cloned master and created a new branch
tf/allCommands-linked-fvwm.man


I'd rather you didn't do this just yet.  If anything, I'd much rather
you contributed to ta/docs-to-md in the fvwm repo, because once that's
done, the means by which we generate HTML documentation will be
different, and simpler.


No prob. Which documents you've meant? the manpages in bin ? Or others?
If so, how should I added the files? For example fvwm.bug.1.in ... create
a new one named fvwm.bug.md.in?

Another question is if there're some manpages which aren't important enough
to convert (e.g. fvwm.bug.1.in ;-) )?

-- Thomas --

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