Re: FVWM: A question on Actions in FvwmButtons

On Thu, 25 Jan 2024 at 12:50, João Oliveira wrote: > Action (Mouse 1) 'Exec exec firefox ; ResizeMove 90 90 5 5' You should probably use the PositionPlacement style for this. -- Thomas

Re: Crashes with monitor_resolve_name

On Sat, Nov 27, 2021 at 07:02:29PM +0100, Dominik Vogt wrote: > Are there other places with unusual monitor name parsing? Maybe in GotoDeskAndPage, but I don't think there's other places. -- Thomas

Re: [RFC] Fix window title format leak?

On Fri, Nov 26, 2021 at 01:17:42AM +0100, Dominik Vogt wrote: > Is this the proper fix? I think so. I can't see it leak under Valgrind... Kindly, Thomas

Re: memleak in FScreenParseGeometryWithScreen

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(): > > > > > &

Re: memleak in 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

Re: UPDATE_FVWM_SCREEN macro?

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

Re: [PATCH/RFC] Xinerama

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

Re: [RFC] parser branches ready for commit

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

Re: [PATCH/RFC] Xinerama

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:

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

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

Re: [RFC] parser branches ready for commit

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

Re: Idea: "elastic" move

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

Re: Idea: "elastic" move

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

Re: [RFC] parser branches ready for commit

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

Re: dv Branches

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,

Re: [PATCH - parser] (4) updates

On Sun, Nov 21, 2021 at 11:41:33AM +0100, Dominik Vogt wrote: > "git add -i" is extremely useful for not accidentally committing It's "git add -pi" which I use all the time. However, this is more about me hunting down which plugin is causing this and turning it off. Kindly, Thomas

Re: git access

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

Re: fork-bomb like functions

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

Re: [PATCH - parser] (4) updates

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

Re: fork-bomb like functions

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

Re: Xinerama

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

Re: [PATCH - parser] (4) updates

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,

Re: [PATCH - parser] (4) updates

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

Re: [PATCH] (6) Various small changes

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

Re: [PATCH - parser] (4) updates

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

Re: [PATCH - parser] (4) updates

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 functi

Re: [PATCH - parser] (4) updates

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

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

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

Re: [RFC] New parser framework for testing

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

Re: [RFC] New parser framework for testing

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

Re: [RFC] New parser framework for testing

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

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

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

Re: parser branch

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 r

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

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.

Re: parser branch

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

Re: [PATCH] (5) Man page changes

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 >

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

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

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

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

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

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)

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

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

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

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

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

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 >

Re: [PATCH] Fix resize calculations.

On Mon, Nov 15, 2021 at 09:37:48PM +0100, Dominik Vogt wrote: > The earlier patch broke resize calculations by making windows too > big. This patch fixes this. Makes sense. I'm surprised I've not noticed that during the working day. Applied now, thanks. -- Thomas

Re: [RFC] Splitting the man page

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

Re: [RFC] Splitting the man page

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

Re: [PATCH] (7) Miscellaneous cleanup

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

Re: [PATCH] (2) Remove Dmalloc and Efence support.

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

Re: Removind dmalloc and efence support?

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

Re: Plans for the NEWS file?

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

Re: Paging issue

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

Re: [PATCH] (3) Miscellaneous updates

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

Re: Plans for the NEWS file?

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

Re: Paging issue

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

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

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

Re: Paging issue

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

Re: Paging issue

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

Re: Paging issue

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

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

On Sun, Nov 14, 2021 at 10:58:19AM +0100, Dominik Vogt wrote: > The patch makes the bogus "bugopts debugrandr" option actually do > something. Hi Dominik, Thank you. All four patches have now been merged! Thanks, Thomas

Re: FVWM: Fvwm3 Virtual Desktop Problem

On Thu, Feb 20, 2020 at 06:53:43PM -0500, Larry Piet wrote: > When I started fvwm3 using the same config file as with fvwm-2.6.9 > there were no apparent problems. However, my virtual desktops were > missing. The config file specifies a 2x2 arrangement but with > fvwm3 I only get a 2x1

Re: FVWM: Minimum task bar example

On Sun, Dec 22, 2019 at 02:11:10PM +0100, Carsten Kunze wrote: > Hello, > > is there a minimum task bar example as a starting point for something more > sophisticated? Just making the task bar appear with as few as possible > lines? The example at https://fvwmforums.org/wiki/Panels/FvwmTaskBar/

Re: FVWM: avoiding crosshair when thumbnailing

On Thu, Dec 26, 2019 at 12:26:03AM +, Peter Holm wrote: Hi Peter, > To get thumbnails within fvwmpager, I do as following. > DestroyFunc Mini_Thumbnail > AddToFunc Mini_Thumbnail > + I Raise > + I SetEnv MiniIcon-$[w.id] $[w.MiniIconFile] > + I ThisWindow (!Shaded, !FvwmPager, !Iconic)

Re: FVWM: Window title placed to low in title area

blem you're having, but I'd say it's working as expected. > Is there an option to somehow affect the vertical placement of the window > title text? No, there is not. -- Thomas Adam

Re: FVWM: Question regarding actions when modifier keys are held down/released

t; available elsewhere... It's dead, Jim. To be replaced with something newer, sometime soon. > But really, use Thomas's suggestion, as usual, it's terse and entirely on > point. :) -- Thomas Adam

Re: FVWM: Question regarding actions when modifier keys are held down/released

On Wed, Aug 28, 2019 at 01:03:32PM -0400, Dave Weller-Fahy wrote: > Greetings, > > I've search the website, archives, wiki, and a number of configuration > websites, and have been unable to find a way to cause an action to > happen when a modifier key is held down and/or released. I'm running >

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

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

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

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

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

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

[fvwmorg/fvwm] ea7ed8: Update README.md

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

[fvwmorg/fvwm]

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

[fvwmorg/fvwm] ea7ed8: Update README.md

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

[fvwmorg/fvwm] f4a498: Update README.md

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

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

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

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

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

Re: [PATCH] Fix FvwmMakeMissingDesktopMenu

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,

Re: FVWM: howto conditionally add menu entries?

nd/execute things like the 'Test' command. In your case, you need to wrap the menu definitions in a function: DestroyFunc foo AddToFunc. foo + Test () AddToMenu . -- Thomas Adam

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: FVWM: Session management.

connection?). Pass. You won't find a better/more featured window manager other than FVWM to fit the 4GB deskop you describe. -- Thomas Adam

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

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 c

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

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.

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

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 a

Re: Some advices about the new static website

sier 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

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

nce 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

sabled 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

o 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 ha

Re: Some advices about the new static website

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

u 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]

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

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

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

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

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 goo

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

on: 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

  1   2   3   4   5   6   7   8   >