On Sat, Nov 27, 2021 at 07:02:29PM +0100, Dominik Vogt wrote:
> Are there other places with unusual monitor name parsing?
Maybe in GotoDeskAndPage, but I don't think there's other places.
-- Thomas
On Fri, Nov 26, 2021 at 01:17:42AM +0100, Dominik Vogt wrote:
> Is this the proper fix?
I think so. I can't see it leak under Valgrind...
Kindly,
Thomas
On Fri, Nov 26, 2021 at 12:45:36AM +0100, Dominik Vogt wrote:
> On Thu, Nov 25, 2021 at 11:04:25PM +0000, Thomas Adam wrote:
> > On Wed, Nov 24, 2021 at 03:13:34PM +0100, Dominik Vogt wrote:
> > > From FScreen.c:FScreenParseGeometryWithScreen():
> > >
> > &
On Wed, Nov 24, 2021 at 03:13:34PM +0100, Dominik Vogt wrote:
> From FScreen.c:FScreenParseGeometryWithScreen():
>
> I can't fix this because I don't understand what the code does.
I will fix this.
Kindly,
Thomas
On Wed, Nov 24, 2021 at 03:43:47PM +0100, Dominik Vogt wrote:
> Does anybody know why this is a macro and not a function?
> (screen.h)
Because when I wrote it, it wasn't as complex as it is now.
See the ta/update-fvwm-screen branch, I've converted it to a function instead.
Kindly,
Thomas
On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote:
> The old manmage said:
>
> XineramaRoot
>
> the root window of the whole Xinerama screen. Equivalent to
> "root" when Xinerama is not used.
>
> Can you please restate that for me? What is "whole Xinerama
> screen" in xrandr t
On Mon, Nov 22, 2021 at 11:26:14PM +0100, Dominik Vogt wrote:
> I want to remove completely it once the code has been tested well
> enough. It's just there for the moment in case something happens.
OK. I'm now about to merge this to master.
Thanks,
Thomas
On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > Patch attached. Can you please double check and fill in the gaps?
> > (see comments belo).
> >
> > > > ./fvwm/menus.c: fXineramaRoot = False;
> > > > ./fvwm/menus.c:
On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote:
> For debugging I need to run another fvwm in xnest, but that
> doesn't support randr.
Bloody xnest/xephyr.
I suppose this OK, but it bothers me we need to fix it this way... I am not
sure though there's a workaround.
> The attached p
On Mon, Nov 22, 2021 at 12:02:33AM +0100, Dominik Vogt wrote:
> Mostly done, except a couple of comments where there's still work
> to do.
OK, I'll wait for those.
I've not noticed any crashes from running this for three days now.
Note that I still don't think we should hide the debugging behind
On Mon, Nov 22, 2021 at 12:24:09AM +0100, Dominik Vogt wrote:
> Yes, when the pointer comes too close to any border (leaves the
> dotted area on the sketch), it's warped back by the __move_loop to
> the original "P" in the sketch. Thus it can continue moving in
> all directions. Of course, the wi
On Sun, Nov 21, 2021 at 03:29:29PM +0100, Dominik Vogt wrote:
> Situation: At the moment, interactive move with the mouse feels
> awkward. Pushing windows past the page edge often fails because
> the pointer hits the edge and cannot move further. It's annoying
> and uncomfortable. The "pointer
On Sun, Nov 21, 2021 at 02:38:09PM +0100, Dominik Vogt wrote:
> The parser branch is a ready as it will be without people testing
> it more. The upstream branch dv/master hat the latest, merged
> together patches with extensive debug to stderr enabled.
>
> Please take a look. If there are no fin
On Sun, Nov 21, 2021, 11:22 Dominik Vogt wrote:
> Okay, git access works again. I'll do further development on
> dv/devel or on private topic branches, then put them in dv/master
> before considering to push them.
>
That's one way of doing it, yes. Whichever is going to make it easier for
you,
On Sun, Nov 21, 2021 at 11:41:33AM +0100, Dominik Vogt wrote:
> "git add -i" is extremely useful for not accidentally committing
It's "git add -pi" which I use all the time.
However, this is more about me hunting down which plugin is causing this and
turning it off.
Kindly,
Thomas
On Sun, Nov 21, 2021 at 12:59:17AM +0100, Dominik Vogt wrote:
> Sending patches is getting out of hand. I believe I had once
Ah. I had thought you were doing this because you preferred this way of
working.
> write access to the git repo, but it doesn't work anymore
> (permission denied when upd
On Sun, Nov 21, 2021 at 12:51:46AM +0100, Dominik Vogt wrote:
> How about
>
> 1. MAX_FUNCTION_DEPTH100 (stricter limit)
> 2. MAX_FUNCTION ITEMS 1000 (limit maximum size of functions)
> 3. MAX_CMDS_PER_INVOCATION 1 (max. cmds per top level function
> invocation)
Sounds sen
On Sat, Nov 20, 2021 at 03:16:02PM +0100, Dominik Vogt wrote:
> Look at commit ba9f161998f7da942996bcf0d3f96baa8b249070. You
> added new-parser.md, but also committed a complete reindentation
> of functions.c.
Oh heavens. That's not good at all. Clearly something has run in the
background and I
On Sat, Nov 20, 2021 at 04:26:13PM +0100, Dominik Vogt wrote:
> I wonder if we should do something about these kind of functions:
> Theres the definition "MAX_FUNCTION_DEPTH 512" in defaults.h that
> prevents functions from nesting infinitely deep:
Yeah. How likely is this problem in the real wor
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> On Sat, Nov 20, 2021 at 02:15:58PM +0000, Thomas Adam wrote:
> > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote:
> >
> > > Is Xinerama still useful for anything or can we remove it?
> > >
> >
On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote:
> Is Xinerama still useful for anything or can we remove it?
>
It has already been removed. Where are you seeing references to it?
Kindly,
Thomas
>
>
On Sat, Nov 20, 2021 at 10:51:51AM +0100, Dominik Vogt wrote:
> It works on my local branch but not the one in Git because of the
> reindentation commit. Can we please not reindent patches that are
> still under development?
I haven't reindented anything -- at least, not knowingly. Even then, ho
On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> > On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> > > >
On Sat, Nov 20, 2021 at 03:03:44AM +0100, Dominik Vogt wrote:
> For master:
>
> 0001: Fix uninitialised variables in lib.
> 0002: Remove "-blackout" option.
> 0003: Docuement -v and alias it to --verbose.
> 0004: Don't list all options in the SYNOPSIS.
> 0005: Change getpwuid.c interface (for next
On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > On Fri, Nov 19, 2021 at 03:09:35PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > > &g
On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > A couple of patches for the parser branch:
> >
> > 0001: Some cleanup.
> > 0003: Fix function depth handling and an uninitialised function
On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> A couple of patches for the parser branch:
>
> 0001: Some cleanup.
> 0003: Fix function depth handling and an uninitialised function argument.
> (I.e. a crash)
Thanks; applied these two.
Kindly,
Thomas
On Fri, Nov 19, 2021 at 02:53:32AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote:
> > For debugging I need to run another fvwm in xnest, but that
> > doesn't support randr.
> >
> > The attached patch mocks up a global monitor to use if init fails.
> > It
On Thu, Nov 18, 2021 at 02:19:11PM +0100, Dominik Vogt wrote:
> Most of the tests were meant to catch parsing bugs, leaks and
> crashes. A mor organised approach in the future would be good.
> Maybe it would even be possible to generate test cases for
> commands programmatically from the BNF.
It
On Thu, Nov 18, 2021 at 12:31:09AM +0100, Dominik Vogt wrote:
> I haven't found anything yet either. Anyway, we need
> infrastructure for automated testing. That shouldn't involve much
> more than a testing directory, a Makefile with a "test" target,
> and a couple of files that can be fed into "
On Wed, Nov 17, 2021 at 08:40:09PM +0100, Dominik Vogt wrote:
> 'k, the patched code didn't immediately crash, so here it is (two
> patches). Please test.
I've applied those two patches on a branch called `new-parser`.
So far, I've tested this on approximately five different configuration files
On Wed, Nov 17, 2021 at 08:18:07PM +0100, Dominik Vogt wrote:
> On Wed, Nov 17, 2021 at 04:40:55PM +0000, Thomas Adam wrote:
> > I've also added an OVERVIEW
> > section to fvwm3all.adoc explaining how the man page is split up into
> > different sections.
>
> Sho
On Wed, Nov 17, 2021 at 01:47:05PM +, Thomas Adam wrote:
> On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> > I'd like to finish the parser work started in 2014. Is the old
> > branch still available somewhere?
>
> Remind me what work that was...
I
On Wed, Nov 17, 2021 at 02:35:32PM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote:
> > This is the full set of patches for splitting the man page, to be
> > applied to master.
>
> Second attempt. The style docs are not moved aound in the man
> page. The
On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> I'd like to finish the parser work started in 2014. Is the old
> branch still available somewhere?
Remind me what work that was...
Kindly,
Thomas
On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote:
> This is the full set of patches for splitting the man page, to be
> applied to master.
>
> 1, 2 and 4 are unrelated cleanups.
> 3 and 5 implement the split.
>
> 4 conflicts with both, 3 and 5, so it can't be pulled out of the
> seque
On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> Two more patches for the man page branch, this time taking care of
> the style commands.
>
> 0001: General cleanup.
> 0002: Split of fvwm3styles.1.
>
> Need to be applied in this order.
>
> Please take a good look at the result of t
On Tue, Nov 16, 2021 at 01:32:11AM +0100, Dominik Vogt wrote:
> Sorry, won't work, I've already reordered, merged and edited
> patches. I don't want to commit a pile of junk like in CVS times.
> With Git I want much higher patch quality. :)
I understand that -- I suppose I'm not following your d
On Tue, Nov 16, 2021 at 01:28:45AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> > Off-topic: Can we remove the "globalopts" command description?
>
> And while we're at it, remove its implementation as well?
>
> At the moment, GlobalOpts:
>
> (1) E
On Tue, Nov 16, 2021 at 01:13:24AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 12:09:41AM +0000, Thomas Adam wrote:
> > On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> > > On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > > &g
On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > 0001: Some man page cleanup.
> > 0002: New man page fvwm3menus.1
>
> 0003: Fix list formatting (attached).
I've applied these three patches now, thanks.
They still di
On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> 0001: Some man page cleanup.
> 0002: New man page fvwm3menus.1
Are these patches based off the ta/dv-manpage-sections branch? They don't
apply cleanly via 'git am'.
> The ending text goes back to the indentation of the section
> hea
On Mon, Nov 15, 2021 at 09:37:48PM +0100, Dominik Vogt wrote:
> The earlier patch broke resize calculations by making windows too
> big. This patch fixes this.
Makes sense. I'm surprised I've not noticed that during the working day.
Applied now, thanks.
-- Thomas
On Mon, Nov 15, 2021 at 09:00:43PM +0100, Dominik Vogt wrote:
> Now, about the contents of the new man pages: Splitting has not
> bought us that much yet. 75% of the contents are now in the
> commands man page. It's difficult to remove more things from that
> because the command list also contai
On Mon, Nov 15, 2021 at 07:04:57PM +0100, Dominik Vogt wrote:
> Guessed so. I believe automake + autoconf should support that
> automatically in the generated rules, but it needs to be tested.
> Anybody here who knows how that works?
You don't get it for free, which is why you need the custom ins
On Mon, Nov 15, 2021 at 05:13:47PM +0100, Dominik Vogt wrote:
> 2) The Makefile.am now uses the standard "man1_MANS" file type to
> describe the generated files. That should make local installation
> rules unnecessary. Not sure whether it also handles the
> "transform" stuff or not. For now I've
On Mon, Nov 15, 2021 at 12:11:51PM +0100, Dominik Vogt wrote:
Thanks. Will apply. With respect this this patch:
> 0007: Remove the "MWM COMPATIBILITY" section. Nobody cares anymore.
Presumably the "OPEN LOOK AND XVIEW COMPATIBILITY" section can go as well?
Kindly,
Thomas
On Mon, Nov 15, 2021 at 02:07:58AM +0100, Dominik Vogt wrote:
> 0001: Remove Efence and Dmalloc support.
> 0002: Remove trailing whitespace.
Applied. Thanks!
Kindly,
Thomas
On Mon, Nov 15, 2021 at 01:42:33AM +0100, Dominik Vogt wrote:
> Has anybody really used them in the last fifteen years? Since
> valgrind has become pretty stable and good I never saw a need for
> dmalloc or efence any more.
I agree. It can go. There's a chance some distros ship efence (and poss
On Mon, Nov 15, 2021 at 01:40:40AM +0100, Dominik Vogt wrote:
> There probably needs to be some time when we annouce that we're
> done removing stuff so that people know that future changes will
> no longer break their configs. I'd say the feature set is
> unstable at the moment, not the code qual
On Mon, Nov 15, 2021 at 01:36:15AM +0100, Dominik Vogt wrote:
> While we're at it, much of the markup could be removed. The
> manpage is partially unreadable because too many words have markup
> (especially for the style command).
Yeah. I suspect this is a holdover from when the original man pag
On Mon, Nov 15, 2021 at 01:26:31AM +0100, Dominik Vogt wrote:
> 0001: Improve Snap... docuemntation.
> 0002: Improve EdgeMoveDelay documentation.
> 0003: Remove superfluous "#if 1".
Applied, thanks!
Kindly,
Thomas
On Mon, Nov 15, 2021 at 01:18:49AM +0100, Dominik Vogt wrote:
> Is the NEWS file going to be used for 3.x releases too? I always
> found it easier to add new entries when patches are written
> instead of reading the whole changelog when making a release.
I now autogenerate this at release time vi
On Mon, Nov 15, 2021 at 01:16:06AM +0100, Dominik Vogt wrote:
> Of course. What is the maximum line length that was used to
> format the .adoc files? (Can we re-add some formatting
> instructions in comments at the start of the main manpage source
> as we had in the groff sources? I've noticed t
On Mon, Nov 15, 2021 at 01:11:34AM +0100, Dominik Vogt wrote:
> Fixes programs going crazy when you accidentally say something like
>
> all (mplayer) resize 1920 1200
>
> instead of
>
> all (mplayer) resize 1920p 1200p
>
> (Generates an error message without doing anything else.)
Makes sen
On Mon, Nov 15, 2021 at 12:31:28AM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 12:19:59AM +0100, Dominik Vogt wrote:
> > What do you think about the attached patch? Pressing "Alt" during
> > an interactive move already disables snapping. It's easy to make
> > it enable paging without any
On Sun, Nov 14, 2021 at 04:50:23PM +0100, Dominik Vogt wrote:
> Current situation for me: At least 90% of all paging situations
> are accidents.
Yeah, and it gets even worse if you happen to use paging with
'DesktopConfiguration per-monitor' as well.
> Maybe that feature ist just crap and we nee
On Sun, Nov 14, 2021 at 01:55:32PM +0100, Dominik Vogt wrote:
> 1) Because the pointer is at the top of the screen, it's
> immediately in the one pixel high panning window, so fvwm waits
> the configured 500 ms and then switches pages to 0 0 although
> neither the window nor the pointer have ever m
On Sun, Nov 14, 2021 at 10:58:19AM +0100, Dominik Vogt wrote:
> The patch makes the bogus "bugopts debugrandr" option actually do
> something.
Hi Dominik,
Thank you. All four patches have now been merged!
Thanks,
Thomas
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
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
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
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
Branch: refs/heads/ThomasAdam-patch-1
Home: https://github.com/fvwmorg/fvwm
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
On 7 May 2016 14:46, "Thomas Funk" 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 XSe
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.
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 look
he 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
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
e 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
sabled snapshot builds ages ago.
Again, there'll only ever be one set of man pages.
-- Thomas Adam
e'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 re
nd 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
oving 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
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
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 s
On Sat, Apr 02, 2016 at 11:58:41AM -0600, Jaimos Skriletz wrote:
> On Fri, Apr 1, 2016 at 5:43 PM, Thomas Adam wrote:
>
> > On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> > >
> >
> > Thanks! It looks really good. We can remove the Chang
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
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
en 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
On Fri, Mar 25, 2016 at 12:52:21PM +0100, Thomas Funk wrote:
> "Thomas Adam" wrote:
> > On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> > > I think we should. It's better to have such in the documentation so no
> > > questions appears a
On Fri, Mar 25, 2016 at 05:37:50PM -0500, Jason L Tibbitts III wrote:
> >>>>> "TA" == Thomas Adam 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
ebhooks 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.)
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 figur
is.
> 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 m
1 - 100 of 203 matches
Mail list logo
