REWRITE: Porting patches from fvwm to mvwm?
Thomas, what's that plan to get the patches and fixes in fvwm since you forked the mvwm repo into the latter? From which fvwm commit did you fork? Maybe we could set tags in fvwm and mvwm to identify these commits. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Some removed features
Dominik Vogt dominik.v...@gmx.de wrote: 2. Support for xpm, xbm and svg images. While I've no idea whether svg images are really usefull (in title buttons perhaps?), xpm images, and to a lesser extent xbm iamges, are still used a lot in old icon themes. So I vote for reviving support for xpm and xbm format. I can take care of both. In Fvwm-Nightshade I am using mostly svg's because of the flexibility in conjunction with different display resolutions. Also the trend in other DEs/WMs is in direction to svg (icon themes, decorations). It would be a pitty if FVWM(3) loose this support. But to reduce the core to an effective minimum it is ok for me. I suppose that Thomas thought to implement those parts as modules which would be great because then other image formats can plugged to FVWM very easily. Also it would reduce the maintenance ^^ -- Thomas --
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote:
Some features that have been removed in mvwm that I'm not sure
about:
1. FvwmCpp and FvwmM4
Heh. In my mind, it came back to maintainability, and from time-to-time we
often see problems with people trying to use these modules. but with nonone
in the development team really owning them, so most of the problems end up
either being ignored or worked around at some higher level. (Some of the
problems may be surrounding the whole approach of ModuleSynchronous, etc.,
but that's tangential to my point.)
These preprocessing modules are an important part of fvwm's
flexibility. I extensively use FvwmCpp to adapt my fvwm config
to the actual machine I'm working on. My .fvwm2rc looks like
this:
Oh, I understand their use, and I appreciate that the module interface fvwm
has allows for these sorts of things to be written. My eventual aim though
is to see them naturally fall out of usefulness over time; assuming we have
a more robust parser, we shouldn't *need* these kinds of modules to
preprocess commands for us.
But we're a long way off that, so perhaps reviving FvwmCpp in the interim
should happen. I'd be OK with that.
But please bear in mind that I am seriously *loathe* to want to keep adding
things in; the whole point of trying to clean this up is to also identify
easy wins of removal as well. So I'm willing to be flexible on this, of
course. And seeing as this is a module, there's perhaps no harm in reviving
it.
Go for it. :)
2. Support for xpm, xbm and svg images.
While I've no idea whether svg images are really usefull (in
title buttons perhaps?), xpm images, and to a lesser extent xbm
iamges, are still used a lot in old icon themes. So I vote for
reviving support for xpm and xbm format.
Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one
image format used. PNG seems to suffice for this, and caters for replacing
{X,B}PM files, as they can easily be converted without any hassle to the
user. If necessary I could even put a script in contrib/ to facilitate
this. It also reduces the code a little.
-- Thomas Adam
Re: REWRITE: Porting patches from fvwm to mvwm?
On Mon, Aug 18, 2014 at 03:58:13PM +0100, Dominik Vogt wrote: Thomas, Hi, what's that plan to get the patches and fixes in fvwm since you forked the mvwm repo into the latter? From which fvwm commit did you fork? Maybe we could set tags in fvwm and mvwm to identify these commits. It looks like I forked it from here: 6f2b4e3134b4270d1ef8d2bb05ad42161260565c Going from the commit in: https://github.com/ThomasAdam/fvwm Hence in the mvwm repo, I have this: % git remote add fvwm ssh://g...@github.com:ThomasAdam/fvwm.git % git fetch fvwm % git log fvwm/branch-2_6..master And I can see the butchery I've done to mvwm since that point. Would it help if you had collaboration rights to my fvwm.git repository as well, Dominik? -- Thomas Adam
Re: REWRITE: Comments on change of coding style
On Mon, Aug 18, 2014 at 03:04:19PM +0100, Dominik Vogt wrote: On Sun, Aug 17, 2014 at 03:30:04PM +0100, Thomas Adam wrote: On Sun, Aug 17, 2014 at 03:27:32PM +0100, Dominik Vogt wrote: Would simply reverting the reindentation commit and postponing a new round of reindentation be okay? Yup; go for it. :) Done. The new branch is named dv/undo-reindent. Please double check that I did not forget to include some files - had to redo the renaming step from scratch. Also, I've added several low level .gitignore files to ignore some generated files. Did you actually push your commits onto this branch, as I only see my own butchery there, and nothing from you? -- Thomas Adam
Re: REWRITE: Porting patches from fvwm to mvwm?
On Mon, Aug 18, 2014 at 05:02:24PM +0100, Dominik Vogt wrote: On Mon, Aug 18, 2014 at 04:12:19PM +0100, Thomas Adam wrote: On Mon, Aug 18, 2014 at 03:58:13PM +0100, Dominik Vogt wrote: Would it help if you had collaboration rights to my fvwm.git repository as well, Dominik? I don't know, but if you just give them to me we can figure out later whether that is usefull. :-) I'm still a beginner with github. That's OK. I've added you. Your remote for this is: g...@github.com:ThomasAdam/fvwm.git Should you ever want to push things out there. Don't commit to the branch-2_6 directly, that's the sync point from CVS which I use, and happens to be the default branch when you clone from that repo. HTH, -- Thomas Adam
Re: REWRITE: Some removed features
On Mon, Aug 18, 2014 at 04:06:02PM +0100, Thomas Adam wrote:
On Mon, Aug 18, 2014 at 03:18:13PM +0100, Dominik Vogt wrote:
Some features that have been removed in mvwm that I'm not sure
about:
1. FvwmCpp and FvwmM4
Heh. In my mind, it came back to maintainability, and from time-to-time we
often see problems with people trying to use these modules. but with nonone
in the development team really owning them, so most of the problems end up
either being ignored or worked around at some higher level. (Some of the
problems may be surrounding the whole approach of ModuleSynchronous, etc.,
but that's tangential to my point.)
These preprocessing modules are an important part of fvwm's
flexibility. I extensively use FvwmCpp to adapt my fvwm config
to the actual machine I'm working on. My .fvwm2rc looks like
this:
Oh, I understand their use, and I appreciate that the module interface fvwm
has allows for these sorts of things to be written. My eventual aim though
is to see them naturally fall out of usefulness over time; assuming we have
a more robust parser, we shouldn't *need* these kinds of modules to
preprocess commands for us.
But we're a long way off that, so perhaps reviving FvwmCpp in the interim
should happen. I'd be OK with that.
But please bear in mind that I am seriously *loathe* to want to keep adding
things in; the whole point of trying to clean this up is to also identify
easy wins of removal as well. So I'm willing to be flexible on this, of
course. And seeing as this is a module, there's perhaps no harm in reviving
it.
I find it really strange to have a configuration input filter
implemented as a module. I don't know what to do with it in the
long run, but at the moment I find it indispensable.
2. Support for xpm, xbm and svg images.
While I've no idea whether svg images are really usefull (in
title buttons perhaps?), xpm images, and to a lesser extent xbm
iamges, are still used a lot in old icon themes. So I vote for
reviving support for xpm and xbm format.
Hmm. I mean, try and convince me otherwise, Dominik, but I'd rather see one
image format used. PNG seems to suffice for this, and caters for replacing
{X,B}PM files, as they can easily be converted without any hassle to the
user. If necessary I could even put a script in contrib/ to facilitate
this. It also reduces the code a little.
I agree that converting them is not a big deal. It's just that
there are these old icon distributions in xpm format around. Maybe
it's indeed feasible to have a module concept like zsh that would
automatically load additional features when they are needed for the
first time. If the module concept was less broken, such features
could be implemented over the module interface.
And xpm images are easy to write as source code. Hm, don't we
have some hard coded xpm images somewhere in the sources anyway?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: REWRITE: Some removed features
Thomas Adam tho...@fvwm.org writes: On Mon, Aug 18, 2014 at 05:23:57PM +0100, Dominik Vogt wrote: I find it really strange to have a configuration input filter implemented as a module. I don't know what to do with it in the long run, but at the moment I find it indispensable. I understand. And xpm images are easy to write as source code. Hm, don't we have some hard coded xpm images somewhere in the sources anyway? We don't have anything in the source, but we do seem to offer these still: http://fvwm.org/download/icons.php Is that what you were thinking of? There are XPM files in the test directory and one XPM file stored with FvwmBanner. -- Dan Espen
Re: REWRITE: Comments on change of coding style
On Mon, Aug 18, 2014 at 05:44:55PM +0100, Dominik Vogt wrote: Done. I've moved the old master to master-bak-1. We can delete that and dv/undo-reindent once we're sure we don't need them anymore. Thank you. I've added some commits ontop of this to address a few missing files, as well as mvwm/mvwm binary being tracked. Please check you can built mvwm locally still. Kindly, -- Thomas Adam
Re: REWRITE: Some removed features
The MvwmCpp module is back on the master branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
REWRITE: mvwm_callow?
Is that a typo? Shouldn't the name be mvwm_calloc()? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: mvwm_callow?
On Mon, Aug 18, 2014 at 07:01:23PM +0100, Dominik Vogt wrote: Is that a typo? Shouldn't the name be mvwm_calloc()? Oh, stupid question. I've made the tyo myself. Fixed in a minute. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Comments on change of coding style
On Mon, Aug 18, 2014 at 06:16:37PM +0100, Thomas Adam wrote: On Mon, Aug 18, 2014 at 06:11:08PM +0100, Dominik Vogt wrote: Oh, great. Can you add the following CFLAGS in the make line? $ make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror Done. The definition for this is a .travis.yml YAML file in the root of the mvwm repository. Instead of sudo make install, a simple make distcheck2 should be much more helpful to see whether the sources compile and install. It does not run through at the moment, and I don't have time at the moment, but can take care if it later of you don't fix it before me. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Docs conversion and introducing a new (humble) contributor
Hi Roman, On Mon, Aug 18, 2014 at 10:43:55PM +0400, Roman Grazhdan wrote: documentation conversion part - docbook to mdoc. Can you give me a max. ten line summary of what mdoc is and give a short example of a file converted to that format, please? Additionally, Thomas proposed me to look into code formatting, and I'm still very enthusiastic about it, but I'm afraid I can't handle two pieces of work right now (but we can always reprioritise if need be). That's fine, I think the documentation issue is more important anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Docs conversion and introducing a new (humble) contributor
On Mon, Aug 18, 2014 at 10:43:55PM +0400, Roman Grazhdan wrote: documentation conversion part - docbook to mdoc. Thomas, what about the documentation I had converted to asciidoc a year ago? -- Thomas -- -- -- Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. -- Albert Einstein
Re: REWRITE: Docs conversion and introducing a new (humble) contributor
On Mon, Aug 18, 2014 at 09:08:04PM +0200, Thomas Funk wrote: On Mon, Aug 18, 2014 at 10:43:55PM +0400, Roman Grazhdan wrote: documentation conversion part - docbook to mdoc. Thomas, what about the documentation I had converted to asciidoc a year ago? Ditched. Having seen asciidoc break itself too many times and have annoying dependencies, I'm not using it again. -- 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: REWRITE: Docs conversion and introducing a new (humble) contributor
On Mon, Aug 18, 2014 at 07:58:49PM +0100, Dominik Vogt wrote: Hi Roman, On Mon, Aug 18, 2014 at 10:43:55PM +0400, Roman Grazhdan wrote: documentation conversion part - docbook to mdoc. Can you give me a max. ten line summary of what mdoc is and give a short example of a file converted to that format, please? It's going back to using man pages. It's similar to roff, but not quite. .Dd $Mdocdate$ .Dt PROGNAME section .Os .Sh NAME .Nm progname .Nd one line about what it does .\ .Sh LIBRARY .\ For sections 2, 3, and 9 only. .\ Not used in OpenBSD. .Sh SYNOPSIS .Nm progname .Op Fl options .Ar .Sh DESCRIPTION The .Nm utility processes files ... I _really_ like it, and have been using it for years on several projects. The finer details: http://mdocml.bsd.lv/man/mdoc.7.html -- 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: REWRITE: Comments on change of coding style
On Mon, Aug 18, 2014 at 07:52:08PM +0100, Dominik Vogt wrote: On Mon, Aug 18, 2014 at 06:16:37PM +0100, Thomas Adam wrote: On Mon, Aug 18, 2014 at 06:11:08PM +0100, Dominik Vogt wrote: Oh, great. Can you add the following CFLAGS in the make line? $ make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror Done. The definition for this is a .travis.yml YAML file in the root of the mvwm repository. Instead of sudo make install, a simple make distcheck2 should be much more helpful to see whether the sources compile and install. It does not run through at the moment, and I don't have time at the moment, but can take care if it later of you don't fix it before me. Done. I've not changed the yml file yet because I know nothing about that and did not want to break it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Docs conversion and introducing a new (humble) contributor
On 18.08.2014 22:58, Dominik Vogt wrote: Can you give me a max. ten line summary of what mdoc is and give a short example of a file converted to that format, please? mdoc is a format used to write manual pages. Well I'm not sure if 'format' is a right word here, more like set of (g)roff macros. As such, it has macros working good with a traditional man page structure and parts. It's less semantic and than mdoc and probably won't produce such nice web pages, but it's more simple. A better description and good mdoc can be found here: http://mdocml.bsd.lv/. A worse mdoc formatted document can be found here: https://github.com/Hoodoo/mvwm-docs/blob/master/fvwm/man/options.mdoc to render it, run groff -mdoc -Tascii $document
Re: REWRITE: Docs conversion and introducing a new (humble) contributor
On Mon, Aug 18, 2014 at 09:00:36PM +0100, Thomas Adam wrote: It's going back to using man pages. It's similar to roff, but not quite. .Dd $Mdocdate$ .Dt PROGNAME section .Os .Sh NAME .Nm progname .Nd one line about what it does .\ .Sh LIBRARY .\ For sections 2, 3, and 9 only. .\ Not used in OpenBSD. .Sh SYNOPSIS .Nm progname .Op Fl options .Ar .Sh DESCRIPTION The .Nm utility processes files ... I _really_ like it, and have been using it for years on several projects. The finer details: http://mdocml.bsd.lv/man/mdoc.7.html My prayers have been heard! Never got used to the Xml horror format! Does that include a solution for breaking up the man page into severalm html files too? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: REWRITE: Comments on change of coding style
On Mon, Aug 18, 2014 at 09:04:49PM +0100, Dominik Vogt wrote: On Mon, Aug 18, 2014 at 07:52:08PM +0100, Dominik Vogt wrote: On Mon, Aug 18, 2014 at 06:16:37PM +0100, Thomas Adam wrote: On Mon, Aug 18, 2014 at 06:11:08PM +0100, Dominik Vogt wrote: Oh, great. Can you add the following CFLAGS in the make line? $ make CFLAGS=-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror Done. The definition for this is a .travis.yml YAML file in the root of the mvwm repository. Instead of sudo make install, a simple make distcheck2 should be much more helpful to see whether the sources compile and install. It does not run through at the moment, and I don't have time at the moment, but can take care if it later of you don't fix it before me. Done. I've not changed the yml file yet because I know nothing about that and did not want to break it. You beat me to it by ~2 minutes. ;) I've changed the YAML file. Testing it now. -- 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: REWRITE: Docs conversion and introducing a new (humble) contributor
On Mon, Aug 18, 2014 at 09:08:24PM +0100, Dominik Vogt wrote: My prayers have been heard! Never got used to the Xml horror format! Nor me, and oddly enough there's HTML output filters as well as ASCII. Does that include a solution for breaking up the man page into severalm html files too? Yes it does; and it should include having multiple files which you can link together to form different manpage sections. Having said that, Roman has a better overview of what that looks like, so I'll defer to him. All credit on this goes to him, BTW, all I did was tell him why I wanted to use mdoc and the benefits it brings over XML (which isn't a difficult one to win, really. ;)) -- 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.)
