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

2019-08-24 Thread 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] 6e4fb0: README: correct markdown syntax

2019-08-24 Thread 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] 4df413: README: clarifications and typo fixes

2019-08-24 Thread 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

2019-08-24 Thread 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



[fvwmorg/fvwm]

2019-08-24 Thread Thomas Adam
  Branch: refs/heads/ThomasAdam-patch-1
  Home:   https://github.com/fvwmorg/fvwm



[fvwmorg/fvwm] ea7ed8: Update README.md

2019-08-24 Thread 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] f4a498: Update README.md

2019-08-24 Thread 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] a61c97: README: clarify development situation

2019-08-24 Thread 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

2019-08-24 Thread 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





Re: [PATCH] Fix FvwmMakeMissingDesktopMenu

2019-08-22 Thread 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/fvwm3] bdeed0: read: remove custom fgets logic and use fparseln()

2019-05-16 Thread 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()

2019-05-16 Thread 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.





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

2019-05-16 Thread 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] 09226a: read: remove custom fgets logic and use fparseln()

2019-05-16 Thread 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] e423e7: read: remove custom fgets logic and use fparseln()

2019-05-15 Thread 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] 57819c: read: remove custom fgets logic and use fparseln()

2019-05-14 Thread 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] 8024f6: read: remove custom fgets logic and use fparseln()

2019-05-14 Thread 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] 885e5a: read: remove custom fgets logic and use fparseln()

2019-05-14 Thread 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] b3eb85: read: remove custom fgets logic and use fparseln()

2019-05-14 Thread 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] d036d0: WIP: NEW-COMMANDS.md

2019-05-13 Thread 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



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

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


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

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



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

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



Re: Some advices about the new static website

2016-04-19 Thread 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: Release versioning and tagging

2016-04-17 Thread 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



Release versioning and tagging

2016-04-15 Thread 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

2016-04-08 Thread Thomas Adam
On Sat, Apr 09, 2016 at 12:40:54AM +0200, Thomas Funk wrote:
> I meant the links in
> http://fvwm.org/doc/unstable/fvwm/fvwm.man.html
> 
> And again the html docs under http://fvwm.org/doc/unstable are/were the
> same as under http://fvwm.org/doc/stable since ages.

Yes, since I disabled snapshot builds ages ago.

Again, there'll only ever be one set of man pages.

-- Thomas Adam



Re: Some advices about the new static website

2016-04-08 Thread Thomas Adam
On Fri, Apr 08, 2016 at 11:33:05PM +0200, Thomas Funk wrote:
> I could help you if you like as I did much inside Fvwm-Nightshade with
> perllib.

I'll let you know when I've put this together.

> > As for unstable man pages, no.  There's no such thing any more, and
> >hasn't been for a long time now.
> 
> 'unstable' was only used as example. As I remember the same pages exists
> on 'stable', too. But it would be a shame to lost those pages. Also Dan
> did much work on the linking on the FVWM page.

Maybe, but again, there'll only ever be one set of man pages to reflect when
releases happen.  Since I've put in place a means of generating them from
markdown (and have yet to receive offers on help with that), I'll see what
happens when I have time to look at this.

I'm not clear what you're referring to with "linking" either. But no
information has been lost that's important.

-- Thomas Adam



Re: Some advices about the new static website

2016-04-08 Thread Thomas Adam
On Fri, Apr 08, 2016 at 09:44:48PM +0200, Thomas Funk wrote:
> What about the perlib pages and the ... uhm ... 'unstable' documentation
> pages (http://fvwm.org/doc/unstable/index.html)? Will they appear again
> in the future?

perllib maybe (althought woefully out of date, and it's on my TODO list to
look at).  As for unstable man pages, no.  There's no such thing any more, and
hasn't been for a long time now.

> Btw I have some website links for our 'Links' page:
> 
> History
> ---
> In the beginning was ...
> http://edulinux.homeunix.org/fvwm/user_enumerate.html

Really?  That shouldn't resolve at all.  You mean:

http://www.xteddy.org/fvwm/user_enumerate.html

> Other FVWM-related sites
> 
> How Styles are Applied
> http://linuxgazette.net/127/adam.html
> 
> Fvwm and Session Management
> http://linuxgazette.net/100/adam.html
> (perhaps a little bit outdated but anyway interesting)

It'll still work with xsm(1).

-- Thomas Adam



RFH: manpages in markdown

2016-04-04 Thread 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



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

2016-04-04 Thread 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



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

2016-04-02 Thread 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]

2016-04-02 Thread 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]

2016-04-01 Thread 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]

2016-03-26 Thread 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: [fvwmorg/fvwm] c6de88: distcheck2: remove bzip2 archive generation

2016-03-25 Thread 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]

2016-03-25 Thread 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]

2016-03-25 Thread 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]

2016-03-25 Thread 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]

2016-03-25 Thread 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]

2016-03-25 Thread 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: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-25 Thread 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: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-25 Thread Thomas Adam
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.

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

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

2016-03-24 Thread 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.)



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

2016-03-24 Thread 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"

2016-03-24 Thread 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]

2016-03-24 Thread 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



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

2016-03-23 Thread 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: FVWM code moved to Github

2016-03-21 Thread 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: FVWM code moved to Github

2016-03-21 Thread 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


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

2016-03-21 Thread 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

2016-03-20 Thread 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



FVWM code moved to Github

2016-03-19 Thread 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 2.6.6: slightly out of sync in CVS/fvwm-web: do not commit anything

2016-03-19 Thread 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 2.6.6: slightly out of sync in CVS/fvwm-web: do not commit anything

2016-03-15 Thread Thomas Adam
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.

Kindly,
Thomas Adam



Re: Release 2.6.6?

2016-03-13 Thread Thomas Adam
Hi Dan,

No worries, I can eliminate the 2.7 branch too. You're right, at some point
we'll hit this revision. Sooner to get rid of it than not.

Thanks. I'll release 2.6.6 soon!

Thomas
On 13 Mar 2016 20:03, "Dan Espen" <des...@verizon.net> wrote:

> Thomas Adam <tho...@fvwm.org> writes:
>
> > Hi,
> >
> > I'm getting quite a few emails off-list, asking me when 2.6.6 is going
> to be
> > released.  I know it's been a while, so I'm thinking of doing this this
> > evening at some point.
> >
> > Any objections?  The CVS branch seesm stable enough to me.
>
> No objections at all.
> It's long overdue.
>
> Every time I look I get distracted by the 2.7 branch, which should be
> eliminated.  But I don't know how to turn 2.6 into the new head.
> So, just doing 2.6.6 would be fine.
>
> --
> Dan Espen
>
>


Release 2.6.6?

2016-03-13 Thread Thomas Adam
Hi,

I'm getting quite a few emails off-list, asking me when 2.6.6 is going to be
released.  I know it's been a while, so I'm thinking of doing this this
evening at some point.

Any objections?  The CVS branch seesm stable enough to me.

Kindly,
Thomas Adam



Re: FIX for fvwm burning CPU on resize/move unresizable/unmovable windows

2012-09-23 Thread Thomas Adam
On Sun, Sep 23, 2012 at 03:28:30PM +0200, Axel Rohde wrote:
 FIX for fvwm burning CPU on resize/move unresizable/unmovable windows
 
 Hi Thomas, FVWM Workers,

Can you please send unified diffs, please?

 *** fvwm-2.6.5/fvwm/events.c_orig   2012-09-22 12:54:50.838388626 +0200
 --- fvwm-2.6.5/fvwm/events.c2012-09-22 12:55:00.818388316 +0200
 ***
 *** 4729,4736 
  * okay here */
 }
 mask = DEFAULT_ALL_BUTTONS_MASK;
 !   usleep(1);
 !   }
 if (use_wait_cursor == 0  count == 20)
 {
 GrabEm(CRS_WAIT, GRAB_NORMAL);
 --- 4729,4738 
  * okay here */
 }
 mask = DEFAULT_ALL_BUTTONS_MASK;
 !   usleep(1); /* fixes 50% to 100% (P4) CPU load 
 when trying */ 
 ! /* to move/resize unmovable/unresizable windows. Tested on */
 ! /* P4 3GHz/HT, ATi X550, and core i5-3550. Axel Rohde Sep. 22 
 2012 */
 !   }  

This is not a correct solution.  usleep() is hiding the problem further, not
fixing it.

I do not have the time to help you though.

-- Thomas Adam



Re: fvwm burning CPU on Move-or-Raise, Resize-or-Lower functions

2012-06-07 Thread Thomas Adam
On Thu, Jun 07, 2012 at 01:13:04AM +0200, Axel Rohde wrote:
 Hi Thomas and fvwm-workers,
 
 attached is my .fvwm2rc with workarounds.
 
 In case you are not going to fix the root causes, 
 other users experiencing slow down, whistling graphics boards or 
 angry admins might find it useful.

Unfortunately that's not a solution, and won't work in a lot of cases.

I appreciate it's annoying for you.  The reason this won't change -- and why
I refuse to even do so -- is that it would require quite a large change to
fvwm/functions.c:execute_complex_function().  In essence, when FVWM sees
this:

AddToFunc foo M Resize

And that just happens to be on a window which has FixedSize set, then this
happens:

* Grab on pointer.
* (M) context found (assuming other (I) context have run first.)
* Action (Resize) run.
* Wait for button to be released -- with the server grabbed.
* FVWM locks.
* Button released.
* Function ended.

There is no check to know if by the time the Resize command has bailed due
to it not being able to operate on the window in question, that just because
the pointer is held down, there's nothing to do.  By design, FVWM is going
to wait for that button to come up -- it's what you asked with M or H in
the first place:

1113 type = CheckActionType(x, y, d, HaveHold, True, button);

-- 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: Glitches and feature requests

2012-06-06 Thread Thomas Adam
Hi,

On Sat, Jun 02, 2012 at 12:13:27AM +0300, Andi Cristian Șerbănescu wrote:
 1. When using the HilightBack MenuStyle option, disabled menu items use the

Deprecated in favour of colorsets.

 2. Raising the icon labels above everything else when hovering above them with
 the mouse is annoying. They should always be in the same layer as the icons

That's because the labels themselves are just a normal window, created with
XCreateSimpleWindow().  I'll look in to this.

 themselves. Also, the icon label should expand only when focused, not simply
 when under the pointer (it could be made customisable, but I don't see why one
 would like it the way it is).

No.  It used to work like this in FVWM 2.3.X, and I don't want an option for
it.

 3. When using the FPClickDecorRaisesFocused FocusStyle together with
 MouseFocus, FPPassRaiseClick indeed passes the click to the widgets, but
 it doesn't raise the window anymore. !FPPassRaiseClick (default) behaves
 as expected, but FPClickRaisesFocused and FPClickIconRaisesFocused pass
 the click regardless of it. Something's wrong…

Send me through a proper fvwm2rc snippet for this, using XTerm as a guide
and I'll take a look.  I suspect I know what's causing this though.

[...]

-- Thomas Adam



Re: fvwm burning CPU on Move-or-Raise, Resize-or-Lower functions

2012-06-06 Thread Thomas Adam
On Thu, May 31, 2012 at 07:49:24PM +0200, Axel Rohde wrote:
 Hi Thomas,
 
 on a SuSe system at work I found a system.fvwm2rc apparently authored by
 you. I appended those parts of my config that reproduce the issue on
 my PC at the end of the file.

So the CPU usage here is because we lock and wait, whilst the button is held
down, having grabbed the server, because whilst the curosr is down, the
cursor is changed, whilst we do nothing, because the resultant operation is
a no-op -- we're just waiting for WaitForButtonsUp() to complete all the
time.

So after *all* of that, and leading me all around the houses, all you needed
to have said originally was:

FixedSize/FixedPosition windows cause CPU to increase when a function is
run on such windows.  Here's the Styles and function I'm using.

Nevermind though.  :)

Nothing I want to do about this -- and nothing I can do about this, because
the pointer is grabbed throughout the lifetime of the function being run.

-- Thomas Adam



Re: FVWM Patch for Interaction problem with Java 7

2012-04-16 Thread Thomas Adam
On Mon, Apr 16, 2012 at 03:37:48PM -0400, Schaaf, Jonathan P (GE Healthcare) 
wrote:
 diff -urNp fvwm-2.6.4/doc/commands/BugOpts.xml 
 fvwm-2.6.4-modified/doc/commands/BugOpts.xml
 --- fvwm-2.6.4/doc/commands/BugOpts.xml   2009-12-31 11:35:47.0 
 -0600
 +++ fvwm-2.6.4-modified/doc/commands/BugOpts.xml  2012-04-16 
 14:19:41.543549878 -0500
 @@ -139,4 +139,12 @@ utf-8 fails due to characters which have
  the target charecter set. Some clients however neglect to set non utf-8
  properties correctly in which case this option may help./para
  
 +paraThe fvwmopt cmd=BugOpts opt=Java7FocusWorkaround/ option

I don't like the name, and thinking about it some more, I don't think a
bugopt is the right thing to do here either -- FPLenient should be implied
for this to work, so really I think:

 + if (mra-w_with_focus != None  !Scr.bo.do_java_focus_behavior)

diff --git a/fvwm/frame.c b/fvwm/frame.c
index 55922ce..e4aafab 100644
--- a/fvwm/frame.c
+++ b/fvwm/frame.c
@@ -1938,7 +1938,7 @@ void frame_free_move_resize_args(
}
update_absolute_geometry(fw);
frame_reparent_hide_windows(Scr.NoFocusWin);
-   if (mra-w_with_focus != None)
+   if (mra-w_with_focus != None  FP_IS_LENIENT(FW_FOCUS_POLICY(fw)))
{
/* domivogt (28-Dec-1999): For some reason the XMoveResize() on
 * the frame window removes the input focus from the client

What do you 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.)



Re: [PATCH 2/2] FvwmPager: add an option for wrapping too long window titles.

2012-04-12 Thread Thomas Adam
On Mon, Apr 09, 2012 at 08:09:01AM +0200, Anton Khirnov wrote:
 You mean disregard word boundaries and just fill each line completely?
 I'd rather not do that, word wrapping looks better to me (at least in my
 setup, compare [1] and [2]). I can of course make it configurable if you
 want, it's just a matter of adding one condition to the inner while().

No, that's OK.  I am not interested at all in more options for something so
trivial to be honest.

I'll apply this later on, with some changes.

-- Thomas Adam



Re: fvwm for Fedora

2012-03-22 Thread Thomas Adam
On Wed, Mar 21, 2012 at 11:34:19AM -0500, Ranjan Maitra wrote:
 I was wondering if any of the features in those patches will
 eventually come into fvwm. Rounded borders for windows, translucent
 menus and the hover patches are the ones I am most interested in.

I suspect so, yes.  Just never how they've currently been implemented.

Please note one thing though, and note it well:  if you do decide to include
these patches in some FVWM RPM, I would suggest you create a separate RPM
entirely from the vanilla upstream sources, and mark that RPM as being
completely on its own without endorsement from fvwm.org.  I *do not* want
*any* bug reports from people using a patched FVWM version.  It's not
supported.

-- Thomas Adam



Re: fvwm for Fedora

2012-03-21 Thread Thomas Adam
On Wed, Mar 21, 2012 at 11:11:53AM -0500, Ranjan Maitra wrote:
 On Tue, 20 Mar 2012 06:56:07 + Thomas Adam tho...@fvwm.org wrote:
 
  On 20 March 2012 05:23, Ranjan Maitra mai...@iastate.edu wrote:
   So, I just wanted to be sure: none of the above-mentioned packages are
   of much use anymore, is that correct?
  
  Correct.
  
   Also, are any of the patches in the ArchLinux/Gentoo builds already
   included/proposed to be so in fvwm? I wanted to put together a local
   RPM for fvwm, and I therefore wanted to know.
  
  They won't be included here at upstream, no.
 
 Thanks again! May I ask: is the reasoning behind prohibiting
 inclusion of these features upstream philosophical, or is
 it that it increases code complexity or resource usage overhead
 substantially (or something similar)? If the latter, of course that is
 far more serious, and would be helpful to know.

I fail to see why it matters, but it's simply that the code those patches
touch is obsolete and will be replaced, versus some questionable decisions
in *how* those patches work, as well as them lacking in functionality for
hard-coding assumptions, no documentation, etc.

-- Thomas Adam



Re: Updating Fedora's FVWM

2012-01-24 Thread Thomas Adam
On Tue, Jan 24, 2012 at 10:44:52AM -0500, Chris Siebenmann wrote:
 | On 24 January 2012 14:54, Dan Espen des...@verizon.net wrote:
 |  I think any platform that supports XDG is going to have python.
 |
 | It will; but I think it's best described the other way round -- that
 | is, any platform that has python installed can use XDG -- and I say
 | that only because of the availability of the python XDG bindings.
 | Not that it really matters to me, but it is worth investigating if
 | these bindings come with python or are external.  I'm thinking about
 | packaging.
 
  The bindings are an external package, not part of the core Python
 distribution (on Fedora they are packaged as 'pyxdg', on Ubuntu
 'python-xdg').  On Fedora the package seem to be part of the default
 installation if you have the Gnome desktop (Totem and IBus both depend
 on the package).
 
 (I don't have any clean stock Ubuntu desktop machines to see if the
 package is there in their Gnome setup. An Ubuntu server install with
 basic X packages installed doesn't have them.)

Yes -- I really don't care about this point, it's a packaging problem.  But
it's perhaps a bigger change for some packagers because FVWM will now
depend on both perl and python.  But as to how that happens, I don't care.

-- Thomas Adam



Re: [PATCH] small doc patch

2012-01-15 Thread Thomas Adam
On Sun, Jan 15, 2012 at 07:25:41PM +, Michael Stevens wrote:
 Okay this is really trivial, but it bugged me reading the README for 2.6
 and seeing references to 2.5!
 
 I didn't do a changelog entry on the grounds of the vast trivialness of
 the patch, but I can add one if people want.

Hmm.  Looking at this file, it's not as simple as changing the version
number.  There's still references to older areas of FVWM.

I'll look in to it this week.  Thanks for starting this though.

See -- nothing's ever as trivial as you first think.  :)

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: Reworked fvwm-menu-desktop

2011-11-01 Thread Thomas Adam
On Tue, Nov 01, 2011 at 01:07:27PM +0100, Thomas Funk wrote:
 I constructed create_fvwm2_menu_hash() and merge_fvwm2_menus() because I don't
 understand the structure Dan created in read_menu() ... but now it's more
 important to analyze it deeper, than fix merge_fvwm2_menus() because using his
 structure is the better way - it's in one context ...
 
 Dan, if i need help to understand your work, would you help me? Would be 
 great ...

Dan didn't construct that structure, that's how it was originally based on
parsing the XML files for the XDG menu definitions, and it's always been the
structured formed from the XDG data which I've had an issue with, since it's
very inefficient.

And it's this, including my reply to you previously in this thread, which I
was hoping you'd be addressing.  Yes, the XDG spec talks about merging items
together, etc., and that's fine, but making that a direct facet of how the
data is structured and stored is not the bes thing to do, IMO.

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: Reworked fvwm-menu-desktop

2011-10-30 Thread Thomas Adam
Hi,

[ I have no time at all to really give this the attention it deserves, so
I'm going to have to be brief and merely point you in the right directions.
I will though expect this to go through several iterations as a result. ]

On Sun, Oct 30, 2011 at 11:54:29PM +0100, Thomas Funk wrote:
 -Ursprüngliche Nachricht-
 Von: Thomas Adam tho...@fvwm.org
 Gesendet: 20.10.2011 15:00:58
 An: Thomas Funk t.f...@web.de
 Betreff: Re: Reworked fvwm-menu-desktop
 
 Some very quick observations...
 [...]
 
 Can you describe the internal data overall, and now it's derived, and then
 we can look at how best to process it. That way, we can reduce a lot of the
 clutter, and define a more cleaner interface for all of this.
 
 Hi Thomas,
 sorry for the delay, but I was seriously ill the last days. But now I've done 
 the description of merge_fvwm2_menus.

It's fine.  I wasn't interested in the descriptions actually, since I can
read your code fine.  I wanted the internal structure which you've now
given.

 sub merge_fvwm2_menus {
     my $weight = 0;
     my $reference_menu;
     # check first if xdg_menu_prefix is set
     if (defined $xdg_menu_prefix) {
     $reference_menu = $xdg_menu_prefix;
     } else {
     # check if applications.menu exist
     # question: correct to disable autovivification?
     if (ref $fvwm2_menus{''} eq 'HASH') {
     $reference_menu = '';


This is ultimately incorrect, but I think you now understand why.

     } else {
     # get the biggest menu as reference
     foreach my $prefix (keys %fvwm2_menus) {
     my $size = scalar keys %{$fvwm2_menus{$prefix}};


Can just say:

my $size = (keys %{...});

     ## compare the other menus with reference and delete same entries
     # create an fvwm menu hash
     %{$fvwm2_menus{'fvwm-'}} = %{$fvwm2_menus{$reference_menu}};
     # get the first hash key ('gnome-', 'kde-', 'fvwm-')
     foreach my $compare_menu (keys %fvwm2_menus) {
     # don't check the reference or the fvwm menu
     next if ($compare_menu eq $reference_menu || $compare_menu eq 
 'fvwm-');

     # get the menu names from the reference menu (check the known menus 
 for same entries)
     foreach my $refkey (keys %{$fvwm2_menus{$reference_menu}}) {
     # get the menu names from the menu should compared
     foreach my $compkey (keys %{$fvwm2_menus{$compare_menu}}) {
     # compare array A (@{$fvwm2_menus{$compare_menu}{$compkey}}) 
 to Array B (@{$fvwm2_menus{$reference_menu}{$refkey}})
     # and removing B elements from A. Exception: DestroyMenu and 
 AddToMenu entires
     my @rest = grep { my $x = $_; not grep { $x =~ /\Q$_/i and $x 
 !~ /DestroyMenu|AddToMenu/} @{$fvwm2_menus{$reference_menu}{$refkey}} } 
 @{$fvwm2_menus{$compare_menu}{$compkey}};

This is why your structure is incorrect -- and leads to inefficiencies like
this.  What you actually have in the abstract case is a structure such as
this:

# This is just me thinking...
%menu = (
'fvwm' = {
'name' = mynicenewmenuname,
'items' = [
{
'label' = 'label4',
'action' = $some_action4,
'icon' = undef,
},
{
'label' = 'label3',
'action' = $some_action3,
'icon' = undef,
}
],
}
);

Note that you might have multiple item sections, perhaps where each section
has a separator line (+ Nop) defined in it.  How this translates from
{gnome,kde}- prefix menus, I don't know.  It's down to you to find out.

Traversing this is slightly easier then, for you can now do things like:

my @menu_entries = map {
   + . $_-{'label'} . \tPopup  . $_-{'action'} . ,\n;
} @{ $menu{'fvwm'}{'items'} };

This will allow to use functions like join as well as anything else.  Note
the struture says nothing about the overall format for things like needing
{Add,Destroy}Menu lines.  These can be added at the point you generate the
menu, and do not need to be stored as part of the menu's data.  You need
only look at the rather hacked-up fvwm-convert-2.6 script to see examples of
this which I wrote.

The other benefit to the above is that traversing this also means you do not
end up grepping an array, but now can check a hash key which is O(1) and not
O(n*m) as in your current implementation.

Grepping/manipulating data which is already in the output format you're
after is almost always doomed to looping and ugly constructs because that
data is almost never in a parsable format to begin with.

HTH,

-- 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: po files of locale zh_TW

2011-10-22 Thread Thomas Adam
On Thu, Oct 13, 2011 at 11:54:20PM +0800, 趙惟倫 wrote:
 Hi,
 
 In attachment there are po files of locale zh_TW.

Can you please confirm in branch-2_6 in CVS that FVWM translates to the
given locale, please?  I can't test this myself.

-- 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: Reworked fvwm-menu-desktop

2011-10-20 Thread Thomas Adam
On Thu, Oct 20, 2011 at 01:07:07PM +0200, Thomas Funk wrote:
 On Thu, Oct 20, 2011 at 12:12:43PM +0200, Thomas Adam wrote:
 Thanks, but I'd like to see a unified diff, not an entire file.
 
 Uuups, sorry :S
 
 Attached.

Some very quick observations...


+my $xdg_data_home = $ENV{XDG_DATA_HOME} || $ENV{HOME}/.local/share;
+my $xdg_menu_prefix = $ENV{XDG_MENU_PREFIX} || '';
+my %xdg_menus;
 my @PATH_DIRS = split(':',$ENV{PATH}); # for checking if applications exist
 
+

Why?

 my $version = '2.6.4';
 my $menu_prefix='FvwmMenu';
 my $DefaultAppDirs;
@@ -116,19 +144,22 @@
 my $charset = 'iso-8859-1';
 my $root_cmd;
 my $kde_cmd;
+my $menu_content = 'applications';
+my $global = 0;

What's global here?

my $die_on_error = 0;
 my $verbose = 0;
+my $desktop;
 
 my @language_keys;
 
 #my @accessed_files;
 my $TERM_CMD = xterm -e;
 
-

Why?

 my %Desktop_entries;
 my %Directory_entries;
 
 my $root_menu;
+my $user_menu;
 my $help;
 
 # Default for the mini-icons is mini/ (relatively to the ImagePath)
@@ -202,14 +233,20 @@
   check-app!   = \obsolete,
   time-limit=s = \obsolete,
   merge-user-menu  = \obsolete,
-  desktop=s= \obsolete,
+  desktop=s= \$desktop,
   su_gui   = \$root_cmd,
   kde_config   = \$kde_cmd,
-   verbose  = \$verbose
+  content=s= \$menu_content,
+  global   = \$global,
+   verbose  = \$verbose
 );
 
 icon_init();
 
+if (defined $desktop) {
+$xdg_menu_prefix = $desktop-;
+}
+
 # kde-config helps us find things.
 # sometimes it has funny names.
 # we can get by without it.
@@ -225,7 +262,25 @@
 $DefaultAppDirs = get_app_dirs();
 $DefaultDirectoryDirs = get_desktop_dirs();
 
-$root_menu = get_root_menu();

Would be nice to use File::BaseDir to be honest for all of this.

+# get menus
+unless ($global) {
+# first check user home
+foreach my $dir (split(/:/, $xdg_config_home)) {
+my $user_file_list = get_file_list($dir/menus, 0);

What's 0 here supposed to signify?

+print \n;
+foreach my $prefix (sort (keys %xdg_menus)) {
+  warn \tDEBUG: ${prefix}menu is \'$xdg_menus{$prefix}\'.;

Read up on the qq operator here.

+foreach my $prefix (sort (keys %xdg_menus)) {

You sort this a lot -- why?  Can you not sort %xdg_menus once, or better yet
Tie it?

 
-if ($file !~ /^\// and defined $basedir)
-{
-$file = $basedir/$file;
-}
-
 unless (defined $basedir)
 {
 $basedir = $file;
 $basedir =~ s/\/[^\/]*$//;
+} else {
+if ($file !~ /^\// and defined $basedir)
+{
+$file = $basedir/$file;
+} else {
+$basedir = $file;
+$basedir =~ s/\/[^\/]*$//;

Do we guarantee -d $basedir at all with all this mangling?  See File::Copy
for instance.

+sub get_file_list
+{
+my ($path, $subdirs) = @_;
+$subdirs = defined($subdirs)?$subdirs:0;

But $subdirs is always defined here -- you're passing it in.  Note that the
idiom you're referring to is:

$subdirs ||= 0;

+my %files = ();
+push (my @all_directories, $path);

Why?

+foreach my $dir (@all_directories) {
+opendir (my $IN, $dir) || return {};
+my @all = readdir($IN);
+closedir $IN;
+
+foreach my $file (@all) {
+next if ($file eq '..' || $file eq '.');

You can avoid this by not slurping readdir into an array.

my @all = grep { !/^\.+/ and -d } readdir(...);

And note that @all needs a better name.

+if (-d $dir/$file) {
+if ($subdirs == 1) {
+push (@all_directories, $dir/$file);
+$files{$dir/$file} = $file;

Nasty to use a key name like that.

-# Fixme, remove unsupported options.
+sub get_prefixes_and_menus {
+my $file_list = shift;
+my $verbosecheck = 0;
+foreach my $file (sort (keys %{$file_list})) {

Why sort?

+next if (-d $file);

Unlikely.

+if ($file_list-{$file} =~ m/(.*)$menu_content.menu(.*)/) {

This is a little ugly, given the interolation each time.  Substr() the
thing instead.

+my $front_prefix = $1;
+my $back_prefix = $2;

You should always check these, especially given the greedy patten match.

+sub create_fvwm2_menu_hash {
+my $menu = shift;
+my %new_menu = ();
+my @reference_menu = split(\n, $menu);
+# first create menu hashes
+foreach my $line (@reference_menu) {
+if ($line =~ m/^DestroyMenu \(.*)\/) {
+$new_menu{$1} = ();
+}
+}

my %new_menu = map {
/^DestroyMenu \(.*)\/ and $1 = ''
} split(\n, $menu);

Assigning an empty list literal as you've done is meaningless in this
context.

+# add menu entries
+foreach my $key (keys %new_menu) {
+my $start = 0;
+foreach my $line (@reference_menu

Re: Reworked fvwm-menu-desktop

2011-10-20 Thread Thomas Adam
On Thu, Oct 20, 2011 at 04:59:40PM +0200, Thomas Funk wrote:
 -Ursprüngliche Nachricht-
 Von: Thomas Adam tho...@fvwm.org
 Gesendet: 20.10.2011 15:00:58
 An: Thomas Funk t.f...@web.de
 Betreff: Re: Reworked fvwm-menu-desktop
 
 Some very quick observations...
 
 +my $xdg_data_home = $ENV{XDG_DATA_HOME} || $ENV{HOME}/.local/share;
 +my $xdg_menu_prefix = $ENV{XDG_MENU_PREFIX} || '';
 +my %xdg_menus;
  my @PATH_DIRS = split(':',$ENV{PATH}); # for checking if applications exist
 
 Why?
 because it's follows the xdg spec.

No, this was in reference to a blank line, which had no reason being there
(yes, I am picky.)

 because it's a command line variable? I thought I need it. It's like the same
 as with $kde_cmd. Or not?

Same reason as above -- a blank line.  Why?

 I sort it because an empty key ('' = applications.menu) should start first.
 But I see, in this case it is useless.

A key of '' is a bug, not a feature.  :)

 Can you not sort %xdg_menus once, or better yet Tie it?
 I red often that hash keys cannot sorted. They will be written
 randomly into the hash structure. So, therefore I sort them ever i need it ...

Yes, hash lookups are not ordered, but it wasn't that which I was asking, it
was why the need to sort at all, and why do it where it's needed?

 +sub create_fvwm2_menu_hash {
 + my $menu = shift;
 + my %new_menu = ();
 + my @reference_menu = split(\n, $menu);
 + # first create menu hashes
 + foreach my $line (@reference_menu) {
 + if ($line =~ m/^DestroyMenu \(.*)\/) {
 + $new_menu{$1} = ();
 + }
 + }
 
 my %new_menu = map {
  /^DestroyMenu \(.*)\/ and $1 = ''
 } split(\n, $menu);
 
 Assigning an empty list literal as you've done is meaningless in this
 context.
 I thought pattern matching is faster than working with substrings :S

No -- firing up the regexp engine is expensive on items where substr() is
more useful, no matter now tempting it is to do otherwise.  Especially for
interpolated content which is generally set once and then never changes.

-- Thomas Adam



Re: po files of locale zh_TW

2011-10-14 Thread Thomas Adam
On Thu, Oct 13, 2011 at 11:54:20PM +0800, 趙惟倫 wrote:
 Hi,
 
 In attachment there are po files of locale zh_TW.

Thanks.  Will apply these with a few minor changes at the weekend.

-- Thomas Adam



Re: [PATCH] Fix broken Perl version dependency in fvwm-menu-desktop

2011-04-16 Thread Thomas Adam
On Sat, Apr 16, 2011 at 11:56:36PM +0400, Sergey Vlasov wrote:
 use version '5.0008' does not do what was intended - the proper form

Thank you, but I've already fixed this with a runtime check for XML::Parser.

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: fixing FvwmProxyMove.

2010-09-16 Thread Thomas Adam
On 16 September 2010 13:50, Sergey Vlasov v...@altlinux.ru wrote:
 Removing the offending line fixes the problem.

Thanks.  I had to copy and paste what looked like your Changelog
entry.  Annoyingly.   Please read up on how we accept patches here.

If there's another bug that crops up with this again, be warned I'll
revert both this, and Vermeulen's patch.

-- Thomas Adam



Re: fixing FvwmProxyMove.

2010-09-16 Thread Thomas Adam
On Thu, Sep 16, 2010 at 05:55:38PM +0400, Sergey Vlasov wrote:
 On Thu, Sep 16, 2010 at 02:14:57PM +0100, Thomas Adam wrote:
  On 16 September 2010 13:50, Sergey Vlasov v...@altlinux.ru wrote:
   Removing the offending line fixes the problem.
  
  Thanks.  I had to copy and paste what looked like your Changelog
  entry.  Annoyingly.   Please read up on how we accept patches here.
 
 Oops.  (Some other projects prefer Changelog separate from the patch -
 most likely to avoid rejects when someone else had also added a
 Changelog entry.)

Not here.  We prefer them together.

 Yes, there is a bug - the patch was applied at the wrong place (I
 wonder how that could happen, there are different number of leading
 tabs in those places).
 
 Here is the fixup patch, if you will not decide to revert the whole
 thing (with -U10, so that at least one different context line would be
 visible - yes, that much code is duplicated there):

For crying out loud.

I've pushed this for now -- when I get home, this entire function gets my
own special treatment of refactoring.  This shouldn't take two bloody
patches to get right.

Watch this space.

-- Thomas Adam



Re: Hi!

2010-02-16 Thread Thomas Adam
On Tue, Feb 16, 2010 at 10:25:44AM -0500, MK wrote:
 On Mon, 15 Feb 2010 20:12:08 -0600
 Jonathan Kotta jpko...@gmail.com wrote:
  On Mon, Feb 15, 2010 at 7:56 PM, MK halfcountp...@intergate.com
  wrote:
   But I don't see a way to call a function on a window by name? ?Am I
   wrong?
  
  Have look at List of Conditional Commands in the manpage.  Look at
  All, Next, and Prev in particular.  You can also use WindowId if you
  know the window's ID.
 
 Thanks, that will probably work, at least for the first part.
 
 However, I now notice that FvwmPager has a zero length title in the
 window list.  Does anyone know of a way to give it a name, or do I have
 to patch the FvwmPager source?

Eh?  Are you sure you haven't set the style WindowListSkip on it or
something?  By default, the name of the FvwmPager is the name of the current
desk you're on, as referenced through either the deprecated option
*FvwmPager: Label, or more preferrably:  DesktopName.

But patch the source?  No.

 Tangential question: am I missing something or is WindowId bordeline
 useless?  Isn't this like saying You can use the exact address of the
 variable if you know it?  Sure, but it is unlikely to remain the same
 between invocations and AFAICT must be hardcoded in .fvwm2rc...

Oh, it has a lot of uses in passing around specific window IDs to functions
to refer to specific windows -- and is used a lot internally by FVWM as
well.

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: Hi!

2010-02-16 Thread Thomas Adam
On Tue, Feb 16, 2010 at 12:24:53PM -0500, MK wrote:
 I could see it being useful internally; but as for specific windows in
 the config how can you know in advance what windowID to use?

Oh right -- in that case it's probably not useful, not when most things tend
to run in window context anyway.  It used to be useful for use with
FvwmEvent, when the windowid was passed into a calling function for the
event, so you could do something like:

*FvwmEvent: passid
*FvwmEvent: configure_window FooFunc

DestroyFunc FooFunc
AddToFunc   FooFunc
+ I WindowId $0 (Optional_name) DoSomething

... but these days, because the calling function operates within the context
of a known window, such checks degrade to:

+ I ThisWindow (Optional_name) DoSomething

So, standalone it's usecase is somewhat limited.

Why do you even ask, out of interest?

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: Bug report: FvwmIconMan weighted sorting

2010-02-15 Thread Thomas Adam
On 3 October 2009 02:23, Thomas Adam thomas.ada...@gmail.com wrote:
 2009/9/22 Thomas Adam thomas.ada...@gmail.com:
 2009/9/22 Leeman Strout m...@mooluv.com:
 I realize that it's all case sensitive, and I used xprop to find this info.
  As for specific cases for case sensitivity, this is what xprop says for
 gvim:  WM_CLASS(STRING) = gvim, Gvim    and pidgin:

 Ah -- you're failing to interpret that correctly.  The lowercase
 version is the *resource*, and the Gvim one there is the *class*.
 Look at FvwmIdent for instance.

 Leeman,

 What is the status of this?  It was left dangling, pending feedback from you.

I'll try one last time, then I am unconditionally dropping this
without another word -- I just want my TODO list to shrink.

Leeman -- speak now about the status of this, or consider it
unconditionally dropped.  ;P

-- Thomas Adam



Re: Hi!

2010-02-15 Thread Thomas Adam
On Mon, Feb 15, 2010 at 08:56:03PM -0500, MK wrote:
 The style settings already depend upon regexing or globbing with the
 window names (hey -- which is it?) .  Those are hardcoded in the

Look at the implementation of matchWildcards() in libs/wild.c

-- Thomas Adam

-- 
It was the cruelest game I've ever played and it's played inside my head.
-- Hush The Warmth, Gorky's Zygotic Mynci.



Re: Bug report: FvwmIconMan weighted sorting

2009-10-02 Thread Thomas Adam
2009/9/22 Thomas Adam thomas.ada...@gmail.com:
 2009/9/22 Leeman Strout m...@mooluv.com:
 I realize that it's all case sensitive, and I used xprop to find this info.
  As for specific cases for case sensitivity, this is what xprop says for
 gvim:  WM_CLASS(STRING) = gvim, Gvim    and pidgin:

 Ah -- you're failing to interpret that correctly.  The lowercase
 version is the *resource*, and the Gvim one there is the *class*.
 Look at FvwmIdent for instance.

Leeman,

What is the status of this?  It was left dangling, pending feedback from you.

-- Thomas Adam



Re: Bug report: FvwmIconMan weighted sorting

2009-09-22 Thread Thomas Adam
2009/9/22 Leeman Strout m...@mooluv.com:
 I realize that it's all case sensitive, and I used xprop to find this info.
  As for specific cases for case sensitivity, this is what xprop says for
 gvim:  WM_CLASS(STRING) = gvim, Gvim    and pidgin:

Ah -- you're failing to interpret that correctly.  The lowercase
version is the *resource*, and the Gvim one there is the *class*.
Look at FvwmIdent for instance.

So in your case, in terms of your config file, you probably want to do:

s/class/resource//g

But it's academic at this point, since all of this has come down to
your own misunderstanding entire.  Next time, use FvwmIdent for this
sort of thing.  xprop is a tool intended for developers more than
anything else.

WM_CLASS(STRING) =
 pidgin, Pidgin  So those should be no issue I would think.

See above.

 Paying attention to your specifying class I re-read the IconMan man page.
  Is IconMan not able to deal with name=...  as in my jEdit line?

It is, I just found it easier to use classes/

 Other than that it would seem that this config should work.

But it won't.  See above.  Again, as I stated originally, as the
weightings in your example mostly come out all at 40, FvwmIconMan will
fall back to a string comparison for working out placements in the
FvwmIconMan list.

-- Thomas Adam



Re: Bug report: FvwmIconMan weighted sorting

2009-09-21 Thread Thomas Adam
Hello --

2009/9/9 Leeman Strout m...@mooluv.com:
 I believe that I am experiencing a bug in the weighted sorting for
 FvwmIconMan.

 pertinent Iconman config:
 *FvwmIconMan: Sort       weighted

 *FvwmIconMan: SortWeight 5  class=Firefox
 *FvwmIconMan: SortWeight 15 class=gvim
 *FvwmIconMan: SortWeight 15 name=jEdit*
 *FvwmIconMan: SortWeight 20 class=Terminal
 *FvwmIconMan: SortWeight 30 class=pidgin

 *FvwmIconMan: SortWeight 40

 Actual results in IconMan:
 Firefox / gcalc / gvim / pidgin / gftp / jEdit / Thunar / Terminal

 Expected results:
 Firefox / gvim / jEdit / Terminal / pidgin / (gftp / Thunar / gcalc)

Sorry it's taken me so long to get back to -- I've been busy.  I think
I've found the bug you're referring to -- patch attached, so if you
could apply it to the latest CVS HEAD, that'd be grand.

But first -- I really hope the above config snippet is in error -- I
mean, you *do* realise that the window Class, like everything else is
case-sensitive, right?   For me pidgin's class is really Pidgin, and
gvim's class is really Gvim.  You'll want to correct that first, and
I suspect when you do you'll get your expected result -- because at
the moment, the windows are being treated as though they had a
weighting of 40 in your example.

However, there is an edge-case in the comparisons for working out when
the slots for the windows are meant to happen, and it's that which
this patch tries to address.  I really haven't tested it, so I would
appreciate you do thoroughly before I even consider adding it to CVS.

-- Thomas Adam
Index: modules/FvwmIconMan/xmanager.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/xmanager.c,v
retrieving revision 1.95
diff -u -r1.95 xmanager.c
--- modules/FvwmIconMan/xmanager.c  28 Jan 2007 15:29:26 -  1.95
+++ modules/FvwmIconMan/xmanager.c  21 Sep 2009 20:07:36 -
@@ -2153,7 +2153,15 @@
wb = compute_weight(b);
if (wa != wb)
{
-   return wa - wb;
+   /* TA:  (2009-09-21):  If the weightings of the window
+* don't match, only take the difference for list
+* insertion if the difference is less than the
+* weighting on the window -- and if not, use the
+* original weighting.  This takes into account those
+* windows using a default weighting matched against
+* those windows which have specific weightings.
+*/
+   return (wa - wb)  wa ? (wa - wb) : wa;
}
return strcmp((a-display_string)? a-display_string:,
  (b-display_string)? b-display_string:);


Re: Possible error in fvwm(1) manpage

2007-07-31 Thread Thomas Adam
On 31/07/07, Gustavo Rondina [EMAIL PROTECTED] wrote:
 Shouldn't that first after be replaced by before?  These two
 paragraphs seems to be opposing each other.  The first says that it
 is critical (i.e., dangerous, error prone) to start apps or modules
 after the config file is entirely read and processed.  The second,
 on the other hand, states that apps and modules which must be
 launched on start up should be placed within an initialization
 function, so they would only be started after the config file was
 read and executed.  The latter assertion seems to go against the former.

Probably.  The whole point of that is in the way FVWM processes the
file it's reading.  It does this:

1.  Executes the entire file line-by-line.
2.  If it comes across function definitions such as
{Init,Start}Function, it executes those *AFTER* the entire file has
been processed.

So in that sense, what it's trying to convey is if you had this in your config:

Module FvwmButtons A
DestroyModuleConfig FvwmButtons A:*
*A: Columns 1
*A: Rows 20
*A: (1x1)

That there is every chance FvwmButtons might not start because of the
order you have specified things in.  Inverting that on its head:

DestroyModuleConfig FvwmButtons A:*
*A: Columns 1
*A: Rows 20
*A: (1x1)
Module FvwmButtons A

Makes all the more sense.  Although generally speaking you would leave
the module definitions in the file as-is, but move the module
invocation call into the function:

AddToFunc StartFunction I Module FvwmButtons A

This explains why you can have multiple:

AddToFunc StartFunction I Bar

lines in your config and have them all appear to run at the same time,
because StartFunction is read after the entire file has been
processed.

Kindly,

Thomas Adam



Re: Condition Visible does not seem to work when xcompmgr is running.

2007-07-03 Thread Thomas Adam

On 03/07/07, Michał Kazior [EMAIL PROTECTED] wrote:

But then again, why would Overlapped condition work flawlessly with
xcompmgr running ?


Because that's not done through notification -- that's just really
checking whether the window is in a layer that other windows don't
interfere with.

-- Thomas Adam


Re: Tracking flag changes from modules

2006-08-08 Thread Thomas Adam
On Tue, 8 Aug 2006 16:18:41 +0100
seventh guardian [EMAIL PROTECTED] wrote:

 On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote:
 As a way to provide backward compatibility and minimizing the
 effects of the above VISIBLE changes there could be provided a
 command that the modules could use to request an alias. This way
 the module would parse the command line alias options and request
 the attribution of an alias. So old configs would still work
 properly!! :)
   
Strange thing now looking through module_interface.c: there is already
a string array called pipeAlias!! Is it possible that the
infrastructure is already there??
  
   YES! Strangely enough, the infrastructure is there!! You can actually
   send commands to specific aliased modules! Just use the module alias
   instead of the name, and voila!
  
   Except pipeAlias is never properly written. It seems that someone
   started the job but didn't get to finish it.
 
  The code is as good as it could be at the time Mikhael wrote it.
  It's not much more than a hack that tries to guess whether the
  first argument of a module was intended to be an alias (i.e. not an
  option etc.).  It fails in a number of cases, but we can not do much
  better without rewriting the interface of some modules.
 
 So what could be the solution to the initial problem without any kind
 of rewrite?

There isn't, I'm afraid.  I can perfectly understand and see the logic behind
why the flags should be sent in the packet information -- however in order
for there to be a solution to what you're proposing, it is going to mean a
rewrite most likely.  This was discussed here on this list a few months ago.
If you like I will dig through the on-line archives for you.


  Well, shouldn't we try to stabilise 2.5.x now, release it an then think
  about big changes in the module interface?
 
 Yes.. But we are constantly facing problems that would either be
 solved by some kind of rewrite or by hacks..
 
 2.5 is mostly stable. It's definitely more stable than some other
 release programs

There's still one or two things that need fixing before I would deem 2.5.X as
a release candidate.  There's no rush.  :)  I'd much rather see it done
proper than released; pampering to the possible cries of the users that so
desperately want it.  :)

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Re: FvwmIconMan: debug code cleanup

2006-08-08 Thread Thomas Adam
On Tue, 8 Aug 2006 16:39:42 +0100
seventh guardian [EMAIL PROTECTED] wrote:

 On 8/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:
Hello,
 
  Here some documentation fixes and debug code cleanups in FvwmIconMan.
  Please see attached patch's ChangeLog section for more information.
 
 Hello!
 
 Your patch seems ok to me :)
 
 BTW, I've seen some references of manger replaced by manager. I
 guess having so many of them could mean the intended word was indeed
 manger. After a search in the dictionary, manger means something
 like a cattle pen (a fenced place where you put livestock). This
 would definitely fit the module, as it is indeed a fenced place for
 icons :)

Indeed -- have you never sung the Christmas carol Away in a Manger?

 Could there have been a misunderstanding of the Man short word right
 in the begining? Can the original author clear this up?

It depends in what context the word 'manger' is being used (I haven't
looked).  It does seem awfully like a typo to me.  :)

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Re: Patching FvwmButtons to use Balloons (tooltips).

2006-08-01 Thread Thomas Adam
On Tue, 1 Aug 2006 15:30:15 +0400
Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:

 My suggestions:
 
 - Use term 'tips' instead of 'balloons' in any new code  docs.

I was going to do this anyway.

 - Rename 'balloons' to 'tips' in FvwmPager, still supporting the old
   variant, but marking it explicitly as deprecated. (I can do all
   necessary changes and send a patch if core developers agree with this
   opinion).

I don't see a problem with this providing the Balloon* syntax is maintained
by *warning* of future deprecation (the classic example of this is the Decor
code in FVWM.  :P)

You can patch that aspect if you want, but the logic of it would be after I
have finished adding the necessary code to work with FTips.h, and seeing as I
am doing that anyway, marking as I go a warning of deprecation isn't all that
hard to be honest.  Either way I don't mind.

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Patching FvwmButtons to use Balloons (tooltips).

2006-07-31 Thread Thomas Adam
Dear all,

Before I attempt to do this, I just wanted to make sure that this is
something worthwhile doing.  Currently, FvwmPager is about the only module
that implements balloons to easily tell which window is which.  For a long
time now, one of the biggest feature requests has been for FvwmButtons to
support a similar feature.  (I have no doubt if we get this right,
FvwmIconMan might follow, since this has an applicable use for balloons also.)

Before I do this though I just want to check with you to make sure my
approach is correct.  I was thinking of using libs/FTips.h to do this in
FvwmButtons since this lib has been present for a while but never used.  I
assume it is a refactor of what FvwmPager currently has [1].

How should balloons work in FvwmButtons?  I was thinking of something akin to
the following:

*FvwmButtons: BalloonTitleFormat %t

Where '%w' could be the swallowed window's title.  Although this represents
some problems since not all FvwmButtons have swallowed windows, because
they're there to perform some action.  So, I am assuming instead such
balloons would be used on a per-button basis with the user supplying the
string, as in:

*FvwmButtons: (12x60, Swallow (...) MyApplication \
Exec exec MyApplication, Balloon This is MyApplication)

Within this of course, perhaps one could then use some form of '%t', '%i'
symbols to represent a window's title or icon name without having to do it
manually for swallowed windows.

I would assume that for sundry options such as:

BalloonColorset n

That would be a global option to FvwmButtons rather than a per-button
option?  (I say this only because FvwmPager does it this way -- but that
doesn't mean to say it's correct.  :P)

I'm open to suggestions on how to do this -- I can envisage some updates to
FTips.h to accommodate some of this.  I've not looked too deeply into it yet,
and wanted to seek approval/recommendations, etc., before I went ahead to try
and do this.

-- Thomas Adam

[1] Patching FvwmPager to make use of FTips.h is a task I can do at a later
date.

-- 
ThisWindow (thomas_adam) Destroy



Re: Documentation for module developers

2006-07-30 Thread Thomas Adam
On Sun, 30 Jul 2006 14:40:50 +0400
Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:

   Hi,
 
 Are http://www.fvwm.org/documentation/dev_modules.php is the only module
 related documentation available? BTW, I found an error on this page: in
 section 'Colorset support' InitPictureCMap() should be PictureInitCMap()
 instead (this function  was renamed on 2002-04-22 according to main
 ChangeLog).

Other than that minor fix, was there some specific information not listed on
that page you were after?

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Re: Documentation for module developers

2006-07-30 Thread Thomas Adam
On Mon, 31 Jul 2006 00:19:51 +0400
Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:

 On Sun, Jul 30, 2006 at 06:02:51PM +0100, Thomas Adam wrote:
  On Sun, 30 Jul 2006 14:40:50 +0400
  Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote:
  
 Hi,
   
   Are http://www.fvwm.org/documentation/dev_modules.php is the only module
   related documentation available? BTW, I found an error on this page: in
   section 'Colorset support' InitPictureCMap() should be PictureInitCMap()
   instead (this function  was renamed on 2002-04-22 according to main
   ChangeLog).
  
  Other than that minor fix, was there some specific information not listed
  on that page you were after?
 
 Yes. I want full FVWM API description. For example, FScreenInit,
 FRenderInit and many other functions used in modules aren't described
 there. Tutorials are also welcome. Of course I can figure out all
 missing details by reading source code, but this cost time.


Currently there isn't any such documentation about those.  Do what you can
by reading the source code and sporadic comments therein where applicable.
This is all I do.  If you feel like documenting it yourself as you go, that
too would be good.  :)

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Re: Manpage fix for 2.5.17: Wait command.

2006-07-29 Thread Thomas Adam
On Sat, 29 Jul 2006 10:50:21 +0200
Dominik Vogt [EMAIL PROTECTED] wrote:

 On Fri, Jul 28, 2006 at 11:30:19AM +0100, Thomas Adam wrote:
  Scott --
  
  On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley [EMAIL PROTECTED] wrote:
  
   Hi Thomas,
   
I noticed earlier that there is a discrepency in the FVWM manpage
(2.5.X series is the only one to be fixed) for the Wait command
description.  The description says initially that the command waits
of windowname.   This is parly true -- the code in builtins.c
apparently also checks for the window's tile, class and resource
(just like how the style command works).

I feel this needs to be reflected in its description
   
   ...
   
+.BI Wait [ windowtitle | windowclass | windowresource ]
   
   Personally, I think it would be prudent to stick with windowname here.
   A novice user might think it appropriate to specify, say, a window
   resource  then be surprised to learn that some other window with a
   matching _title_ was matched.
  
  
  That's fine, and it makes sense of course.  Quite often a window's name
  (as it appears on the titlebar) is taken from WM_TITLE anyway.
  
  
   How about:
   
   Wait windowname
 This  command is intended to be used in fvwm functions only.  It
 causes execution of a function to pause until a new window
   matching windowname appears. A window can match windowname on either its
 title, class or resource. This is particularly useful in
 InitFunction if you are trying to start windows on specific
   desks or pages:
   
   It's still not perfect - any suggested improvements?
 
 Why not just use the same text as the style command:
 
   stylename can be a window's name, class, or resource string.  It
   may contain the wildcards '*' and '?', which are matched in the
   usual Unix filename manner.
 
 Stylename should be replaced by something neutral, maybe just
 window.

That works for me, but other than agreeing with it, there's nothing more I
can do to correct it.  :)

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Re: Manpage fix for 2.5.17: Wait command.

2006-07-28 Thread Thomas Adam
Scott --

On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley [EMAIL PROTECTED] wrote:

 Hi Thomas,
 
  I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X
  series is the only one to be fixed) for the Wait command description.  The
  description says initially that the command waits of windowname.   This
  is parly true -- the code in builtins.c apparently also checks for the
  window's tile, class and resource (just like how the style command works).
  
  I feel this needs to be reflected in its description
 
 ...
 
  +.BI Wait [ windowtitle | windowclass | windowresource ]
 
 Personally, I think it would be prudent to stick with windowname here.
 A novice user might think it appropriate to specify, say, a window resource
  then be surprised to learn that some other window with a matching
 _title_ was matched.


That's fine, and it makes sense of course.  Quite often a window's name (as
it appears on the titlebar) is taken from WM_TITLE anyway.


 How about:
 
 Wait windowname
   This  command is intended to be used in fvwm functions only.  It
   causes execution of a function to pause until a new window matching
   windowname appears. A window can match windowname on either its
   title, class or resource. This is particularly useful in
   InitFunction if you are trying to start windows on specific desks
   or pages:
 
 It's still not perfect - any suggested improvements?


That's better.  I still think it is wise to specify in the syntax for the
command the fact that one can have:  windowname, windowclass, windowresource
-- and while I realise this forces a slight amount of Xlib knowledge onto the
user, it does clarify the list of options one can use to that command.  When
I first read it I was confused, since it did (to  me) read as though the
window's name was only considered.


  Note that in the function example accompanying the Wait command's
  description, I have taken the liberty of replacing the function's use of
  the Desk command with GotoDesk since this is now the preferred
  command to use.
 
 Ok.
 
  ThisWindow (thomas_adam) Destroy
 
 ThisWindow (thomas_adam) Wait godo :)


Heh.

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy



Manpage fix for 2.5.17: Wait command.

2006-07-27 Thread Thomas Adam
Hello,

I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X
series is the only one to be fixed) for the Wait command description.  The
description says initially that the command waits of windowname.   This is
parly true -- the code in builtins.c apparently also checks for the window's
tile, class and resource (just like how the style command works).

I feel this needs to be reflected in its description, hence see the patch
file attached with this email -- my groff skills are far from perfect, so I
hope it's accurate.  If not, let me know and I will ammend it for you.

Note that in the function example accompanying the Wait command's
description, I have taken the liberty of replacing the function's use of the
Desk command with GotoDesk since this is now the preferred command to use.

Note also that I feel the entire function example needs rewriting.   I am
hoping that in some future FVWM version that the use of InitFunction will be
completely deprecated in favour of using StartFunction explicitly and testing
conditions via:  Test (Init) Some_Command.

I've also replaced the use of 'windowname' to 'windowtitle' since the XAtom
WM_TITLE is apparent.  The name really ought to be windowtitle.

-- Thomas Adam

-- 
ThisWindow (thomas_adam) Destroy
--- ./fvwm.1.in.orig	2006-07-28 00:24:09.0 +0100
+++ ./fvwm.1.in	2006-07-28 00:58:01.0 +0100
@@ -10297,22 +10297,26 @@
 started directly by fvwm.
 
 .TP
-.BI Wait  windowname
+.BI Wait [ windowtitle | windowclass | windowresource ]
 This command is intended to be used in fvwm functions only.  It
 causes execution of a function to pause until a new window with
-the title
-.I windowname
-appears.  This is particularly useful in the InitFunction if you
-are trying to start windows on specific desktops:
+either the
+.I windowtitle
+or
+.I windowclass
+or 
+.I windowresource
+(in that order) appears.  This is particularly useful in the 
+InitFunction if you are trying to start windows on specific desktops:
 .EX
 AddToFunc InitFunction
  + I Exec exec xterm -geometry 80x64+0+0
  + I Wait xterm
- + I Desk 0 2
+ + I GotoDesk 0 2
  + I Exec exec xmh -font fixed -geometry \\
507x750+0+0
  + I Wait xmh
- + I Desk 0 0
+ + I GotoDesk 0 0
 .EE
 The above function starts an xterm on the current desk, waits for
 it to map itself, then switches to desk 2 and starts an xmh.


Re: Man page changes - negation method

2006-07-24 Thread Thomas Adam

On 24/07/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote:

seventh guardian wrote:
 On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote:
 seventh guardian wrote:
  Ok, what about this:
 
  Some options are now deactivated by prefixing ! to the option. This
  will eventually be the default, and the old negative options are
  now deprecated.
  This is a list of MenuStyle deprecated negative options:
  AutomaticHotkeysOff, HilightBackOff, TitleWarpOff
 
 
  It's a bit more conservative, yet should still be useful :)
 
  Cheers
   Renato

 the default in that could be confusing to new users, how about the
 preferred form?

 (default could be taken as all options will be default off.)

 You're right. But it will not be the preferred method, it will be the
 only method (hence the other methods being deprecated). Can you find
 me a word for the only method that fits here? :)

 Cheers
  Renato

 This would be:

 Some options are now deactivated by prefixing ! to the option.  This
 will eventually be the preferred form, and the old negative forms are
 now deprecated.


Ok, how about:

Some options are now deactivated by prefixing ! to the option.  This


I wouldn't use that word.  This seems to be becoming more complex when
it's actually very simple.  Rewording the sentence above, and adding
what you have below should be sufficient.  I would simply reword that
sentence as:

   Some options can now be negated by prefixing ``!'' to the option.


will soon be the preferred form for all such options.  Any negatable
option for which ! does not work should be reported as a bug.  The other
negative forms are now deprecated and will be removed in FVWM X.Y.



-- Thomas Adam



Added SkipSection MenuStyle option.

2006-07-21 Thread Thomas Adam
This is a rather esoteric patch, but one of the things I disliked about
the current menu behaviour is that pressing Ctrl-Tab on a menu would
jumpt to the next section delimited via separators.  I wanted to turn
this feature off, which I've now done by adding:  SkipSection /
!SkipSection menustyle options.

Please find the patch enclosed, it's patched against CVS.   I apologise
slightly for not using 'cvs diff' for most of the patches I write -- but
for very small things like this, I find going down the .orig route
easier.

-- Thomas Adam

-- 
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.
--- ./menustyle.c.orig  2006-02-09 11:49:33.0 +
+++ ./menustyle.c   2006-07-21 18:29:22.0 +0100
@@ -396,6 +396,7 @@
PopupActiveArea,
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage,
+   SkipSection,
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
@@ -1479,11 +1480,14 @@
case 57: /* ScrollOffPage */
ST_SCROLL_OFF_PAGE(tmpms) = on;
break;
-
-   case 58: /* TrianglesUseFore */
+   case 58:
+   /* SkipSection */
+   ST_SKIP_SECTION(tmpms) = on;
+   break;
+   case 59: /* TrianglesUseFore */
ST_TRIANGLES_USE_FORE(tmpms) = on;
break;
-   case 59: /* TitleColorset */
+   case 60: /* TitleColorset */
if (GetIntegerArguments(args, NULL, val, 1) == 0 ||
*val  0)
{
@@ -1498,11 +1502,11 @@
}
has_gc_changed = True;
break;
-   case 60: /* TitleHilightBack */
+   case 61: /* TitleHilightBack */
ST_DO_HILIGHT_TITLE_BACK(tmpms) = on;
has_gc_changed = True;
break;
-   case 61: /* TitleFont */
+   case 62: /* TitleFont */
if (arg1 != NULL 
!(new_font = FlocaleLoadFont(dpy, arg1, FVWM)))
{
@@ -1529,8 +1533,6 @@
}
has_gc_changed = True;
break;
-
-
 #if 0
case 99: /* PositionHints */
/* to be implemented */
--- ./menustyle.h.orig  2006-02-09 11:49:33.0 +
+++ ./menustyle.h   2006-07-21 18:01:06.0 +0100
@@ -129,6 +129,8 @@
 /* feel */
 #define ST_IS_ANIMATED(s) ((s)-feel.flags.is_animated)
 #define MST_IS_ANIMATED(m)((m)-s-ms-feel.flags.is_animated)
+#define ST_SKIP_SECTION(s)   ((s)-feel.flags.skip_section)
+#define MST_SKIP_SECTION(m)  ((m)-s-ms-feel.flags.skip_section) 

 #define ST_DO_POPUP_IMMEDIATELY(s)((s)-feel.flags.do_popup_immediately)
 #define MST_DO_POPUP_IMMEDIATELY(m)\
((m)-s-ms-feel.flags.do_popup_immediately)
@@ -217,6 +219,7 @@
unsigned use_automatic_hotkeys : 1;
unsigned mouse_wheel : 2;
unsigned scroll_off_page : 1;
+   unsigned skip_section : 1;
} flags;
int PopdownDelay10ms;
int PopupOffsetPercent;
--- ./menus.c.orig  2006-03-27 21:29:19.0 +0100
+++ ./menus.c   2006-07-21 18:40:33.0 +0100
@@ -1110,7 +1110,13 @@
break;
case 2:
/* ctrl-tab */
-   fSkipSection = True;
+   /* Negatable via the !SkipSection style flag */
+   if (!MST_SKIP_SECTION(mr))
+   {
+   fSkipSection = True;
+   } else {
+   fSkipSection = False;
+   }
break;
case 3:
/* ctrl-meta-tab */
--- ./fvwm.1.in.orig2006-07-21 19:15:27.0 +0100
+++ ./fvwm.1.in 2006-07-21 19:05:49.0 +0100
@@ -3514,6 +3514,12 @@
 .I !ScrollOffPage
 disables this behaviour.
 
+.I SkipSection
+removes the ability to have the first item of each section (when using
+menus separators) to be selected when pressing Ctrl-Tab on a menu.
+.I !SkipSection
+enables this behaviour.
+
 .I TrianglesUseFore
 draws sub menu triangles with the foreground color of the menu colorset
 (normally drawn with the hilight color).


Re: FVWM: How to use StippledTitleOff

2006-07-19 Thread Thomas Adam
On Mon, Jul 17, 2006 at 06:20:43PM +0100, seventh guardian wrote:
 On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote:
 On Mon, Jul 17, 2006 at 04:56:18PM +0100, seventh guardian wrote:
 
  Lol.. Yes, but how do you specify if its an and or an or?
 
 Just have two separate lines for them?
 
 Style (title=foo, winstate=normal ii, winstate=iconic ) .


 Touche.. :) Renato

Well, in the meantime, and as a proof-of-concept, see:

http://edulinux.homeunix.org/fvwm/patches.html

-- Thomas Adam

-- 
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.



Re: FVWM: How to use StippledTitleOff

2006-07-17 Thread Thomas Adam
On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote:
 On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote:
 On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote:
 
  Thomas Adam [EMAIL PROTECTED] writes:
 
   On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote:
  
   However it seems it does nothing at all. All the icons still
   have sticky title. Any ideas?
  
   Of course -- the style StippledTitleOff is only applicable to
   non-sticky windows which have been told to use StippledTitle --
   it doesn't work for sticky windows.

 Humm first of all this now should be a flag StippledTitle vs
 !StippledTitle. I will correct the man page.

Most commands should be using !Foo in the negatory sense.

 Style only works with window/class names. So there's no easy way of

Name, Class, Resource.

 telling fvwm just to stipple sticky windows. (Like Style Sticky
 !StippledTitle). Perhaps this could be done with conditional
 commands, but it's not an easy thing. 

How do you mean?  It's perfectly simple to add something like:

Style * StickyStipples
Style * !StickyStipples

... Which might apply to windows which have been declared as sticky.


 The imediate solution would be
 to add another style to set/reset the StippledTitle flag only on the
 sticky windows, or globally (like Style * NeverStipple) but in my
 oppinion this is wrong..

Maybe it is, but then you can turn that around and say that stippling
sticky windows in the first place is also wrong. 

 But the long term solution would be to extend the Style command not
 just for window/class names but also for Window states (Style Icon
 (...) or Style Sticky (...)). Dominik?

I don't like this, since you would probably extend it to include things
like:

Style Shaded (...)
Style HasTitle (...)

It gets too boring, unmanagable, and ultimately wrong.   The stylation
of window *states* (as in the above) just doesn't make logical sense to
me.

-- Thomas Adam

-- 
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.



Re: Flags - is negation prefered?

2006-07-17 Thread Thomas Adam
On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote:
 Hi.

 I have a question. Is the flag vs. !flag syntax the prefered one? I
 ask this because even though some styles only have the !(stylename)
 counterpart, some are still documented as (stylename)Off. So if the
 flag negation is prefered to the (stylename) vs. (stylename)Off, or
 the other way round, then it should be explicit in the man page. This
 is the only way we can avoid compatibility confusion in a future
 version.

 My opinion is that the flag vs. !flag style is simpler to parse, and
 it should be prefered. the (stylename)Off code should be maintained
 for compatibility's sake, but marked as deprecated.

 Comments? Renato

Yes -- I thought 2.5.X was having the !Foo syntax as the preferred one,
removing any old Foo versus NoFoo options.  Of course, it's currently on
FVWM 2.4.X which still exhibits this.

-- Thomas Adam

-- 
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.



Re: FVWM: How to use StippledTitleOff

2006-07-17 Thread Thomas Adam
On Mon, Jul 17, 2006 at 04:01:36PM +0100, seventh guardian wrote:
 Yes, but then you'd end up with lots of equal styles applying to
 different situations..

I don't see how -- it still only applies to a specific group of windows
(or a specific window, depending on the style used.)

 It would allow us for instance to use a different color style for
 sticky windows, instead of just allowing stippling..

You can do this with FvwmEvent -- although currently you can't turn the
stipples off.

 It would allow setting different colors to the iconified windows. This
 currently can only be done with the use of colorsets, which I belive
 is a broken behaviour.

Do you?  An icon is just another window -- giving it its own colorset
makes sense to me.

 And the list goes on. It's a flexible solution that follows the same
 philosophy that was behindreplacing all sorts of old fvwm commands
 with their Style counterpart..

Maybe -- I just think it adds too much verbosity.  I'd much rather more
work was done to look into the following idiom:

Style (name=foo, class=Foo) Stick

... Which currently has its own branch in the FVWM CVS, but obviously
breaks any compatibility with the way current style lines are parsed.
The above is something I'd prefer to see, above and beyond changing the
style states for different windows.

-- Thomas Adam

-- 
If I were a witch's hat, sitting on her head like a paraffin stove, I'd
fly away and be a bat. -- Incredible String Band.



  1   2   >