Re: COVID-19: Hope everyone's well
On Sat, Mar 21, 2020 at 03:20:06PM +, Thomas Adam wrote: > Just emailing to check that everyone's OK and not suffering too much at the > moment. I know different countries are largely doing the same things as one > another -- and I'm working from home for the foreseeable. I'm fine, working from home for the forseeable future. Things are a bit strange in Germany. Hopefully people hav understood the severity of the current situation now. Keep well and fit everybody, as we now say in Germany. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Request to increase 1024 char/line limit in read.c
On Mon, Mar 05, 2018 at 11:57:27AM +, Thomas Adam wrote: > Hi, > > On Mon, Mar 05, 2018 at 04:38:08AM +0100, Stefan Blachmann wrote: > > Hi fvwm-workers, > > > > the 1024 char limit in the read line buffer in fvwm/read.c has become too > > small. > > This caused a breakage in my MissingSubmenuFunction menu generator > > after after addition of programs + update; the Popup did not display. > > > > Could the buffer be extended to, say, 4096 chars? > > We'd be chasing stack limits if we do this. > > I'd much rather see that fgets() loop replaced with fparseln() instead, which > would also solve this problem indefinitely. The reson for commnd line limitation is mostly the size limit of pipes (pipereas command and module communication). In the past we used the largest value that every system guaranteed to support (256) and then increased that to 1024 at some time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]
On Fri, Mar 02, 2018 at 08:33:20PM +, Thomas Adam wrote: > On Tue, Feb 13, 2018 at 11:19:41PM +0100, Dominik Vogt wrote: > > On Mon, Feb 12, 2018 at 02:14:57PM +, Thomas Adam wrote: > > > Well, this is good news! Apologies for bouncing this between fvwm@ and > > > fvwm-workers@. > > > > > > If no one objects, I'll go ahead an start making the relevant changes? > > > > Good. With the extra clauses gone, things get easier - go ahead. > > So, I've started this here: > > https://github.com/fvwmorg/fvwm/commit/7274b020a4dfec4adcc5317f557605b006bce085.diff > > However, we're not out of the woods yet, as there's the following > complications: > > libs/Picture.c: > libs/PictureBase.c: > > /* > * Copyright 1996, Romano Giannetti. No guarantees or warantees or anything > * are provided or implied in any way whatsoever. Use this program at your > * own risk. Permission to use this program for any purpose is given, > * as long as the copyright is kept intact. > * > * Romano Giannetti - Dipartimento di Ingegneria dell'Informazione > *via Diotisalvi, 2 PISA > * mailto:rom...@iet.unipi.it > * http://www.iet.unipi.it/~romano > * > */ > > modules/FvwmBacker/FvwmBacker.c: > modules/FvwmBacker/FvwmBacker.h: > > /* Copyright 1994, Mike Finger (mfin...@mermaid.micro.umn.edu or > * mike_fin...@atk.com) > */ > /* Robert Nation and Nobutaka Suzuki */ > > modules/FvwmIdent/FvwmIdent.c: > > /* Copyright 1994, Robert Nation and Nobutaka Suzuki. */ > > > So I need to track down these additional people as well before I can remove > the full clause. I think in all these cases it is enough to move the copyright notice to the COPYING file (it also has a copyright section). After all, the copyright does not go away if the copyright notice is removed. Rob's clauses were problematic because they specifically required to be kept intact. When that work is done, I'll backport the patches to the old stable branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [robert.j.nat...@baesystems.com: RE: FVWM Code License]
On Mon, Feb 12, 2018 at 02:14:57PM +, Thomas Adam wrote: > Well, this is good news! Apologies for bouncing this between fvwm@ and > fvwm-workers@. > > If no one objects, I'll go ahead an start making the relevant changes? Good. With the extra clauses gone, things get easier - go ahead. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Stopping to use Github / Don't push to Github(!!)
On Sat, Jun 10, 2017 at 07:41:24PM +0100, Thomas Adam wrote: > On Wed, Apr 12, 2017 at 08:47:15PM +0100, Dominik Vogt wrote: > > I don't see how this is fixable without either removing all of > > Rob's code or changing Github's terms and conditions. I see no > > problems between D.4 and D.5 and the GPL though. > > Gitlab might be an option, but that would require me to set the infrastructure > up there again -- something I'm not willing to do at all. Frankly, we lose > more than we gain. I'm not crazy about switching either. > The other option we have is contacting Rob Nation and asking him if he's happy > for his terms to change. I would be *amazed* if there's much of any of his > original code left to such an extent where his original copyright notice even > means anything, not to mention, it was written such a long time ago as well. > > I can certainly try and contact him. Good idea, please do. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Sometimes windows remain after the process has died.
On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote: > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote: > >> Sometimes when a process stops the window will remain open until some > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm > >> will remove the window. > > > > That is not possible unless either > > ... > > The process do not appear in 'ps fax' and the script outputs [Done] on > all the jobs that were run in the background in the shell, so this is > not the case. > > > 2) the X server has a bug, > > This does seem to be the case. The user and myself both tested this > running an xsession with only an xterm. We could not reproduce it with > only running an xterm. > > I decided to test another window manager, openbox in this case, and > was able to reproduce the issue in openbox. So it seems to be some bug > with how the xserver but may require a window manager to trigger it. I wonder what that trigger could be. If the window can be moved, fvwm is communicating with the X server in both directions, so if a destroy event was pending it should have been delivered to fvwm before any mouse motion events. Maybe the X server itself has destroyed the window internally but not yet sent the event for some reason, and does so only when some request for that window is issued. (Moving the fvwm window does not move the client window directly but the frame.) If you type "xsync" in FvwmConsole, does that kill the window? (This forces all pending requests and events to be delivered in both directions.) My guess is that it doesn't, i.e. no event is pending. > In all cases trying to get any info from the xserver closes the > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo > will close all the windows that were left open when running that > command. Does it also kill the window to request information from a different (non-zombie) window? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Sometimes windows remain after the process has died.
On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> Sometimes when a process stops the window will remain open until some
> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> will remove the window.
That is not possible unless either
1) the process is not really dead,
2) the X server has a bug,
3) fvwm does not destroy the frame after the window has gone.
I've spent lots of time to get rid of any cases of #3, and what
you describe does not sound like "empty frame remains".
> The following script was provided by the user which launches and
> closes a large number of xterms. When running this script some of the
> xterm windows will remain even though the process is no longer
> running.
>
> On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre <vinc...@vinc17.net> wrote:
> > Simpler test case:
> >
> >
> > #!/bin/sh
> >
> > n=${1:-200}
> > n=$((n+0))
> >
> > for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
> >
> > wait
> >
That's how I've tested that the frame always gets removed.
> After this script ends a few windows remain and can be moved,
> iconified, shaded, resized. But if you run FvwmIdent something is
> triggered which removes all the affected windows.
>
> I was not able to reproduce this on my main machine (though rarely I
> would have a window stick around for a second or two before it was
> removed, most weren't even drawn), but I was able to reproduce this
> with the default config on both the debian 2.6.7-3 package and the
> master branch from git inside a virtual machine.
Maybe it's a problem with the X server in a virtual machine? I
don't have such a setup to test that, but it doesn't happen on a
plain X server with or without config and neither in Xnest for me.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Stopping to use Github / Don't push to Github(!!)
On Wed, Apr 12, 2017 at 09:24:45AM +0100, Thomas Adam wrote: > On Wed, Apr 12, 2017 at 09:48:30AM +0200, Christoph Fritz wrote: > > On Thu, 2017-03-09 at 13:55 +0100, Dominik Vogt wrote: > > > There is a discussion about Github's new terms of service which may > > > not be compatible with the Gpl: > > > https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm > > > > > > I didn't have time to read the new terms yet, but it is possible > > > that we need to remove all fvwm repositories from Github. The > > > most important thing right now is to *not* *push* *anything* to > > > Github until we've decided about this issue, because by continuing > > > to use Github, the new terms of service are automatically accepted. > > > > out of curiosity: Are there any updates on this? > > Storm in a tea cup, really: > > http://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft No that's not correct. D.7 conflicts with this: /* * This module is all original code * by Rob Nation * Copyright 1993, Robert Nation * You may use this code for any purpose, as long as the original * copyright remains in the source code and all documentation */ D.7 To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; ... I don't see how this is fixable without either removing all of Rob's code or changing Github's terms and conditions. I see no problems between D.4 and D.5 and the GPL though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Stopping to use Github / Don't push to Github(!!)
There is a discussion about Github's new terms of service which may not be compatible with the Gpl: https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm I didn't have time to read the new terms yet, but it is possible that we need to remove all fvwm repositories from Github. The most important thing right now is to *not* *push* *anything* to Github until we've decided about this issue, because by continuing to use Github, the new terms of service are automatically accepted. Ciao Dominik ^_^ ^_^
[fvwmorg/fvwm] d89af5: Fix "--" bindings.
Branch: refs/heads/fvwm2-stable Home: https://github.com/fvwmorg/fvwm Commit: d89af5d26a27e52ba86e529fbde02a26533c2d84 https://github.com/fvwmorg/fvwm/commit/d89af5d26a27e52ba86e529fbde02a26533c2d84 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/bindings.c Log Message: --- Fix "--" bindings. Commit: b7dfb7bad58c51470615b6479ab2d3a70f387e10 https://github.com/fvwmorg/fvwm/commit/b7dfb7bad58c51470615b6479ab2d3a70f387e10 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M ChangeLog Log Message: --- ChangeLog. Commit: 65007a8f70e09eadb4e20d1fb3d083f268c3df9b https://github.com/fvwmorg/fvwm/commit/65007a8f70e09eadb4e20d1fb3d083f268c3df9b Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/47e634b66324...65007a8f70e0
Re: fvwm 2.6.x title vs icon title bug
On Thu, Mar 02, 2017 at 12:00:08AM +0700, ?? wrote: > On 01.03.2017 23:38, Dominik Vogt wrote: > >On Wed, Mar 01, 2017 at 04:20:29PM +0100, Dominik Vogt wrote: > >>On Sat, Feb 18, 2017 at 11:35:48AM +0700, ?? wrote: > >>>With both fvwm 2.6.5 and latest 2.6.7 I experience a bug when icon > >>>of the window of some apps keeps a previously set title. For > >>>example: > >>>- Normal window has title AND icon title "title", which is correct > >>>according to FvwmIdent, > >>>- After Iconify, icon title appears as some default name of the > >>>application, or "title". > >>>- Deiconifying it again, and making app change title to "title > >>>(new)". Both title and icon title are correct and shown as "title > >>>(new)" according to FvwmIdent. > >>>- Iconifying it again, and icon is named "title" (if there was some > >>>default app name, it changes to this previously set name). > >>>- Deiconifying it again, and making app change title to "new title". > >>>Again, both title and icon title is correct per FvwmIdent. > >>>- Iconifying it again, and I see icon name set to "title (new)". > >>> > >>>This issue happens only with some apps. Namely, I think all FOX > >>>toolkit apps are affected (for me they are Xfe, Xfw, Adie). > >>> > >>>On forums http://fvwmforums.org/phpBB3/viewtopic.php?f=6=3204 I > >>>was directed to mailing list thread > >>>http://www.mail-archive.com/fvwm-workers@fvwm.org/msg03213.html, > >>>which gave me an idea that setting IconTitleFormat to %i and > >>>TitleFormat to %n separately may work. Indeed this worked and solved > >>>my issue I described. > >> > >>I'm working on the problem. > > > >Can you please try the fix on the master branch in Git? > > > > I removed temporaries related to this issue from my .fvwm2rc and > tested a patch with 2.6.7. I can say the issue is gone fully. I will > notify if there will be regressions related to this. Good. I'll push the patch onto the stable branch. One thing I'm not quite sure about; before that patch that added TitleFormat and IconTitleFormat in 2008, what did fvwm show as the icon title? Was it the icon name or the window title? Now it's the icon name, but was it the same before that patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] bc685f: Fix updating window and icon titles.
Branch: refs/heads/fvwm2-stable Home: https://github.com/fvwmorg/fvwm Commit: bc685fd15f2f2f1064347f0ae1cfc19560ef9de4 https://github.com/fvwmorg/fvwm/commit/bc685fd15f2f2f1064347f0ae1cfc19560ef9de4 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Commit: af8c4580b9d7f54798ebd251eda3bf232a63f1f6 https://github.com/fvwmorg/fvwm/commit/af8c4580b9d7f54798ebd251eda3bf232a63f1f6 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M ChangeLog Log Message: --- ChageLog. Commit: 47e634b66324df8fb9acd235fefa40b7be76fee5 https://github.com/fvwmorg/fvwm/commit/47e634b66324df8fb9acd235fefa40b7be76fee5 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/b57836af68bc...47e634b66324
[fvwmorg/fvwm] 5df54f: Fix "--" bindings.
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 5df54fcf24d2488f4ba82acd92412df85d2a60b3 https://github.com/fvwmorg/fvwm/commit/5df54fcf24d2488f4ba82acd92412df85d2a60b3 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/bindings.c Log Message: --- Fix "--" bindings. Commit: f6c69f52e643f3d6a8b7cc3643c3962c875b4f1d https://github.com/fvwmorg/fvwm/commit/f6c69f52e643f3d6a8b7cc3643c3962c875b4f1d Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M NEWS Log Message: --- NEWS Compare: https://github.com/fvwmorg/fvwm/compare/ffe942d66cdb...f6c69f52e643
Re: FvwmIconMan still sometimes triggers Hint Warnings
On Wed, Mar 01, 2017 at 07:18:11AM -0700, Jaimos Skriletz wrote:
> On Wed, Mar 1, 2017 at 5:30 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
> >> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
> >> <jaimosskril...@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > FvwmIconMan still reports Hint warnings even with the patchs applied.
> >>
> >> I wrote this small patch that has FvwmIconMan wait until the window
> >> has resized to set the window hints. This is in the lines of Dominik
> >> Vogt's patch, but waits until FvwmIconMan has fully resized to run
> >> fix_manager_size() to set the window hints. My tests here no longer
> >> seem to tiger the warnings like it still sometimes did.
> >>
> >> As an additional thought, talking to Thomas Adam about the patch in
> >> #fvwm, he mentioned that the issue is more FVWM being overly cautious
> >> and the fix should be in how fvwm handles size hint warnings over
> >> working with FvwmIconMan to avoid triggering them.
> >>
> >
> > So, if it's not possible to completely fix FvwmIconMan in a decent
> > way, what do we do with the warning? I'd rather not disable it,
> > but the number of false positives is too high. One could make a
> > style that disables the warning for a certain class of windows,
> > but that would probably be used as "style * ...", disabling the
> > warning for everything. :-/
> >
>
> FvwmIconMan isn't the only application that triggers these warnings,
> but using it in a situation where it grows/shrinks is a very regular
> way to cause the warnings and it fills up .xsession-error with mostly
> warnings. Other applications I use only trigger these warnings rarely,
> and in each case the application appears to work fine so yet more
> false positives. But FvwmIconMan is the only one that regularly
> resizes itself triggering the warning a lot.
Of course. Flooding the log was not the intention of the patch.
> I had two ideas on this, one is use a BugOpts option that can turn on
> these warnings for a user who wants to debug things, but they are off
> by default. This is basically your style idea and the affect will be
> almost everywhere these warnings will not appear and thus may miss out
> on programs that actually need to be reported.
Yes, but defaulting to "off" makes the warning effectively useless.
> Another is maybe don't have fvwm jump to conclusions that there is a
> warning.
Let me rephrase that: Fvwm informs the user about something that
might not be possible to clean up. In such a situation the user
would see that the window did not get resized as intended and has
no clue why. At least, fvwm has told her that something strange
was going on.
> What if there was some timer that fvwm gave the application
> to fix itself before reporting a warning, and then the warning is not
> just that the window had this inconstant state which seems to give
> false positives, but it has been inconsistent for a set amount of time
> without fixing itself.
Too complex stuff for such a simple situation. Maybe one could
peek the event queue for an event that fixes the windows's size
and not complain if such an event is already pending? Another
option is to generate only a limited number of these warning for
each window.
Does the attached patch improve the situation?
> Anyways, for those of us who use FvwmIconMan as a growing/shrinking
> standalone module, this patch drastically reduces the amount of
> warnings, but I agree it really doesn't seem like the way to deal with
> this issue to make applications have to add these waits to deal with
> resizing both the window and the size hints.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From 8f74a2e6f1f0e059e9d1e073bace15a33dd2c016 Mon Sep 17 00:00:00 2001
From: Dominik Vogt <dominik.v...@gmx.de>
Date: Wed, 1 Mar 2017 17:24:13 +0100
Subject: [PATCH] Try to fix FvwmIconMan warnings.
---
fvwm/events.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index 980ccab..a7d41d0 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -3627,6 +3627,10 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
break;
}
case XA_WM_NORMAL_HINTS:
+ {
+ int do_check;
+ XEvent dummy;
+
/* just mark wm normal hints as changed and look them up when
* the next ConfigureRequest w/ x, y, width or height set
* arrives. */
@@ -3641,8 +3645,11 @@ ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
* Note that SET_HAS_NEW_WM_NORMAL_HINTS being set here to
* true is still valid.
*/
- GetWindowSizeHintsWithCheck(fw, 1);
+ do_check = !FCheckTypedWindowEvent(
+ dpy, FW_W(fw), ConfigureRequest, );
+ GetWindowSizeHintsWithCheck(fw, do_check);
break;
+ }
default:
if (te->xproperty.atom == _XA_WM_PROTOCOLS)
{
--
1.7.10.4
[fvwmorg/fvwm] 3bad8f: Add "J" function actions (late immediate).
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c https://github.com/fvwmorg/fvwm/commit/3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M doc/commands/AddToFunc.xml M fvwm/functions.c Log Message: --- Add "J" function actions (late immediate). This works like "I" but is executed later (once), when the user starts interacting with the function, e.g. on the first button release or if the pointer moves (and the function uses "M"). This can be used to write an "escalating" close function that runs on the first button release: AddToFunc CloseOrDestroy + J Close + D Destroy Run "Close" immediately (but not right when the button is pressed) and follow up with a Destroy in case of a double click. Compared to the normal "+ C Close" this avoids the double click delay before the action is triggered. Commit: ffe942d66cdb1a24d761d9e89c1a4dab49f2400c https://github.com/fvwmorg/fvwm/commit/ffe942d66cdb1a24d761d9e89c1a4dab49f2400c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Compare: https://github.com/fvwmorg/fvwm/compare/fa8125cec830...ffe942d66cdb
[fvwmorg/fvwm] 3bad8f: Add "J" function actions (late immediate).
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c https://github.com/fvwmorg/fvwm/commit/3bad8f5e61a9ac1a9e510fe085f69fbbb348fd3c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M doc/commands/AddToFunc.xml M fvwm/functions.c Log Message: --- Add "J" function actions (late immediate). This works like "I" but is executed later (once), when the user starts interacting with the function, e.g. on the first button release or if the pointer moves (and the function uses "M"). This can be used to write an "escalating" close function that runs on the first button release: AddToFunc CloseOrDestroy + J Close + D Destroy Run "Close" immediately (but not right when the button is pressed) and follow up with a Destroy in case of a double click. Compared to the normal "+ C Close" this avoids the double click delay before the action is triggered. Commit: ffe942d66cdb1a24d761d9e89c1a4dab49f2400c https://github.com/fvwmorg/fvwm/commit/ffe942d66cdb1a24d761d9e89c1a4dab49f2400c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: M fvwm/add_window.c M fvwm/add_window.h M fvwm/events.c M fvwm/ewmh_names.c M fvwm/session.c M fvwm/style.h M fvwm/update.c M libs/defaults.h Log Message: --- Fix updating window and icon titles. With the introduction of the TitleFormat and IconTitleFormat styles, a change of the window or icon name could affect both titles. The existing code did not reflect this and a change in the icon name might not be visible in the window title and vice versa. The patch cleans up and unifies handling of changes of the window and icon names and fixes this problem. Also, the said patch simply set the default IconTitleFormat to the same as TitleFormat, so the icon name would never be used anyway. This commit replaces the default IconTitleFormat with "%i" instead. Commit: 3ecfb3d3080a34507840d427d7ae32d0dd847f39 https://github.com/fvwmorg/fvwm/commit/3ecfb3d3080a34507840d427d7ae32d0dd847f39 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2017-03-01 (Wed, 01 Mar 2017) Changed paths: A fvwm/ChangeLog A libs/ChangeLog Log Message: --- ChangeLog. Compare: https://github.com/fvwmorg/fvwm/compare/5c75103c1224...3ecfb3d3080a
Re: FvwmIconMan still sometimes triggers Hint Warnings
On Tue, Feb 28, 2017 at 10:22:33PM -0700, Jaimos Skriletz wrote:
> On Mon, Feb 27, 2017 at 11:10 PM, Jaimos Skriletz
> <jaimosskril...@gmail.com> wrote:
> > Hello,
> >
> > FvwmIconMan still reports Hint warnings even with the patchs applied.
>
> I wrote this small patch that has FvwmIconMan wait until the window
> has resized to set the window hints. This is in the lines of Dominik
> Vogt's patch, but waits until FvwmIconMan has fully resized to run
> fix_manager_size() to set the window hints. My tests here no longer
> seem to tiger the warnings like it still sometimes did.
>
> As an additional thought, talking to Thomas Adam about the patch in
> #fvwm, he mentioned that the issue is more FVWM being overly cautious
> and the fix should be in how fvwm handles size hint warnings over
> working with FvwmIconMan to avoid triggering them.
>
> I don't know enough about the issue to say which is more appropriate,
> but here is a patch that stops the warnings from being triggered in my
> tests.
Changing window geometry and hints has inherent race conditions by
design of the X protocol, unless every change is synchronized with
the server, and even then it's impossible to avoid some
inconsistencies. For example, there is no way to change the
window size and the requested min/max size in one atomic action.
Even more, there are lots of applications that set invalid hints
or in an ambigouos way. The window manager has to guess the
apllication's intention in such cases. A while ago I've started
adding more warnings to Fvwm in order to better identify such
situations, but this specific one has too many false positives.
Patching the application to wait for something happening is
definitely the wrong approach, not just because it is inefficient
but because there is no guarantee that the window manager ever
honours such requests.
So, if it's not possible to completely fix FvwmIconMan in a decent
way, what do we do with the warning? I'd rather not disable it,
but the number of false positives is too high. One could make a
style that disables the warning for a certain class of windows,
but that would probably be used as "style * ...", disabling the
warning for everything. :-/
> From 227d7ea2597ec3fec304c53934fcc41773ab7e89 Mon Sep 17 00:00:00 2001
> From: Jaimos Skriletz <jaimosskril...@gmail.com>
> Date: Tue, 28 Feb 2017 17:43:12 -0700
> Subject: [PATCH 1/1] Wait until FvwmIconMan is resized to set window HINTS
>
> ---
> modules/FvwmIconMan/xmanager.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/modules/FvwmIconMan/xmanager.c b/modules/FvwmIconMan/xmanager.c
> index 58eaaedc..b4efe890 100644
> --- a/modules/FvwmIconMan/xmanager.c
> +++ b/modules/FvwmIconMan/xmanager.c
> @@ -439,6 +439,16 @@ static void resize_window(WinManager *man)
> }
> MyXUngrabServer(theDisplay);
>}
> +
> + // Wait until the window has resised to fix the HINTS.
> + // counter is used to break an infinte loop.
> + XWindowAttributes attribs;
> + int counter = 2;
> + while ( counter && (attribs.width != man->geometry.width ||
> + attribs.height != man->geometry.height)) {
> +XGetWindowAttributes(theDisplay, man->theWindow, );
> +counter--;
> + }
>fix_manager_size(man, man->geometry.width, man->geometry.height);
> }
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Menu hot keys with accented characters
On Sun, Jan 08, 2017 at 11:13:52AM -0700, Jaimos Skriletz wrote:
> On Sun, Jan 8, 2017 at 3:14 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
> >> Here is an old (minor) bug that is lurking in the Debian BTS.
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
> >>
> >> The bug is that when assigning non ASCII keys as hot keys in a Menu,
> >> the underline underlines the non ASCII character and the one after it.
> >
> > Hotkeys must be printable 7 bit Ascii characters, which is
> > probably not documented. The reason for this is that the hotkey
> > is specified as a substring from the item label (e.g. "á") instead
> > of a key name ("aacute"). X has no real way to convert a string
> > into a key name or vice versa, so hotkeys work only for keys where
> > both representations are the same.
> >
>
> If keybindings for non 7 bit ASCII keys don't work, documentation
> could be useful. Though this has been around for a long time and not
> many seem to mention it so it probably isn't a big deal in the overall
> picture.
This may be a real issue for automatic hotkeys in languages other
than English. Words beginning with non-latin letters like Ü, Á
etc. are not uncommon in European languages.
> > I can reproduce the drawing bug. Maybe we should simply disable
> > hotkeys completely for anything not 7 bit ASCII.
> >
>
> Disabling the keys since they aren't working anyways and giving a
> warning may be useful for those who try to use non ASCII characters.
> Such a warning should only trigger when items are added to the menu,
> not each time the menu pops up.
Yes, a warning if it's a manual hotkey, at least. Not sure what
to do about automatic ones. It may be confusing to get no hotkey
without a warning (and without iconv we can't reliably look past
the first letter). On the other hand the user has probably not
asked for warnings regarding automatic hotkeys.
> At least this way if anyone tries to use non-ASCII characters they are
> correctly informed that they do not work and this can move to a
> feature request to add support for these keys.
I *could* implement the table I mentioned (there are several
version floating around the net) to get non-Ascii hotkeys working,
but then we might as well leave hotkeys as they are in fvwm-2.x
and rewrite the hotkey syntax to allow specifying key names for
fvwm-3.x. E.g. "&(aacute)" or something like that, or even
ábc use "á" as hotkey if iconv support is compiled in
(using a built-in table), otherwise no automatic
hotkey. Maybe rather use b as the hotkey as there's
no guarantee the keyboard has a key for á?
&ábcif iconv support is compiled in; automatic hotkeys
work; use built-in table
&(aacute) string representation of a keysym (XStringToKeysym)
&(12345)numeric representation of a keysym
Too stupid that X has no way to convert keysyms into printable
strings and vice versa.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Menu hot keys with accented characters
On Sun, Jan 01, 2017 at 02:10:03AM -0700, Jaimos Skriletz wrote:
> Here is an old (minor) bug that is lurking in the Debian BTS.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464363
>
> The bug is that when assigning non ASCII keys as hot keys in a Menu,
> the underline underlines the non ASCII character and the one after it.
Hotkeys must be printable 7 bit Ascii characters, which is
probably not documented. The reason for this is that the hotkey
is specified as a substring from the item label (e.g. "á") instead
of a key name ("aacute"). X has no real way to convert a string
into a key name or vice versa, so hotkeys work only for keys where
both representations are the same.
A solution for this would be to hard code a unicode-to-keysym
table inside fvwm and also requires iconv support. :-/
> Here is a simple test
>
> DestroyMenu TestMenu
> AddToMenu TestMenu "Test" Title
> + "T&êst" Echo Test
> + "&ñice one" Echo Nice One
> + "Th&ááát" Echo Thaaat
> + " One" Echo This
>
> Then open the menu.
I can reproduce the drawing bug. Maybe we should simply disable
hotkeys completely for anything not 7 bit ASCII.
> In addition to the visual bug, I was not able to correctly use these
> non-ASCII characters as hot keys. Since I don't have a keyboard that
> has accented keys on them it could be that I can't properly test if
> they work as hot keys (since I have to hit alt-key to type them).
To test it:
$ xmodmap -pki > ~/xmm
# edit some key binding in ~/xmm
$ xmodmap ~/xmm
> Seems there was once a patch trying to make these hot keys work better
>
> http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01916.html
>
> Unsure if the bug is just an extra character is underlined in the Menu
> or if using non ASCII characters for hot-keys doesn't work.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: Improving the default config
See branch dv/devel for various patches.
On Sat, Dec 31, 2016 at 07:26:54AM -0700, Jaimos Skriletz wrote:
> On Sat, Dec 31, 2016 at 6:03 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> > 1. In the log there is
> >
> > Traceback (most recent call last):
> > File "/home/luthien/bin/fvwm-menu-desktop", line 78, in
> > import xdg.Menu
> > ImportError: No module named xdg.Menu
> >
> >We should get rid of any error messages during startup, even if
> >some things may not be installed.
> >
> > 1b. In the builtin menu (if no config is used), the above message
> >is generated every time you move the pointer over the xdg menu
> >item.
> >
>
> Yes we should deal with the case either python or python-xdg is not
> installed. Unsure if there is a way we can test for python-xdg with
> Test or if that should be done in the fvwm-menu-desktop script. I
> would like the script to error out if run from a console and
> python-xdg is not installed so the user is aware of a missing
> component, so maybe add a -q/--quiet option that can be used in the
> config to just have it quietly exit if python-xdg is not installed.
>
> > 2. Are the buttons of inactive windows really meant to look like
> >in the attached image? NeverFocus windows like Xclock don't
> >ever get their buttons drawn properly.
> >
>
> Yes that is how the config draws inactive buttons. This can be
> changed, I just copied this from my setup.
>
> > 3. The main menu has a submenu for module manpages, but not a
> >submenu to start them. Weird.
> >
>
> This was brought up and is something that could be added. Though
> outside of FvwmConsole I personally don't know what other modules
> would be that useful to have in a menu to be launched, without some
> additional configurations of the module. But by all means add a
> submenu.
>
> > 4. The "Copy config" dialog should *really* state the filename of
> >the config file it generates, not just the target directory.
> >
>
> Okay.
>
> > 5. Double clicking the top left window button does not close the
> >window. The menu needs a doubleclick action:
> >
> > Mouse 1 1 A Menu MenuWindowOps delete
> >
> >(or maybe "destroy" instead).
> >
>
> I would not think that double clicking the menu button would close a
> window. But this could be added, though I don't see why since this can
> be done via the X button.
It's a historical thing. Double clicking that button close
windows long before the X button even appeared.
See dv/devel.
> > 6. Clicking the "X" button works only with a delay.
> >
>
> It is set up for a single click is Close and a double click is
> Destroy. So the delay is just the function waiting for ClickTime to
> pass to make sure it wasn't a double click.
I know, but it's annoying. Shouldn't that button just bind
"Delete" on a click? More forceful methods of closing are
available through the window menu.
The first patch on the branch is an attempt to close the window
earlier, but it doesn't actually work as we have to wait for the
end of the function anyway.
> > 7. The config uses button 4+5 for window shading. It shouldn't
> >require any non-standard mouse buttons for that.
> >
> > Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> > Mouse 5TA MoveClickX Nop Raise "WindowShade False"
> >
> >Also, this should really be just
> >
> > Mouse 4TA WindowShade True
> > Mouse 5TA WindowShade False
> >
> >Otherwise it may or may not raise the window when pushing a
> >mouse wheel, depending on the speed of the wheel.
>
> Fine, again just another thing adopted because I prefer the double
> click here, but your solution is simpler.
See dv/devel.
> > 8. The MoveClickX function is used even for functions that do not
> >have a doubleclick action ("Nop" instead). Therefore clicking
> >such a indow button works only with a delay (coubleclicktime),
> >and it won't work at all if you double click:
> >
> > Mouse 1FS A MoveClickX Resize Raise Nop
See dv/devel.
> > 9. Similarly, a button with "Nop" move action won't do anything if
> >you happen to move the mouse while clicking:
> >
> > Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> >
>
> Didn't consider that as I'm just use to it, I was just trying to avoid
> writing multple functions, but I agree it would be better to not have
>
Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer
On Sat, Dec 31, 2016 at 05:37:45AM -0700, Jaimos Skriletz wrote: > On Sat, Dec 31, 2016 at 4:11 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote: > >> On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote: > >> >> Hello, > >> >> > >> >> This was reported by a Debian user. Please retain the CC to > >> >> 802604-forwar...@bugs.debian.org in your response, so that > >> >> the Debian BTS has a record. > >> >> > >> >> In short if the mouse cursor is over the root window and hidden with > >> >> unclutter, when switching pages (and maybe desks), focus is not given > >> >> to the window under the pointer. > >> > > >> > Works fine for me. I'd need a precise description + config file > >> > to test this. > >> > > >> > >> Using SloppyFocus with a 2x2 grid of pages with the default config and > >> the following two key bindings > >> > >> Key Right A CM Scroll 100 0 > >> Key Left A CM Scroll -100 0 > >> > >> I then run unclutter to hide the mouse after being idle for a second: > >> > >> unclutter -idle 1 -root > >> > >> I move the mouse over the root window and wait for it to be hidden. > >> Once it is hidden > >> I use the key binding to switch to a new page. After I switch to the > >> page focus is kept > >> on the window in the old page and is not transferred. > > > > Still does not happen for me. With unclutter 8-18 (Debian): > > > > * Start fvwm with default config. > > * Open two Xterms from the menu (left side of screen). > > * Open FvwmConsole and move it to the bottom right corner. > > * Type > > style * sloppyfocus > > Key Right A CM Scroll 100 0 > > Key Left A CM Scroll -100 0 > >in FvwmConsole. > > * Run "unclutter -idle 1 -root" from one of the Xterms. > > * Press ctrl-alt-right to switch to page (1 0). > > * (Optional: open an Xterm there and close it to take away the > >focus from any window on (0 0).) > > * Move the pointer roughly to the middle of the FvwmConsole > >window. > > * Press ctrl-alt-left to switch to page (0 0). > > => The pointer ends up over FvwmConsole which gets the focus. > > > > These steps work for me. "Work" = "the window does not get focus"? > I tried with various versions of the optional > step, though in my tests I left the xterm around, but this did not > seem to matter, Leaving the xterm or not did not change the result. Neither for me. > Unsure how else to describe it as those steps cause this to happen, > just tested again in a VM and have attached screen shots to show how > the focus is right before and right after I switch pages. In the > before picture the mouse is in the bottom right corner over the root > window near the panel (but not over it) and unclutter has hidden the > mouse. > > Only other thing I note, as soon as I move the mouse, focus is then > given to the window under the mouse, but until then it remains on the > window on the previous page. You probably have a different version of unclutter. In the past, there was some change of the method it uses to hide the pointer. his may well play a role here. Can you find out which version you have? I guess it's something that should be fixed in unclutter if it's still an issue with the latest version. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer
On Fri, Dec 30, 2016 at 09:12:50PM -0700, Jaimos Skriletz wrote: > On Fri, Dec 30, 2016 at 8:49 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote: > >> Hello, > >> > >> This was reported by a Debian user. Please retain the CC to > >> 802604-forwar...@bugs.debian.org in your response, so that > >> the Debian BTS has a record. > >> > >> In short if the mouse cursor is over the root window and hidden with > >> unclutter, when switching pages (and maybe desks), focus is not given > >> to the window under the pointer. > > > > Works fine for me. I'd need a precise description + config file > > to test this. > > > > Using SloppyFocus with a 2x2 grid of pages with the default config and > the following two key bindings > > Key Right A CM Scroll 100 0 > Key Left A CM Scroll -100 0 > > I then run unclutter to hide the mouse after being idle for a second: > > unclutter -idle 1 -root > > I move the mouse over the root window and wait for it to be hidden. > Once it is hidden > I use the key binding to switch to a new page. After I switch to the > page focus is kept > on the window in the old page and is not transferred. Still does not happen for me. With unclutter 8-18 (Debian): * Start fvwm with default config. * Open two Xterms from the menu (left side of screen). * Open FvwmConsole and move it to the bottom right corner. * Type style * sloppyfocus Key Right A CM Scroll 100 0 Key Left A CM Scroll -100 0 in FvwmConsole. * Run "unclutter -idle 1 -root" from one of the Xterms. * Press ctrl-alt-right to switch to page (1 0). * (Optional: open an Xterm there and close it to take away the focus from any window on (0 0).) * Move the pointer roughly to the middle of the FvwmConsole window. * Press ctrl-alt-left to switch to page (0 0). => The pointer ends up over FvwmConsole which gets the focus. > Note: If the mouse is over a window (hidden or not) this does not > happen and focus is transfered. If the mouse is visible over the root > window this does not happen either. It needs to be hidden. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] b2f4bc: !!! Start work on replacing the parsing in __execu...
Branch: refs/heads/dv/new-parser-2 Home: https://github.com/fvwmorg/fvwm Commit: b2f4bce686118c71e3b2c22c2905479588af303f https://github.com/fvwmorg/fvwm/commit/b2f4bce686118c71e3b2c22c2905479588af303f Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/Makefile.am M fvwm/add_window.c M fvwm/builtins.c A fvwm/cmdparser.h A fvwm/cmdparser_old.c A fvwm/cmdparser_old.h M fvwm/colorset.c M fvwm/conditional.c M fvwm/events.c M fvwm/ewmh.c M fvwm/ewmh_events.c M fvwm/expand.c M fvwm/expand.h M fvwm/functions.c M fvwm/functions.h M fvwm/fvwm.c M fvwm/fvwm.h M fvwm/menucmd.c M fvwm/menus.c M fvwm/module_interface.c M fvwm/move_resize.c M fvwm/read.c M fvwm/repeat.c M fvwm/schedule.c M fvwm/update.c M fvwm/virtual.c M fvwm/windowlist.c Log Message: --- !!! Start work on replacing the parsing in __execute_command_line ... ... with hook functions that are implemented elsewhere. This aims at allowing to writing and testing multiple parsers in parallel and at moving all parsing and expansion stuff to a different place. Commit: e4ee0c738b5df1504d6a8736e3ebf93f86a3a28c https://github.com/fvwmorg/fvwm/commit/e4ee0c738b5df1504d6a8736e3ebf93f86a3a28c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser.h M fvwm/cmdparser_old.c M fvwm/functions.c Log Message: --- add debug output and fix positional arguments Commit: a8d1bf48531d00c10dc17ed3ba95905ca0b4748e https://github.com/fvwmorg/fvwm/commit/a8d1bf48531d00c10dc17ed3ba95905ca0b4748e Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser_old.c M fvwm/functions.c Log Message: --- add debug output and fix command line prefixes Commit: a7a34304f8bb06013b4189f67da44092f1795ec5 https://github.com/fvwmorg/fvwm/commit/a7a34304f8bb06013b4189f67da44092f1795ec5 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/Makefile.am M fvwm/cmdparser.h A fvwm/cmdparser_hooks.h M fvwm/cmdparser_old.c M fvwm/conditional.h M fvwm/functable.c M fvwm/functable.h A fvwm/functable_complex.c A fvwm/functable_complex.h M fvwm/functions.c M fvwm/functions.h M fvwm/fvwm.h M fvwm/misc.c M fvwm/repeat.c M fvwm/screen.h M libs/FScreen.h Log Message: --- Convert special logic in __execute_command_line for functions ... ... that may move a window to a separate function flag. Move find_builtin_function() to functable.[ch]. Moved some functions to functable.[ch] and functable_complex.[ch]. This separation is needed for the parsing hooks. It was very difficult to get the #icludes right. The DesktopsInfo structure was moved to libs/FScreen.h so that the library does not depend on core header files anymore. Move WindowConditionMask from mvwm.h to conditional.h. Finish 1st draft of hook implementation (__execute_command_line) Commit: 18e740675182d319189d298f2d27abd53b15b15c https://github.com/fvwmorg/fvwm/commit/18e740675182d319189d298f2d27abd53b15b15c Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser.h M fvwm/cmdparser_hooks.h M fvwm/cmdparser_old.c M fvwm/expand.c M fvwm/functions.c Log Message: --- Split pos_args into a string with all positional args and an array. Commit: ce22e8d80c29240799f75aa3f1e659cffbfbbde6 https://github.com/fvwmorg/fvwm/commit/ce22e8d80c29240799f75aa3f1e659cffbfbbde6 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/builtins.c M fvwm/events.c Log Message: --- Update execute_function calls for libstroke. Commit: 4149c9a1234627cc0a40ee696e86e5fe364a2c80 https://github.com/fvwmorg/fvwm/commit/4149c9a1234627cc0a40ee696e86e5fe364a2c80 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/cmdparser_old.c M fvwm/functions.c M fvwm/modconf.c M modules/FvwmButtons/dynamic.c Log Message: --- !!!debug fprintfs Commit: 82672e0e905aca13b9a2615215488a2a549255d9 https://github.com/fvwmorg/fvwm/commit/82672e0e905aca13b9a2615215488a2a549255d9 Author: Thomas Adam <tho...@fvwm.org> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M libs/FScreen.h Log Message: --- Reinstate libs/FScreen.h Commit: ab97d146234acf939f520cff4ed0569cf8a24ecc https://github.com/fvwmorg/fvwm/commit/ab97d146234acf939f520cff4ed0569cf8a24ecc Author: Thomas Adam <tho...@fvwm.org&
[fvwmorg/fvwm] 7cfd20: Improve and clean up size hints warnings.
Branch: refs/heads/master Home: https://github.com/fvwmorg/fvwm Commit: 7cfd209e17ed88c34f7ec9318dd82aabc3757baa https://github.com/fvwmorg/fvwm/commit/7cfd209e17ed88c34f7ec9318dd82aabc3757baa Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/add_window.c Log Message: --- Improve and clean up size hints warnings. Commit: e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 https://github.com/fvwmorg/fvwm/commit/e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M modules/FvwmIconMan/xmanager.c Log Message: --- FvwmIconMan: Don't trigger size hints warning in fvwm core. Commit: 5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 https://github.com/fvwmorg/fvwm/commit/5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wrong. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications. Commit: ccea4a057b8dca8657da9f3a505022716ce91999 https://github.com/fvwmorg/fvwm/commit/ccea4a057b8dca8657da9f3a505022716ce91999 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Commit: 2db6922a298738568c3a012e5a62183efe543e48 https://github.com/fvwmorg/fvwm/commit/2db6922a298738568c3a012e5a62183efe543e48 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M bin/Makefile.am M configure.ac M doc/fvwm/Makefile.am M fvwm/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmAuto/Makefile.am M modules/FvwmBacker/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am R modules/FvwmCommand/FvwmCommandS.c M modules/FvwmCommand/Makefile.am A modules/FvwmCommandS/FvwmCommand.h A modules/FvwmCommandS/FvwmCommandS.c A modules/FvwmCommandS/Makefile.am A modules/FvwmCommandS/fifos.c M modules/FvwmConsole/Makefile.am M modules/FvwmCpp/Makefile.am M modules/FvwmEvent/Makefile.am M modules/FvwmForm/Makefile.am M modules/FvwmIconMan/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmM4/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmPerl/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmRearrange/Makefile.am M modules/FvwmScript/Makefile.am M modules/Makefile.am Log Message: --- Fix installation and uninstallation with --program-transform-name. Had to move FvwmCommandS to a different subdir to do this. Commit: 359820be6d7b85b9ceb796a7f1a03c964f08d9d2 https://github.com/fvwmorg/fvwm/commit/359820be6d7b85b9ceb796a7f1a03c964f08d9d2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Compare: https://github.com/fvwmorg/fvwm/compare/9a57db1dd4ae...359820be6d7b
[fvwmorg/fvwm] 7cfd20: Improve and clean up size hints warnings.
Branch: refs/heads/dv/devel Home: https://github.com/fvwmorg/fvwm Commit: 7cfd209e17ed88c34f7ec9318dd82aabc3757baa https://github.com/fvwmorg/fvwm/commit/7cfd209e17ed88c34f7ec9318dd82aabc3757baa Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/add_window.c Log Message: --- Improve and clean up size hints warnings. Commit: e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 https://github.com/fvwmorg/fvwm/commit/e98b3e7fae771ca0f6db4ef4c3102bc248a64a02 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M modules/FvwmIconMan/xmanager.c Log Message: --- FvwmIconMan: Don't trigger size hints warning in fvwm core. Commit: 5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 https://github.com/fvwmorg/fvwm/commit/5ffc872c63fbd70db2dfc73042fe580fd7a57ec2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wrong. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications. Commit: ccea4a057b8dca8657da9f3a505022716ce91999 https://github.com/fvwmorg/fvwm/commit/ccea4a057b8dca8657da9f3a505022716ce91999 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Commit: 2db6922a298738568c3a012e5a62183efe543e48 https://github.com/fvwmorg/fvwm/commit/2db6922a298738568c3a012e5a62183efe543e48 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M bin/Makefile.am M configure.ac M doc/fvwm/Makefile.am M fvwm/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmAuto/Makefile.am M modules/FvwmBacker/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am R modules/FvwmCommand/FvwmCommandS.c M modules/FvwmCommand/Makefile.am A modules/FvwmCommandS/FvwmCommand.h A modules/FvwmCommandS/FvwmCommandS.c A modules/FvwmCommandS/Makefile.am A modules/FvwmCommandS/fifos.c M modules/FvwmConsole/Makefile.am M modules/FvwmCpp/Makefile.am M modules/FvwmEvent/Makefile.am M modules/FvwmForm/Makefile.am M modules/FvwmIconMan/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmM4/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmPerl/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmRearrange/Makefile.am M modules/FvwmScript/Makefile.am M modules/Makefile.am Log Message: --- Fix installation and uninstallation with --program-transform-name. Had to move FvwmCommandS to a different subdir to do this. Commit: 359820be6d7b85b9ceb796a7f1a03c964f08d9d2 https://github.com/fvwmorg/fvwm/commit/359820be6d7b85b9ceb796a7f1a03c964f08d9d2 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-12-28 (Wed, 28 Dec 2016) Changed paths: M NEWS Log Message: --- NEWS. Compare: https://github.com/fvwmorg/fvwm/compare/7cfd209e17ed^...359820be6d7b
Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed
On Tue, Dec 27, 2016 at 05:34:08PM -0700, Jaimos Skriletz wrote: > On Tue, Dec 27, 2016 at 5:28 PM, Jaimos Skriletz > <jaimosskril...@gmail.com> wrote: > > On Tue, Dec 27, 2016 at 5:15 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote: > >>> On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz > >>> <jaimosskril...@gmail.com> wrote: > >>> > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> > >>> > wrote: > >>> >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote: > >>> >>> Hello, > >>> >>> > >>> >>> This was reported by a Debian user. Please retain the CC to > >>> >>> 849355-forwar...@bugs.debian.org in your response, so that > >>> >>> the Debian BTS has a record. > >>> >>> > >>> >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when > >>> >>> opening and closing windows. I too have had this issue in 2.6.7 (and > >>> >>> previous versions) so I can also say it affects my Debian system. > >>> >> > >>> >> > >>> >> I don't get any such messages with or without FvwmIconMan. Can > >>> >> you give detailed instructions pelase? > >>> >> > >>> > > >>> > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian > >>> > patches, but I will compile a version without patches and test. > >>> > > >>> > >>> Tested with a fresh compile of Fvwm 2.6.7 without any debian patches, > >>> same issue. > >>> > >>> > > >>> > I tested this with other windows and modules. FvwmScript modules > >>> > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to > >>> > do with transient windows or not (just something I noticed). > >>> > > >>> > >>> Nevermind this, FvwmIdentify is not a traisnent window, the reason it > >>> was not producing the warning was it was configured so FvwmIconMan did > >>> not create a button for that window. > >>> > >>> After further testing the warning seems to be due to be caused by > >>> adding/removing the button for a window from FvwmIconMan. Windows that > >>> appear there trigger the warning but ones that don't appear don't. > >> > >> Still no luck to reproduce it. After said message there should > >> always be this one which prints all the details of the window and > >> the faulty hints: > >> > >> fvwm_msg( > >> WARN, "GetWindowSizeHints", > >> "The application window (id %#lx)\n" > >> " \"%s\" has broken size hints (%s).\n" > >> "fvwm is ignoring those hints. " > >> " hint override = %d, flags = %lx\n" > >> " min_width = %d, min_height = %d, " > >> "max_width = %d, max_height = %d\n" > >> " width_inc = %d, height_inc = %d\n" > >> " min_aspect = %d/%d, max_aspect = %d/%d\n" > >> " base_width = %d, base_height = %d\n" > >> " win_gravity = %d\n", > >> > > > > I get no other output after the warning, so that message is never > > printed to stderr on my system. > > > > Unsure if this helps, but I did enable BugOpts DebugCRMotionMethod, > > and get the output > > > > _cdim: not moved 0x55927d4a8990 'FvwmIconMan' > > > > after each time the warning is produced. > > Further testing, if I set the ManagerGeometry to something like 5x3 so > FvwmIconMan doesn't resize itself, I no longer get the warning. It is > only with the default like 0x1, causing the window to grow/shrink I > get the warning. Could be reproduced with a standalone FvwmIconMan (instead of the one inside FvwmButtons). > Wild guess, could it be some timing issue during the resizing of the > window when adding/removing a button cause the window's current size > to become invalid as per the warning? Roughly, yes. FvwmIconMan sets the minimum and maximum width and height size hints to the new geometry it wants, then requests the new size. When fvwm reads the new hints, the current geometry of the manager window becomes obviously invalid until the window is also resized. That's what triggers the warning. So, to fix this: 1. Remove the size restrictions, then resize, then set the new size restrictions. Theoretically the winodw might be resized by the user in between, but that's highly unlikely. 2. Also print the size hints that trigger this warning in a second message. Fixed on the (new) fvwm2-stable branch; patch for the development branches will follow one I've figured out how to deal with the two repositories. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Fwd: Bug#849355: fvwm: GetWindowSizeHints warnings when windows and opened and closed
On Tue, Dec 27, 2016 at 05:04:40PM -0700, Jaimos Skriletz wrote: > On Tue, Dec 27, 2016 at 4:52 PM, Jaimos Skriletz > <jaimosskril...@gmail.com> wrote: > > On Tue, Dec 27, 2016 at 3:44 PM, Dominik Vogt <dominik.v...@gmx.de> wrote: > >> On Mon, Dec 26, 2016 at 01:17:05PM -0700, Jaimos Skriletz wrote: > >>> Hello, > >>> > >>> This was reported by a Debian user. Please retain the CC to > >>> 849355-forwar...@bugs.debian.org in your response, so that > >>> the Debian BTS has a record. > >>> > >>> In short when running FvwmIconMan, fvwm prints warnings to stderr when > >>> opening and closing windows. I too have had this issue in 2.6.7 (and > >>> previous versions) so I can also say it affects my Debian system. > >> > >> > >> I don't get any such messages with or without FvwmIconMan. Can > >> you give detailed instructions pelase? > >> > > > > Using Fvwm 2.6.7 Debian package, doubt it is any of the debian > > patches, but I will compile a version without patches and test. > > > > Tested with a fresh compile of Fvwm 2.6.7 without any debian patches, > same issue. > > > > > I tested this with other windows and modules. FvwmScript modules > > seemed to trigger it, FvwmIdentify did not, so I wonder if it has to > > do with transient windows or not (just something I noticed). > > > > Nevermind this, FvwmIdentify is not a traisnent window, the reason it > was not producing the warning was it was configured so FvwmIconMan did > not create a button for that window. > > After further testing the warning seems to be due to be caused by > adding/removing the button for a window from FvwmIconMan. Windows that > appear there trigger the warning but ones that don't appear don't. Still no luck to reproduce it. After said message there should always be this one which prints all the details of the window and the faulty hints: fvwm_msg( WARN, "GetWindowSizeHints", "The application window (id %#lx)\n" " \"%s\" has broken size hints (%s).\n" "fvwm is ignoring those hints. " " hint override = %d, flags = %lx\n" " min_width = %d, min_height = %d, " "max_width = %d, max_height = %d\n" " width_inc = %d, height_inc = %d\n" " min_aspect = %d/%d, max_aspect = %d/%d\n" " base_width = %d, base_height = %d\n" " win_gravity = %d\n", Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[fvwmorg/fvwm] b1912e: Fix disappearing windows.
Branch: refs/heads/dv/fix-disappering-windows Home: https://github.com/fvwmorg/fvwm Commit: b1912ee1d0af84aef588bebb4b37a118a91ec6a8 https://github.com/fvwmorg/fvwm/commit/b1912ee1d0af84aef588bebb4b37a118a91ec6a8 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-11-21 (Mon, 21 Nov 2016) Changed paths: M fvwm/events.c Log Message: --- Fix disappearing windows. The old patch that removed synthetic UnmapNotify events on the root window to suppress windows in HandeMapRequestKeepRaised() being unmapped later. However, this also caused problems. vmplayer windows still diasppeared when returning from fullscreen mode. It seems that the real problem was the XUnmapWindow in HandleUnmapNotify. Whoever thought this was a necessary or a good idea is wron. When we get an UnmapNotify on a client window, the client has already unmapped it itself. When we get a synthetic UnmapNotify on the root window the client has also unmapped the window. There's no need whatsoever to unmap it again, and events caused by unmapping twice do confuse applications.
[fvwmorg/fvwm] b26886: Update parser documentation.
Branch: refs/heads/dv/new-parser-2 Home: https://github.com/fvwmorg/fvwm Commit: b26886b96ce400d9258fa586011cf7b97e795c7b https://github.com/fvwmorg/fvwm/commit/b26886b96ce400d9258fa586011cf7b97e795c7b Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-11-15 (Tue, 15 Nov 2016) Changed paths: M fvwm/cmdparser.h M fvwm/cmdparser_hooks.h Log Message: --- Update parser documentation.
[fvwmorg/fvwm] 3443ad: Fix crash in new parser.
Branch: refs/heads/dv/new-parser-2 Home: https://github.com/fvwmorg/fvwm Commit: 3443ade4c10cef5e0d2b6f3a30b30b6731a9ec60 https://github.com/fvwmorg/fvwm/commit/3443ade4c10cef5e0d2b6f3a30b30b6731a9ec60 Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-11-15 (Tue, 15 Nov 2016) Changed paths: M fvwm/cmdparser_old.c Log Message: --- Fix crash in new parser. Because dest_c->call_depth was not properly set, set_repeat_data was called during nested function execution and deleted the original command line before the function completed. Triggered for example with "all windowshade off".
Re: Request for testing help
On Sun, Nov 13, 2016 at 04:39:53PM +0100, Dominik Vogt wrote: > I'm still struggling with reproducing a creash in the a crash in > the branch dv/new-parser-2. It has something to do with passing > around arguments from one complex function to another (possibly > nested deeper). In some situations, the memory for an argument is > freed while still being in use somewhere else. It may also have > something to do with multiple things happening at once, like > switching pages or so (triggered by a module?). > > The biggest debugging problem is that it happens very rarely with > my config, maybe twice a year. If any of you had the time and > leisure to fiddle around a bit with nested complex functions with > lots of arguments and identified a reproduceable case that > crashes, that would help me a lot to finally identify and fix the > problem. I've figured it out and fixed it, please don't spend time on this anymore. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Mon, Nov 14, 2016 at 01:11:57AM +, Ethan Raynor wrote: > I can understand personal opinions - they're important and they happen > all the time with projects, I understand that. But I don't think it is > very fair to say I should not read it - when I won't know weather it's > there or not to start with. So I think just not having those > conversations is better. I don't. Software development is difficult enough without worrying about the feelings of the readers. This just eats up time that could be used to do some useful work. -- Please don't top post on this list, i.e. put your answers below the text you're refering to, not above it. https://en.wikipedia.org/wiki/Posting_style BAD ^ | | > On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt <dominik.v...@gmx.de> wrote: > > Please don't top post on the fvwm lists. > > > > On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote: > >> it's those points i would like to see put elsewhere | | v GOOD Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Mon, Nov 14, 2016 at 12:58:42AM +, Thomas Adam wrote: > On Mon, Nov 14, 2016 at 01:52:51AM +0100, Dominik Vogt wrote: > > By the way, any idea why "make distcheck" has never caught the > > faulty uninstallation of the symlinks? > > Nope, no idea. > > I find dist/distcheck to be some seriously weird automake black magic which > I've never fully understood. As far as I understand it: 1. Make everything. 2. Build a tarball from the build result, using the files mentioned in the Makefile.am. 3. Create three subdirs (SOURCE, BUILD, INSTALL or whatever the exact names are). 4. Extract the tarball into SOURCE. 5. Unprotect BUILD, write protect SOURCE and protect INSTALL from any access. 6. cd into the builddir, build everything with --srcdir=SOURCE and --prefix=INSTALL. => This makes sure that all files built are placed in BUILD, all source files are taken from SOURCE, and nothing is installed or built in INSTALL during the build step. 7. Protect SOURCE from any access, write protect BUILD and unprotect INSTALL. 8. make install => This makes sure that installing actually places the files in INSTALL and not elsewhere. 9. make uninstall and check that nothing is left in INSTALL except empty directories. => Check that everything put into INSTALL ist removed, and that files are actually removed from the INSTALL and not from SOURCE or BUILD. If "make distcheck" fails, it's normally either because some file is missing from the tarball or not properly uninstalled. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
Please don't top post on the fvwm lists. On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote: > it's those points i would like to see put elsewhere I've completely understood that it bothers you. If you don't want to read it, don't. This is an unavoidable part of public software development. > as that doesnt have much - if anything- to do with fvwm. Discussing the fvwm infrastructure and the personal opinions about it is completely on topic. This list is not a place where politeness or political correctness is exspecially important. > or am i wrong? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Sun, Nov 13, 2016 at 05:13:22PM +, Thomas Adam wrote: > On Sun, Nov 13, 2016 at 04:09:14PM +0100, Dominik Vogt wrote: > > Bofore you start working on that, please take a look at the > > dv/fix-transform-name branch. > > OK, this looks good. I'm surprised that FvwmCommand.sh is installed to > /.../libexec/fvwm/$(VERSION) without execute permissions. But this isn't a > bug, it seems to always have been the case. It's still not good. Isn't there a standard Automake way to install shell scripts? > I suppose the next step is to remove the compatability symlinks, both in terms > for fvwm2 -> fvwm and xpmroot, and the symlinks for the documentation. You > can do that on top of what you have, if you like. I think it's more important to first fix the Makefile.am in default-config and its subdirs as written in the other thread. Furthermore, the symlinks are not properly installed when --program-transform-name is used, and they are not properly uninstalled. (I certainly can do this, but I'd like to give the author of the Makefile.am the chance to fix it - I know it's tedious, but it's neccessary.) By the way, any idea why "make distcheck" has never caught the faulty uninstallation of the symlinks? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Mon, Nov 14, 2016 at 12:07:42AM +, Ethan Raynor wrote: > Is it OK to request these sorts of conversations take place someplace > else? No. If there's one place for discussing fvwm development, it's this mailing list. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Request for testing help
Hi folks, I'm still struggling with reproducing a creash in the a crash in the branch dv/new-parser-2. It has something to do with passing around arguments from one complex function to another (possibly nested deeper). In some situations, the memory for an argument is freed while still being in use somewhere else. It may also have something to do with multiple things happening at once, like switching pages or so (triggered by a module?). The biggest debugging problem is that it happens very rarely with my config, maybe twice a year. If any of you had the time and leisure to fiddle around a bit with nested complex functions with lots of arguments and identified a reproduceable case that crashes, that would help me a lot to finally identify and fix the problem. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] f508f5: Fix installation and uninstallation with --program...
On Sun, Nov 13, 2016 at 07:00:29AM -0800, Dominik Vogt wrote: > Branch: refs/heads/dv/fix-program-transform > Home: https://github.com/fvwmorg/fvwm > Commit: f508f5f574de461e21fa5ad2d4d2d50eb75378df > > https://github.com/fvwmorg/fvwm/commit/f508f5f574de461e21fa5ad2d4d2d50eb75378df > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-11-13 (Sun, 13 Nov 2016) > > Changed paths: > M bin/Makefile.am > M configure.ac > M doc/fvwm/Makefile.am > M fvwm/Makefile.am > M modules/FvwmAnimate/Makefile.am > M modules/FvwmAuto/Makefile.am > M modules/FvwmBacker/Makefile.am > M modules/FvwmBanner/Makefile.am > M modules/FvwmButtons/Makefile.am > R modules/FvwmCommand/FvwmCommandS.c > M modules/FvwmCommand/Makefile.am > A modules/FvwmCommandS/FvwmCommand.h > A modules/FvwmCommandS/FvwmCommandS.c > A modules/FvwmCommandS/Makefile.am > A modules/FvwmCommandS/fifos.c > M modules/FvwmConsole/Makefile.am > M modules/FvwmCpp/Makefile.am > M modules/FvwmEvent/Makefile.am > M modules/FvwmForm/Makefile.am > M modules/FvwmIconMan/Makefile.am > M modules/FvwmIdent/Makefile.am > M modules/FvwmM4/Makefile.am > M modules/FvwmPager/Makefile.am > M modules/FvwmPerl/Makefile.am > M modules/FvwmProxy/Makefile.am > M modules/FvwmRearrange/Makefile.am > M modules/FvwmScript/Makefile.am > M modules/Makefile.am > > Log Message: > --- > Fix installation and uninstallation with --program-transform-name. > > Had to move FvwmCommandS to a different subdir to do this. Actually, I find commit messages without the diffs really useless. Could we activate the diffs with some size limit? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > Why on earth do we have to repeat the mistake of the past by
> > > > putting the version number in the project name *again*? Every
> > > > other project manages backwards incompatible releases just fine,
> > > > only fvwm changes its name with each major release. This just
> > > > complicates things, and helps nobody. That's what configure's
> > > > binary suffix is for.
> > >
> > > So what would you rather, and to what extent should this happen?
> >
> > See attached patch. The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs). It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
>
> Right. I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier. So I'll rejig some things and use this.
>
> I can see there's a few things which will need adjusting. We won't need the
> fvwm2 symlink at all since that would be misleading, surely? The other parts
> you've identified shouldn't be too difficult to fix.
> I'm unsure what should
> happen with the gettext files, and if they need namespacing at all.
As with my path modules don't get a suffix (unless installed in
bin/), the same concern applies to the module manpages. It would
be confusing to have a module "FvwmButtons" with a manpage
"FvwmButtons-3.1". But if the module name is not suffixed, there
cannot be multiple versions of the manpage installed.
> One observation I've got is:
>
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
>
> Is this not what the option '--program-transform-name=program' is doing? See:
>
> https://www.gnu.org/software/automake/manual/html_node/Renaming.html
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > Why on earth do we have to repeat the mistake of the past by
> > > > putting the version number in the project name *again*? Every
> > > > other project manages backwards incompatible releases just fine,
> > > > only fvwm changes its name with each major release. This just
> > > > complicates things, and helps nobody. That's what configure's
> > > > binary suffix is for.
> > >
> > > So what would you rather, and to what extent should this happen?
> >
> > See attached patch. The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs). It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
>
> Right. I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier. So I'll rejig some things and use this.
>
> I can see there's a few things which will need adjusting. We won't need the
> fvwm2 symlink at all since that would be misleading, surely? The other parts
> you've identified shouldn't be too difficult to fix. I'm unsure what should
> happen with the gettext files, and if they need namespacing at all. I don't
> make use of such things.
Bofore you start working on that, please take a look at the
dv/fix-transform-name branch.
> One observation I've got is:
>
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
>
> Is this not what the option '--program-transform-name=program' is doing? See:
Roughly, but it only modifies program names while we also want to
change some subdir names. And it does not work in Makefile.am
hooks. :-/
> https://www.gnu.org/software/automake/manual/html_node/Renaming.html
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
[fvwmorg/fvwm] f508f5: Fix installation and uninstallation with --program...
Branch: refs/heads/dv/fix-program-transform Home: https://github.com/fvwmorg/fvwm Commit: f508f5f574de461e21fa5ad2d4d2d50eb75378df https://github.com/fvwmorg/fvwm/commit/f508f5f574de461e21fa5ad2d4d2d50eb75378df Author: Dominik Vogt <dominik.v...@gmx.de> Date: 2016-11-13 (Sun, 13 Nov 2016) Changed paths: M bin/Makefile.am M configure.ac M doc/fvwm/Makefile.am M fvwm/Makefile.am M modules/FvwmAnimate/Makefile.am M modules/FvwmAuto/Makefile.am M modules/FvwmBacker/Makefile.am M modules/FvwmBanner/Makefile.am M modules/FvwmButtons/Makefile.am R modules/FvwmCommand/FvwmCommandS.c M modules/FvwmCommand/Makefile.am A modules/FvwmCommandS/FvwmCommand.h A modules/FvwmCommandS/FvwmCommandS.c A modules/FvwmCommandS/Makefile.am A modules/FvwmCommandS/fifos.c M modules/FvwmConsole/Makefile.am M modules/FvwmCpp/Makefile.am M modules/FvwmEvent/Makefile.am M modules/FvwmForm/Makefile.am M modules/FvwmIconMan/Makefile.am M modules/FvwmIdent/Makefile.am M modules/FvwmM4/Makefile.am M modules/FvwmPager/Makefile.am M modules/FvwmPerl/Makefile.am M modules/FvwmProxy/Makefile.am M modules/FvwmRearrange/Makefile.am M modules/FvwmScript/Makefile.am M modules/Makefile.am Log Message: --- Fix installation and uninstallation with --program-transform-name. Had to move FvwmCommandS to a different subdir to do this.
default-config installation
This is not how to install files with automake: default-config/Makefile.am: > ## Process this file with automake to create Makefile.in > > configdir = @FVWM_DATADIR@/default-config > inst_location = $(DESTDIR)@FVWM_DATADIR@/default-config > config_DATA = config \ > .stalonetrayrc \ stalonetraydir = $(configdir)/.stalonetrayrc > FvwmScript-DateTime \ > FvwmScript-ConfirmQuit \ Remove subdirs from this Makefile.am, add them to the SUBSIRS variable, add a Makefile.am in their directory and list all files to be installed in a variable: foobardir = @FVWM_DATADIR@/default-config/ foobar_DATA = (list all files) > FvwmScript-ConfirmCopyConfig > > EXTRA_DIST = images \ > config \ > .stalonetrayrc \ > FvwmScript-DateTime \ > FvwmScript-ConfirmQuit \ Liekwise. > FvwmScript-ConfirmCopyConfig > > install-data-hook: > cp -r $(srcdir)/images $(inst_location) > ln -sf $(inst_location)/FvwmScript-DateTime $(inst_location)/.. > ln -sf $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/.. > ln -sf $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/.. Use "$(LN_S) -f", don't merge options. See bin/Makefile.am for an example how to make symlinks. > > uninstall-hook: > rm -fr $(DESTDIR)/$(configdir) Don't merge options, i.e. use "rm -r -f". This command runs a high risk of destroying user data because of the recursive delete. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)
On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > Why on earth do we have to repeat the mistake of the past by
> > putting the version number in the project name *again*? Every
> > other project manages backwards incompatible releases just fine,
> > only fvwm changes its name with each major release. This just
> > complicates things, and helps nobody. That's what configure's
> > binary suffix is for.
>
> So what would you rather, and to what extent should this happen?
See attached patch. The Makefile.am need some tuning because some
names are hard coded in install...local rules (FvwmCommand.sh,
FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs). It's easy to
firgure out; just configure with --prefix=some-private-dir, ass
program-suffix and program-prefix, then install and see which
files end up in the wrong place.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From 08f22e1a9aa492cf084020ea9d3c7dbf286659ea Mon Sep 17 00:00:00 2001
From: Dominik Vogt <dominik.v...@gmx.de>
Date: Sun, 13 Nov 2016 04:16:14 +0100
Subject: [PATCH] !
---
configure.ac |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index e3a5424..665e77b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,9 +93,11 @@ AC_MSG_RESULT([assuming $PERL as perl location])
AC_SUBST(PERL)
# installation paths
-FVWM_MODULESUBDIR=/${PACKAGE}/${VERSION}
-FVWM_DATASUBDIR=/${PACKAGE}
-FVWM_DOCSUBDIR=/doc/${PACKAGE}
+transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
+PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
+FVWM_MODULESUBDIR=/${PPACKAGE}/${VERSION}
+FVWM_DATASUBDIR=/${PPACKAGE}
+FVWM_DOCSUBDIR=/doc/${PPACKAGE}
AC_ARG_ENABLE(package-subdirs,
AS_HELP_STRING([--disable-package-subdirs],
--
1.7.10.4
Re: Final long term stable version
On Fri, Nov 11, 2016 at 11:35:42AM +, Thomas Adam wrote: > On Wed, Nov 09, 2016 at 09:01:20PM +, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 01:26:19AM +0100, Dominik Vogt wrote: > > > The branch dv/stable-fvwm2 is up for review. Collecting the > > > patches was a piece of cake. Just one conflict with the NEWS > > > file. The branch builds fine for me, without warnings, and I'm > > > using it now for work. > > > > Indeed -- it seems fine for me too. We should ideally rename this as > > 'fvwm2-stable'; I can do that if you don't have time, but I'm certainly > > happy > > to call this complete and releasable -- with the appropriate documentation > > updated, too. > > Branch pushed; documentation to follow. Thanks. I'm still hoping that crash shows up again soon so that it can be fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Separate or common project infrastructure fvwm v2/v3.
This is important enough to warrant a separate discussion thread. On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote: > Oh, and the point of a separate repo still stands, in my eyes. You might > think it moot, or even an unnecessary point, but I feel it's a very important > one. It reinforces (psychologically) that it's separate from fvwm2. It > reinforces that fvwm3 is discrete, and it reinforces the idea that it will > become divergent from fvwm2 quite quickly. First of all, for me personally there is no psychological issue. I can think of the continued work to be all new regardless of which mailing list its discussed on and where the repository is located. It may be different for others. >From the point of view of the users and the people reading fvwm-workers I am very sceptical. We have already abandoned cvs in favour of git, and as you can see, this has even further reduced the number of old timers who have set up a development environment. I'd be very careful about sending yet another "we don't want to have anything to do with the old stuff" message to the world. Switching to new infrastructure, we'll automatically lose some of the people that are interested in fvwm development, be it that they miss that the mailing lists have moved or that they won't understand why there are two projects with the same name and which to look at. On the other hand: * Staying on the same mailing list: Readers will notice over time that we're working on something new, that version 3 will be a more modern and radically different thing than version 2. They may become interested in it or not, only time will tell. There is no information hurdle they have to take to find out that something new is being done. Bugs reported for fvwm-2.x will still be relevant to fvwm-3.x for a long time (depends on the bugs). We don't want to keep people from reporting bugs on the list because they might think the project is dead when it has just moved. * Switching git repository: Given that the current amount of work going into version 2.x is very low, having both versions in the same repository is certainly manageable. It's just more work for anybody who is interested in both repos (and getting access to github *is* very cumbersome compared to cvs access in the past). * Switching to a new web space: This would make us the target of ridicule for years and cause musch confusion. How would we explain that there are two distict web pages for the same project that differ only in version number? It would just be inconvenient for everybody. All right, we would have to place a big announcement on the web page with a link that points to the version 2 related sub pages, but I think with two different web pages we'd have to do it on both anyway. * With new infrastructure we'd run the risk that fvwm is kicked out of even more distributions. So, is there maybe *another* way to foster enthusiasm about a new, incompatible version? Maybe we just need to do some "public relations" work here. A while ago you started a discussion about a new logo contest. Great idea, why not make it an event around the official "fork" date. I'd be happy to donate another prize. We'd have something "new" practically from day one. Maybe an Irc "fvwm version 3" kickoff party where we explain our plans for the future? > It's not as if we're backporting features or fixes between the two. Of course I'll continue backporting fixes like the recent ones in event handling in the window management core. This code is changes at a very low pace, and backports are easily done. > Copy---if it makes you feel any easier--- the entirety of the > files from fvwm's master branch to new fvwm3 repository. Do your > work there, the set up is Not at all, that would just greatly complicate things and confuse people. What use would two copies of the same code in deifferent repositories be? > Do your work there, the set up is > easy. Having a separate fvwm3 repository also allows to integrate anything we > wish to the main fvwm website as well (when that becomes appropriate). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...
On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote: > On Wed, Oct 26, 2016 at 02:21:57PM +0200, Dominik Vogt wrote: > > First of all I hope I'll be able to find the crash caused by a free of a > > string that is still > > used, then experiment with it to see whether a step by step replacement of > > the old > > parser is feasible while keeping the old parser around for a while. > > Disentangling the > > builtin functions from the parser without changing their syntax is an > > important step towards a new parser with a new syntax. As long as all the > > functions do their own parsing, replacing the syntax is a huge amount of > > work. > > But what you're describing is the biggest piece of work which would almost > define fvwm3. Thus far, there's still an on-going discussion about how we're > going to do that. Heck, we haven't even declared fvwm2-stable or fvwm-2.6.7 > yet. Aren't you jumping the gun a little? Maybe, maybe not. This work only changes the inner structure of the parser yet and has few user visible changes (some rarely triggered quoting issues). > I'd argue---quite strongly---that any work towards a new parser should be done > with breaking everything completely. Sure, you can still keep some of the > surrounding things, but trying to maintain backwards-compatibility isn't > necessary given the measures we're putting in place for fvwm2's future. It's not about staying compatible but about changing the parser in steps with a useable intermediary result that can be tested. Donig the parser from zero would mean to have nothing that works even remotely for months. > But at the moment, we haven't even discussed what that will look like, or what > requirements we might have. I started to do that recently when I put out a > proposal for a new syntax to see how that fared. Yeah, I've seen that. The current work should be independent of the syntax we're aiming at though. I would imagine changing the parser in several distinct steps: 1. Restructuring the code so that different parsers can be plugged in at run time on a per builtin basis. [This is what the current work is about.] 2. Replace the current builtins parsing code with an abstract syntax description and provide a parsing core that can parse the input and provide the output the builtins need. [This is the really big chunk of work.] 3. Replace the internal parser language (quoting, argument passing, variable expansion, conditional syntax etc.). 4. Rewrite the builtins' syntax descriptions to a new style that will hopefully be easier to read, write and parse. Note that once step 1 is complete, the following steps can be written and tested in a separate parser plugin, so the code stays useable even while the new parser is still under construction. You just switch to the unfinished parser for certain commands. Once the result is stable, the duplicate code can be eliminated (or kept around for a while to give people more time to adapt). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Wed, Oct 26, 2016 at 08:40:02AM +0200, Florian Schmidt wrote: > On 10/25/2016 06:38 PM, Dominik Vogt wrote: > >Right. A solution must disable the warnings on any compilers and > >versions the developers use, and not break compilation anywhere. > > The way I generally do it is check for the compiler, and then define > a macro for gcc and for clang using those attributes. Admittedly, > that works, because for the stuff I work on, those two are all that > is expected to be ever used; something that probably cannot be said > about fvwm. > > In the end, this mail (and the one from yesterday) are outdated > anyway No, I'm still thinking about a possible solution that works without using potentially unportable headers. A colleague has come up with this: x = (x >= 0) ? (((unsigned) x) & 0x7fff) : - ((- (unsigned) x) & 0x7fff); Well, there's CARD16/INT16 defined in Xmd.h, maybe we should use them instead of the the C standard headers. > because I see you already found another solution via the > SUPPRESSED_UNUSED_VAR_WARNING macro, so disregard my comments. > But, since I'm curious: that macro doesn't have the problem of > potentially masking warnings about using uninitialized variables? I hope so, but that may depend on how clever the compiler is. > I guess the important difference is that you only use , not x > itself any more? Yes. Apparently when the pointer is used, Gcc thinks any value set may be used, but does not consider it a potentially uninitialised use. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...
> Gesendet: Mittwoch, 26. Oktober 2016 um 12:06 Uhr > Von: "Thomas Adam" <tho...@fvwm.org> > An: "Dominik Vogt" <dominik.v...@gmx.de> > Cc: fvwm-workers@fvwm.org > Betreff: Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing > in __execu... > > On Wed, Oct 26, 2016 at 12:04:46PM +0200, Dominik Vogt wrote: > > > On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote: > > > > Branch: refs/heads/dv/new-parser-2 > > ... > > > > > > I ported all of this over before here: > > > > > > https://github.com/fvwmorg/fvwm/tree/new-parser > > > > > > You should just rebase that against master, and use that if it's any use? > > > > This new branch is the result of rebasing the new-parser branch against > > master. There > > were some conflicts with the USE_DECOR removal patch, and rebase had some > > trouble > > with the mvwm subdirectory, so I've rewritten the history to eliminate this > > directory > > (and merged some commits for simplicity). > > Cool -- but what do you intend to do with this work? First of all I hope I'll be able to find the crash caused by a free of a string that is still used, then experiment with it to see whether a step by step replacement of the old parser is feasible while keeping the old parser around for a while. Disentangling the builtin functions from the parser without changing their syntax is an important step towards a new parser with a new syntax. As long as all the functions do their own parsing, replacing the syntax is a huge amount of work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...
> On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote: > > Branch: refs/heads/dv/new-parser-2 ... > > I ported all of this over before here: > > https://github.com/fvwmorg/fvwm/tree/new-parser > > You should just rebase that against master, and use that if it's any use? This new branch is the result of rebasing the new-parser branch against master. There were some conflicts with the USE_DECOR removal patch, and rebase had some trouble with the mvwm subdirectory, so I've rewritten the history to eliminate this directory (and merged some commits for simplicity). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Setting a reply-to header in commit messages
Thomas, can you set a Reply-To: header in the commit mails that points to fvwm-workers? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 1d38f7: !!! Start work on replacing the parsing in __execu...
I've rebased the new-parser branch to the current master. I've not yet tested it, but it compiles and has no mention of "mvwm" in its history anymore, so coming rebases should be much easier. @Thomas: Can you remember what the patches to FScreen.h in ~2 and ~6 are about? On Tue, Oct 25, 2016 at 03:41:45PM -0700, GitHub wrote: > Branch: refs/heads/dv/new-parser-2 > Home: https://github.com/fvwmorg/fvwm > Commit: 1d38f7a2727f28f1817e1c951bc07267002d2006 > > https://github.com/fvwmorg/fvwm/commit/1d38f7a2727f28f1817e1c951bc07267002d2006 > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-25 (Tue, 25 Oct 2016) > > Changed paths: > M fvwm/Makefile.am > M fvwm/add_window.c > M fvwm/builtins.c > A fvwm/cmdparser.h > A fvwm/cmdparser_old.c > A fvwm/cmdparser_old.h > M fvwm/colorset.c > M fvwm/conditional.c > M fvwm/events.c > M fvwm/ewmh.c > M fvwm/ewmh_events.c > M fvwm/expand.c > M fvwm/expand.h > M fvwm/functions.c > M fvwm/functions.h > M fvwm/fvwm.c > M fvwm/fvwm.h > M fvwm/menucmd.c > M fvwm/menus.c > M fvwm/module_interface.c > M fvwm/move_resize.c > M fvwm/read.c > M fvwm/repeat.c > M fvwm/schedule.c > M fvwm/update.c > M fvwm/virtual.c > M fvwm/windowlist.c > > Log Message: > --- > !!! Start work on replacing the parsing in __execute_command_line ... > > ... with hook functions that are implemented elsewhere. This aims > at allowing to writing and testing multiple parsers in parallel > and at moving all parsing and expansion stuff to a different > place. > > > Commit: 71b8dd6064553ad646bfadebfb501a95f7d5da9c > > https://github.com/fvwmorg/fvwm/commit/71b8dd6064553ad646bfadebfb501a95f7d5da9c > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-25 (Tue, 25 Oct 2016) > > Changed paths: > M fvwm/cmdparser.h > M fvwm/cmdparser_old.c > M fvwm/functions.c > > Log Message: > --- > add debug output and fix positional arguments > > > Commit: 4deefa9510ef6da3ca9d2e4d1a90aa59785e4a74 > > https://github.com/fvwmorg/fvwm/commit/4deefa9510ef6da3ca9d2e4d1a90aa59785e4a74 > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-25 (Tue, 25 Oct 2016) > > Changed paths: > M fvwm/cmdparser_old.c > M fvwm/functions.c > > Log Message: > --- > add debug output and fix command line prefixes > > > Commit: 7f357808de11b36d40f86c1d5731597036df56f3 > > https://github.com/fvwmorg/fvwm/commit/7f357808de11b36d40f86c1d5731597036df56f3 > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-25 (Tue, 25 Oct 2016) > > Changed paths: > M fvwm/Makefile.am > M fvwm/cmdparser.h > A fvwm/cmdparser_hooks.h > M fvwm/cmdparser_old.c > M fvwm/conditional.h > M fvwm/functable.c > M fvwm/functable.h > A fvwm/functable_complex.c > A fvwm/functable_complex.h > M fvwm/functions.c > M fvwm/functions.h > M fvwm/fvwm.h > M fvwm/misc.c > M fvwm/repeat.c > M fvwm/screen.h > M libs/FScreen.h > > Log Message: > --- > Convert special logic in __execute_command_line for functions ... > > ... that may move a window to a separate function flag. > > Move find_builtin_function() to functable.[ch]. > > Moved some functions to functable.[ch] and functable_complex.[ch]. > > This separation is needed for the parsing hooks. It was very difficult to get > the #icludes right. The DesktopsInfo structure was moved to libs/FScreen.h > so that the library does not depend on core header files anymore. > > Move WindowConditionMask from mvwm.h to conditional.h. > > Finish 1st draft of hook implementation (__execute_command_line) > > > Commit: 5f747ebc65614dd91906bb8bfbcf7f73452fa7ec > > https://github.com/fvwmorg/fvwm/commit/5f747ebc65614dd91906bb8bfbcf7f73452fa7ec > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-25 (Tue, 25 Oct 2016) > > Changed paths: > M fvwm/cmdparser.h > M fvwm/cmdparser_hooks.h > M fvwm/cmdparser_old.c > M fvwm/expand.c > M fvwm/functions.c > > Log Message: > --- > Split pos_args into a string with all positional args and an array. > > > Commit: 6c1872dd38731d9a5a8f42bcfa5a2b36f5b73149 > > https://github.com/fvwmorg/fvwm/commit/6c1872dd38731d9a5a8f42bcfa5a2b36f5b73149 > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10
Re: Black screen and fallback config with master
On Tue, Oct 25, 2016 at 10:03:49PM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 09:46:48PM +0100, Dominik Vogt wrote: > > On Tue, Oct 25, 2016 at 07:20:11PM +0100, Dominik Vogt wrote: > > > With the current master, my configuration file is not used anymore > > > (no error message) All I get is a black screen with the builtin > > > menu. > > > > It looks like > > > > ModulePath +:$HOME/bin > > > > is broken. With this line it does not find FvwmCpp anymore > > > > -fvwm -d "$DISPLAY" -cmd "FvwmCpp -I$HOME -DHOMEDIR=$HOME > > $HOME/.fvwm/.fvwm2rc" > > Do you get a corefile? I can't get fvwm to crash or segfault when I mess with > defining ModulePath, but I don't use FvwmCpp either. No, it doesn't crash, it just starts without a config. I've tried to bisect it, and at master~11 it started to work again, and now I'm unable to reproduce the effect. Maybe configure just got confused becuase of the switching between master and dv/stable-fvwm2? I'll watch this and try to pin it down if it reappears. Maybe "fvwm --version" should print the builtin paths. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Black screen and fallback config with master
On Tue, Oct 25, 2016 at 07:20:11PM +0100, Dominik Vogt wrote: > With the current master, my configuration file is not used anymore > (no error message) All I get is a black screen with the builtin > menu. It looks like ModulePath +:$HOME/bin is broken. With this line it does not find FvwmCpp anymore -fvwm -d "$DISPLAY" -cmd "FvwmCpp -I$HOME -DHOMEDIR=$HOME $HOME/.fvwm/.fvwm2rc" Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 0c5211: Expose: don't flush accumulated events
On Tue, Oct 25, 2016 at 02:39:36AM +0100, Dominik Vogt wrote: > On Tue, Oct 25, 2016 at 01:59:46AM +0100, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 01:42:58AM +0100, Thomas Adam wrote: > > > On Tue, Oct 25, 2016 at 01:34:57AM +0100, Dominik Vogt wrote: > > > > I fear this commit is too disruptive. Aggregating Expose events > > > > is very important to deal with race conditions cause by > > > > applications doing crazy stuff. Is there some explanation of the > > > > problem that was fixed with this commit? I'd like to revisit it > > > > and see what needs to be done with the aggregation code to fix it > > > > without completely removing it. Probably it just needs to stop > > > > aggregating more often. > > > > > > It was to do with icons not being redrawn with moving one icon over > > > another > > > when using ParentRelative (transparent icons). The icons would leave > > > artefacts and never refresh. > > > > > > I can't find the original thread in the archives but I know there is one. > > > > Because it was posted on GH. Here's the issue: > > > > https://github.com/fvwmorg/fvwm/issues/11 > > > > That's all the information you'll need. > > Thanks. I'll take a look at the bug. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Mon, Oct 24, 2016 at 09:59:56PM +0100, Dominik Vogt wrote: > On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote: > > On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote: > ... > > > Can you please try out the branch "dv/fix-cr-merging" tha I've > > > just pushed and see if the fix works for you? (For me, it does.) > > > > And it does for me. > > I've overwritten the branch with a new, hopefully portable version > of the patch. Can you please try it again? The fix is on master now, but master is broken at the moment. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Black screen and fallback config with master
With the current master, my configuration file is not used anymore (no error message) All I get is a black screen with the builtin menu. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Excluding files from Travis-CI
Is it possible to exclude commits that only touch files like TODO.md or .gitignore from requiring a build before they can be pushed to master? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 0c5211: Expose: don't flush accumulated events
On Tue, Oct 25, 2016 at 01:59:46AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 01:42:58AM +0100, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 01:34:57AM +0100, Dominik Vogt wrote: > > > I fear this commit is too disruptive. Aggregating Expose events > > > is very important to deal with race conditions cause by > > > applications doing crazy stuff. Is there some explanation of the > > > problem that was fixed with this commit? I'd like to revisit it > > > and see what needs to be done with the aggregation code to fix it > > > without completely removing it. Probably it just needs to stop > > > aggregating more often. > > > > It was to do with icons not being redrawn with moving one icon over another > > when using ParentRelative (transparent icons). The icons would leave > > artefacts and never refresh. > > > > I can't find the original thread in the archives but I know there is one. > > Because it was posted on GH. Here's the issue: > > https://github.com/fvwmorg/fvwm/issues/11 > > That's all the information you'll need. Thanks. I'll take a look at the bug. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:38:17AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > > > I wouldn't bother with this point---fvwm3 should be a separate repository > > > entirely. > > > > Why? Unless some people step up and tell us they'd want to take > > over fvwm2 development, what is the gain of duplicating all > > infrastructure? > > You're assuming fvwm3 is based off fvwm2 for anything. Whilst that might be > true for somethings, I think that should be the exception rather than the > rule. I was serious in my proposal to make fvwm3 a clean break, and it should > be that in its entirety including its own repository. That leaves much room for interpretation. A "clean break" to me would mean to write it from scratch, and that's practically impossible because the fvwm2 window managing code contains many hundreds of hours undocumented experience with strange applications and optimising communication with the X server. Well, my plan for fvwm3 has always been to make changes to fvwm2 to be able to do things that are not possible with todays code. For example, styles that can be attached to window states or even more complex conditions. One thing that gets in the way of lots of future work is the terrible parser and backwards compatibility of the syntax. I also want to see FvwmButtons being replaced by something flexible, configurable at run time and useable. I have no intention of removing _useful_ features because the code looks ugly. > I question what "infrastructure" might be needed from fvwm2 that would mean > using it as a basis. Developers, repository, webspace. > > That would be good (I'm assuming that you mean just #3). Give me > > some time to organise the fvwm2-stable branch (suggestions for a > > better name welcome maybe "stable-fvwm2"). > > Yes, I was just referring to point #3; let me know when that's good to be > done. As soon as we know that nothing important is missing from dv/stable-fvwm2. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 8e9804: configure.ac: appease CLANG
On Mon, Oct 24, 2016 at 05:24:07PM -0700, GitHub wrote: > Branch: refs/heads/dv/stable-fvwm2 > Home: https://github.com/fvwmorg/fvwm > Commit: 8e9804aa79e6dcba040ab1e4cb6e6e56fae6c5e4 > > https://github.com/fvwmorg/fvwm/commit/8e9804aa79e6dcba040ab1e4cb6e6e56fae6c5e4 > Author: Thomas Adam <tho...@fvwm.org> > Date: 2016-10-25 (Tue, 25 Oct 2016) This is the candidate for the stable-fvwm2 branch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 0c5211: Expose: don't flush accumulated events
On Sat, Aug 06, 2016 at 01:09:23AM -0700, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/fvwmorg/fvwm > Commit: 0c5211e20940cd8dc811753c83118107d6964c8c > > https://github.com/fvwmorg/fvwm/commit/0c5211e20940cd8dc811753c83118107d6964c8c > Author: Thomas Adam <tho...@fvwm.org> > Date: 2016-08-06 (Sat, 06 Aug 2016) > > Changed paths: > M fvwm/events.c > M fvwm/icons.c > M fvwm/menus.c > > Log Message: > --- > Expose: don't flush accumulated events > > When dealing with Expose events, don't ever flush the accumulated ones; the > handling of the queue here is incorrect, and ultimately gets addressed during > other operations. > > This should help fix the problem of ParentRelative icon pixmaps from > corrupting other icons, etc. > > > Commit: f51d113bf456d23fedbad73145d9c4f05d097bb8 > > https://github.com/fvwmorg/fvwm/commit/f51d113bf456d23fedbad73145d9c4f05d097bb8 > Author: Thomas Adam <tho...@fvwm.org> > Date: 2016-08-06 (Sat, 06 Aug 2016) > > Changed paths: > M fvwm/events.c > M fvwm/icons.c > M fvwm/menus.c I fear this commit is too disruptive. Aggregating Expose events is very important to deal with race conditions cause by applications doing crazy stuff. Is there some explanation of the problem that was fixed with this commit? I'd like to revisit it and see what needs to be done with the aggregation code to fix it without completely removing it. Probably it just needs to stop aggregating more often. This code is actually the result of many hours dealing with totally broken applications and trying to keek fvwm responsive even when flooded with all kinds of stupid events. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Tue, Oct 25, 2016 at 01:08:21AM +0100, Dominik Vogt wrote: > On Tue, Oct 25, 2016 at 12:53:44AM +0100, Thomas Adam wrote: > > On Tue, Oct 25, 2016 at 12:48:01AM +0100, Dominik Vogt wrote: > > > Okay, then how about this: > > > > > > 1. Start a branch fvwm2-stable at 2.6.6 and document it as the > > >long term stable branch. > > > > OK. > > > > > 2. Backport fixes and functional changes from master. > > > > OK. (Which, and why?) > > Obviously at least the fix I've just made to FEvent.c as it was > introduced in 2.6.6 and breaks things really badly. The fix for > the hang in FvwmButtons is another likely candidate. There are > only a few interesting commits. Possibly the things you mentioned > in NEWS, which sound all like small changes. > > > > 3. Release 2.6.7 on this branch with a proper announcement. > > > > OK. > > > > > 4. Release 2.9.0* on master and announce it as the release > > >starting future development towards fvwm3. > > > > I wouldn't bother with this point---fvwm3 should be a separate repository > > entirely. > > Why? Unless some people step up and tell us they'd want to take > over fvwm2 development, what is the gain of duplicating all > infrastructure? > > Well, at the moment the only interesting issue is how to name the > release tags. I'd prefer a naming scheme like 3.-1.x, but the > tools will probably not like this. :-) > > > > I can take care of 1 and 2 but need some help with 3 because I've > > > never done a release using the new infrastructure. > > > > I can take care of that if you like? > > That would be good (I'm assuming that you mean just #3). Give me > some time to organise the fvwm2-stable branch (suggestions for a > better name welcome maybe "stable-fvwm2"). The branch dv/stable-fvwm2 is up for review. Collecting the patches was a piece of cake. Just one conflict with the NEWS file. The branch builds fine for me, without warnings, and I'm using it now for work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Tue, Oct 25, 2016 at 12:53:44AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 12:48:01AM +0100, Dominik Vogt wrote: > > Okay, then how about this: > > > > 1. Start a branch fvwm2-stable at 2.6.6 and document it as the > >long term stable branch. > > OK. > > > 2. Backport fixes and functional changes from master. > > OK. (Which, and why?) Obviously at least the fix I've just made to FEvent.c as it was introduced in 2.6.6 and breaks things really badly. The fix for the hang in FvwmButtons is another likely candidate. There are only a few interesting commits. Possibly the things you mentioned in NEWS, which sound all like small changes. > > 3. Release 2.6.7 on this branch with a proper announcement. > > OK. > > > 4. Release 2.9.0* on master and announce it as the release > >starting future development towards fvwm3. > > I wouldn't bother with this point---fvwm3 should be a separate repository > entirely. Why? Unless some people step up and tell us they'd want to take over fvwm2 development, what is the gain of duplicating all infrastructure? Well, at the moment the only interesting issue is how to name the release tags. I'd prefer a naming scheme like 3.-1.x, but the tools will probably not like this. :-) > > I can take care of 1 and 2 but need some help with 3 because I've > > never done a release using the new infrastructure. > > I can take care of that if you like? That would be good (I'm assuming that you mean just #3). Give me some time to organise the fvwm2-stable branch (suggestions for a better name welcome maybe "stable-fvwm2"). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Need of a "devel" branch?
On Sun, Oct 23, 2016 at 12:23:45AM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 11:41:54PM +0100, Dominik Vogt wrote: > > Unless we're doing lots of disruptive stuff I'd prefer to > > propagate completed patchsets into master early so they get more > > testing. > > Yup. Well, that's what we have enforced right now, so I think it's working as > intended. Of course, during development on a given feature, there's nothing > stopping a few developers working against a common topic integration branch of > their own, which is then used as the topic-branch for review before it hits > master. I suspect we'll never get there though, given the low number of > developers, alas. Let's just watch how things work for a while and then see if its necessary or not. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
On Tue, Oct 25, 2016 at 12:27:40AM +0100, Thomas Adam wrote: > On Tue, Oct 25, 2016 at 12:23:54AM +0100, Dominik Vogt wrote: > > On Mon, Oct 24, 2016 at 11:54:00PM +0100, Thomas Adam wrote: > > > On Mon, Oct 24, 2016 at 10:29:30PM +0100, Dominik Vogt wrote: > > > > ... but in a separate commit please. Patching the NEWS file in > > > > the same commit as the code change makes bug hunting and reverting > > > > patches more difficult. > > > > > > Maybe, but how often does that really happen? > > > > It actually happens all the time when you want to reshuffle or > > revert commits with NEWS entries. The was worse with the > > ChangeLog. In CVS you wouldn't notice this often becaus you > > couldn't rebase anything, but in Git its quite annyoing to my > > experience. > > Hmm. But then you'll also have to explicitly identify the other stuff in NEWS > as well. Ah, I dunno---maybe it's not such a problem, but I think trying to > enforce this going to be hard. It's not something I'll necessarily remember > to follow. I've made a habit of using "git add -i" to sort the pending changes into series of small commits so I won't accidentally changes that I don't want to (like debug printfs and accidental formatting changes). If I keep NEWS and ChangeLog changes and the like in the commits that actually so the real work, I always get conflicts when rebasing stuff, so keeping it separately comes with lazyness. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Mon, Oct 24, 2016 at 11:52:03PM +0100, Thomas Adam wrote: > On Mon, Oct 24, 2016 at 11:24:58PM +0100, Dominik Vogt wrote: > > How about a compromise: Leave the code in, but announce that > > these features are deprecated and will not be maintained anymore. > > So, if any people still use some of them (FvwmTheme, FvwmWinList, > > FvwmTaskBar and GNOME support being the most liekely), they can > > still use the code as it is. If any problems arise with these > > features, all we'll do is providing information on replacing the > > features. > > That's OK. I'm done with it anyway; I've put a lot of effort into dragging > FVWM out from its hiding place; improving it in the best way I could. I'm > actually proud to leave it in the state that's in in now---in the last six > months of effort I've spent putting into this, I've yet to have anyone tell me > that they'd miss these things, or that they're actually used. Really, this is not about people who are interested in new fvwm development or who are simply content with what fvwm2 does now. It's only a service for people running obscure boxes with configurations maybe a ten years old kiosk system config who need an important fix. > But maybe you know different, in which case you're more than free to go ahead > with this > ---but know that I find it rather insulting to think that my efforts > have been largely ignored on the idea that the small minority of users might > be inconvenienced by these changes. Your efforts are *not* ignored. All these removals are good; the only thing I fell a bit uneasy about is removing GNOME support because I've seen so many funny commercial applications that use wild sets of GNOME/ICCCM2/EWMH hints, and these are notorius to be still broken ten years after a bug was found. > I just don't think that's true at all. > Trying to rearrange things is madness---and I won't have master rebased > because of that. That's not how this works, and I'm not hearing a good reason > for this at all. Actually, another way is to make an fvwm2-stable branch from 2.6.6 and backport the fixes from master. That's not much of an effort either, only that the ChangeLog entries will be missing for some of them. > If we're leaving 2.6 behind, we should do that by releasing master as 2.6.7 > and calling it a day. If people want something so badly, then they can use > 2.6.6 and do whatever ontop of it. Okay, then how about this: 1. Start a branch fvwm2-stable at 2.6.6 and document it as the long term stable branch. 2. Backport fixes and functional changes from master. 3. Release 2.6.7 on this branch with a proper announcement. 4. Release 2.9.0* on master and announce it as the release starting future development towards fvwm3. I can take care of 1 and 2 but need some help with 3 because I've never done a release using the new infrastructure. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
On Mon, Oct 24, 2016 at 11:54:00PM +0100, Thomas Adam wrote: > On Mon, Oct 24, 2016 at 10:29:30PM +0100, Dominik Vogt wrote: > > ... but in a separate commit please. Patching the NEWS file in > > the same commit as the code change makes bug hunting and reverting > > patches more difficult. > > Maybe, but how often does that really happen? It actually happens all the time when you want to reshuffle or revert commits with NEWS entries. The was worse with the ChangeLog. In CVS you wouldn't notice this often becaus you couldn't rebase anything, but in Git its quite annyoing to my experience. > The problem with making NEWS > file special somehow is going to cause problems with git-bisect because you'd > be forever skipping over commits. The worst that can happen is that you have twice as many commits, i.e. one bisect step more that usual. But actually NEWS commits are quite rare. Most of the changes don't make it into the NEWS file. So, yes, sometimes you'll have one more bisect step, but that's maybe an extra three minutes or so. I wouldn't worry about that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sun, Oct 23, 2016 at 11:50:48AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 11:46:23AM +0100, Dominik Vogt wrote: > > The old stable branch should provide important fixes for people > > who use old versions, and that includes not taking away stuff from > > them, no? The idea is that people who have some good (but rare) > > reason to stick with the old version can continue doing so. > > > > > Given all of this, I think it's safe to do this. I have heard nothing > > > from > > > anyone in recent years who are using the above, and/or who haven't already > > > migrated to FvwmButtons or FvwmTaskbar for the most part. > > > > But actually these removals are only half a year old and are not > > part of any release yet. > > So this work is going towards that next release. If you were to forget about > 2.6.7 being the last release of fvwm2 before we move away to pastures new, > then this work is simply another iteration on improving fvwm2. This is where > I want to leave fvwm2, in a known good state, by removing all the things I've > mentioned. It means the user can actually use something which is "current", > and more maintainable, and it also means that any maintenance work needed is > reduced in scope because there's less things to worry about. How about a compromise: Leave the code in, but announce that these features are deprecated and will not be maintained anymore. So, if any people still use some of them (FvwmTheme, FvwmWinList, FvwmTaskBar and GNOME support being the most liekely), they can still use the code as it is. If any problems arise with these features, all we'll do is providing information on replacing the features. I understand your wish to leave fvwm2 in a clean, maintainable state but think that leaving it as compatible as possible is more important here so that people can keep using the feature set they are used to. Remember that we're not making the long term stable release to win a beaty contest but to make the transition for the users as painless as possible. Anyway, leaving the modules in won't cause anybody any pain. The only thing that is potentially problematic regarding maintenance is GNOME support (and removing it may be problematic too because there are (mostly commercial) applications out in the wild that still use it). After this one time cut were free to conclusively remove any old features and never look back. With just a little more work (a few hours), adding the removal patches right after the release is just a matter of glueing the release label to the right commit. Reshuffling the commits is quite easy (see dv/master-late-deletes branch), and the commit before the removal patches still builds fine. It's just a bit more work to figure out what to do with NEWS and INSTALL.fvwm. The only thing that's not nice is that the master needs to be rebased once. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] acd886: Infostore: persist on restart
On Mon, Oct 24, 2016 at 03:02:11PM -0700, GitHub wrote: > Branch: refs/heads/dv/master-late-deletes Forget about what the commit mail says. This branch is an attempt to resort the patches after 2.6.6 so that the patches removing features come last. It mostly works out of the box, except for conflicts in the documentation files NEWS and INSTALL.fvwm. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
On Sun, Oct 23, 2016 at 02:46:46AM +0100, Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 06:32:12PM -0700, GitHub wrote: > > Branch: refs/heads/ta/reluctant-news > > Home: https://github.com/fvwmorg/fvwm > > Commit: 64d4244746754610a64ed35de9ca69e557d3e25a > > > > https://github.com/fvwmorg/fvwm/commit/64d4244746754610a64ed35de9ca69e557d3e25a > > Author: Thomas Adam <tho...@xteddy.org> > > Date: 2016-10-23 (Sun, 23 Oct 2016) > > > > Changed paths: > > M docs/DEVELOPERS.md > > > > Log Message: > > --- > > DEVELOPERS: mention NEWS file > > Thanks. > > > Let's try and get patches which introduce changes to also include changes to > > the NEWS file. ... but in a separate commit please. Patching the NEWS file in the same commit as the code change makes bug hunting and reverting patches more difficult. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 11:39:14AM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 13:25 (+0100), Dominik Vogt wrote: ... > > Can you please try out the branch "dv/fix-cr-merging" tha I've > > just pushed and see if the fix works for you? (For me, it does.) > > And it does for me. I've overwritten the branch with a new, hopefully portable version of the patch. Can you please try it again? > What is slightly weird is that if I have the acroread window wholly > contained on my laptop screen and go into full screen, the window > warps over to the external monitor. Is that something new or has it always been this way? I'll have a look at how acroread actually does the transition to fullscreen mode. Maybe it's doing something differently. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 04:10:25PM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 04:05:03PM +0100, Dominik Vogt wrote: > > I never can remember this; is it safe (in C) to assume that > > negative integers are stored in two-complement format? (Of course > > the old code makes the same assumtion, but it's broken and I want > > to fix it.) > > It is not safe to make the assumption that negative integers are stored as > twos-compliment. C99 does not mandate whether that will be in > twos-compliment, or ones-compliment. Although most hardware will typically > (in my experience) used twos-compliment, that's no guarantee. > > So it's not portable; casting the values is the way to go. Ah, the autoconf manual has some information in stdint.h: 5.6.1 Portability of Headers ... inttypes.h vs. stdint.h The C99 standard says that inttypes.h includes stdint.h, so there's no need to include stdint.h separately in a standard environment. Some implementations have inttypes.h but not stdint.h (e.g., Solaris 7), but we don't know of any implementation that has stdint.h but not inttypes.h. As far as I remember there was also an issue that inttypes.h does not include stdint.h on all platforms, so we need configure tests for both headers. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 04:39:53PM +0200, Viktor Griph wrote:
> Den 23 okt. 2016 14:36 skrev "Dominik Vogt" <dominik.v...@gmx.de>:
> > void fev_sanitise_configure_request(XConfigureRequestEvent *cr)
> > {
> > if (cr->value_mask & CWX)
> > {
> > cr->x = (((int)cr->x) & 0x);
> > }
> > ...
> > if (cr->value_mask & CWHeight)
> > {
> > cr->height = (((unsigned int)cr->height) &
> 0x);
> > }
> > ...
> > }
> >
> > This tries to deal with an inconsistency between the X protocol
> > and the Xlib structures: In the X protocol, in the
> > ConfirureWindow request, X and Y are signed "INT16" quantities and
> > WIDTH and HEIGT are unsigned "CARD16" quantities, while in the
> > Xlib structures they are "int" or "unsigned int".
> >
> > The code tries to cut off the excess bits from X and Y and does it
> > wrong. With 32-bit integers, if cr->x is -1:
> >
> > ((int)-1) & 0x = 0x & 0x
> > = 0x
> > = 65535
> >
> > I'm not sure how to fix this. The easiest approach would be to
> > cast these values to int16_t or uint16_t from stdint.h, but I
> > vaguely remember there are some portability issues with the
> > inttypes.s/stdint.h headers.
>
> Instead of setting the excess bits to 0 we need to set them to 1 for the
> negative case.
>
> What about
> if (cr->x & 0x8000)
> {
> cr->x = (((int)-1) ^ 0x7fff) | (((int)cr->x) & 0x7fff);
> }
> else
> {
> cr->x = (((int)cr->x) & 0x);
> }
>
> The negative case could be simplified to
>
> (((int)-1) ^ 0x7fff) | ((int)cr->x)
>
> Or
>
> ((int)-1)<<16|((int)cr->x)
I never can remember this; is it safe (in C) to assume that
negative integers are stored in two-complement format? (Of course
the old code makes the same assumtion, but it's broken and I want
to fix it.)
If it's really portable, the cleanest way is casting to int16_t
and uint16_t from stdint.h.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > > > On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > >> I cloned the git version about 15 minutes ago and compiled it, and > >> acroread still does not go full-screen correctly. > > > Can you reproduce this using a more accessible program, please? I'm using > > FreeBSD. > > No, I can't. That is, all other programs I use which have a > "full-screen" mode work fine. Can you please try out the branch "dv/fix-cr-merging" tha I've just pushed and see if the fix works for you? (For me, it does.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sun, Oct 23, 2016 at 11:51:52AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 11:13:59AM +0100, Dominik Vogt wrote: > > I'm now trying to identify the commit with which this strange > > placement started. Do you know of any other commit ids or dates > > between 2.6.5 and 2.6.6 that were definitely fine or broken? > > Whoever ends up doing this, should use git-bisect to ascertain how I broke > this. ;P Don't panic, it's one of my commits. 9e08db937a873943721f247e3ddfaed358faa143 Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sun, Oct 23, 2016 at 03:22:08AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 03:12:19AM +0100, Dominik Vogt wrote: > > On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > > > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will > > > be > > > the last stable/supported version. Up to this point I've installed all > > > optional libraries and fixed all the warnings for the versions I have > > > available (FreeBSD) -- so that's something. I think it's in a good state > > > to > > > be left behind, and allowing it to receive minor fixes, etc. > > > > Hm, is it actually a good idea to remove half the modules and > > GNOME hints support in the last stable fvwm2 release? Could the > > commits be rearranged so that this stuff stays in 2.6.7 and is > > removed immediately after that? > > > > Or maybe start the long term stable branch at 2.6.6 and > > cherry-pick only the patches that add something from master. > > Hmm. Why? I'm *not* against removal of anything on that list. It's just very inconsinstent if we announce "2.6.7 is the last long time stable version of fvwm2, and after that release we start rewriting stuff from scratch and remove old things" and then actually start removing things in 2.6.7. The old stable branch should provide important fixes for people who use old versions, and that includes not taking away stuff from them, no? The idea is that people who have some good (but rare) reason to stick with the old version can continue doing so. > Given all of this, I think it's safe to do this. I have heard nothing from > anyone in recent years who are using the above, and/or who haven't already > migrated to FvwmButtons or FvwmTaskbar for the most part. But actually these removals are only half a year old and are not part of any release yet. > As for GNOME hints support -- that's reduced code, and isn't used in the wild > at all. Good for me, I hate that code. > Should enough people complain loudly enough, sure, I might add it back in, but > I really don't think they will. So I still think going ahead with 2.6.7 in > this state--whereby we've made the best effort to leave it with *useful* stuff > that we then don't have to fix in the future, can only been a good thing. All I care is having a base for long term maintenance without breaking things. I'd even be fine to release 2.6.7 as the last old stable release without the removals and 2.7.0 adding them back on the same day. (But first this acroread issue needs to be resolved.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. Hm, is it actually a good idea to remove half the modules and GNOME hints support in the last stable fvwm2 release? Could the commits be rearranged so that this stuff stays in 2.6.7 and is removed immediately after that? Or maybe start the long term stable branch at 2.6.6 and cherry-pick only the patches that add something from master. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 58d1a6: NEWS: formatting tweaks
On Sat, Oct 22, 2016 at 06:42:08PM -0700, GitHub wrote:
> Branch: refs/heads/ta/reluctant-news
> Home: https://github.com/fvwmorg/fvwm
> Commit: 58d1a64671c12e93554dd48e6112f6c6e0d921ed
>
> https://github.com/fvwmorg/fvwm/commit/58d1a64671c12e93554dd48e6112f6c6e0d921ed
> Author: Thomas Adam <tho...@xteddy.org>
> Date: 2016-10-23 (Sun, 23 Oct 2016)
>
> Changed paths:
> M NEWS
>
> Log Message:
> ---
> NEWS: formatting tweaks
I had always used an Xemacs highlighting mode for the NEWS file
(to highlight formatting inconsistencies). If we make format
changes, it needs to be adapted. Anyway, it may be useful to
others, and it might even be put in the git repo. (attached)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
;; NEWS file Major Mode for XEmacs (draft)
;
; (C) 2004 Dominik Vogt <dominik.v...@gmx.de>
; This program is free software; you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation; either version 2 of the License, or
; (at your option) any later version.
;
; This program is distributed in the hope that it will be useful,
; but WITHOUT ANY WARRANTY; without even the implied warranty of
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
; GNU General Public License for more details.
;
; You should have received a copy of the GNU General Public License
; along with this program; if not, write to the Free Software
; Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
; Note: The major mode was designed for xemacs and may or may not work with
; plain emacs.
;
; Copy this file to a lisp library directory, for example
; /usr/share/xemacs/site-lisp or $HOME/share/xemacs/site-lisp
; To acticate put this line in your xemacs configuration file:
;
; (load-library "news-file.el")
;
; or
;
; (load-library "/news-file.el")
;; basic mode setup
; option group
(defgroup news-file nil
"NEWS file mode."
:tag "NEWS file"
:group 'wp)
; mode hook
(defcustom news-file-mode-hook
nil
"Hook to be run when `news-file-mode' is entered."
:type 'hook
:group 'news-file)
;!!!how do you do this the right way?
(add-hook 'news-file-mode-hook (lambda () (setq fill-column 66)))
(add-hook 'news-file-mode-hook 'auto-fill-mode)
; mode map
(defvar news-file-mode-map ()
"Keymap used in `news-file-mode' buffers.")
(if news-file-mode-map
()
(setq myws-mode-map (make-sparse-keymap))
;; So far there aren't any news-file-mode specific functions
)
; auto mode definition
(add-to-list 'auto-mode-alist '("O*NEWS$" . news-file-mode))
;; syntax highlighting
(defconst news-file-font-lock-keywords
(list
; complain about tabs
'(" " . highlight)
; separator
'("^--*$" . font-lock-keyword-face)
; title + date
'("^\\(Changes in \\)\\(.*\\)$" (1 font-lock-keyword-face t) (2 highlight t
t))
'("^Changes in \\(alpha\\|beta\\|official\\|stable\\|development\\).*$" 1
font-lock-variable-name-face t)
'("^Changes in [a-z]*\\( release \\).*$" 1 font-lock-keyword-face t)
'("^Changes in [a-z]* release \\([0-9]+\\(\\.[0-9]+\\)*\\).*$" (1
font-lock-variable-name-face t t))
'("^Changes in [a-z]* release [0-9.]*\\( (\\).*$" 1 font-lock-keyword-face t)
'("^Changes in [a-z]* release [0-9.]*\\(
(\\)\\(\\([0-9][0-9]?-\\(Jan\\|Feb\\|Mar\\|Apr\\|May\\|Jun\\|Jul\\|Aug\\|Sep\\|Oct\\|Nov\\|Dec\\)-[1-9][0-9][0-9][0-9][0-9]*\\)\\|\\(not
released yet\\)\\)).*$" (1 font-lock-keyword-face t) (2
font-lock-variable-name-face t t))
'("^Changes in [a-z]* release [0-9.]* ([-a-z0-9 ]*\\()\\).*$" 1
font-lock-keyword-face t)
; section
'("^\\(\\* \\)?[a-z][ a-z]*[a-z]:$" . font-lock-preprocessor-face)
; bullets
'("^\\(\\* \\).*$" 1 font-lock-keyword-face)
'("^\\( +- \\).*$" 1 font-lock-keyword-face)
; faulty lines
'("^[^ \n].*[^:]$" . highlight)
'("^.$" . highlight)
)
"Minimal highlighting expressions for NEWS file mode")
(defun news-file-mode ()
"Major mode for editing NEWS files"
(interactive)
(kill-all-local-variables)
(use-local-map news-file-mode-map)
(setq major-mode 'news-file-mode)
(setq mode-name "NEWS file")
(set (make-local-variable 'font-lock-defaults)
'(news-file-font-lock-keywords nil t))
(run-hooks 'news-file-mode-hook)
)
(provide 'news-file-mode)
Re: [fvwmorg/fvwm] 64d424: DEVELOPERS: mention NEWS file
On Sat, Oct 22, 2016 at 06:32:12PM -0700, GitHub wrote: > Branch: refs/heads/ta/reluctant-news > Home: https://github.com/fvwmorg/fvwm > Commit: 64d4244746754610a64ed35de9ca69e557d3e25a > > https://github.com/fvwmorg/fvwm/commit/64d4244746754610a64ed35de9ca69e557d3e25a > Author: Thomas Adam <tho...@xteddy.org> > Date: 2016-10-23 (Sun, 23 Oct 2016) > > Changed paths: > M docs/DEVELOPERS.md > > Log Message: > --- > DEVELOPERS: mention NEWS file Thanks. > Let's try and get patches which introduce changes to also include changes to > the NEWS file. That's what I've always done (for user visible changes or internal changes with a high risk of breaking things). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
As a little bit of explanation how to read this output: On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote: > cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'Adobe Reader' ^^^ ^^^ ^^^ ^^ X Y Width HeightInternal window id These are the values from the COnfigureRequest, i.e. the message that was generated when the application tried to change the window geometry. If the number is parentheses after the value if zero, that bit of information is unused, if it's non-zero, that part of the geometry was requested. This request looks sensible, and from that I guess your screen is 1920x1080 pixels (16:9). > cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' "Move window to +0+0 and resize to 3276x1048" The width looks weird. > cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Similar, but some decorations seem to have been taken into account. From the requested height I assume your window window border is 5 pixels thick and the window title is 22 pixels high. > cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew > 0x06200031 'zshguide.pdf - Adobe Reader' ^^ The program has added space for another border around the window by subtracting some pixels from X and Y and adding some to Width and Height. The coordinates have become negative, but the program seems to store them as "unsigned short", not as signed int as it should. So it gets a wraparound and requests some astronomically huge coordinates (which the X server limits to 16 bits again). > cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' "Resize window (without actually changing its size) > cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Back to the original size with what looks like random coordinates: 1433/18. So, is this what you see, a window starting at X=1433 with a page that is about 3300 pixels wide? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:55:38AM +0100, Dominik Vogt wrote: > On Sun, Oct 23, 2016 at 01:32:17AM +0100, Thomas Adam wrote: > > On Sun, Oct 23, 2016 at 01:28:17AM +0100, Dominik Vogt wrote: > > > On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > > > > Branch: refs/heads/ta/install > > > > Home: https://github.com/fvwmorg/fvwm > > > > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > > > > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > Author: Thomas Adam <tho...@fvwm.org> > > > > Date: 2016-08-11 (Thu, 11 Aug 2016) > > > > > > > > Changed paths: > > > > R ChangeLog > > > > R ChangeLog-pre-2.4 > > > > R ChangeLog-pre-2.6.6 > > > > R NEWS > > > > > > Hm, what's the logic behind removing the NEWS file? Is it > > > somewhere else now? > > > > It's mostly here: http://fvwm.org/features/ (because stuff hasn't changed), > > > and its successor will be release notes for the next version on Github > > anyway. > > Okay, and where is the source for the release notes? This needs > to be kept in the fvwm source tree. I don't see me writing up any > decent quality release notes, say, half a year after committing a > patch. This stuff needs to be written down when the work is done, > not at some indefinite time in the future. > > (I see fvwm more as a GNU style project rather than a Github style > project. Using features of git or Github is fine, but I don't > think we should give up the GNU project standards, where > applicable: https://www.gnu.org/prep/standards/standards.txt Specifically, it won't cost much to to stick to the following: 3.5 Conditional Compilation 4.4 Formatting Error Messages -> future work 4.5 Standards for Interfaces Generally 4.6 Standards for Graphical Interfaces 4.7 Standards for Command Line Interfaces 4.8 Standards for Dynamic Plug-in Interfaces 4.9 Table of Long Options 5.5 Portability between System Types 5.6 Portability between CPUs 5.7 Calling System Functions 5.8 Internationalization 5.9 Character Set 5.10 Quote Characters 6.7 The NEWS File 6.8 Change Logs -> now kept in Git 6.9 Man Pages 7.1 How Configuration Should Work 7.2 Makefile Conventions Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 10:00:16PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote: > > > On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: > >> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > > >>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > >>>> I cloned the git version about 15 minutes ago and compiled it, and > >>>> acroread still does not go full-screen correctly. > > >>> Can you reproduce this using a more accessible program, please? I'm using > >>> FreeBSD. > > >> No, I can't. That is, all other programs I use which have a > >> "full-screen" mode work fine. > > > All right, I can see that acroread generates some weird requests > > for new size and position. For me, the size is good, but the > > position is totally screwed (x=65600, y=66000). > > > In fvwm/events.c at line 1077 there is this debug statement: > > > #if 0 > > fprintf(stderr, > > "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " > > ... > > #endif > > > Can you please replace the "#if 0" with "#if 1", rebuild and post > > the output that going fullscreen causes on the console? (Don't > > move or resize any windows when doing this to reduce the amount of > > output.) Also, please add this line to the fvwm config file (or > > type it in FvwmConsole before starting acroread) > > > bugopts explainwindowplacement > > > This will produce some more output that may be helpful. > > I trust this is what you were looking for? > > cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201 > 'stalonetray' > [fvwm][__execute_function]: <> No such command 'explainwindowplacement' The command is bugopts explainwindowplacement > cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'Adobe Reader' > cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b > 'acroread' > cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew > 0x06200031 'zshguide.pdf - Adobe Reader' > cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' > cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899 > 'acroread' > cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 > 'zshguide.pdf - Adobe Reader' Uh, even stranger than on my box. > Anything else I can provide? Yes, a couple of things please: 1. What size are your pages, and how many pages do you use on the desktop? On which page do you do this? Do you have FvwmPager running and can see more of the window on other pages? If you have multiple monitors, please describe the geometry of this setup (coordinates and size of each monitor and on which one you expect the fullscreen window to appear). 2. Please do this again (and post the new output), and then, without movind or resizing the window, run FvwmIdent on the reader window and post the contents of the FvwmIdent window (a small screenshot is fine). (I need the new console output so that I can relate the information in FvwmIdent to the debug output on the console.) 3. Is this really a regression between 2.6.6 and 2.6.5, or did you also switch to a different acroread release? (If so, which one did work with 2.6.5?) And please, (unless you write sensitive information), reply to fvm-work...@fvwm.org, not to me personally. (This should happen automatically if you hit the "reply" button in your mail porogram.) It might also help to include your config file or at least the commands not refering to modules. (You can send that to me directly if you don't want to write it to the list.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[zli...@ns.sympatico.ca: Re: regression from 2.6.5 to 2.6.6 ?]
- Forwarded message from zli...@ns.sympatico.ca - Date: Sat, 22 Oct 2016 22:00:16 -0300 From: zli...@ns.sympatico.ca To: Dominik Vogt <dominik.v...@gmx.de> Subject: Re: regression from 2.6.5 to 2.6.6 ? User-Agent: Mutt/1.6.1 (2016-04-27) On Sun, Oct 23, 2016 at 01:21 (+0100), Dominik Vogt wrote: > On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: >> On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: >>> On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: >>>> I cloned the git version about 15 minutes ago and compiled it, and >>>> acroread still does not go full-screen correctly. >>> Can you reproduce this using a more accessible program, please? I'm using >>> FreeBSD. >> No, I can't. That is, all other programs I use which have a >> "full-screen" mode work fine. > All right, I can see that acroread generates some weird requests > for new size and position. For me, the size is good, but the > position is totally screwed (x=65600, y=66000). > In fvwm/events.c at line 1077 there is this debug statement: > #if 0 > fprintf(stderr, > "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " > ... > #endif > Can you please replace the "#if 0" with "#if 1", rebuild and post > the output that going fullscreen causes on the console? (Don't > move or resize any windows when doing this to reduce the amount of > output.) Also, please add this line to the fvwm config file (or > type it in FvwmConsole before starting acroread) > bugopts explainwindowplacement > This will produce some more output that may be helpful. I trust this is what you were looking for? cre: 0(0) 0(0) 48(4)x96(8) fw 0x00400cb3 w 0x0201 ew 0x0201 'stalonetray' [fvwm][__execute_function]: <> No such command 'explainwindowplacement' cre: 935(1) 0(2) 985(0)x1080(0) fw 0x00401005 w 0x06200031 ew 0x06200031 'Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x00401166 w 0x0620086b ew 0x0620086b 'acroread' cre: 0(1) 0(2) 3276(4)x1048(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 3286(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 65529(1) 65481(2) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(0) 0(0) 3300(4)x1142(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' cre: 0(1) 0(2) 200(0)x200(0) fw 0x004012ac w 0x06200899 ew 0x06200899 'acroread' cre: 1433(1) 65517(2) 985(4)x1080(8) fw 0x00401005 w 0x06200031 ew 0x06200031 'zshguide.pdf - Adobe Reader' Anything else I can provide? - End forwarded message - Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Sun, Oct 23, 2016 at 01:32:17AM +0100, Thomas Adam wrote: > On Sun, Oct 23, 2016 at 01:28:17AM +0100, Dominik Vogt wrote: > > On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > > > Branch: refs/heads/ta/install > > > Home: https://github.com/fvwmorg/fvwm > > > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > > > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > > > Author: Thomas Adam <tho...@fvwm.org> > > > Date: 2016-08-11 (Thu, 11 Aug 2016) > > > > > > Changed paths: > > > R ChangeLog > > > R ChangeLog-pre-2.4 > > > R ChangeLog-pre-2.6.6 > > > R NEWS > > > > Hm, what's the logic behind removing the NEWS file? Is it > > somewhere else now? > > It's mostly here: http://fvwm.org/features/ (because stuff hasn't changed), > and its successor will be release notes for the next version on Github anyway. Okay, and where is the source for the release notes? This needs to be kept in the fvwm source tree. I don't see me writing up any decent quality release notes, say, half a year after committing a patch. This stuff needs to be written down when the work is done, not at some indefinite time in the future. (I see fvwm more as a GNU style project rather than a Github style project. Using features of git or Github is fine, but I don't think we should give up the GNU project standards, where applicable: https://www.gnu.org/prep/standards/standards.txt ) I don't care much about the other files (ChangeLogs and such), but fvwm should have a NEWS file like other GNU projects. > If people really want more detail they can look in git. The point of removing > these files is duplicating these things when git provides most of them is a > good thing. The NEWS file has been a readable summary of user visible changes. I don't see how this could be generated from commit information and diffs in git. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] b753a0: Remove stale files
On Thu, Aug 11, 2016 at 04:23:47PM -0700, GitHub wrote: > Branch: refs/heads/ta/install > Home: https://github.com/fvwmorg/fvwm > Commit: b753a06d2eb0325fd682563fcc127acbd6cf7813 > > https://github.com/fvwmorg/fvwm/commit/b753a06d2eb0325fd682563fcc127acbd6cf7813 > Author: Thomas Adam <tho...@fvwm.org> > Date: 2016-08-11 (Thu, 11 Aug 2016) > > Changed paths: > R ChangeLog > R ChangeLog-pre-2.4 > R ChangeLog-pre-2.6.6 > R NEWS Hm, what's the logic behind removing the NEWS file? Is it somewhere else now? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: regression from 2.6.5 to 2.6.6 ?
On Sat, Oct 22, 2016 at 08:36:10PM -0300, zli...@ns.sympatico.ca wrote: > On Sun, Oct 23, 2016 at 00:20 (+0100), Thomas Adam wrote: > > > On Sat, Oct 22, 2016 at 07:56:31PM -0300, zli...@ns.sympatico.ca wrote: > >> I cloned the git version about 15 minutes ago and compiled it, and > >> acroread still does not go full-screen correctly. > > > Can you reproduce this using a more accessible program, please? I'm using > > FreeBSD. > > No, I can't. That is, all other programs I use which have a > "full-screen" mode work fine. All right, I can see that acroread generates some weird requests for new size and position. For me, the size is good, but the position is totally screwed (x=65600, y=66000). In fvwm/events.c at line 1077 there is this debug statement: #if 0 fprintf(stderr, "cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x " ... #endif Can you please replace the "#if 0" with "#if 1", rebuild and post the output that going fullscreen causes on the console? (Don't move or resize any windows when doing this to reduce the amount of output.) Also, please add this line to the fvwm config file (or type it in FvwmConsole before starting acroread) bugopts explainwindowplacement This will produce some more output that may be helpful. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Need of a "devel" branch?
On Sat, Oct 22, 2016 at 11:23:17PM +0100, Thomas Adam wrote: > On Sat, Oct 22, 2016 at 11:12:58PM +0100, Dominik Vogt wrote: > > A "devel" branch could come in handy. When a feature is complete > > or ready for reviews, the patches are placed on the devel branch > > and then every ambitious user can try them out and report > > problems. The "devel" branch would receive the same automatic > > testing as master, but can be rebased or rewritten at any time. > > > > Releasing commits drom devel to master just means to do a fast > > forward rebase of the master's tip to a commit on devel. > > > > Of course, devel must never be rebased past the current master, > > and merge commits on the devel branch should be avoided (so it can > > be reabes without disrupting things). > > What you're fundamentally describing is what the git project does, although > they call their next-release-branch "next", rather than "devel" (the name > really doesn't matter). See: > > https://git-scm.com/docs/gitworkflows > > I suspect that's overkill for us, Yes, you're right. We're not a project with dozens of developers, so most of it is overkill. > although we could adopt some of this --- > namely, a devel branch which we rewind against master after every release. Unless we're doing lots of disruptive stuff I'd prefer to propagate completed patchsets into master early so they get more testing. > Topic branches still apply, and if any fixes are needed, they have to come > from those branches and nowhere else. Yes, nobody should be working on the integration or release branches directly. Although it's a bit more typing, I like it that all changes go through mandatory topic branches. Makes you work more carefully. > I don't think we need anything like their 'pu' concept since we don't have > enough development. Yep. After all, it's not possible to completely prevent bad commits from creeping into master. Things can be changed on master, but then it's the old CVS-like ways of undoing old commits. It's not the end of the world though. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Need of a "devel" branch?
In the times of CVS we've pushed every dirty commit to the one CVS branch we had, undoing things if need be. Nowadays using Git I feel really unconfortable doing this, not everything should be pushed to the stable branch right away. Although we do have topic branches with proposed changes now and everybody could test them easily, I suspect there would be very few people who would actually try out a topic branch. A "devel" branch could come in handy. When a feature is complete or ready for reviews, the patches are placed on the devel branch and then every ambitious user can try them out and report problems. The "devel" branch would receive the same automatic testing as master, but can be rebased or rewritten at any time. Releasing commits drom devel to master just means to do a fast forward rebase of the master's tip to a commit on devel. Of course, devel must never be rebased past the current master, and merge commits on the devel branch should be avoided (so it can be reabes without disrupting things). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
On Sat, Oct 22, 2016 at 10:55:39PM +0100, Thomas Adam wrote: > OK, this looks better. Thanks! > > GCC/Clang don't moan at these changes, which is good. The changes built via > travis-ci just fine. > > I say you're good to merge to master. Good. I think I've also figured out how these safety measures on master work. Thanks for your patience, Thomas. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] c0ae18: Fix Gcc warnings.
Different approach at fixing the warning. Hopefully this one works without removing any "uninitialised variable" warnings. The macro SUPPRESS_UNUSED_VAR_WARNING(var) from config.h is used to remove the "set but not used" warning in the discussed case. I've forced a new version of the branch replacing the old one. Plese double check this is sensible. > * fvwm/session.c (SessionInit, set_sm_properties): Fix warnings. > * fvwm/frame.c (frame_prepare_animation_shape) > (frame_setup_shape): Fix warnings. > * fvwm/icons.c (CreateIconWindow): Fix warnings. > * fvwm/add_window.c (setup_style_and_decor): Fix warnings. > * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. > * configure.ac: Add helper macro SUPPRESS_UNUSED_VAR_WARNING to fake > using a variable and its value in certain hard to fix places. > * fvwm/menus.c (size_menu_vertically): Fix write access to read-only > location with gettext. > > libs: > * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) > (NewConnectionMsg): Fix warnings. > * FGettext.c (FGettextInit): Fix warnings. > * FImage.c (FGetFImage): Fix warnings. > * Fft.c (FftGetFont): Fix warnings. > * FRender.c (FRenderVisualInit, FRenderCreateShadePicture) > (FRenderTintPicture, FRenderTintRectangle, FRenderRender): Fix > warnings. > * FScreen.c (FScreenInit): Fix warnings. > * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 10:04:39PM +0100, Thomas Adam wrote:
> On Sat, Oct 22, 2016 at 07:55:01PM +0100, Dominik Vogt wrote:
> > Yes, but that does not fix the warning. "x" is unused because of
> > the dummy replacement of the function call. The compiler does not
> > see that if "x = 0" is ever executed, Fxyz_some_func always has a
> > non-empty definition.
> >
> > I've always used
> >
> > if (FEATURE)
> > {
> > ...
> > }
> >
> > Instead of
> >
> > #if FEATURE
> > ...
> > #endif
> >
> > so that the conditional code is always compiled, even if the
> > feature is disabled (so we would catch compile errors earlier).
> > But in this case, it introduces a warning.
>
> Yes -- which makes this impossible to fix unless the code is changed to be
> #ifdef'd out, rather than using 'if (FEATURE)', which makes things harder to
> read anyway.
In that case I'd rather have a warning in a rare corner case than
the code becoming un-compileable over time because nobody ever
bothers to disable all optional configure features before building
a release. Ifdefs are a maintenance nightmare.
But of course it is fixable, we'd just have to replace the dummy
macros with real functions that do nothing. A decent compiler
will remove the dead code anyway. But I won't do that unless I
really find no better way.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
On Sat, Oct 22, 2016 at 06:19:46PM +0100, Thomas Adam wrote:
> On Sat, Oct 22, 2016 at 03:42:13PM +0100, Dominik Vogt wrote:
> > Proof reading this patch would also be helpful.
>
> I've taken a look. It's fine. I can't say I like the void casts all over the
> place -- what's wrong with giving a default value?
It results in "set but not used" messages (gcc-4.7.2). This is in
some functions where a feature is disabled with a macro:
void foo(void)
{
int x;
if (!FEATURE_XYZ)
{
return;
}
x = 0;
Fxyz_some_func();
return;
}
Where
#if FEATURE_XYZ
#define Fxyz_some_function(a) Xyz_some_sunction(a)
#else
#define Fxyz_some_function(a) do { } while (0)
#fi
If FEATURE_XYZ is disabled, the preprocessed code is just
...
x = 0;
do { } while (0);
...
And the least invasive way to prevent this is faking a read with
the coid-cast.
> However, since I'm using FreeBSD and hence clang, here's a further diff I'd
> like you to include (to shut up clang):
>
> diff --git a/fvwm/icons.c b/fvwm/icons.c
> index a3cb0cd..a6cc234 100644
> --- a/fvwm/icons.c
> +++ b/fvwm/icons.c
> @@ -754,7 +754,7 @@ void CreateIconWindow(FvwmWindow *fw, int def_x, int
> def_y)
> /* when fvwm is using the non-default visual client
> * supplied icon pixmaps are drawn in a window with no
> * relief */
> - int off ;
> + int off = 0;
>
> (void)off;
> if (Pdefault || fw->iconDepth == 1 ||
Ouch. So, the void casts are really bad because they actualy hide
real bugs. This is not just a warning fix, the patch really
breaks code that was fine before, except for the warning. There
must be another way then...
> Incidentally, you can always check to see what the different compilers are
> doing (gcc/clang) by looking at the output from the travis-ci builds. In the
> Clang case, your build looks are here:
>
> https://travis-ci.org/fvwmorg/fvwm/jobs/169749072
Hm, I just see a summary on top and below the heading "Job log" a
"loading" icon that never finishes.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Broken code spans in DEVELOPERS.md
With markdown-1.0.1 the code spans in DEVELOPERS.md come out all broken when converting the file to html, and I don't get how to do it right. Viewed with seamonkey they looks like this. -- git checkout topic/branch git rebase origin/master git checkout master git merge topic/branch git push -- without indentation and line breaks. -- ``` include "config.h" ``` -- The backticks have not been recognized, there's no indentation, an extra blank line and the font is HUGE. Seems to be misunderstood as a chapter heading. -- make CFLAGS="-g -O2 -Wall -Wpointer-arith -fno-strict-aliasing -Werror" -- without indentation. -- git clone g...@github.com:fvwmorg/fvwmorg.github.io.git -- without indentation. For me, this ``` construct doesn't do anything useful. Markdown documentation says a preformatted code block ist started by adding an additional level of indentation. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] 5b3250: Fix gettext write to read only string; fix warning...
Proof reading this patch would also be helpful. On Sat, Oct 22, 2016 at 07:36:12AM -0700, GitHub wrote: > Branch: refs/heads/dv-gcc-warning-fixes > Home: https://github.com/fvwmorg/fvwm > Commit: 5b325057dc569621230a2326d1640dcb07cacdb1 > > https://github.com/fvwmorg/fvwm/commit/5b325057dc569621230a2326d1640dcb07cacdb1 > Author: Dominik Vogt <dominik.v...@gmx.de> > Date: 2016-10-22 (Sat, 22 Oct 2016) > > Changed paths: > M fvwm/add_window.c > M fvwm/events.c > M fvwm/frame.c > M fvwm/icons.c > M fvwm/menus.c > M fvwm/session.c > M libs/FGettext.c > M libs/FImage.c > M libs/FRender.c > M libs/FScreen.c > M libs/Fft.c > M libs/Ficonv.c > M libs/fsm.c > M modules/FvwmConsole/getline.c > > Log Message: > --- > Fix gettext write to read only string; fix warnings. > > * modules/FvwmConsole/getline.c (get_line): Fix warnings. > * fvwm/session.c (set_sm_properties, SessionInit): Fix warnings. > * fvwm/frame.c (frame_prepare_animation_shape) > (frame_setup_shape): Fix warnings. > * fvwm/icons.c (CreateIconWindow): Fix warnings. > * fvwm/add_window.c (setup_style_and_decor): Fix warnings. > * fvwm/events.c (_handle_cr_on_shaped): Fix warnings. > * fvwm/menus.c (size_menu_vertically): Fix write access to read-only > location with gettext. > > libs: > * fsm.c (SaveYourselfPhase2ReqProc, SaveYourselfDoneProc) > (NewConnectionMsg): Fix warnings. > * FGettext.c (FGettextInit): Fix warnings. > * FImage.c (FGetFImage): Fix warnings. > * Fft.c (FftGetFont): Fix warnings. > * Ficonv.c (is_translit_supported, convert_charsets): Fix warnings. > * FRender.c (FRenderCreateShadePicture, FRenderVisualInit) > (FRenderTintRectangle, FRenderTintPicture, FRenderRender): Fix > warnings. > * FScreen.c (FScreenInit): Fix warnings. > > > > Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Sat, Oct 22, 2016 at 01:19:57PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > * From version X+1 onwards, no guarantees are made about > >continued support of obscure features, until there's an > >official fvwm-3.0. > > I am looking at releasing 2.6.7 this weekend. AFAIAC, this release will be > the last stable/supported version. Up to this point I've installed all > optional libraries and fixed all the warnings for the versions I have > available (FreeBSD) -- so that's something. I think it's in a good state to > be left behind, and allowing it to receive minor fixes, etc. I'm fixing the warnings I discovered through building with all configurable features switched off. The result should probably make it into 2.6.7. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Removing libstroke support?
On Tue, Oct 18, 2016 at 06:29:59AM +0200, Viktor Griph wrote: > Den 17 okt. 2016 11:56 PM skrev "Dominik Vogt" <dominik.v...@gmx.de>: > > > > Does anybody really use libstroke support? > > I've been using it in my configs since I started using fvwm. > > > It's resonsible for > > quite some hardly readably code, and I suspect nobody uses it > > anymore. If there's a need for mouse gesture or touchpad support, > > there must certainly be some other library around that does a > > better job. > > I haven't looked for alternatives, but it feels like the functionality > really should live in a separate application. It's not about managing > windows, but being able to execute commands on gestures. So, for what kind of actions do you use it? Somthing window manager related like, say iconifying windows etc., or something else that could be done without the WM? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Final long term stable version
On Mon, Oct 17, 2016 at 11:25:47PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 11:20:25PM +0100, Dominik Vogt wrote: > > While the enthusiasm to remove outdated stuff (strokes, Xinerama, > > colourmaps, old parser etc.) is an important step towards a > > maintainable and nice future fvwm3, there are certainly some old > > systems still running that use some obscure features. > > > > In order to not alienate long time users from fvwm we may need to > > make a clean cut at some time: > > > > * Up to version X, the old feature set and syntax is supported > >"forever". There won't be any new features anymore, but if > >need be, we'll look into fixes like to new library versions and > >such, so that the old version will continue to run on old boxes. > >Patches fixing such problems are welcome, and once in a while a > >new maintenance release is made. > > > > * From version X+1 onwards, no guarantees are made about > >continued support of obscure features, until there's an > >official fvwm-3.0. > > > > Is that doable? WIth X == 2.6.7? (Of course this is all depends > > on people actually doing that work.) > > It's doable from a code/maintenance point of view, yes. But I hope that > there's no real expectation that developers or future developers (chance would > be a fine thing!) who might be working on this mythical fvwm-3, should care > about fvwm-legacy. > > Oh, and I love the idea---but I am incredibly skpetical about it coming to > fruition, given that there are so few people developing fvwm these days. Well, developers or not is one thing, but the first step would be to *announce* that fvwm2 is not going to be disposed off on the compost heap. That anybody is welcome if she wants to take care of the fvwm2 branch for a while, and that the "fvwm3" developers are not going to put a spoke in her wheel, and support that maintenance work if possible. (If it turns out that there are no developers for fvwm this discussion is moot anyway.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Final long term stable version
While the enthusiasm to remove outdated stuff (strokes, Xinerama, colourmaps, old parser etc.) is an important step towards a maintainable and nice future fvwm3, there are certainly some old systems still running that use some obscure features. In order to not alienate long time users from fvwm we may need to make a clean cut at some time: * Up to version X, the old feature set and syntax is supported "forever". There won't be any new features anymore, but if need be, we'll look into fixes like to new library versions and such, so that the old version will continue to run on old boxes. Patches fixing such problems are welcome, and once in a while a new maintenance release is made. * From version X+1 onwards, no guarantees are made about continued support of obscure features, until there's an official fvwm-3.0. Is that doable? WIth X == 2.6.7? (Of course this is all depends on people actually doing that work.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Removing colour map support
The last time I've had a system where private colourmap support was useful was back in 1991 or so. Many people nowadays probably don't even know what it is: On systems with a limited number of colours (anybody remembers graphics cards that could only display 256 colours in parallel) every window could have its own set of colours to use, and when it got the focus, that map would be installed, rendering all other windows in funny colours. I've honestly no ideas if there are still applications around that do that (Netscape was one). Is there a reason to keep it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm] d30479: Make PNG support mandatory
On Mon, Oct 17, 2016 at 10:30:37PM +0100, Thomas Adam wrote: > On Mon, Oct 17, 2016 at 10:05:04PM +0100, Dominik Vogt wrote: > > The intention of having a show off or default config using PNG is > > a good idea, but one can still have an option "--disable-png" and > > tell people: > > [...] > > OK -- so what if we do that, but it defaults to using PNG if it's on the > system? Fine with me, even if it produces an error message if libpng-devel is not found and --disable-png is not explicitly used. > Would that make things easier for everyone? If so, I'm happy to do that. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
