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

ow is on, rather than referencing the width/height of the entire root window. Kindly, Thomas

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

[MOVE_TO_SCREEN] > > This one should be just renamed to just "screen"? Yes please. > Ping. Sorry, I didn't spot this earlier. Kindly, Thomas

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

attached patch mocks up a global monitor to use if init fails. > It works at the first glance, but the patch is not very clean. > Please comment. It sucks. Under whar circumstances is this likely to fail? I mean, I appreciate the point you're making, but whatelse am I missing? Kindly, Thomas

Re: [RFC] parser branches ready for commit

ugging behind '#define OCP_DEBUG 1' even though it's always set to on at compile time. Certainly not for new code. We could make it a BugOpts option if it really mattered. I'm not saying we need to fix this now, mind you. Kindly, Thomas

Re: Idea: "elastic" move

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

Re: Idea: "elastic" move

colour could also be used when a window > border hits the page edge during an interactive move. Say, > if the window is already at the edge and you keep "pushing", > that border uses the "activity" colour to indicate that > something is happening. I think this is definitely going to be required, yes. Kindly, Thomas

Re: [RFC] parser branches ready for commit

d, because this branch is level with master so it doesn't need to be merged just to test it -- and it's that shift in mentality, trying to keep master in the most stable state it can be which helps a lot with the release process. Kindly, Thomas

Re: dv Branches

sier for you, and also for reviewing. This is why I don't want an upstream branch. Merging topics into master can accumulate there for the next release. The review process of those topics makes things easier to manage. I'm out for the rest of the day but will be back later. Kindly, Thomas

Re: [PATCH - parser] (4) updates

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

happy with my own branches > without committing to master myself.) See: https://github.com/fvwmorg/fvwm3/blob/master/dev-docs/DEVELOPERS.md Kindly, Thomas

Re: fork-bomb like functions

nvocation) Sounds sensible to me. I say, go for it! Kindly, Thomas

Re: [PATCH - parser] (4) updates

vim plugin has done this, although it hasn't done so in the past. Kindly, Thomas

Re: fork-bomb like functions

ofunc foo i bar > # hangs: > foo I can maybe foresee this situation arising. Maybe this is worth fixing? Kindly, Thomas

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

ly. Even then, how did that cause the failure in the first place? > I'll ditch the upstream branch for now and start a new one. Well, new-parser builds fine now, thanks. Kindly, Thomas

Re: [PATCH - 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

r beforehand, some display managers won't capture stderr which is why I didn't previously include it, but then again if you're still starting fvwm via .xsession or .xinitrc, this will be useful. Kindly, Thomas

Re: [PATCH - parser] (4) updates

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.

n a single screen. For reference, I did used to support that, but removed it in commit 6e646e6201051d19dea5fa8e985fcaf884f0d94d Kindly, Thomas

Re: [RFC] New parser framework for testing

nds: > > foobarfunc --match-resource "xterm" > > (Problem: How can we distinguish between general filters and the > actual command/function arguments?) If a command in a complex function isn't overriding the calling filter, then use that? > Note: Complex functions already have a kind of filtering with the > "I", "C", ... bits. Yeah -- this needs more thinking. Hmm. Kindly, Thomas

Re: [RFC] New parser framework for testing

e instead), and some context_t which has evaluated which window, etc., the command needs in order to run. Then you can add some function pointers for checking/validating the parsed string, etc. Kindly, Thomas

Re: [RFC] New parser framework for testing

gt;parameters being passed. I did a quick santity check of the ones which were pulled in from your changes, and they look fine. All other parser debug is going to stderr anyway. > * The "repeat" command may cause crashes or leaks. Weren't we thinking of removing the repeat command at one point? Kindly, Thomas

Re: [PATCH] (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

lbeit I'm hoping to create some additional sections as well so it doesn't feel like this change is incomplete. The PR is here: https://github.com/fvwmorg/fvwm3/pull/637 Kindly, Thomas

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

am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Patches 1 - 4 before it apply just fine. Any thoughts? Thomas

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

g problems left, but can be fixed later. Yes. > -- > > Off-topic: Can we remove the "globalopts" command description? Yes. I can see a small section that's still present. Kindly, Thomas

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

it makes it harder for me to know what I'm supposed to be tracking, that's all. Kindly, Thomas

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

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

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

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.

made so far. Kindly, Thomas

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

t found a good solution to this. I suppose I could ask the asciidoctor maintainers... Kindly, Thomas

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

. Then we would need an "fvwmallstyles" man page which aggregates these together. > It's not obvious how to move the Style command (a subsection of > the commands page) to a different file without cluttering the > source with ifdefs. That's a small price to pay for trying to increase readability, IMO. Kindly, Thomas

Re: [RFC] Splitting the man page

ges. Agreed. I'm sure there's an asciidoc(tor)-specific way of being able to do this. > Seems to do what is intended; "make install" and "make uninstall" > work fine, but I haven't tried to build and test a distro from > that. Worked well for me. This work is now being tracked here: https://github.com/fvwmorg/fvwm3/pull/637 Via the `ta/dv-manpage-sections` branch. Kindly, Thomas

Re: [PATCH] (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?

ip efence (and possibly the BSDs), but it all pales in light of Valgrind. I know Dan used to use one of the proprietary IBM profilers on fvwm's code base from time-to-time as well, but I don't recall what that was called. Kindly, Thomas

Re: Plans for the NEWS file?

not the code quality. Right, I understand. Yeah, that's fair. I think the majority of the bigger breaking changes have largely happened (such as deprecating certain modules), but you're right -- we should take stoke of that, and what's left and make that a focus of the release schedule(s). Kindly, Thomas

Re: Paging issue

levant section for .adoc files and then that would also apply to Vim as well (which is what I use). Kindly, Thomas

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?

although there's many rough edges still left to tidy up -- not helped by my own butchery of fvwm over the past year... HTH, Thomas

Re: Paging issue

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

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

oing anything else.) Makes sense, Dominik. Will apply. Thanks! Thomas

Re: Paging issue

mode. > > P.S.: Does not work with "Resize" yet. Noted. I like this, and I think it will also work well for Resize. Also needs a quick manpage update. Kindly, Thomas

Re: Paging issue

. If enough people don't like it, I'm sure they'll let us know. :) Kindly, Thomas

Re: Paging issue

anything until the pointer has moved, even if it is already in the panframe window? Kindly, Thomas

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

[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

fvwm2 early next week, please do chase me. Kindly, Thomas

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

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

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

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

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

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

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 ea

Re: Some advices about the new static website

ide the window? ^^ Best, Thomas -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -- Albert Einstein

Re: Release versioning and tagging

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

'unstable'. Okay, wasn't the right word but in quotes. -- Thomas -- [1] http://fvwm.org/doc/unstable/index.html -- -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -- Albert Einstein

Re: Some advices about the new static website

the current scripts will be outdated, so after that conversion is done, I will go checkout how to get such a set of links setup. Provided they only linked to headings that will be generated by markdown this should be fairly straight forward to script. That would be great :) -- Thomas

Re: Some advices about the new static website

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 di

Re: Some advices about the new static website

On 04/08/2016 11:41 PM, Thomas Adam wrote: 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

Re: Some advices about the new static website

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 be

Fwd: Re: Some advices about the new static website

On 04/08/2016 10:47 PM, Jaimos Skriletz wrote: On Fri, Apr 8, 2016 at 1:44 PM, Thomas Funk <t.f...@web.de <mailto:t.f...@web.de>>wrote: ​The "logo" is now the menu entry, so instead of just saying "FVWM" I put the logo in its place. The logo except for loo

Re: Some advices about the new static website

On 04/08/2016 11:08 PM, Thomas Adam wrote: 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

Re: Some advices about the new static website

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 o

Some advices about the new static website

with these advices 0_0 ... Best, Thomas Btw I have some website links for our 'Links' page: History --- In the beginning was ... http://edulinux.homeunix.org/fvwm/user_enumerate.html Other FVWM-related sites How Styles are Applied http://linuxgazette.net/127/adam.html Fvwm

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]

erhead, 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]

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

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

end 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

  1   2   3   >