Re: FVWM 2.6.6: slightly out of sync in CVS/fvwm-web: do not commit anything

[Thomas Adam]

On Tue, Mar 15, 2016 at 09:50:31PM +, Thomas Adam wrote:
> All,
> 
> Please be aware that I've started the process of releasing FVWM
> 2.6.6---but note that the CVS tree is currently wedged with me trying
> to tag the release.
> 
> PLEASE DO NOT COMMIT ANYTHING TO CVS
> 
> Otherwise, I'll have a nasty job trying to tag the tree proper.
> 
> I've emailed Jason.  Hopefully he'll respond soon.

Alas, he did not.  More details coming in a new thread.

-- Thomas Adam

FVWM code moved to Github

[Thomas Adam]

Hi all,

I know we've had these discussions in the past, but I think now is the time we
actually do something about them.

I appreciate I've swooped in here, and just done this, but the discussion[0]
happened once before, and given the recent circumstances with the borked CVS
repository, it seemed unfair to leave an impending release hanging.

To that end, I have therefore created an organisation on Github[1] which at
the moment houses what I'm now calling the "official" FVWM repository [2].
This has been converted from the existing FVWM CVS repository (branch-2_6).

The 2.6.6 release now has a tarball uploaded and can be found here[3].

I've not changed fvwm-web, but this will likely be converted as well and put
on [1] in due course.

Note that as an organisation on Github, we have a lot more freedom, in that
more than one person who is a member of the fvwmorg organisation will be able
to do things like handle releases, etc., and that should something happen,
it's not anything in our control that we'd need to worry about.

This has absolutely *no* reflection on Jason at all.  He's spent the last
twenty odd years managing this, and to have all of this go through one person
is not scalable, especially when something goes wrong.  So we should be really
thankful indeed for Jason's efforts, and to note that I hope he continues to
manage the hosting/mailing lists, but the code... that's now better handled by
us.  Moving away from CVS is also long overdue.

So what happens next?  Well, I need existing fvwm-workers who had commit-bit
access to let me know so I can add you to the organisation.

Additionally, I have the following outstanding items:

* Convert fvwm-web, and add to fvwmorg on GH;
* Rip out the existing CVS docs and put something else in place;
* Update the release procedure
* Put our logo on the front of the landing page for fvwmorg on GH

Any questions, do please let me know.

Kindly,
Thomas Adam

[0]
http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/4839/focus=4844
[1] https://github.com/fvwmorg
[2] https://github.com/fvwmorg/fvwm
[3] https://github.com/fvwmorg/fvwm/releases/tag/version-2_6_6

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On 23 March 2016 at 22:21, Dan Espen <des...@verizon.net> wrote:
> I think we're embarking on a lot of work.

Which aspect, specifically?  Note that if you're referring just to the
website, then you might be right---I don't know enough about HTML/CSS
to make that call.  However, it requires someone with enough
understanding to put in place something static which can be hosted on:

https://github.com/fvwmorg/fvwmorg.github.io

Note that this repository as-named, assumes hosting under github.io,
which as I understand it makes thing a lot easier.  Certainly,
removing PHP at this point is definitely a good idea, as we're not
gaining anything from its use any more that CSS can't provide.  I
consider this a good thing.

> As a start I've updated the download instructions to send users to GIT.

OK.

> I know you have the web stuff on GIT but if I make changes there they
> won't get to fvwm.org.

That's OK -- because we can leave what's hosted on fvwm.org
as-is---and start to do something proper with fvwmorg.github.io --
that's your play area.  Go forth and have a blast.  Note that I'm
envisaging something which is self-hosting.  That is to say, something
we can redirect to from fvwm.org -- I see that as a positive thing
indeed.

> Jason, let us know if/when you start pulling the web pages from GIT.

See previous paragraph, I do not think this is the right approach at all.

> I'm pretty good with HTML/CSS.  PHP gives us some nice stuff, but I
> guess we can live without it.

Excellent.  Then set yourself up with a Github account, and let me
know your username, and I'll add you to the fvwmorg and you can do
something with the website repository.

Note that I'm getting married this weekend and will then be away on
honey moon for two weeks.

Kindly,
Thomas Adam

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam" <tho...@fvwm.org> wrote:
> On Fri, Mar 25, 2016 at 03:30:03AM +0100, Thomas Funk wrote:
> > One point:
> > Should we use for development branches a special nomination like 
> > feature_xy, fix_abc?
> > Or only a README which describes the feature/fix?
> 
> I don't think that's necessary.  Typically, you have this pattern:
> 
> initials/rough-branch-description
> 
> Which denotes---by the initials---who's mainly working on the branch,
> so for example:
> 
> ta/fix-clang-warnings
> 
> Should denote that I am working on a branch which fixes warnings from
> Clang.  Similarly, there's also "git branch --edit-description" which
> can further annotate a branch, usually more helpful when issuing
> pull-requests.
> 
> Perhaps in a more wider-context, if a branch ends up not having a
> prefix, it might mean more than one person is working on it.
> 
> But I don't think this really needs documenting.

I think we should. It's better to have such in the documentation so no
questions appears anymore ;)

I can add it to the document, no prob.

> 
> > To think about this point: 
> > http://nvie.com/posts/a-successful-git-branching-model/
> 
> Hmm.  I have always been against this design---this is what lead to the
> whole git-flow set of tooling, which completely locks you in to one way
> of working.  We really do not need anything as complicated as that.

Ok.

> 
> -- Thomas Adam
> 
> -- 
> "Deep in my heart I wish I was wrong.  But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
> 
> 

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam" <tho...@fvwm.org> wrote:
> On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> > I think we should. It's better to have such in the documentation so no
> > questions appears anymore ;)
> > 
> > I can add it to the document, no prob.
> 
> I've added a few words about this, without making this a rule, which
> hopefully people will follow.

That's fine, thanks.

> 
> -- Thomas Adam
> 
> -- 
> "Deep in my heart I wish I was wrong.  But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
> 
> 

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Adam]

On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> I think we should. It's better to have such in the documentation so no
> questions appears anymore ;)
> 
> I can add it to the document, no prob.

I've added a few words about this, without making this a rule, which
hopefully people will follow.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: travis-ci - fvwm.git master branch is "protected"

[Thomas Adam]

On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote:
> Is our strategy for handling of branches and pull requests summarized
> anywhere?

I'm working on that.  Will put that out for tenure later on today.

-- Thomas Adam

travis-ci - fvwm.git master branch is "protected"

[Thomas Adam]

Hi all,

I've to document this formally, but I wanted to let you know of a few options
I've enabled for the "master" branch on the main fvwm Git repository.

All pushes by default (across all branches) will now have Travis CI ran
against them.  Travis is a Continuous Integration tool[1] which allows the
code to be compiled.  If there's any errors, an email is sent out indicating
where the logs can be found[2].  Note that I've set up a matrix job, which
means that _both_ GCC and clang builds have to succeed in order for a build to
be successful.  Over the last few years, I've found clang/LLVM to often give
better indications of problems than GCC, hence why I've enabled both.

Additionally, the master branch (which is where all the stable code intended
for releases ends up) now has protection enabled, which means code will not be
merged there by default, should Travis CI be unable to build it.  This should
help things be more robust, and provides a much more powerful alternative to
the old snapshot mechanisms of yesteryear.  This also means commits directly
on master are discouraged---but that's OK because we've discussed that before.

Any questions, do please let me know.

[1] https://travis-ci.org/
[2] https://travis-ci.org/fvwmorg/fvwm/builds

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On 24 March 2016 at 01:19, Dan Espen <des...@verizon.net> wrote:
>> Thomas Adam <tho...@fvwm.org> writes:
>> See previous paragraph, I do not think this is the right approach at all.
>
> I don't see the difference.
> Right now Jason pulls from CVS to build the pages at fvwm.org.
> He said he's willing to pull from Git instead.
> So, the fvwm-web can be in CVS or GIT, it doesn't matter,
> we just need Jason to decide where he wants to pull from.

Well, it makes all the difference, actually.  There's no need to pull
from anything if the eventual aim is to switch over to the fvwm-web
repository on Github.  One of the reasons for doing this way is it's
not only easy to set up, but it means _we_ as fvwm-workers@ don't need
to have the overhead of hosting it ourselves.

We can leave the fvwm-web version on fvwm.org as is, and just redirect
to fvwmorg.github.io as needed, when the work on the website is
complete.

Note that I can't remember if I've mentioned it already, but the
current "building" phase of the website relies on files from the fvwm
repository.  This will have to change, notably:

* We no longer need a NEWS file or Changelog---yes, we can have NEWS
items, but we'll have to handle that differently to how we do now.
* The FAQ is same; that file should be moved out of the fvwm
repository and into the website repository, ideally converted to use
Markdown---I've already done this to some of the files in the fvwm
repository, should you need an example.

> Well, CONGRATULATIONS.
> That's just great.

Cheers!

> I was married in 1964.
> I'm retiring as of March 31.

Oh, congratulations to you, too!  Do you have plans for your retirement, Dan?

Kindly,
Thomas

FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Sun, Mar 20, 2016 at 08:16:13PM -0400, Dan Espen wrote:
> Moving the Fvwm-web source to Github won't help if we still need to
> publish using Jason's services.

So I've taken a look at this, and have noted the following:

* PHP is used to regenerate the theming components of the site;
* PHP is used to render in from the fvwm repo, the contents of files from:
  
  NEWS
  FAQ

* PHP is used to ensure the theme is applied consistently for the borders for
  "window" (the default theme).

What happens via github.io pages is that static content can be used for this.

I'm starting to think that we have no desire or need for PHP at all for the
website.  Before the use of static HTML generators, etc., it made a lot of
sense.  Additionally, there's a lot one can do with CSS which mitigates the
need for PHP as we're currently using it for the website.

As for the linking in NEWS/FAQ -- the NEWS file in particular is obsoleted,
given that git commit logs can be used to gather the same information.  That
said, if we do retain NEWS for releases, we can just upload a separate set of
notes for that against each release in the releases area of Github [1].  It's
a part of the process.

The FAQ therfore, is part of the website and it should be moved into that
repository.

I've since renamed the fvwm-web repository [2] to match the expectations of
what github.io expects.

I'd really (REALLY!) be interested in someone coming up with a proof of
concept on what a FVWM website might look like using a static HTML generator
that github.io accepts, just to prove my points above.  I won't be doing that
work, however, but if someone does want to give this a go, do please let us
know!

Kindly,
Thomas Adam

[1]  https://github.com/fvwmorg/fvwm/releases
[2]  https://github.com/fvwmorg/fvwmorg.github.io

Re: FVWM code moved to Github

[Thomas Adam]

Hi Jason,

On 21 Mar 2016 17:18, "Jason L Tibbitts III" <ti...@math.uh.edu> wrote:
>
> >>>>> "TA" == Thomas Adam <tho...@fvwm.org> writes:
>
> TA> Yes, and he's not always around, alas.
>
> I'm _almost_ always around.  But I was in New Orleans with crappy
> Internet, and got home to no Internet at all.  (Thanks, Comcast.)  And I
> will be jaunting around Europe for most of July and some of August.

No worries at all. I'm glad you're off enjoying yourself, as well you
should be. Hopefully my point wasn't lost, in that your continued efforts
to support FVWM are a must, it's just that the less you personally need to
do regarding CVS, etc, the better. :-)

Enjoy your trips over the next few months!

Kindly,
Thomas Adam

Re: FVWM code moved to Github

[Thomas Adam]

Hi Jason,

On 21 Mar 2016 17:04, "Jason L Tibbitts III" <ti...@math.uh.edu> wrote:
> I can continue to provide mailing lists in case people still find them
> useful.

Please. We really need those as they're a core part of our infrastructure.
Is there some means by which you'd be able to delegate the list management
side of things, perhaps to myself and/or others, so that you're not the
sole person responsible for maintaining this?

> I can also try to come up with some way to deal with the web
> site, probably by just doing a git pull every few minutes, if people
> want that.

I'm looking at options. The hosting ought not to be a problem if we can
switch to something static. As mentioned in my previous email, that's
preferable.

> Finally, if you end up not liking github for some reason, I am willing
> to try running a Pagure instance.  Pagure is sort of like github, but
> you run it on your own infrastructure.  https://pagure.io

Thanks indeed! I'm hoping that won't be needed. Github ought to suit us
well, once we've ironed out the wrinkles!

Kindly,
Thomas Adam

Re: [fvwmorg/fvwm] c6de88: distcheck2: remove bzip2 archive generation

[Thomas Adam]

Hi,

On 25 March 2016 at 22:57, GitHub <nore...@github.com> wrote:
>   Branch: refs/heads/ta/makedist-no-bzip2
>   Home:   https://github.com/fvwmorg/fvwm
>   Commit: c6de883d85466cdc4c3ee4fc6b8ee3f5c87b8af0
>   
> https://github.com/fvwmorg/fvwm/commit/c6de883d85466cdc4c3ee4fc6b8ee3f5c87b8af0
>   Author: Thomas Adam <tho...@fvwm.org>
>   Date:   2016-03-25 (Fri, 25 Mar 2016)
>
>   Changed paths:
> M Makefile.am
>
>   Log Message:
>   ---
>   distcheck2: remove bzip2 archive generation
>
> Having two sets of generated archives was always wasteful, and the release
> mechanism on Github only allows for zip or tar.gz to be uploaded, making the
> bzip2 archive redundant.

To that end---and to illustrate---I've opened up a PR (pull-request)
for this here:

https://github.com/fvwmorg/fvwm/pull/1

You'll note that I cannot merge this to master, even though I have the
rights, until the build has passed.

As and when people here gain commit-bit rights on the repository,
"Watching" the repository will send out emails to you whenever issues
and/or pull-requests are made.

-- Thomas Adam

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Wed, Mar 23, 2016 at 09:19:18PM -0400, Dan Espen wrote:
> Yep, I'm referring to the web pages.
> I have some CSS based pages at work using themes.
> The themes aren't really important to me, but since
> I doubt GIT is going to give us PHP I think we'll be better off without
> the PHP.

Have a look at this:

https://help.github.com/articles/about-github-pages-and-jekyll/

I think this would be a good way to go, and would reduce the need for us to
potentially write any HTML.

I'm all for using Jekyll in this case!

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Fri, Mar 25, 2016 at 05:37:50PM -0500, Jason L Tibbitts III wrote:
> >>>>> "TA" == Thomas Adam <tho...@fvwm.org> writes:
> 
> TA> I note that it's possible to set up webhooks on repositories on
> TA> Github.  We could use that mechanism to notify you of changes which
> TA> need pulling (and hence, enact some script to do a git-pull), rather
> TA> than polling for them.
> 
> It's probably not worth the effort compared to running a cron job every
> few minutes, but if it's easy then I'll at least try.

I think it's worth exploring, and I've done it before for other notification
things.

> I'm OK with continuing to maintain the site this way, but I'm not going
> to complain if you want to move it all to github.  What I really want to
> do is get away from having to keep the CVS server running.

Of course, I'm surprised you hadn't burned it already.  :)

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Fri, Mar 25, 2016 at 05:21:27PM -0400, Dan Espen wrote:

Hi Dan,

> My first impression, it's Github only.

No, not at all.  It's a way of generating HTML from static templates, which
can be augmented with CSS and extra HTML where necessary.  It just so happens
that what Github hosting offers, is Jekyll support out-of-the-box.

> I lean toward writing plain HTML/CSS with a little JavaScript for
> maximum portability and familiarity.

I'm afraid I lean in the opposite direction.  We are by no means a special
snowflake such that we need to do this from scratch.  One of the aims here is
to be able to take away the need for writing HTML/CSS, not make it an upfront
requirement.

Jaimos Skriletz has also expressed an interest in this (I'ev Cced him), and
he'll post here soon about what his thoughts are, etc.  Hopefully you and he
can work together on this.

> Meanwhile, I committed fvwm-web changes yesterday, but those
> changes have not shown up at fvwm.org.
> 
> Jason, what's up?

Probably the same problem with the main FVWM repo; it's wedged.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Fri, Mar 25, 2016 at 04:43:53PM -0500, Jason L Tibbitts III wrote:
> OK, a manual pull worked.  Turns out that the update script is in my
> home directory, which isn't accessible without a kerberos ticket.
> That's fixed up.

TGTs.  Nice!

> It's a trivial matter to have this do a git pull instead, so if the
> fvwm-web repository on github is up to date, then just let me know and
> I'll switch over.

I keep thinking about that; it's certainly an option.  Perhaps we can trial
this to see how it goes.  I note that it's possible to set up webhooks on
repositories on Github.  We could use that mechanism to notify you of changes
which need pulling (and hence, enact some script to do a git-pull), rather
than polling for them.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Fri, Mar 25, 2016 at 04:00:19PM -0600, Jaimos Skriletz wrote:
> Hello, I have offered to help migrate the fvwm.org to something more
> maintainable as this is something Thomas was wanting help with in #fvwm.

Hi Jaimos,

> I am unsure on a lot of the details about how the current site is
> generated, who controls the domain name fvwm.org, and what any current or
> future plans for the site are, but offered to help in any migration.

So the domain is controlled by "us", but in reality, it's Jason who's
responsible for that.

The fvwm-web documentation (if you can call it that) is found here:

http://fvwm.org/documentation/dev_cvs.php#fvwm-web

Note the scripts (I've mentioned them in other threads here) which link
through to the fvwm repo.  That's an aspect we have to change---what's needed
on the website stays in the website, so if we have to move files into that,
sobeit.

Other than that, everything is in PHP.  When the website is updated (currently
with 'cvs update') then that's polled sometime later via a cronscript which
makes the content live on fvwm.org

> Thomas mentioned wanting to move it to git-hub and generating it from
> markdown using jekyll. So I offered to learn jekyll and convert the current
> site to a static site written in markdown. I was just going to do this all
> locally and see what I am able to get done in figuring out how to customize
> a site with jekyll.
> 
> So this email is just to let you know that I'm looking at what it would
> take to move the site to markdown and use jekyll to generate a static copy.
> I'm thinking once I get it configured a lot of copying and pasting, but
> I'll have to get back to the jekyll docs to figure out more.

Thanks!

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On 26 March 2016 at 01:11, Dan Espen <des...@verizon.net> wrote:
> My account is named "danespen".

I've added you, along with Jaimos as well.  My last official act
before I move onto a few more important things for a bit.

>> Note that I'm getting married this weekend and will then be away on
>> honey moon for two weeks.
>
> Enjoy and don't even think about Fvwm.

What's Fvwm?  ;)

> I've no specific plans for retirement.
> I'm on my own and starting over.

I wish you all the best, Dan.

-- Thomas Adam

Re: FVWM code moved to Github

[Thomas Adam]

On 21 March 2016 at 00:16, Dan Espen <des...@verizon.net> wrote:

Hi Dan,

> I'm not clear on what we can do with Github.
> You mention leaving the web pages and mailing lists on fvwm.org.
>
> For that we need Jason.

Yes, and he's not always around, alas.

> Is it possible to move the whole project to github or some other hosting site?

It is possible, barring mailing lists.  For that we really _do_ need
Jason.  As for hosting of the website, again, Github has the
capability do to that as well---it provides per-project hosting to
have any HTML we like.  But we're not yet in a position to do that,
hence the odd side-shuffle.

Thankfully, for now though, no one's going to notice that side of
things.  When Jason is able to get in contact, then we'll have a
different conversation about what we do with the website.

I see no changes with the mailing lists though---they just work---and
need to, since there's no replacement for them anyway.

Kindly,
Thomas Adam

Re: travis-ci - fvwm.git master branch is "protected"

[Thomas Adam]

On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote:
> Cool. Would it be possible to stick some unit test framework to it as well?

Sorry, Viktor, I missed this point the last time round.  Yes, that's
possible, and depending on how we decide to write unit tests, it can
just hook into the Travis configuration.  This isn't something I'm
wanting to look at myself just yet, but feel free to do so!

> Is our strategy for handling of branches and pull requests summarized
> anywhere?

I was thinking along the lines of this diff:

https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch

Which you can view rendered here:

https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md

What do others think?

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Funk]

"Thomas Adam" <tho...@fvwm.org> wrote:
> I was thinking along the lines of this diff:
> 
> https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch
> 
> Which you can view rendered here:
> 
> https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md
> 
> What do others think?

Thanks Thomas! It is really good and detailed instruction.

One point:
Should we use for development branches a special nomination like feature_xy, 
fix_abc?
Or only a README which describes the feature/fix?

To think about this point: 
http://nvie.com/posts/a-successful-git-branching-model/

-- Thomas --

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> ​​
> 
> On Sat, Mar 26, 2016 at 2:09 PM, Jaimos Skriletz <
> jaimosskril...@boisestate.edu> wrote:
> 
> > Here is what I have created so far
> >
> > http://fvwmforums.org/fvwm.org/
> >
> > The sources are available on github
> >
> > https://github.com/somiaj/fvwmorg.github.io
> >
> >
> ​Update: ​The site is mostly complete and can probably be used as is. Just
> seeing if there is anything that should be added or removed from the site
> (you can check out the copy on fvwmforums.org for the current site).

Thanks!  It looks really good.  We can remove the Changelog section; people
can look at the release descriptions and/or Git history from now on.
Maintaining this is a doubling of effort for absolutely no reason.

In terms of the FAQ, have you (for now) just copied that from $FVWM.GIT/docs/
?  If so, I can remove that file from the FVWM repo and make the one in
fvwmorg.gh.io the authoritative version (as it should be).  Same goes for
removing other files from the FVWM repo too, but that's a different concern.

> I am working on a 'Config' section for the site to include examples of
> decors, icons, sounds and vector buttons (many adapted from fvwm-themes).
> But this is gonna take a while as I play with the different decors.

Maybe.  It might be easier to just direct people towards things like
Fvwm-{Crystal,Nightshade}.  The icons/sounds/etc., can just be forgotten
about.  They're so old, it's not even funny, and if someone *really* wants
those, shove them on the wiki.
 
> I also think adding some feature to the buttons on the page would be nice,
> but not sure what sort of silly feature (maybe some js/css magic) would be
> good to add to the site.

Maximizing of the div, perhaps?

> Anyways, those are some ideas but as of now the above links give a
> recreation of fvwm.org using a static site (with some redesigning). Any
> input is appreciated.

Thanks for this, Jaimos.  One question:  how would we handle adding new
screenshots?  There's a script which runs to generate some HTML.  I presume
this is manual at the moment?

You've got a whole bunch of files that shouldn't be committed; will discuss
this with you on IRC if you like, and we've a little bit of work to do with
tidying up, but from what I can tell, this looks more-or-less complete.

Good job!

Thomas Adam

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Sat, Apr 02, 2016 at 11:58:41AM -0600, Jaimos Skriletz wrote:
> On Fri, Apr 1, 2016 at 5:43 PM, Thomas Adam <tho...@fvwm.org> wrote:
> 
> > On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> > > ​​
> >
> > Thanks!  It looks really good.  We can remove the Changelog section; people
> > can look at the release descriptions and/or Git history from now on.
> > Maintaining this is a doubling of effort for absolutely no reason.
> >
> >
> ​The ChangeLog page is just links to the files on GitHub so there is no
> maintenance on the page. Could be removed, I just thought it would be nice
> to have links easily found on fvwm.org for them.
> ​

It can be removed.

> > In terms of the FAQ, have you (for now) just copied that from
> > $FVWM.GIT/docs/
> > ?  If so, I can remove that file from the FVWM repo and make the one in
> > fvwmorg.gh.io the authoritative version (as it should be).  Same goes for
> > removing other files from the FVWM repo too, but that's a different
> > concern.
> >
> >
> No, the FAQ is a html dump (save as) from the old fvwm.org page as it was a
> copy of that file with linked anchors in it. The FAQ needs to be converted
> into a markdown file (complete with anchored links). Then I will create a
> simple wrapper to wrap the markdown file into the webpage. I would keep the
> FAQ around in $FVWM.GIT/docs/ until then.
> 
> Also I am unsure if these various markdown files, FAQ.md, AUTHORS.md,
> DEVELOPERS.md, etc should be located and maintained on the webpage or
> in $FVWM.GIT source. I think either can work with git.io so it is probably
> a matter of preference. But agreed, these markdown files should all be
> collected and maintained in a single place.

The point here is to put the files which relate to the website into the
repository which handles the web site, and for other files to remain outside of
it.  For the website, this includes:  authors, faq.  Developing happens in
FVWM and although you could link to that file in the FVWM.git repo, I wouldn't
bother.

>- A simple/minimal "default" config.

This has to then be maintained by us.  Maybe, but no thanks.  We've done this
in the past, and no one has maintained it.  There's such a plethora out there
on the Internet, just link to those.

>- Examples of various config snippets for things such as Vector
>Buttons, Window Decors, Menus, Modules, etc. (This was kinda attempted on
>the current fvwm.org page).


This can move to the wiki.

> I think the actual question is should fvwm.org provide any resources for
> configurations like above, or should it only link to other sites? This is
> also not something I was planning on including in the initial transition of
> moving the site to git.io, but was something I was thinking of developing
> and adding if there was interest to have a collection of config snippets on
> fvwm.org. If not I will look into updating the wiki (though I am liking
> jekyll over ikiwiki for building static pages).

Redirect to other sites for that sort of thing.  As for moving the wiki to
somthing on GH, sure.  But that's a different conversation and has no bearing
on the transition of the web site.

-- Thomas Adam

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Sat, Apr 02, 2016 at 02:45:22PM -0400, Dan Espen wrote:
> Jaimos Skriletz  writes:
> 
> > Also I am unsure if these various markdown files, FAQ.md, AUTHORS.md,
> > DEVELOPERS.md, etc should be located and maintained on the webpage or
> > in $FVWM.GIT source. I think either can work with git.io so it is
> > probably a matter of preference. But agreed, these markdown files
> > should all be collected and maintained in a single place.
> 
> If I recall  correctly, we created Changelog, and AUTHORS  in the source
> tree because its a recommended part of a GNU source tree.
> (Similar to INSTALL, README, NEWS.)

Yes, but not required, thankfully.

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Thomas Adam]

On Mon, Apr 04, 2016 at 11:56:47AM -0600, Jaimos Skriletz wrote:
> https://help.github.com/articles/using-a-custom-domain-with-github-pages/
> https://help.github.com/articles/setting-up-your-pages-site-repository/

I say we trial this, as it's the simplest change, without additional overhead,
and we are then directly able to tweak things as we see fit.

Jason, are you OK with this?

Kindly,
Thomas Ada

RFH: manpages in markdown

[Thomas Adam]

Hi all,

I've started to look at moving away from using docbook for man page
generation, and instead using markdown as the base format which can then be
converted to nroff and HTML, etc.

Using markdown for this seems sensible---using just nroff (or my preference,
mdoc) is one solution, but not as accessible to everyone, and since we've a
*lot* of options in FVWM, the documentation needs to be easier to manipulate
and have others contribute to, hence why I'm keen to go with plain text in
this regard.

So far, I've got something lashed together, but it is just mechanical
conversions at the moment.  There's a lot more that needs to happen which I'll
outline below.  However, I'm hoping I'm not the person to do this, although
I'll happily help/mentor anyone who wishes to pick up from where I've started.

What I've done so far is used pandoc to convert the existing Docbook files
(XML) to Markdown.  I've not checked extensively whether this was successful,
but by-and-large it seems to have been.

Then, I moved all the generated files to a new top-level directory, "manpages"
and added a file in there called ORDER which details how the Markdown files
should be catted together to form one huge markdown file which will be the
fvwm man page.

There's a script called 'generate_manpages.sh' which does all of this
mechanically.   Run it from within the manpages directory.

The conversion of markdown -> nroff is done using a program called 'ronn',
found here:

https://github.com/rtomayko/ronn

But all is not perfect.   Install 'ronn' and see for yourself what it spits
out.

Anyone who's interested in this needs to:

* Audit the markdown files to ensure the conversion is complete;
* Think whether we need all of the individual .md files or whether we can
  amalgamate.  I suspect we can quite a bit.  I'm keen not to see one huge
  file again.
* Fix up a lot of warnings from the markdown files converting to nroff;
* Hook these things into the buildsystem, removing the Docbook files.

Any questions, do please ask.  Any offers of help, *definitely* let me know.
You can find my efforts here:

https://github.com/fvwmorg/fvwm/tree/ta/docs-to-md

Specifically, the 'ta/docs-to-md' branch.

Kindly,
Thomas Adam

Man page now in rst format (WAS: Re: RFH: manpages in markdown)

[Thomas Adam]

On Mon, Apr 04, 2016 at 11:14:59PM +0100, Thomas Adam wrote:
> Hi all,
> 
> I've started to look at moving away from using docbook for man page
> generation, and instead using markdown as the base format which can then be
> converted to nroff and HTML, etc.

So I've looked again.  markdown is an OK format for this, but the generation
of markdown -> nroff is far from perfect.

Thankfully, there's RST (http://docutils.sourceforge.net/rst.html) which can
be used instead; similar to Markdown if nothing else.  On most systems,
there's rst* programs from the 'python-docutils' package which we can use to
provide the conversion.

To that end, I've removed everything in doc/* and instead, added a 'manpages'
directory with a single file in there which is the basis file for the fvwm man
page.

The conversion was automatic from HTML.  It will need a few tweaks, but
running:

rst2html manpages/fvwm.rst > manpages/fvwm.1

and then viewing the man page:

mandoc ./manpages/fvwm.1 | less

is a good start.

Anyone who wants to pick this up, do please let me know.  I'll also add this
into the the build at some point, assuming people are happy with this as a way
forward.

Historically, writing the documentation has been a reason for turning
developers away.  I hope using RST simplifies that.

-- Thomas Adam

Release versioning and tagging

[Thomas Adam]

Hi all,

I've done some work to try and improve how releases of FVWM happen.  Now that
we're using git, it makes sense to me that building FVWM should use the
information stored in git to detect the release information.

This also has the benfit that we can also see where in git versions of FVWM
might have come from (when talking about debug builds, etc.)

So from now on the release versions are taken from the tagged status of git.
Tag names will be in the form 'x.y.z' so that will be '2.6.7' from the next
point on.   The older naming of 'version_x_y_z' is completely deprecated.

The one potential downside to this is that non-released versions will struggle
with the internal version check, that is:

Test (Version >= 2.6.5) Echo foo

Since the version will not be in that form (deliberately).  I consider this a
feature and this won't be something I'm going to worry about, since such
builds from git in this way are in-development anyway.

You can view the work I've done here:

https://github.com/fvwmorg/fvwm/pull/4

I'll let this sit around for a bit.  If no one has any comments/objections,
I'll merge it soon enough.

Kindly,
Thomas Adam

Re: Some advices about the new static website

[Thomas Adam]

On 19 April 2016 at 14:57, Thomas Funk <t.f...@web.de> wrote:
> One idea came to my mind after clicking Support->FVWM Forums ...
> Is it possible to show the forums inside the window? ^^

No, thanks.  You'd have to use some sort of iframe to do that.  I
think what would be easier is to make the menu link a redirect to
fvwmforums.org, and remove the contents from the support page on
fvwm.org, since going to the forums speaks for itself.

-- Thomas Adam

Re: Some advices about the new static website

[Thomas Funk]

Hi Jaimos,

I've visited the website again and I only can say - WOW! Great work!
The Header 'inside' the window looks pretty cool :-)
Also your other changes (colors, formatings, ...)

One idea came to my mind after clicking Support->FVWM Forums ...
Is it possible to show the forums inside the window? ^^

Best,
Thomas

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

Re: Release versioning and tagging

[Thomas Adam]

On Fri, Apr 15, 2016 at 03:14:01PM +0100, Thomas Adam wrote:
> I'll let this sit around for a bit.  If no one has any comments/objections,
> I'll merge it soon enough.

Merged.

-- Thomas Adam

Re: Do we still need color-limit/visual options in fvwm?

[Thomas Funk]

On 05/07/2016 12:40 PM, Thomas Adam wrote:

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?


I would suggest to swap out the functionality into a module like bidi but
don't know how hard it is to do that ...

Does removing color limiting affecting things like remote connections?

If so, it shouldn't be removed.

Best,
Thomas

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

Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?

Kindly,
Thomas

Re: Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

On 7 May 2016 14:46, "Thomas Funk" <t.f...@web.de> wrote:
>
> On 05/07/2016 12:40 PM, Thomas Adam wrote:
>>
>> Hi all,
>>
>> Just looking through a few things, and I thought I'd ask whether fvwm
needs to
>> stlil support color limiting, and color depths for XServers with less
than
>> TrueColor?
>>
>> These days, 24-bit seems to be the standard, and indeed, I've never yet
come
>> across a server still using only 256 colours.  Whilst I appreciate you
can
>> still go and find such things, do we actually need fvwm to supprort it?
>
>
> I would suggest to swap out the functionality into a module like bidi but
> don't know how hard it is to do that ...

That's not the point, and wouldn't help here. Shuffling code around like
this isn't an option and wouldn't achieve anything. Furthermore, there's no
need to libify depth/colour limiting, such a thing doesn't make sense. It's
a capability, not something to be used directly.

> Does removing color limiting affecting things like remote connections?

No, it wouldn't.

-- Thomas Adam

[fvwmorg/fvwm3] d036d0: WIP: NEW-COMMANDS.md

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: d036d0eca0a3825f92d6bd6d3df9b6006ec34178
  
https://github.com/fvwmorg/fvwm3/commit/d036d0eca0a3825f92d6bd6d3df9b6006ec34178
  Author: Thomas Adam 
  Date:   2019-05-06 (Mon, 06 May 2019)

  Changed paths:
A dev-docs/NEW-COMMANDS.md

  Log Message:
  ---
  WIP:  NEW-COMMANDS.md


  Commit: 8dd75710299197a2beaa5bebe27b6b680641ea0d
  
https://github.com/fvwmorg/fvwm3/commit/8dd75710299197a2beaa5bebe27b6b680641ea0d
  Author: Thomas Adam 
  Date:   2019-05-13 (Mon, 13 May 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README.md: update with link to NEW-COMMANDS.md


Compare: https://github.com/fvwmorg/fvwm3/compare/0efbd1b0366a...8dd757102991

[fvwmorg/fvwm3] 8024f6: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 8024f6d66bb1452b711a70c221e643b7bfcb7d74
  
https://github.com/fvwmorg/fvwm3/commit/8024f6d66bb1452b711a70c221e643b7bfcb7d74
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 57819c: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 57819ccf5f760f4cebf7f73fdc37555c2b2fab28
  
https://github.com/fvwmorg/fvwm3/commit/57819ccf5f760f4cebf7f73fdc37555c2b2fab28
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] b3eb85: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: b3eb85fe9a6f930e21a4018720f6157fbd0bdea5
  
https://github.com/fvwmorg/fvwm3/commit/b3eb85fe9a6f930e21a4018720f6157fbd0bdea5
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 885e5a: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 885e5a70eefe0235bca9cdfd4a5b7d2a48e9d470
  
https://github.com/fvwmorg/fvwm3/commit/885e5a70eefe0235bca9cdfd4a5b7d2a48e9d470
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] e423e7: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: e423e76e786ef937bb33cd8ae96bb5da3b19be69
  
https://github.com/fvwmorg/fvwm3/commit/e423e76e786ef937bb33cd8ae96bb5da3b19be69
  Author: Thomas Adam 
  Date:   2019-05-15 (Wed, 15 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 09226a: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 09226a68ed130ea1fd07f8dd8f77513989e91702
  
https://github.com/fvwmorg/fvwm3/commit/09226a68ed130ea1fd07f8dd8f77513989e91702
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] f51066: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: f51066189b9745cc80caa16108e5ae33a418dd61
  
https://github.com/fvwmorg/fvwm3/commit/f51066189b9745cc80caa16108e5ae33a418dd61
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] bdeed0: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: bdeed0543087b69f7b9c672dd061fdb3801faebe
  
https://github.com/fvwmorg/fvwm3/commit/bdeed0543087b69f7b9c672dd061fdb3801faebe
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] d8634f: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: d8634f25a205fae1a500eeba601be7f4e8998401
  
https://github.com/fvwmorg/fvwm3/commit/d8634f25a205fae1a500eeba601be7f4e8998401
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

Re: [PATCH] Fix FvwmMakeMissingDesktopMenu

[Thomas Adam]

On Wed, Aug 21, 2019 at 01:12:47PM +, Luke Lau wrote:
> From: Luke Lau 
> 
> This drops the obsolete --fvwm-icons flag and specifies to add it into
> the "Desktop Programs" menu

Thanks.  Looks fine to me.  Will apply this over the weekend.  If you don't
see this land in fvwm2 early next week, please do chase me.

Kindly,
Thomas

[fvwmorg/fvwm] f4a498: Update README.md

[Thomas Adam]

  Branch: refs/heads/ThomasAdam-patch-1
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f4a498d442bf6a6bafc314889b5e7c3b2ec3311f
  
https://github.com/fvwmorg/fvwm/commit/f4a498d442bf6a6bafc314889b5e7c3b2ec3311f
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.

[fvwmorg/fvwm] 6e4fb0: README: correct markdown syntax

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6e4fb093541f263b4bca0231767cc4cd41850a20
  
https://github.com/fvwmorg/fvwm/commit/6e4fb093541f263b4bca0231767cc4cd41850a20
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: correct markdown syntax

[fvwmorg/fvwm] 6e4fb0: README: correct markdown syntax

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6e4fb093541f263b4bca0231767cc4cd41850a20
  
https://github.com/fvwmorg/fvwm/commit/6e4fb093541f263b4bca0231767cc4cd41850a20
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: correct markdown syntax

[fvwmorg/fvwm]

[Thomas Adam]

  Branch: refs/heads/ThomasAdam-patch-1
  Home:   https://github.com/fvwmorg/fvwm

[fvwmorg/fvwm] ea7ed8: Update README.md

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: ea7ed81c7654bddf7dd57df23be2538038225ffa
  
https://github.com/fvwmorg/fvwm/commit/ea7ed81c7654bddf7dd57df23be2538038225ffa
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.

[fvwmorg/fvwm] a61c97: README: clarify development situation

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: a61c970b863267301a92722fcd0d7e6f8968aae9
  
https://github.com/fvwmorg/fvwm/commit/a61c970b863267301a92722fcd0d7e6f8968aae9
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarify development situation

[fvwmorg/fvwm] a61c97: README: clarify development situation

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: a61c970b863267301a92722fcd0d7e6f8968aae9
  
https://github.com/fvwmorg/fvwm/commit/a61c970b863267301a92722fcd0d7e6f8968aae9
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarify development situation

[fvwmorg/fvwm] 4df413: README: clarifications and typo fixes

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 4df413509888555d063a7cb12c9f899e8712acd3
  
https://github.com/fvwmorg/fvwm/commit/4df413509888555d063a7cb12c9f899e8712acd3
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarifications and typo fixes

[fvwmorg/fvwm] ea7ed8: Update README.md

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: ea7ed81c7654bddf7dd57df23be2538038225ffa
  
https://github.com/fvwmorg/fvwm/commit/ea7ed81c7654bddf7dd57df23be2538038225ffa
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.


  Commit: 4df413509888555d063a7cb12c9f899e8712acd3
  
https://github.com/fvwmorg/fvwm/commit/4df413509888555d063a7cb12c9f899e8712acd3
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarifications and typo fixes


Compare: https://github.com/fvwmorg/fvwm/compare/a61c970b8632...4df413509888

Re: [RFC] Splitting the man page

[Thomas Adam]

On Mon, Nov 15, 2021 at 05:13:47PM +0100, Dominik Vogt wrote:
> 2) The Makefile.am now uses the standard "man1_MANS" file type to
> describe the generated files.  That should make local installation
> rules unnecessary.  Not sure whether it also handles the
> "transform" stuff or not.  For now I've removed it.

We'll need to support the transform stuff, as I know some packagers use it.

> 3) There's a new, experimental page "fvwm3commands.adoc" which
> has a header and then just includes the file
> fvwm3_commands.section.  This file is generated from fvwm3.adoc by
> extracting all text between the two comments
> 
>   // BEGIN 'commands'
>   ...
>   // END 'commands'

I think this is a good approach.  Something in the back of mind tells me this
is something which asciidoc(tor) supports, although it's a moot point as this
is lightweight enough that it's not going to introduce any overhead.

> Sections to extract are listed in the variable "EXTRACT_SECIONS".
> For now, all man pages simply depend on all section files.  To
> build real dependencies we'd have to extract the include
> directives from the .adoc files, but this seems to be overkill.

git.git do something like this for their built documentation (also written in
asciidoc).  But I suspect we won't need this -- it's probably going to be more
relevant if we ever do something about the *content* -- which is a different
issue entirely to just sorting out the structure.

> 4) Also removed the "QUIET_ASCIIDOC" thing because it seems to be
> pointless to suppress single-line rules in the output.  (Don't
> care much about it, though.)

Hmm.  I'm sure I added that because of some weird CI/CD interactions I was
seeing with Github Actions, but I think that's now solved.

> 5) fvwm3.1 still contains everything.  I'd like to rename that to
>fvwm3all.1 and then find a way to create fvwm3.1 without the
>sections that have their own page, containing placeholders that
>point to the other pages.

Agreed.  I'm sure there's an asciidoc(tor)-specific way of being able to do
this.

> Seems to do what is intended; "make install" and "make uninstall"
> work fine, but I haven't tried to build and test a distro from
> that.

Worked well for me.

This work is now being tracked here:

https://github.com/fvwmorg/fvwm3/pull/637

Via the `ta/dv-manpage-sections` branch.

Kindly,
Thomas

Re: [PATCH/RFC] Xinerama

[Thomas Adam]

On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > Patch attached.  Can you please double check and fill in the gaps?
> > (see comments belo).
> >
> > > > ./fvwm/menus.c: fXineramaRoot = False;
> > > > ./fvwm/menus.c:   else if (StrEquals(tok,"xineramaroot"))
> >
> >
> > Not sure what the right name of the option and the flag variable
> > should be.  There's only a placeholder in the man page either.

Making that change would be syntactically breaking people's configs, but... I
bet it's a rarely-used option that should just be "screenroot" or something.

> > > > ./perllib/FVWM/Commands.pm: descr => q{Move a window to 
> > > > another Xinerama screen},
> >
> > [MOVE_TO_SCREEN]
> > This one should be just renamed to just "screen"?

Yes please.

> Ping.

Sorry, I didn't spot this earlier.

Kindly,
Thomas

Re: [PATCH/RFC] Xinerama

[Thomas Adam]

On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote:
> The old manmage said:
> 
>   XineramaRoot
> 
>   the root window of the whole Xinerama screen.  Equivalent to
>   "root" when Xinerama is not used.
> 
> Can you please restate that for me?  What is "whole Xinerama
> screen" in xrandr terms?

>From a quick scan of the code in menus.c where xineramaroot is being used,
it's not entirely clear to me, but if this option is meant to do what I think
it is, then this would be taking the width/height of the monitor the
pointer/window is on, rather than referencing the width/height of the entire
root window.

Kindly,
Thomas

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Mon, Nov 22, 2021 at 11:26:14PM +0100, Dominik Vogt wrote:
> I want to remove completely it once the code has been tested well
> enough.  It's just there for the moment in case something happens.

OK.  I'm now about to merge this to master.

Thanks,
Thomas

Re: Xinerama

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> On Sat, Nov 20, 2021 at 02:15:58PM +0000, Thomas Adam wrote:
> > On Sat, Nov 20, 2021, 14:13 Dominik Vogt  wrote:
> >
> > > Is Xinerama still useful for anything or can we remove it?
> > >
> > It has already been removed. Where are you seeing references to it?
> 
> Everywhere.  I'll remove the junk on the parser branch.
> 
>  $ rgrep -i xinerama . 2> /dev/null
> ./libs/defaults.h:/*** Xinerama ***/
> ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on 
> by default */
> ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig"

These can go, and the corresponding callers in FvwmForm can be changed.  This
looks to be the mechanism module used to use to register Xinerama interest.

> ./libs/FTips.c:   fscreen_scr_arg *fsarg = NULL; /* for now no xinerama 
> support */

That comment is misleading and can be changed,

> ./modules/FvwmForm/FvwmForm.c:  if (strncasecmp(buf, XINERAMA_CONFIG_STRING,
> ./modules/FvwmForm/FvwmForm.c:  
> sizeof(XINERAMA_CONFIG_STRING)-1) == 0)
> ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + 
> sizeof(XINERAMA_CONFIG_STRING)-1);
> ./modules/FvwmForm/FvwmForm.c:buf, XINERAMA_CONFIG_STRING, 
> sizeof(XINERAMA_CONFIG_STRING)-1)
> ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + 
> sizeof(XINERAMA_CONFIG_STRING)-1);

See above.

> ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args);

That's just a function declaration without an implementation and can be
removed.

> ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly 
> adjacent to the screen's or xinerama screen's border. It
> ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly 
> adjacent to the screen's or xinerama screen's border. It

rerere cache from git so will ignore.

> ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama 
> screen's border. It
> ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs 
> border. It
> ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's 
> border. It
> ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama 
> screen\(cqs border. It
> ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama 
> screen's border. It

These can change to either mention RandR, or just "screen".

> ./fvwm/windowlist.c:   * because it sets the xinerama screen origin */
> ./fvwm/add_window.c:  fw->edge_resistance_xinerama_move =
> ./fvwm/add_window.c:  pstyle->edge_resistance_xinerama_move;
> ./fvwm/move_resize.c:  * in case Xinerama is used. */
> ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */
> ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move)


Funtionally now referencing RandR and are poorly named as xinerama isn't used.

> ./fvwm/style.c:   if (add_style->flags.has_edge_resistance_xinerama_move)
> ./fvwm/style.c:   SSET_EDGE_RESISTANCE_XINERAMA_MOVE(
> ./fvwm/style.c:   
> SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style));
> ./fvwm/style.c:   unsigned has_xinerama_move;
> ./fvwm/style.c:   has_xinerama_move = 0;
> ./fvwm/style.c:   has_xinerama_move = 1;
> ./fvwm/style.c:   has_xinerama_move = 0;
> ./fvwm/style.c:   
> ps->flags.has_edge_resistance_xinerama_move =
> ./fvwm/style.c:   has_xinerama_move;
> ./fvwm/style.c:   
> ps->flag_mask.has_edge_resistance_xinerama_move = 1;
> ./fvwm/style.c:   
> ps->change_mask.has_edge_resistance_xinerama_move = 1;
> ./fvwm/style.c:   SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, 
> val[1]);
> ./fvwm/fvwm.h:char*IconScreen;   /* Xinerama 
> screen */
> ./fvwm/fvwm.h:unsigned has_edge_resistance_xinerama_move : 1;
> ./fvwm/fvwm.h:int edge_resistance_xinerama_move;
> ./fvwm/fvwm.h:int edge_resistance_xinerama_move;

As above.  This just needs renaming.

> ./fvwm/commands.h:F_XINERAMA,
> ./fvwm/commands.h:F_XINERAMAPRIMARYSCREEN,
> ./fvwm/commands.h:F_XINERAMASLS,
> ./fvwm/co

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sun, Nov 21, 2021 at 11:41:33AM +0100, Dominik Vogt wrote:
> "git add -i" is extremely useful for not accidentally committing

It's "git add -pi" which I use all the time.

However, this is more about me hunting down which plugin is causing this and
turning it off.

Kindly,
Thomas

Re: dv Branches

[Thomas Adam]

On Sun, Nov 21, 2021, 11:22 Dominik Vogt  wrote:

> Okay, git access works again.  I'll do further development on
> dv/devel or on private topic branches, then put them in dv/master
> before considering to push them.
>

That's one way of doing it, yes. Whichever is going to make it easier for
you, and also for reviewing.

This is why I don't want an upstream branch. Merging topics into master can
accumulate there for the next release. The review process of those topics
makes things easier to manage.

I'm out for the rest of the day but will be back later.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:16:02PM +0100, Dominik Vogt wrote:
> Look at commit ba9f161998f7da942996bcf0d3f96baa8b249070.  You
> added new-parser.md, but also committed a complete reindentation
> of functions.c.

Oh heavens.  That's not good at all.  Clearly something has run in the
background and I had not even noticed at the point I commited that change as I
was in no way expecting anything other than that markdown file to have
changed.  That's why I didn't even check.

Sorry about that.  I'll have to check to see how that happened.  There's a
possibility some "helpful" vim plugin has done this, although it hasn't done
so in the past.

Kindly,
Thomas

Re: git access

[Thomas Adam]

On Sun, Nov 21, 2021 at 12:59:17AM +0100, Dominik Vogt wrote:
> Sending patches is getting out of hand.  I believe I had once

Ah.  I had thought you were doing this because you preferred this way of
working.

> write access to the git repo, but it doesn't work anymore
> (permission denied when updating).  What do I need to do to
> reactivate access?

You're a member of fvwmorg on github -- so presumably the permission denied
you're seeing is an out of date SSH key?

> (A quick recap of the procedure involved in getting patches on
> master wold help too.  I'd also be happy with my own branches
> without committing to master myself.)

See:  https://github.com/fvwmorg/fvwm3/blob/master/dev-docs/DEVELOPERS.md

Kindly,
Thomas

Re: fork-bomb like functions

[Thomas Adam]

On Sat, Nov 20, 2021 at 04:26:13PM +0100, Dominik Vogt wrote:
> I wonder if we should do something about these kind of functions:
> Theres the definition "MAX_FUNCTION_DEPTH 512" in defaults.h that
> prevents functions from nesting infinitely deep:

Yeah.  How likely is this problem in the real world though?  As in, how many
people have actually done this?  I can't say I've ever had to support a user
who has managed to get into this situation.

Even then, what's wrong in just keeping it as it is?

> I could add an execution counter that limits the total number of
> command lines that can be executed from a single top level
> function call; maybe limit that to 1000.

Maybe, if this is an actual problem...

> Another problem:  It's possible to add items to functions that are
> currently in use.
> 
>   addtofunc foo i bar
>   addtofunc bar i addtofunc foo i bar
>   # hangs:
>   foo

I can maybe foresee this situation arising.  Maybe this is worth fixing?

Kindly,
Thomas

Re: fork-bomb like functions

[Thomas Adam]

On Sun, Nov 21, 2021 at 12:51:46AM +0100, Dominik Vogt wrote:
> How about
> 
>  1. MAX_FUNCTION_DEPTH100  (stricter limit)
>  2. MAX_FUNCTION ITEMS   1000  (limit maximum size of functions)
>  3. MAX_CMDS_PER_INVOCATION 1  (max. cmds per top level function 
> invocation)

Sounds sensible to me.  I say, go for it!

Kindly,
Thomas

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Sun, Nov 21, 2021 at 02:38:09PM +0100, Dominik Vogt wrote:
> The parser branch is a ready as it will be without people testing
> it more.  The upstream branch dv/master hat the latest, merged
> together patches with extensive debug to stderr enabled.
> 
> Please take a look.  If there are no findings I'd like to put this
> on master.

I'll keep testing it here over the next few days.  

Before merging, it would be nice to:

* Convert some/all of the printf(stderr, ...) calls to fvwm_debug() lines so
  debugging is going through that mechanism.  I know historically we've had
  different sections for certain debug (stack-ring, enternotify debug, etc.)
  but I am trying to move away from that, and if you turn on debugging, you
  get everything.  This has helped supporting users already last year, in my
  experience.
* Remove/convert some remaining comments starting "!!!".
* Decide on the '#if 1' blocks -- are there they to stay permanently? 
* Not just related to change per se (but still present) appears to be what I
  would class as extraneous "return;" lines at the end of void functions which
  seems odd to me.

I will also get some tests in place as well.

> (Note: Produces a ton of debug output and is not suitable to the
> general audience.  Debug output can be disabled by debug defines
> in functions.c and cmdparser_old.c.)

It's things like this which tell me "it's not quite ready yet to be merged".
Which is good, because this branch is level with master so it doesn't need to
be merged just to test it -- and it's that shift in mentality, trying to
keep master in the most stable state it can be which helps a lot with the
release process.

Kindly,
Thomas

Re: Idea: "elastic" move

[Thomas Adam]

it might get
  confused.
* Edge-sensitivity to 'DesktopConfiguration per-monitor' and screen boundaries
  where paging could occur.

> 5. Visual feedback (optional)
> - Add a new "activity" colour to window decorations.  This
>   colour may be used while a long running action affects a
>   window (interactive move/resize etc.).
> 
> - The "activity" colour could also be used when a window
>   border hits the page edge during an interactive move.  Say,
>   if the window is already at the edge and you keep "pushing",
>   that border uses the "activity" colour to indicate that
>   something is happening.

I think this is definitely going to be required, yes.

Kindly,
Thomas

Re: Idea: "elastic" move

[Thomas Adam]

On Mon, Nov 22, 2021 at 12:24:09AM +0100, Dominik Vogt wrote:
> Yes, when the pointer comes too close to any border (leaves the
> dotted area on the sketch), it's warped back by the __move_loop to
> the original "P" in the sketch.  Thus it can continue moving in
> all directions.  Of course, the window does not follow the warp.
> The (P)ointer to (W)indow offset is internally adjusted to a new
> value.

Ah, yes of course.  This makes sense now.  Thanks.  I guess there could be
more movement with the mouse than before, but we'll have to see what it's
like.

Incidentally, isn't this sort of concept what FvwmProxy was trying to do?  I
seem to recall you could simultaneously move multiple windows...

Kindly,
Thomas

Re: parser branch

[Thomas Adam]

On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> I'd like to finish the parser work started in 2014.  Is the old
> branch still available somewhere?

Remind me what work that was...

Kindly,
Thomas

Re: parser branch

[Thomas Adam]

On Wed, Nov 17, 2021 at 01:47:05PM +, Thomas Adam wrote:
> On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> > I'd like to finish the parser work started in 2014.  Is the old
> > branch still available somewhere?
> 
> Remind me what work that was...

I remember now.  It came in two parts.  The first part, you and I worked on
documenting the commands in BNF notation (back in 2016).  That work is what
got carried across to fvwm.

Then you created some experimental code to start to clean things up.

That work was done in the mvwm repository [1], and the two branches you'll
want to look at are:

* dv/new-parser

  https://github.com/ThomasAdam/mvwm/commits/dv/new-parser

* dv/new-parser-2

  https://github.com/ThomasAdam/mvwm/commits/dv/new-parser-2

You could add mvwm as a git-remote in the fvwm3 repository and try and
cherry-pick/rebase the relevant commits.   But I suspect neither branches will
have any common ancestry with the master branch, so that might not work as
well.  But you could solve that through using grafts if you really wanted to.

I can't really remember where we got to with that work either -- I'm hoping
this trip down memory lane might jog your memory more than it has mine.  ;)

HTH,

Thomas

[1]:  https://github.com/ThomasAdam/mvwm

Re: [PATCH] (6) Man page changes -- second attempt

[Thomas Adam]

On Wed, Nov 17, 2021 at 08:18:07PM +0100, Dominik Vogt wrote:
> On Wed, Nov 17, 2021 at 04:40:55PM +0000, Thomas Adam wrote:
> > I've also added an OVERVIEW
> > section to fvwm3all.adoc explaining how the man page is split up into
> > different sections.
> 
> Shoudn't that go to fvwm3.1 as well?

I wouldn't have thought so -- in that, if you're reading fvwm3.1, you've
chosen that deliberately, or already read fvwm3all.1.  In the same way that we
wouldn't add it to fvwm3{commands,menus,styles}.1

Kindly,
Thomas

Re: [PATCH] (6) Man page changes -- second attempt

[Thomas Adam]

On Wed, Nov 17, 2021 at 02:35:32PM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote:
> > This is the full set of patches for splitting the man page, to be
> > applied to master.
> 
> Second attempt.  The style docs are not moved aound in the man
> page.  The .section files have been renamed to .ad because
> asciidoc only evaluates "ifdef" in included files if they have a
> known extesion.  ".adoc" cannot be used because the pattern rules
> in the Makefile.am would conflict.
> 
> The patch stack has been reshuffled and patches have heen merged,
> and two new ones on top have been added.

Thanks, Dominik.  This applies cleanly now.  I've also added an OVERVIEW
section to fvwm3all.adoc explaining how the man page is split up into
different sections.

I'm going to merge this to master, albeit I'm hoping to create some additional
sections as well so it doesn't feel like this change is incomplete.

The PR is here:  https://github.com/fvwmorg/fvwm3/pull/637

Kindly,
Thomas

Re: [RFC] Fake a global monitor when RandR is not available.

[Thomas Adam]

On Fri, Nov 19, 2021 at 02:53:32AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote:
> > For debugging I need to run another fvwm in xnest, but that
> > doesn't support randr.
> >
> > The attached patch mocks up a global monitor to use if init fails.
> > It works at the first glance, but the patch is not very clean.
> > Please comment.
> 
> Sorry, wrong patch, this is the correct one.

I think most people have started to use Xephyr instead of Xnest, which does
support RANDR... I'd rather that than maintain a single screen.  For
reference, I did used to support that, but removed it in commit 
6e646e6201051d19dea5fa8e985fcaf884f0d94d

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > A couple of patches for the parser branch:
> > 
> > 0001: Some cleanup.
> > 0003: Fix function depth handling and an uninitialised function argument.
> >   (I.e. a crash)
> 
> Thanks; applied these two.

You'll need to fix some missing #includes though, as the build's failing, but
I don't have the time to do so right now.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> A couple of patches for the parser branch:
> 
> 0001: Some cleanup.
> 0003: Fix function depth handling and an uninitialised function argument.
>   (I.e. a crash)

Thanks; applied these two.

Kindly,
Thomas

Re: [RFC] New parser framework for testing

[Thomas Adam]

On Wed, Nov 17, 2021 at 08:40:09PM +0100, Dominik Vogt wrote:
> 'k, the patched code didn't immediately crash, so here it is (two
> patches).  Please test.

I've applied those two patches on a branch called `new-parser`.

So far, I've tested this on approximately five different configuration files
and haven't noticed anything unusual or anything which breaks.  Which is a
good sign.

> The new code:
> 
>  * Rewrites functions.c to use hooks that are provided by a
>pluggable parser module (even at run time).
>  * The module that replicates the old parser behaviour is in
>cmdparser_old.[ch].
>  * The long term goal is to replace the _old parser with a new one
>that evauates the BNF definitions and does the parsing of
>function arguments before actually calling them.
>  * To allow that, a "parsing context" structure is passed to the
>CMD_... functions.  This is already implemented but not used.
>  * How the "parsing context" structure should look like is yet to
>be defined.
>  * It shoul be entirely possible to convert command functions one
>by one to the new type of parser.  So that word does not need
>to be done in a single big step.

This is sensible, and from a quick glance at what's there at the moment, it
makes sense.  I'm hoping that we can also derive the execute_context_t from
the parsed command as well, which would possibly help in unifying some of the
command syntax in the future.

I did wonder whether we might want to consider yacc/bison for the grammar of
the commands, but I've never personally been a fan of it, but it could help
wih some of the raw parsing...

> Possible pitfalls:
>  * Bad behaviour of the fvwm_debug function because of wrong
>parameters being passed.

I did a quick santity check of the ones which were pulled in from your
changes, and they look fine.  All other parser debug is going to stderr
anyway.

>  * The "repeat" command may cause crashes or leaks.

Weren't we thinking of removing the repeat command at one point?

Kindly,
Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> 0001: Some man page cleanup.
> 0002: New man page fvwm3menus.1

Are these patches based off the ta/dv-manpage-sections branch?  They don't
apply cleanly via 'git am'.

> The ending text goes back to the indentation of the section
> heading, or ig "+" is used it's indented like the list text.
> 
> The workaround is to start a new list with smaller indentation with
> 
> --snip--
> .::
> --snip--
> 
> But that creates an additional "." heading.  See line 2904.

Yes.  I've not found a good solution to this.   I suppose I could ask the
asciidoctor maintainers...

Kindly,
Thomas

Re: [PATCH] (2) fvwm3styles.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:28:45AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> > Off-topic:  Can we remove the "globalopts" command description?
> 
> And while we're at it, remove its implementation as well?
> 
> At the moment, GlobalOpts:
> 
> (1) Emits a deprecation warning ans prints the command that has to
> be used instead.
> (2) Executes that command automatically.
> 
> We could remove just (2), leaving the warning in place, or just
> eliminate the command completely.

I say remove it completely -- both its implemention and in the documentation.
I haven't seen a single config where GlobalOpts has ever been used, so I
really do think we can be quite brutal here.

It's about time.

Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:32:11AM +0100, Dominik Vogt wrote:
> Sorry, won't work, I've already reordered, merged and edited
> patches.  I don't want to commit a pile of junk like in CVS times.
> With Git I want much higher patch quality.  :)

I understand that -- I suppose I'm not following your development workflow.
When you're sending patches through to the list, I'm taking them as-is and
applying them on a branch from master.

For the current documentation work you're sending patches for, I'm doing the
same thing, but I presume if you're squashing or editing changes together, it
makes it harder for me to know what I'm supposed to be tracking, that's all.

Kindly,
Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:13:24AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 12:09:41AM +0000, Thomas Adam wrote:
> > On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> > > On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > > > 0001: Some man page cleanup.
> > > > 0002: New man page fvwm3menus.1
> > >
> > > 0003: Fix list formatting (attached).
> >
> > I've applied these three patches now, thanks.
> >
> > They still did not apply cleanly on top of ta/dv-manpage-sections, so I had 
> > to
> > manually modify a few sections with the .rej file.
> >
> > Can you check I've not mangled anything?  I do note some formatting
> > inconsistencies when viewing fvwm3menus.1 but I don't think that's related 
> > to
> > any changes made so far.
> 
> Just ignore it, I'll make a cleaned up series later, so we can
> dump the branch.

That's fine.  I'm using that branch to collect all the documentation changes
you're sending through as it's easier to manage -- so if those patches could
be based from that branch, it would certainly help.  :)

Kindly,
Thomas

Re: [PATCH] Fix resize calculations.

[Thomas Adam]

On Mon, Nov 15, 2021 at 09:37:48PM +0100, Dominik Vogt wrote:
> The earlier patch broke resize calculations by making windows too
> big.  This patch fixes this.

Makes sense.  I'm surprised I've not noticed that during the working day.

Applied now, thanks.

-- Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > 0001: Some man page cleanup.
> > 0002: New man page fvwm3menus.1
> 
> 0003: Fix list formatting (attached).

I've applied these three patches now, thanks.

They still did not apply cleanly on top of ta/dv-manpage-sections, so I had to
manually modify a few sections with the .rej file.

Can you check I've not mangled anything?  I do note some formatting
inconsistencies when viewing fvwm3menus.1 but I don't think that's related to
any changes made so far.

Kindly,
Thomas

Re: [RFC] Splitting the man page

[Thomas Adam]

On Mon, Nov 15, 2021 at 09:00:43PM +0100, Dominik Vogt wrote:
> Now, about the contents of the new man pages:  Splitting has not
> bought us that much yet.  75% of the contents are now in the
> commands man page.  It's difficult to remove more things from that
> because the command list also contains general topics like menus,
> session management and coloursets.  Moving these parts to
> different pages would also remove them from the command list.  The
> original man page just has a bad structure.

I suppose another way of looking at it might be to trying to convey things in
terms of functional areas, almost looking at things that a user might want as
they're configuring fvwm.   Right now, we're trying to lump together a lot of
similar things.  We could go further and have something like:

* An overview section explaining the anatomy/role of the window manager,
  explaining things such as:

  - Windows (decorations, anatomy, etc.)
  - Menus
  - Core functionality
  - Extending functionality (modules)

For explaining windows, we could enumerate the styles which are specific to
manipulating windows.  Grouping them by EWMH, window movement, etc.  Then we
would need an "fvwmallstyles" man page which aggregates these together.

> It's not obvious how to move the Style command (a subsection of
> the commands page) to a different file without cluttering the
> source with ifdefs.

That's a small price to pay for trying to increase readability, IMO.

Kindly,
Thomas

Re: [PATCH] (2) fvwm3styles.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> Two more patches for the man page branch, this time taking care of
> the style commands.
> 
> 0001: General cleanup.
> 0002: Split of fvwm3styles.1.
> 
> Need to be applied in this order.
> 
> Please take a good look at the result of the patch stack.  I think
> this is all going in the right direction.  If you agree and see no
> problems, I'll make a fresh stack of acleaned up patches that can
> go to the master branch.

I agree -- it's looking really good.

> There are various formatting problems left, but can be fixed later.

Yes.

> --
> 
> Off-topic:  Can we remove the "globalopts" command description?

Yes.  I can see a small section that's still present.

Kindly,
Thomas

Re: [PATCH] 1/3 Fix and document "bugopts debugrandr".

[Thomas Adam]

On Sun, Nov 14, 2021 at 10:58:19AM +0100, Dominik Vogt wrote:
> The patch makes the bogus "bugopts debugrandr" option actually do
> something.

Hi Dominik,

Thank you.  All four patches have now been merged!

Thanks,
Thomas

Re: Paging issue

[Thomas Adam]

On Sun, Nov 14, 2021 at 01:55:32PM +0100, Dominik Vogt wrote:
> 1) Because the pointer is at the top of the screen, it's
> immediately in the one pixel high panning window, so fvwm waits
> the configured 500 ms and then switches pages to 0 0 although
> neither the window nor the pointer have ever moved.
> 
> 2) Even worse, _because_ nothing has moved, the window ist still
> completely on page 0 1.  Not a single pixel is visible.
> 
> Overall, the implementation of paging is annoying, and Ive no idea
> how to fix it.

Presumably, the point here is to not do anything until the pointer has
moved, even if it is already in the panframe window?

Kindly,
Thomas

Re: Paging issue

[Thomas Adam]

On Sun, Nov 14, 2021 at 04:50:23PM +0100, Dominik Vogt wrote:
> Current situation for me:  At least 90% of all paging situations
> are accidents.

Yeah, and it gets even worse if you happen to use paging with
'DesktopConfiguration per-monitor' as well.

> Maybe that feature ist just crap and we need a different mechanism
> to trigger paging.  Like holding down Shift while moving etc.

I'd like to see this.   I know it's a departure from how we've always handled
paging, but I find myself doing things like:

EdgeScroll 0 0

For all the reasons you've previously mentioned, Dominik, I like to be able to
sometimes flip pages using panframes but find it so utterly annoying I turn
that off, and then end up not using pages, but rather desks -- hence it's
equivalent to just me using a 'DesktopSize 1x1'.

I say we should implement this change and see how it works in practise.  If
enough people don't like it, I'm sure they'll let us know.  :)

Kindly,
Thomas

Re: Paging issue

[Thomas Adam]

On Mon, Nov 15, 2021 at 12:31:28AM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 12:19:59AM +0100, Dominik Vogt wrote:
> > What do you think about the attached patch?  Pressing "Alt" during
> > an interactive move already disables snapping.  It's easy to make
> > it enable paging without any delay too.  I like it.
> >
> > You can say
> >
> >   style * edgemovedelay
> >
> > (to disable paging during normal moves), then press Alt for a
> > second to switch pages, then release Alt to go back to normal
> > mode.
> 
> P.S.:  Does not work with "Resize" yet.

Noted.  I like this, and I think it will also work well for Resize.  Also
needs a quick manpage update.

Kindly,
Thomas

Re: Crashes with monitor_resolve_name

[Thomas Adam]

On Sat, Nov 27, 2021 at 07:02:29PM +0100, Dominik Vogt wrote:
> Are there other places with unusual monitor name parsing?

Maybe in GotoDeskAndPage, but I don't think there's other places.

-- Thomas

Re: [RFC] Fix window title format leak?

[Thomas Adam]

On Fri, Nov 26, 2021 at 01:17:42AM +0100, Dominik Vogt wrote:
> Is this the proper fix?

I think so.  I can't see it leak under Valgrind...

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > On Fri, Nov 19, 2021 at 03:09:35PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > > > A couple of patches for the parser branch:
> > > >
> > > > 0001: Some cleanup.
> > > > 0003: Fix function depth handling and an uninitialised function 
> > > > argument.
> > > >   (I.e. a crash)
> > >
> > > Thanks; applied these two.
> >
> > You'll need to fix some missing #includes though, as the build's failing, 
> > but
> 
> Builds fine with gcc-10.2.1 in a clean source tree with
> 
>   $ make CFLAGS="-g3 -O3 -Wall -Werror" -j 4
> 
> Can you give me the error messages that cause it?

See fvwm.log attached.  It's possible I've missed a patch, but the code
corresponding to this build is on the new-parser branch in git, FYI.

I know I'm being lazy, I could fix this myself, but I'd like you to check,
just in case there's something else missing which you're working on at the
same time...

Kindly,
Thomas
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating libs/Makefile
config.status: creating fvwm/Makefile
config.status: creating modules/Makefile
config.status: creating bin/Makefile
config.status: creating bin/FvwmCommand
config.status: creating bin/FvwmPrompt/Makefile
config.status: creating bin/fvwm-config
config.status: creating bin/fvwm-perllib
config.status: creating bin/fvwm-menu-xlock
config.status: creating bin/fvwm-menu-directory
config.status: creating bin/fvwm-menu-desktop
config.status: creating bin/fvwm-convert-2.6
config.status: creating utils/Makefile
config.status: creating perllib/Makefile
config.status: creating perllib/General/Makefile
config.status: creating perllib/FVWM/Makefile
config.status: creating perllib/FVWM/Module/Makefile
config.status: creating perllib/FVWM/Tracker/Makefile
config.status: creating perllib/FVWM/Module.pm
config.status: creating default-config/Makefile
config.status: creating doc/Makefile
config.status: creating po/Makefile
config.status: creating modules/FvwmAnimate/Makefile
config.status: creating modules/FvwmAuto/Makefile
config.status: creating modules/FvwmBacker/Makefile
config.status: creating modules/FvwmButtons/Makefile
config.status: creating modules/FvwmConsole/Makefile
config.status: creating modules/FvwmEvent/Makefile
config.status: creating modules/FvwmForm/Makefile
config.status: creating modules/FvwmIconMan/Makefile
config.status: creating modules/FvwmIdent/Makefile
config.status: creating modules/FvwmMFL/Makefile
config.status: creating modules/FvwmPager/Makefile
config.status: creating modules/FvwmPerl/Makefile
config.status: creating modules/FvwmPerl/FvwmPerl
config.status: creating modules/FvwmRearrange/Makefile
config.status: creating modules/FvwmScript/Makefile
config.status: creating modules/FvwmScript/Scripts/Makefile
config.status: creating modules/FvwmScript/Widgets/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
make  all-recursive
make[1]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3'
Making all in default-config
make[2]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3/default-config'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/n6tadam/projects/fvwm/fvwm3/default-config'
Making all in libs
make[2]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3/libs'
  CC   gravity.o
  CC   BidiJoin.o
  CC   Flocale.o
  CC   PictureUtils.o
  CC   FScreen.o
  CC   Bindings.o
  CC   PictureGraphics.o
  CC   Graphics.o
  CC   FlocaleCharset.o
  CC   Parse.o
  CC   PictureImageLoader.o
  CC   Colorset.o
  CC   ColorUtils.o
PictureImageLoader.c: In function ‘PImageLoadSvg’:
PictureImageLoader.c:287:9: warning: ‘rsvg_handle_get_dimensions’ is 
deprecated: Use 'rsvg_handle_get_intrinsic_size_in_pixels' instead 
[-Wdeprecated-declarations]
  287 | Frsvg_handle_get_dimensions(rsvg, );
  | ^~~
In file included from Fsvg.h:9,
 from PictureImageLoader.c:46:
/usr/include/librsvg-2.0/librsvg/rsvg.h:727:6: note: declared here
  727 | void rsvg_handle_get_dimensions (RsvgHandle *handle, RsvgDimensionData 
*dimension_data);
  |  ^~
PictureImageLoader.c:360:9: warning: ‘rsvg_handle_render_cairo’ is deprecated: 
Use 'rsvg_handle_render_document' instead [-Wdeprecated-declarations]
  360 | Frsvg_handle_render_cairo(rsvg, cr);
  | ^
In file included from /usr/include/librsvg-2.0/librsvg/rsvg.h:1460,
 from Fsvg.h:9,
 from PictureImageLoader.c:46:
/usr/include/librsvg-2.0/librsvg/rsvg-cair

Re: [PATCH] (6) Various small changes

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:03:44AM +0100, Dominik Vogt wrote:
> For master:
> 
> 0001: Fix uninitialised variables in lib.
> 0002: Remove "-blackout" option.
> 0003: Docuement -v and alias it to --verbose.
> 0004: Don't list all options in the SYNOPSIS.
> 0005: Change getpwuid.c interface (for next patch)
> 0006: Implement -o/--output-logfile option.
>   If given, use that logfile (abs or relative path)
>   If the path is just "-", use stderr
>   If not present use file from env variable
>   If not presen, use default.
> 
> fvwm -v -o - ...   # to stderr
> fvwm -v -o //home/foo/bar  # to file
> 
>   The patch also fixes a memory leak.

Makes sense.  Applied, with a few tweaks.

Note that the use of stderr is going to be interesting.  Unless you've
explicitly captured stderr beforehand, some display managers won't capture
stderr which is why I didn't previously include it, but then again if you're
still starting fvwm via .xsession or .xinitrc, this will be useful.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> > On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> > > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > > > > A couple of patches for the parser branch:
> > > > >
> > > > > 0001: Some cleanup.
> > > > > 0003: Fix function depth handling and an uninitialised function 
> > > > > argument.
> > > > >   (I.e. a crash)
> > > >
> > > > Thanks; applied these two.
> > >
> > > You'll need to fix some missing #includes though, as the build's failing, 
> > > but
> > 
> > Builds fine with gcc-10.2.1 in a clean source tree with
> > 
> >   $ make CFLAGS="-g3 -O3 -Wall -Werror" -j 4
> > 
> > Can you give me the error messages that cause it?
> 
> See fvwm.log attached.  It's possible I've missed a patch, but the code
> corresponding to this build is on the new-parser branch in git, FYI.
> 
> I know I'm being lazy, I could fix this myself, but I'd like you to check,
> just in case there's something else missing which you're working on at the
> same time...

This works, but I am confused as to why it compiles fine for you:

diff --git a/fvwm/cmdparser_hooks.h b/fvwm/cmdparser_hooks.h
index 42330246b..d8ebde017 100644
--- a/fvwm/cmdparser_hooks.h
+++ b/fvwm/cmdparser_hooks.h
@@ -3,6 +3,9 @@
 #ifndef FVWM_CMDPARSER_HOOKS_H
 #define FVWM_CMDPARSER_HOOKS_H
 
+#include "cmdparser.h"
+#include "functions.h"
+
 /*  included header files -- */
 
 /*  global definitions - */

Kindly,
Thomas

Re: [RFC] New parser framework for testing

[Thomas Adam]

On Thu, Nov 18, 2021 at 02:19:11PM +0100, Dominik Vogt wrote:
> Most of the tests were meant to catch parsing bugs, leaks and
> crashes.  A mor organised approach in the future would be good.
> Maybe it would even be possible to generate test cases for
> commands programmatically from the BNF.

It might be -- although my faith in our accuracy of the BNF notation we came
up with isn't too strong.  Either way, I'll put something together which will
make it easy to expand.

> Sounds interesting.  While implementing new ways of selecting
> source/target (what is the difference?) it is still possible to
> keep the existing conditionals working:  If "-s ..." is present,
> use it.  Otherwise use the window that has been selected  by a
> conditional.  If that's not defined either, ask the user to select
> one.

Yes, in that order as well, I would have thought.  I'm still mulling over what
I mean by source vs target, but source refers to the window or windows which
the command needs to operate on, and target is the end result of that command.
Take the `Move` command, for instance:

Move -s  -t screen|desktop|page

But I think that's overcomplicating things.  What matters is whether the
command expects a window, or if it's a command which changes state (such as a
colorset, or a setting for something).

I think you're right though, Dominik, we need to pull this into a .md file and
start fleshing it out (similar to how we did the BNF work), if you're happy
for that?

> For multi-target conditions the syntax would work too.
> 
> Old way, loop over all windows, filter them by a resource name,
> then apply a command to them:
> 
>   All (xterm) Close
> 
> Same in new syntax (assuming "-c" marks the beginning of the
> command to execute):
> 
>   All --match-resource "xterm" -c Close

Something like that, yes.  Although I'm suggesting that filters would allow
for us doing away with commands such as: All, None, Next, Prev, as they'd
become a part of the filter.  So you might say:

Close --filter "screen:X,desk:*,class:XTerm,condition:*"

... to close all XTerm windows (condition:*), which were only on screen X,
all desks (desk:*).

Either way would work though.

> Taking it a step further filters can be applied to *any* command
> line, not just commands:
> 
>   foobarfunc --match-resource "xterm"
> 
> (Problem: How can we distinguish between general filters and the
> actual command/function arguments?)

If a command in a complex function isn't overriding the calling filter, then
use that?

> Note:  Complex functions already have a kind of filtering with the
> "I", "C", ... bits.

Yeah -- this needs more thinking.

Hmm.

Kindly,
Thomas

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Mon, Nov 22, 2021 at 12:02:33AM +0100, Dominik Vogt wrote:
> Mostly done, except a couple of comments where there's still work
> to do.

OK, I'll wait for those.

I've not noticed any crashes from running this for three days now.

Note that I still don't think we should hide the debugging behind
'#define OCP_DEBUG 1' even though it's always set to on at compile time.
Certainly not for new code.  We could make it a BugOpts option if it really
mattered.  I'm not saying we need to fix this now, mind you.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 10:51:51AM +0100, Dominik Vogt wrote:
> It works on my local branch but not the one in Git because of the
> reindentation commit.  Can we please not reindent patches that are
> still under development?

I haven't reindented anything -- at least, not knowingly.  Even then, how did
that cause the failure in the first place?

> I'll ditch the upstream branch for now and start a new one.

Well, new-parser builds fine now, thanks.

Kindly,
Thomas

Re: [PATCH] Reject out of range windows for Move and Resize commands.

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:11:34AM +0100, Dominik Vogt wrote:
> Fixes programs going crazy when you accidentally say something like
> 
>   all (mplayer) resize 1920 1200
> 
> instead of
> 
>   all (mplayer) resize 1920p 1200p
> 
> (Generates an error message without doing anything else.)

Makes sense, Dominik.  Will apply.

Thanks!

Thomas

Re: Paging issue

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:16:06AM +0100, Dominik Vogt wrote:
> Of course.  What is the maximum line length that was used to
> format the .adoc files?  (Can we re-add some formatting
> instructions in comments at the start of the main manpage source
> as we had in the groff sources?  I've noticed that style names are
> sometimes underlined and sometimes in italics.)

There's some clean up that still needs doing, due to the conversion script I
wrote (albeit badly) to convert from XML -> Asciidoc, so I am not surprise if
you find any glitches.  I suspect there's quite a few of them!

I think it's best to try and keep line length to <=80 characters, although
there's probably going to be times where that's not possible if the formatting
rules require lines to exceed that.

Kindly,
Thomas

Re: Plans for the NEWS file?

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:18:49AM +0100, Dominik Vogt wrote:
> Is the NEWS file going to be used for 3.x releases too?  I always
> found it easier to add new entries when patches are written
> instead of reading the whole changelog when making a release.

I now autogenerate this at release time via Github Actions, where the
relevant bugs/pull-requests, etc., are pulled from Github and formatted
accordingly in CHANGELOG.md

> Can you give me an update on the intended release scheme?  Fvwm is
> probably in an "unstable" phase at the moment?

Right now, I've pre-scoped bugs/PRs/etc., which I feel should be in the 1.0.5
release here:

https://github.com/fvwmorg/fvwm3/projects/1?card_filter_query=milestone%3A1.0.5

This is somewhat arbitrary on my part in that there's no real end-goal for a
given release, other than what I think should be in it -- and typically what
I've been doing is amassing changes and releasing when it feels right, even if
items against that milestone might not yet have been finished.  In such cases,
those items are moved forward to the next release.

I don't think fvwm is in an "unstable" phase.  It seems to be "OK", although
there's many rough edges still left to tidy up -- not helped by my own
butchery of fvwm over the past year...

HTH,
Thomas