[PATCH] (7) Miscellaneous cleanup
0001: Remove trailing whitespace in a module file.
0002: Rename variables in __move_loop (part of a larger cleanup).
0003: Break some long lines in the move/resize code.
0004: Fix manpage glitch.
0005: Don't mention FvwmTheme in the man gape anymore.
0006: Rephrase the introductory paragraphs in the man page and remove the MWM
references. Remove "features" that are not noteworthy nowadays.
0007: Remove the "MWM COMPATIBILITY" section. Nobody cares anymore.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From e1ba8a6c1b3d77c501330acc53e98c8ffbbddf62 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 02:04:06 +0100
Subject: [PATCH 1/7] Remove trailing whitespace.
---
modules/FvwmIconMan/FvwmIconMan.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/modules/FvwmIconMan/FvwmIconMan.h b/modules/FvwmIconMan/FvwmIconMan.h
index dd7be146..33476f47 100644
--- a/modules/FvwmIconMan/FvwmIconMan.h
+++ b/modules/FvwmIconMan/FvwmIconMan.h
@@ -65,7 +65,7 @@ typedef struct Resolution {
NO_SHOW_PAGE = 0x20,
NO_SHOW_SCREEN = 0x40,
} type;
-
+
} Resolution;
typedef enum {
--
2.30.2
From 0ba1427dd27539543579c3a6d88216e6e0549d0f Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 10:31:04 +0100
Subject: [PATCH 2/7] __move_loop: Rename variables.
---
fvwm/move_resize.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index 8536673c..5fd41e8c 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -2725,8 +2725,8 @@ Bool __move_loop(
ButtonMotionMask | ExposureMask, )))
{
XEvent le;
- int x;
- int y;
+ int px;
+ int py;
int delay;
UPDATE_FVWM_SCREEN(fw);
@@ -2761,11 +2761,11 @@ Bool __move_loop(
e.type = MotionNotify;
e.xmotion.time = fev_get_evtime();
if (FQueryPointer(
-dpy, Scr.Root, , , ,
-, , , ) == True)
+dpy, Scr.Root, , , ,
+, , , ) == True)
{
-e.xmotion.x_root = x;
-e.xmotion.y_root = y;
+e.xmotion.x_root = px;
+e.xmotion.y_root = py;
}
else
{
--
2.30.2
From 0e2326257e6fd88c3d207df2b063307c7d7385f1 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 10:31:24 +0100
Subject: [PATCH 3/7] Break long lines.
---
fvwm/move_resize.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index 5fd41e8c..3e09666b 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -2620,8 +2620,10 @@ Bool __move_loop(
m = fw->m;
vx = m->virtual_scr.Vx;
vy = m->virtual_scr.Vy;
- dx = m->virtual_scr.EdgeScrollX ? m->virtual_scr.EdgeScrollX : monitor_get_all_widths();
- dy = m->virtual_scr.EdgeScrollY ? m->virtual_scr.EdgeScrollY : monitor_get_all_heights();
+ dx = m->virtual_scr.EdgeScrollX ?
+ m->virtual_scr.EdgeScrollX : monitor_get_all_widths();
+ dy = m->virtual_scr.EdgeScrollY ?
+ m->virtual_scr.EdgeScrollY : monitor_get_all_heights();
if (!GrabEm(cursor, GRAB_NORMAL))
{
@@ -2981,8 +2983,10 @@ Bool __move_loop(
xl = xl2;
yt = yt2;
}
- if (xl != xl_orig || yt != yt_orig || vx != m->virtual_scr.Vx ||
- vy != m->virtual_scr.Vy || was_snapped)
+ if (
+xl != xl_orig || yt != yt_orig ||
+vx != m->virtual_scr.Vx ||
+vy != m->virtual_scr.Vy || was_snapped)
{
/* only snap if the window actually moved! */
if (!is_alt_mode_enabled)
@@ -4022,8 +4026,10 @@ static Bool __resize_window(F_CMD_ARGS)
Bool was_alt_key_not_pressed = False;
Bool is_alt_mode_enabled = False;
- dx = mon->virtual_scr.EdgeScrollX ? mon->virtual_scr.EdgeScrollX : monitor_get_all_widths();
- dy = mon->virtual_scr.EdgeScrollY ? mon->virtual_scr.EdgeScrollY : monitor_get_all_heights();
+ dx = mon->virtual_scr.EdgeScrollX ?
+ mon->virtual_scr.EdgeScrollX : monitor_get_all_widths();
+ dy = mon->virtual_scr.EdgeScrollY ?
+ mon->virtual_scr.EdgeScrollY : monitor_get_all_heights();
bad_window = False;
ResizeWindow = FW_W_FRAME(fw);
--
2.30.2
From bd008eb022d240c53c3fe92778bb13abddebbca0 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 11:44:29 +0100
Subject: [PATCH 4/7] Fix "" in man page.
---
doc/fvwm3/fvwm3.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/fvwm3/fvwm3.adoc b/doc/fvwm3/fvwm3.adoc
index 3e325ef0..a71c0aed 100644
--- a/doc/fvwm3/fvwm3.adoc
+++ b/doc/fvwm3/fvwm3.adoc
@@ -1762,7 +1762,7 @@ $[...]::
Some examples can be found in the description of the *AddToFunc*
command.
-== SCRIPTING & COMPLEX FUNCTIONS
+== SCRIPTING AND COMPLEX FUNCTIONS
To achieve the more complex effects, fvwm has a number of commands that
improve its scripting abilities. Scripts can be read from a file with
--
2.30.2
From 328548e401de16064feebb81ea43b86325e8d9ee Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 11:4
[PATCH] Alt key during move and resize enables paging.
As discussed in the other thread, this patch
* Enables paging without delay when holding the Alt key during
interactive move and resize.
* Documents it in the man page.
* Fixes a couple of problems in the man page.
Works best when disabling the "normal" way of paging:
Style * EdgeMoveDelay -1, EdgeResizeDelay -1
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From bd8ead5aa462fd68acee06f89725e12b4e5eb79c Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 23:56:12 +0100
Subject: [PATCH 1/4] Pressing Alt during "Move" enables immediate paging.
---
doc/fvwm3/fvwm3.adoc | 27 +++--
fvwm/move_resize.c | 91
2 files changed, 81 insertions(+), 37 deletions(-)
diff --git a/doc/fvwm3/fvwm3.adoc b/doc/fvwm3/fvwm3.adoc
index 5594fdab..3e325ef0 100644
--- a/doc/fvwm3/fvwm3.adoc
+++ b/doc/fvwm3/fvwm3.adoc
@@ -4131,16 +4131,15 @@ AddToFunc lower-to-bottom
window. Move can be called with various options to either start
an interactive move, specify the position to move, or a direction.
+
-Calling *Move* by itself with no options starts an interactive move.
-When moving a window interactively, the window may snap to other windows
-and screen boundaries, configurable via the *SnapAttraction* style. Holding
-down _Alt_ whilst moving the window will disable snap attraction during
-the move. Moving a window to the edge of the screen can be used to drag the
-window to other pages, see *EdgeScroll*, and the *EdgeMoveDelay* style
-for more information.
-+
-The interactive move operation can be aborted with Escape
-or any mouse button not set to place the window. By default mouse
+*Move* without options starts an interactive move. The window may snap to
+other windows and screen boundaries, configurable with the *SnapAttraction*
+style. Moving a window to the edge of the screen can be used to drag the
+window to other pages. (See *EdgeScroll*, and the _EdgeMoveDelay_ style for
+more information.)
++
+Holding down _Alt_ disables snapping and allows to switch pages
+without any delay. Interactive movement can be aborted with the
+_Escape_ key or any mouse button not set to place the window. By default mouse
button 2 is set to cancel the move operation. To change this you may
use the *Mouse* command with special context 'P' for Placement.
+
@@ -4397,9 +4396,13 @@ where ontop is the highest layer used in your setup.
its border, then that window is resized. If called from the root
window then the user is allowed to select the target window.
+
-The operation can be aborted with
+*Resize* without options starts an interactive resize.
+
-or by pressing any mouse button (except button 1 which confirms it).
+If the _EdgeResizeDelay_ style is set or the _Alt_ key is held down,
+the window can be resized across the edge of the screen.
++
+The operation can be aborted with the _Escape_ key or by pressing
+any mouse button (except button 1 which confirms it).
+
If the optional arguments _width_ and _height_ are provided, then the
window is resized so that its dimensions are _width_ by _height_. The
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index 97ff353f..8536673c 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -2603,12 +2603,12 @@ Bool __move_loop(
Window move_w = None;
int orig_icon_x = 0;
int orig_icon_y = 0;
- Bool do_snap = True;
Bool was_snapped = False;
- /* if Alt is initially pressed don't enable no-snap until Alt is
- * released */
- Bool nosnap_enabled = False;
+ /* if Alt is initially pressed don't enable "Alt" mode until the key is
+ * released once. */
+ Bool was_alt_key_not_pressed = False;
/* Must not set placed by button if the event is a modified KeyEvent */
+ Bool is_alt_mode_enabled = False;
Bool is_fake_event;
FvwmWindow *fw = exc->w.fw;
unsigned int draw_parts = PART_NONE;
@@ -2727,6 +2727,7 @@ Bool __move_loop(
XEvent le;
int x;
int y;
+ int delay;
UPDATE_FVWM_SCREEN(fw);
@@ -2734,10 +2735,11 @@ Bool __move_loop(
xl -= XOffset;
yt -= YOffset;
-
+ delay = (is_alt_mode_enabled) ?
+0 : fw->edge_delay_ms_move;
rc = HandlePaging(
, dx, dy, , , _x, _y,
-False, False, True, fw->edge_delay_ms_move);
+False, False, True, delay);
/* Fake an event to force window reposition */
if (delta_x)
@@ -2750,7 +2752,7 @@ Bool __move_loop(
y_virtual_offset = 0;
}
yt += YOffset;
- if (do_snap)
+ if (!is_alt_mode_enabled)
{
DoSnapAttract(fw, Width, Height, , );
was_snapped = True;
@@ -2851,12 +2853,15 @@ Bool __move_loop(
switch (e.type)
{
case KeyPress:
- if (!(e.xkey.state & Mod1Mask))
+ if (e.xmotion.state & Mod1Mask)
+ {
+is_alt_mode_enabled = was_alt_key_not_pressed;
+ }
+ else
{
-nosnap_enabled = True;
+was_alt_key_not_pressed = True;
+is_alt_mode_enabled = False;
}
- do_snap = nosnap_enabled &&
-(e.xke
[PATCH] (2) Remove Dmalloc and Efence support.
0001: Remove Efence and Dmalloc support.
0002: Remove trailing whitespace.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 0d9780ca99675083470398857d149e3d1f05f84e Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 02:03:44 +0100
Subject: [PATCH 1/2] Remove Efence and Dmalloc support.
---
configure.ac | 31 ---
libs/fvwmlib.h| 5 -
modules/FvwmIconMan/FvwmIconMan.c | 7 ---
modules/FvwmIconMan/FvwmIconMan.h | 4
4 files changed, 47 deletions(-)
diff --git a/configure.ac b/configure.ac
index f6b4f6a5..07e4d2a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -166,18 +166,6 @@ AC_DEFINE(FVWM2RC, ".fvwm2rc")
# Various configure-time options
-AC_ARG_ENABLE(dmalloc,
- AS_HELP_STRING([--enable-dmalloc],
-[enable support for the dmalloc debugging library]),
- [ac_cv_dmalloc="$enableval"],
- [ac_cv_dmalloc="no"])
-
-AC_ARG_ENABLE(efence,
- AS_HELP_STRING([--enable-efence],
-[enable support for the efence debugging library]),
- [ac_cv_efence="$enableval"],
- [ac_cv_efence="no"])
-
dnl dummy: smr_SWITCH(sm, dummy for test script, on, SESSION)
# Need to know where X is, for finding some libraries (e.g. xpm)
@@ -1278,19 +1266,6 @@ AH_VERBATIM([_COMPAT_OLD_KEYSYMDEF],
# define XK_Page_Down XK_Next
#endif])
-# Allow building with dmalloc. Do this last to avoid screwing up any
-# other checks above.
-case "$ac_cv_dmalloc" in
- yes) AC_CHECK_HEADERS(dmalloc.h)
- AC_CHECK_LIB(dmalloc, dmalloc_shutdown)
- CPPFLAGS="$CPPFLAGS -DDMALLOC_FUNC_CHECK" ;;
-esac
-
-
-# Allow building with efence.
-case "$ac_cv_efence" in
- yes) AC_CHECK_LIB(efence, malloc) ;;
-esac
# some explicit definitions for config.h file
AH_VERBATIM([_ZEND_EXPLICIT_DEFINITIONS],
@@ -1562,9 +1537,3 @@ Fvwm3 Configuration:
Build man pages?$with_mandoc$problem_mandoc
"
-case "$ac_cv_dmalloc" in
- yes) echo " DMALLOC heap debugging library enabled." ;;
-esac
-case "$ac_cv_efence" in
- yes) echo " EFENCE debugging library enabled." ;;
-esac
diff --git a/libs/fvwmlib.h b/libs/fvwmlib.h
index 7217c7a5..36fee51c 100644
--- a/libs/fvwmlib.h
+++ b/libs/fvwmlib.h
@@ -12,11 +12,6 @@
/* Convenience function ti init all the graphics subsystems */
void flib_init_graphics(Display *dpy);
-/* Set up heap debugging library dmalloc. */
-#ifdef HAVE_DMALLOC_H
-#include
-#endif
-
/* Set up mtrace from glibc 2.1.x for x > ? */
#ifdef MTRACE_DEBUGGING
#include
diff --git a/modules/FvwmIconMan/FvwmIconMan.c b/modules/FvwmIconMan/FvwmIconMan.c
index 4f0e1c32..b9b93b5e 100644
--- a/modules/FvwmIconMan/FvwmIconMan.c
+++ b/modules/FvwmIconMan/FvwmIconMan.c
@@ -206,13 +206,6 @@ main(int argc, char **argv)
{
int i;
-#ifdef HAVE_LIBEFENCE
- extern int EF_PROTECT_BELOW, EF_PROTECT_FREE;
-
- EF_PROTECT_BELOW = 1;
- EF_PROTECT_FREE = 1;
-#endif
-
FlocaleInit(LC_CTYPE, "", "", "FvwmIconMan");
OpenConsole(OUTPUT_FILE);
diff --git a/modules/FvwmIconMan/FvwmIconMan.h b/modules/FvwmIconMan/FvwmIconMan.h
index 29a6e428..dd7be146 100644
--- a/modules/FvwmIconMan/FvwmIconMan.h
+++ b/modules/FvwmIconMan/FvwmIconMan.h
@@ -43,10 +43,6 @@ struct malloc_header {
#endif
-#ifdef HAVE_DMALLOC_H
-#include
-#endif
-
extern void PrintMemuse(void);
typedef unsigned long Ulong;
--
2.30.2
From 941a3c1a00a44f68040eda0437c335822e6cb73f Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 02:04:06 +0100
Subject: [PATCH 2/2] Remove trailing whitespace.
---
modules/FvwmIconMan/FvwmIconMan.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/modules/FvwmIconMan/FvwmIconMan.h b/modules/FvwmIconMan/FvwmIconMan.h
index dd7be146..33476f47 100644
--- a/modules/FvwmIconMan/FvwmIconMan.h
+++ b/modules/FvwmIconMan/FvwmIconMan.h
@@ -65,7 +65,7 @@ typedef struct Resolution {
NO_SHOW_PAGE = 0x20,
NO_SHOW_SCREEN = 0x40,
} type;
-
+
} Resolution;
typedef enum {
--
2.30.2
Re: Removind dmalloc and efence support?
On Mon, Nov 15, 2021 at 12:49:58AM +, Thomas Adam wrote: > On Mon, Nov 15, 2021 at 01:42:33AM +0100, Dominik Vogt wrote: > > Has anybody really used them in the last fifteen years? Since > > valgrind has become pretty stable and good I never saw a need for > > dmalloc or efence any more. > > I agree. It can go. Good. I'll make a patch. > I know Dan used to use one of the proprietary IBM profilers on fvwm's code > base from time-to-time as well, but I don't recall what that was called. Purify. It used to be quite good in finding the source of memory errors, better than Valgrind, but not the best tool available. With the steady Valgrind improvements and the amazing quality of warnings you get from Gcc it's less important nowadays. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Paging issue
On Mon, Nov 15, 2021 at 12:45:18AM +, Thomas Adam wrote: > On Mon, Nov 15, 2021 at 01:36:15AM +0100, Dominik Vogt wrote: > > While we're at it, much of the markup could be removed. The > > manpage is partially unreadable because too many words have markup > > (especially for the style command). > > Yeah. I suspect this is a holdover from when the original man page was in raw > Groff format, where such markup was quite common, and that's carried over from > Dockbook -> Asciidoc. Yes, it's mostly my fault. I'm super correct with such things, but bad at writing readable technical documentation. > > (Also, the Style docuementation should possibly be put in a > > separate manpage. The monolithic manpage is intimidatingly large. > > Even I am reluctant to use it. Maybe like the zsh manpages: One > > manpage per larger topic, and if you really insist on an ugly big > > one, there's also "man fvwmall". Should be generated from a > > single source though.) > > That's now significantly easier thanks to Asciidoc being in use, I agree -- :-) I love Asciidoc. Since I became aware of it around 2000, I've not ever used anything else (unless forced by customers). > and it's a subject which has come up over the years. I like the idea -- and > we can definitely start with styles. As you say, that's the bigger area of > documentation. > I've also never been a fan of styles being documented like this: > > Foo / Bar / Baz > > Where the last one in the group (Bqz, in this case) is meant to be the > default. I suspect that convention hasn't been honoured properly for years, > and we can certainly regroup these things to make it mor readable. The good new is: Since I'm almost the only person who ever wrote styles in the last two decades, this should mostly be good. I always was very pedantic with that. > > > I think it's best to try and keep line length to <=80 characters > > > > Sounds good. If we could add the emacs config for that at the > > start of the file that would help. (Just press alt-q to reformat > > a block.) > > I've been trying to move away from that convention in favour of using > editorconfig: > > https://editorconfig.org/ > > There's already a .editorconfig file in the top-level git repo. Interesting. Need to read up on how to use it from emacs. > We could add > the relevant section for .adoc files and then that would also apply to Vim as > well (which is what I use). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Removind dmalloc and efence support?
Has anybody really used them in the last fifteen years? Since valgrind has become pretty stable and good I never saw a need for dmalloc or efence any more. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Plans for the NEWS file?
On Mon, Nov 15, 2021 at 12:30:34AM +, Thomas Adam wrote: > On Mon, Nov 15, 2021 at 01:18:49AM +0100, Dominik Vogt wrote: > > Is the NEWS file going to be used for 3.x releases too? I always > > found it easier to add new entries when patches are written > > instead of reading the whole changelog when making a release. > > I now autogenerate this at release time via Github Actions, where the > relevant bugs/pull-requests, etc., are pulled from Github and formatted > accordingly in CHANGELOG.md > > > Can you give me an update on the intended release scheme? Fvwm is > > probably in an "unstable" phase at the moment? > > Right now, I've pre-scoped bugs/PRs/etc., which I feel should be in the 1.0.5 > release here: > > https://github.com/fvwmorg/fvwm3/projects/1?card_filter_query=milestone%3A1.0.5 > > This is somewhat arbitrary on my part in that there's no real end-goal for a > given release, other than what I think should be in it -- and typically what > I've been doing is amassing changes and releasing when it feels right, even if > items against that milestone might not yet have been finished. In such cases, > those items are moved forward to the next release. > > I don't think fvwm is in an "unstable" phase. It seems to be "OK", although > there's many rough edges still left to tidy up -- not helped by my own > butchery of fvwm over the past year... There probably needs to be some time when we annouce that we're done removing stuff so that people know that future changes will no longer break their configs. I'd say the feature set is unstable at the moment, not the code quality. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Paging issue
On Mon, Nov 15, 2021 at 12:24:42AM +, Thomas Adam wrote: > On Mon, Nov 15, 2021 at 01:16:06AM +0100, Dominik Vogt wrote: > > Of course. What is the maximum line length that was used to > > format the .adoc files? (Can we re-add some formatting > > instructions in comments at the start of the main manpage source > > as we had in the groff sources? I've noticed that style names are > > sometimes underlined and sometimes in italics.) > > There's some clean up that still needs doing, due to the conversion script I > wrote (albeit badly) to convert from XML -> Asciidoc, so I am not surprise if > you find any glitches. I suspect there's quite a few of them! While we're at it, much of the markup could be removed. The manpage is partially unreadable because too many words have markup (especially for the style command). (Also, the Style docuementation should possibly be put in a separate manpage. The monolithic manpage is intimidatingly large. Even I am reluctant to use it. Maybe like the zsh manpages: One manpage per larger topic, and if you really insist on an ugly big one, there's also "man fvwmall". Should be generated from a single source though.) > I think it's best to try and keep line length to <=80 characters Sounds good. If we could add the emacs config for that at the start of the file that would help. (Just press alt-q to reformat a block.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[PATCH] (3) Miscellaneous updates
0001: Improve Snap... docuemntation. 0002: Improve EdgeMoveDelay documentation. 0003: Remove superfluous "#if 1". Ciao Dominik ^_^ ^_^ -- Dominik Vogt From bda6a6a423ac05b68e65fc850afba9de57c6e46c Mon Sep 17 00:00:00 2001 From: Dominik Vogt Date: Sun, 14 Nov 2021 23:30:49 +0100 Subject: [PATCH 1/4] Improve Snap... documentation. --- doc/fvwm3/fvwm3.adoc | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/fvwm3/fvwm3.adoc b/doc/fvwm3/fvwm3.adoc index 86d7a97d..9d362a7e 100644 --- a/doc/fvwm3/fvwm3.adoc +++ b/doc/fvwm3/fvwm3.adoc @@ -6193,15 +6193,15 @@ during an interactive move the window or icon comes within _proximity_ pixels of another the window or icon, it is moved to make the borders adjoin. The default of 0 means that no snapping happens. Calling this command without arguments turns off snap attraction and restores the -default behavior. Please refer also to the *SnapGrid* command. +default behavior. Please refer also to the _SnapGrid_ option. + -The second argument determined is optional and may be set to one of +The second argument optional and may be set to one of the five following values: With _All_ both icons and windows snap to other windows and other icons. _SameType_ lets windows snap only to windows, and icons snap only to icons. With _Windows_ windows snap only to other windows. Similarly with _Icons_ icons snap only to other icons. With _None_ no snapping takes place. This option can be useful -in conjunction with the following argument if you only want to snap +in conjunction with the thirs argument if you only want to snap against the screen edges. The default behavior is _All_. + The third and last optional argument may be set to one of the four @@ -6223,10 +6223,10 @@ location (top left corner) is coincident with the nearest grid point. The default _x-grid-size_ and _y-grid-size_ setting are both 1, which is effectively no grid all. -An interactive move with both *SnapGrid* and _SnapAttraction_ results +An interactive move with both _SnapGrid_ and _SnapAttraction_ results in the window being moved to be adjacent to the nearest window border (if within snap proximity) or grid position. The window moves the -shortest distance possible to satisfy both *SnapGrid* and +shortest distance possible to satisfy both _SnapGrid_ and _SnapAttraction_. Note that the x and y coordinates are not coupled. For example, a window may snap to another window on the x axis while snapping to a grid point on the y axis. Using this style without -- 2.30.2 From b5eb5f7ad5cde4682dbd6848dda9ea0bc2bb965e Mon Sep 17 00:00:00 2001 From: Dominik Vogt Date: Mon, 15 Nov 2021 01:23:44 +0100 Subject: [PATCH 2/4] Rephrase EdgeMoveDelay documentation. --- doc/fvwm3/fvwm3.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/fvwm3/fvwm3.adoc b/doc/fvwm3/fvwm3.adoc index 9d362a7e..5594fdab 100644 --- a/doc/fvwm3/fvwm3.adoc +++ b/doc/fvwm3/fvwm3.adoc @@ -6232,8 +6232,8 @@ For example, a window may snap to another window on the x axis while snapping to a grid point on the y axis. Using this style without arguments reinstates the default settings. -The styles _EdgeMoveDelay_ and _EdgeResizeDelay_ tells how hard it -should be to change the desktop viewport by moving or resizing a +The styles _EdgeMoveDelay_ and _EdgeResizeDelay_ define how hard it +is to change the desktop viewport by moving or resizing a window over the edge of the screen. The parameter tells how many milliseconds the pointer must spend on the screen edge before fvwm moves the viewport. The command *EdgeScroll* determines how far the -- 2.30.2 From 50c4557110651bbf78b24ed0a2a35ca4075a4ce8 Mon Sep 17 00:00:00 2001 From: Dominik Vogt Date: Sun, 14 Nov 2021 23:55:54 +0100 Subject: [PATCH 3/4] Remove "#if 1". --- fvwm/fvwm.h | 4 1 file changed, 4 deletions(-) diff --git a/fvwm/fvwm.h b/fvwm/fvwm.h index 020de3bf..bdc04ee8 100644 --- a/fvwm/fvwm.h +++ b/fvwm/fvwm.h @@ -687,7 +687,6 @@ typedef struct window_style bool max_window_width_is_c; bool max_window_height_is_c; int shade_anim_steps; -#if 1 /*!!!*/ snap_attraction_t snap_attraction; /* snap grid size */ int snap_grid_x; @@ -696,7 +695,6 @@ typedef struct window_style int edge_delay_ms_resize; int edge_resistance_move; int edge_resistance_xinerama_move; -#endif icon_boxes *icon_boxes; float norm_placement_penalty; pl_penalty_struct pl_penalty; @@ -919,7 +917,6 @@ typedef struct FvwmWindow int max_window_height; int shade_anim_steps; unsigned char grabbed_buttons; -#if 1 /*!!!*/ snap_attraction_t snap_attraction; /* snap grid size */ int snap_grid_x; @@ -928,7 +925,6 @@ typedef struct FvwmWindow int edge_delay_ms_resize; int edge_resistance_move; int edge_resistance_xinerama_move; -#endif #define FM_NO_INPUT0 #define FM_PASSIVE 1 -- 2.30.2
Re: Paging issue
On Sun, Nov 14, 2021 at 11:57:27PM +, Thomas Adam wrote: > On Mon, Nov 15, 2021 at 12:31:28AM +0100, Dominik Vogt wrote: > > On Mon, Nov 15, 2021 at 12:19:59AM +0100, Dominik Vogt wrote: > > > What do you think about the attached patch? Pressing "Alt" during > > > an interactive move already disables snapping. It's easy to make > > > it enable paging without any delay too. I like it. > > > > > > You can say > > > > > > style * edgemovedelay > > > > > > (to disable paging during normal moves), then press Alt for a > > > second to switch pages, then release Alt to go back to normal > > > mode. > > > > P.S.: Does not work with "Resize" yet. > > Noted. I like this, and I think it will also work well for Resize. > Also needs a quick manpage update. Of course. What is the maximum line length that was used to format the .adoc files? (Can we re-add some formatting instructions in comments at the start of the main manpage source as we had in the groff sources? I've noticed that style names are sometimes underlined and sometimes in italics.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Plans for the NEWS file?
Is the NEWS file going to be used for 3.x releases too? I always found it easier to add new entries when patches are written instead of reading the whole changelog when making a release. Can you give me an update on the intended release scheme? Fvwm is probably in an "unstable" phase at the moment? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[PATCH] Reject out of range windows for Move and Resize commands.
Fixes programs going crazy when you accidentally say something like
all (mplayer) resize 1920 1200
instead of
all (mplayer) resize 1920p 1200p
(Generates an error message without doing anything else.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From c7e032441e57cb59b4472e6396e64da45b7628c6 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Mon, 15 Nov 2021 01:07:39 +0100
Subject: [PATCH] Reject out of range windows for Move and Resize commands.
(Width betwees 0 and 65535, size between -32768 and 32767.)
---
fvwm/move_resize.c | 77 +-
1 file changed, 35 insertions(+), 42 deletions(-)
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index ede54fe5..1ccbba8c 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -494,7 +494,7 @@ static void shuffle_win_to_closest(
*pFinalY = cwin.y;
}
-static int __get_shift(int val, float factor)
+static int get_shift(int val, float factor)
{
int shift;
@@ -516,6 +516,7 @@ static int GetOnePositionArgument(
float sfactor, int screen_size, int screen_pos, Bool is_x)
{
int final_pos;
+ int pos_change = 0;
float wfactor;
if (s1 == 0 || *s1 == 0)
@@ -584,7 +585,7 @@ static int GetOnePositionArgument(
n = ParsePositionArgumentSuffix(
, s1, wfactor, sfactor);
s1 += n;
- final_pos += __get_shift(val, f);
+ pos_change += get_shift(val, f);
}
break;
}
@@ -616,7 +617,16 @@ static int GetOnePositionArgument(
/* parse suffix */
n = ParsePositionArgumentSuffix(, s1, wfactor, sfactor);
s1 += n;
- final_pos += __get_shift(val, f);
+ pos_change += get_shift(val, f);
+ }
+ final_pos += pos_change;
+ if (final_pos > 32767 || final_pos < -32768)
+ {
+ fvwm_debug(
+ __func__, "new position is out of range: %d",
+ final_pos);
+
+ return 0;
}
*pFinalPos = final_pos;
@@ -792,7 +802,8 @@ static int ParseOneResizeArgument(
int val;
int add_base_size = 0;
int cch = strlen(arg);
- int tmp_size;
+ int size_change;
+ int new_size;
if (cch == 0)
{
@@ -833,59 +844,40 @@ static int ParseOneResizeArgument(
if (strcmp(arg,"w") == 0)
{
/* do not change size */
+ size_change = 0;
}
else if (sscanf(arg,"w-%d",) == 1)
{
- tmp_size = (int)(val * factor + 0.5);
- if (tmp_size < *ret_size)
- {
- *ret_size -= tmp_size;
- }
- else
- {
- *ret_size = 0;
- }
+ size_change = -(int)(val * factor + 0.5);
}
else if (sscanf(arg,"w+%d",) == 1 || sscanf(arg,"w%d",) == 1)
{
- tmp_size = (int)(val * factor + 0.5);
- if (-tmp_size < *ret_size)
- {
- *ret_size += tmp_size;
- }
- else
- {
- *ret_size = 0;
- }
+ size_change = (int)(val * factor + 0.5);
}
else if (sscanf(arg,"-%d",) == 1)
{
- tmp_size = (int)(val * factor + 0.5);
- if (tmp_size < scr_size + add_size)
- {
- *ret_size = scr_size - tmp_size + add_size;
- }
- else
- {
- *ret_size = 0;
- }
+ size_change = scr_size - (int)(val * factor + 0.5) + add_size;
}
else if (sscanf(arg,"+%d",) == 1 || sscanf(arg,"%d",) == 1)
{
- tmp_size = (int)(val * factor + 0.5);
- if (-tmp_size < add_size + add_base_size)
- {
- *ret_size = tmp_size + add_size + add_base_size;
- }
- else
- {
- *ret_size = 0;
- }
+ size_change =
+ (int)(val * factor + 0.5) + add_size + add_base_size;
}
else
{
return 0;
}
+ new_size = *ret_size + size_change;
+ if (new_size < 0)
+ {
+ new_size = 0;
+ }
+ else if (new_size > 65535)
+ {
+ fvwm_debug(__func__, "new size is too big: %d", new_size);
+ return 0;
+ }
+ *ret_size = new_size;
return 1;
}
@@ -958,8 +950,9 @@ static int GetResizeArguments(FvwmWindow *fw,
else if (*ret_dir == DIR_NONE)
{
tmp_token = PeekToken(naction, );
-if (tmp_token != NULL &&
- StrEquals(tmp_token, "automatic"))
+if (
+ tmp_token != NULL && StrEquals(
+ tmp_token, "automatic"))
{
*detect_automatic_direction = True;
*is_direction_fixed = True;
--
2.30.2
Re: Paging issue
On Mon, Nov 15, 2021 at 12:19:59AM +0100, Dominik Vogt wrote: > What do you think about the attached patch? Pressing "Alt" during > an interactive move already disables snapping. It's easy to make > it enable paging without any delay too. I like it. > > You can say > > style * edgemovedelay > > (to disable paging during normal moves), then press Alt for a > second to switch pages, then release Alt to go back to normal > mode. P.S.: Does not work with "Resize" yet. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Paging issue
On Sun, Nov 14, 2021 at 04:51:26PM +, Thomas Adam wrote:
> On Sun, Nov 14, 2021 at 04:50:23PM +0100, Dominik Vogt wrote:
> > Current situation for me: At least 90% of all paging situations
> > are accidents.
>
> Yeah, and it gets even worse if you happen to use paging with
> 'DesktopConfiguration per-monitor' as well.
>
> > Maybe that feature ist just crap and we need a different mechanism
> > to trigger paging. Like holding down Shift while moving etc.
>
> I'd like to see this. I know it's a departure from how we've always handled
> paging, but I find myself doing things like:
>
> EdgeScroll 0 0
>
> For all the reasons you've previously mentioned, Dominik, I like to be able to
> sometimes flip pages using panframes but find it so utterly annoying I turn
> that off, and then end up not using pages, but rather desks -- hence it's
> equivalent to just me using a 'DesktopSize 1x1'.
>
> I say we should implement this change and see how it works in practise. If
> enough people don't like it, I'm sure they'll let us know. :)
Good, so it's not just me. :-)
What do you think about the attached patch? Pressing "Alt" during
an interactive move already disables snapping. It's easy to make
it enable paging without any delay too. I like it.
You can say
style * edgemovedelay
(to disable paging during normal moves), then press Alt for a
second to switch pages, then release Alt to go back to normal
mode.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 71351bc92e6dc2876dd448103d7653235f7786cd Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 23:56:12 +0100
Subject: [PATCH] Pressing Alt during "Move" enables immediate paging.
---
fvwm/move_resize.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fvwm/move_resize.c b/fvwm/move_resize.c
index 4d49b63e..ede54fe5 100644
--- a/fvwm/move_resize.c
+++ b/fvwm/move_resize.c
@@ -2734,6 +2734,7 @@ Bool __move_loop(
XEvent le;
int x;
int y;
+ int delay;
UPDATE_FVWM_SCREEN(fw);
@@ -2741,10 +2742,10 @@ Bool __move_loop(
xl -= XOffset;
yt -= YOffset;
-
+ delay = (do_snap) ? fw->edge_delay_ms_move : 0;
rc = HandlePaging(
, dx, dy, , , _x, _y,
-False, False, True, fw->edge_delay_ms_move);
+False, False, True, delay);
/* Fake an event to force window reposition */
if (delta_x)
@@ -3070,15 +3071,17 @@ Bool __move_loop(
if (paged == 0)
{
XEvent le;
+ int delay;
+ delay = (do_snap) ?
+ fw->edge_delay_ms_move : 0;
xl = e.xmotion.x_root;
yt = e.xmotion.y_root;
fev_get_last_event();
HandlePaging(
, dx, dy, , ,
_x, _y, False,
- False, False,
- fw->edge_delay_ms_move);
+ False, False, delay);
if (delta_x)
{
x_virtual_offset = 0;
--
2.30.2
Re: Paging issue
On Sun, Nov 14, 2021 at 03:35:12PM +, Thomas Adam wrote: > On Sun, Nov 14, 2021 at 01:55:32PM +0100, Dominik Vogt wrote: > > 1) Because the pointer is at the top of the screen, it's > > immediately in the one pixel high panning window, so fvwm waits > > the configured 500 ms and then switches pages to 0 0 although > > neither the window nor the pointer have ever moved. > > > > 2) Even worse, _because_ nothing has moved, the window ist still > > completely on page 0 1. Not a single pixel is visible. > > > > Overall, the implementation of paging is annoying, and Ive no idea > > how to fix it. > > Presumably, the point here is to not do anything until the pointer has > moved, even if it is already in the panframe window? It's not so simple. It also happens when you just move the window horizontally along the screen edge and pause for too long*. Sounds silly, but it can happen when you need to rearrange fingers on a trackball or pick up the mouse because it has move off the mouse pad. *In ancient time page flipping would also trigger _while_ moving the window horizontally. So I changed that to reset the timer when the pointer moves. The drawback is that you now have to stop the pointer completely to trigger paging. I'd really like to get rid of switching pages while the window stays completely on the previous page. But X11 does not report mouse movement when the pointer hits the screen edge, so the code cannot know in which direction the mouse is actually being moved. With that information one could define a movement angle that allows paging, and lateral movement +/- some angle would not do anything. Current situation for me: At least 90% of all paging situations are accidents. Maybe that feature ist just crap and we need a different mechanism to trigger paging. Like holding down Shift while moving etc. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Snapping issue
The snapping code is really an unmaintainable mess. Some thoughts on how it might be rewritten: Situation: 1. There are three different snapping mechanisms: a) Snapping to windows or icons. b) Snapping to screen edges. c) Snapping to the grid. Each one has some distance defined at which snapping will occur. (a) and (b) are set directly, the value for (c) is roughly half the grid size. 2. The top border is in the vicinity of some locations it might snap to: - The bottom border of the next window above it. - The bottom border of the next window below it. - Possibly it's directly on the bottom border. - The top edge of the screen. - The grid line above it. - The grid line below it. 3. There needs to be some algorithm to decide to which of these coordinates the window should be snapped. The current algorithm treats all three mechanisms in separate code which can cause confusing interaction of windows jumping around while moving. The three mechanisms are not equally important. For example, if you have configured that windows whould snap to screen edges at 16 pixels distance, and the grid size is 4, the snap grid should not override the edge snapping at, say, 10 pixels distance. 4. The situation gets much more complicated because the bottom border of the window has completely different coordinates it can snap to. 5. The top or bottom border of the window may be off screen. The window should not snap to objects that are on another page. -- Idea: At a given window position, gather a list of possible snap coordinates and attraction distances for the top border (2). Gather a similar list for the bottom border (4). The list for the bottom border can actually be recalculated into top border coordinates (if the bottom coordinate is y, the top coordinate is (y - window height)). Now run the algorithm (3) to decide which coordinate shall be used for snapping. Treat window borders and screen edges as equally important. Whatever value is closest is shosen. Snap to the grid only if the window was not snapped to another window, icon or screen edge, Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Paging issue
With Style * SnapGrid 4 4 EdgeResistance 500 Style * EdgeMoveDelay 500, EdgeMoveResistance 128 EdgeScroll 0 0 Problem: * Create on page 0 1 and align it with the top of the screen. * Move the pointer to the top of the screen too. * Use some keyboard shortcut to start an interactive move operation. => 1) Because the pointer is at the top of the screen, it's immediately in the one pixel high panning window, so fvwm waits the configured 500 ms and then switches pages to 0 0 although neither the window nor the pointer have ever moved. 2) Even worse, _because_ nothing has moved, the window ist still completely on page 0 1. Not a single pixel is visible. Overall, the implementation of paging is annoying, and Ive no idea how to fix it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Snapping issue
Snapping to the grid, other windows and screen edges hat a nasty interaction that has been bugging me for years, but I don't know how to fix it. Suppose you have this: Style * SnapAttraction 12 Sametype, SnapGrid 4 4 EdgeResistance 500 Style * EdgeMoveDelay 500, EdgeMoveResistance 128 EdgeScroll 0 0 There's a button bar in the bottom left corner and another window that is a little shorter than the screen height minus the buttons height, say, one pixel shorter: +-+ |++ | <--- small gap || window | | ||| | ||| | ||| | ||| | ||| | |++ | |++ | || button bar | | +-+ When moving the window with the mouse it's difficult to snap the window to the top edge of the screen because it prefers to snap to the button bar instead. Try it out yourself. I just don't know how to "fix" it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[PATCH] (7) Remove ifdefs
#1, 2, 3 and 5 remove code that hasn't been used in ages.
#4 removes an ifdef that commented out code that shouldn't be.
#6 makes a very old code switch permanent.
#7 general ifdef and debug output cleanup.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 6d65cc40b6371f4d0a7a2adf5254e2e329ded7ab Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 12:07:33 +0100
Subject: [PATCH 1/7] Remove ICON_DBG.
---
fvwm/add_window.c | 12
fvwm/events.c | 10 --
fvwm/icons.c | 23 ---
fvwm/misc.h | 6 --
4 files changed, 51 deletions(-)
diff --git a/fvwm/add_window.c b/fvwm/add_window.c
index 63900abc..854183d9 100644
--- a/fvwm/add_window.c
+++ b/fvwm/add_window.c
@@ -1416,14 +1416,10 @@ static void setup_icon(FvwmWindow *fw, window_style *pstyle)
if (SHAS_ICON(>flags) &&
S_ICON_OVERRIDE(SCF(*pstyle)) == ICON_OVERRIDE)
{
- ICON_DBG((stderr,"si: iwh ignored '%s'\n",
- fw->name.name));
fw->icon_bitmap_file = SGET_ICON_NAME(*pstyle);
}
else
{
- ICON_DBG((stderr,"si: using iwh '%s'\n",
- fw->name.name));
fw->icon_bitmap_file = NULL;
}
}
@@ -1432,27 +1428,21 @@ static void setup_icon(FvwmWindow *fw, window_style *pstyle)
if (SHAS_ICON(>flags) &&
S_ICON_OVERRIDE(SCF(*pstyle)) != NO_ICON_OVERRIDE)
{
- ICON_DBG((stderr,"si: iph ignored '%s'\n",
- fw->name.name));
fw->icon_bitmap_file = SGET_ICON_NAME(*pstyle);
}
else
{
- ICON_DBG((stderr,"si: using iph '%s'\n",
- fw->name.name));
fw->icon_bitmap_file = NULL;
}
}
else if (SHAS_ICON(>flags))
{
/* an icon was specified */
- ICON_DBG((stderr,"si: using style '%s'\n", fw->name.name));
fw->icon_bitmap_file = SGET_ICON_NAME(*pstyle);
}
else
{
/* use default icon */
- ICON_DBG((stderr,"si: using default '%s'\n", fw->name.name));
fw->icon_bitmap_file = Scr.DefaultIcon;
}
@@ -2228,8 +2218,6 @@ void increase_icon_hint_count(FvwmWindow *fw)
default:
break;
}
- ICON_DBG((stderr,"icon hint count++ (%d) '%s'\n",
- (int)WAS_ICON_HINT_PROVIDED(fw), fw->name.name));
}
return;
diff --git a/fvwm/events.c b/fvwm/events.c
index 49c23b79..f63a2cf6 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -3506,13 +3506,11 @@ void HandlePropertyNotify(const evh_args_t *ea)
if ((fw->wmhints->flags & IconPixmapHint) ||
(old_wmhints_flags & IconPixmapHint))
{
-ICON_DBG((stderr, "hpn: iph changed (%d) '%s'\n", !!(int)(fw->wmhints->flags & IconPixmapHint), fw->name.name));
has_icon_pixmap_hint_changed = True;
}
if ((fw->wmhints->flags & IconWindowHint) ||
(old_wmhints_flags & IconWindowHint))
{
-ICON_DBG((stderr, "hpn: iwh changed (%d) '%s'\n", !!(int)(fw->wmhints->flags & IconWindowHint), fw->name.name));
has_icon_window_hint_changed = True;
SET_USE_EWMH_ICON(fw, False);
}
@@ -3522,7 +3520,6 @@ ICON_DBG((stderr, "hpn: iwh changed (%d) '%s'\n", !!(int)(fw->wmhints->flags & I
{
if (ICON_OVERRIDE_MODE(fw) == ICON_OVERRIDE)
{
-ICON_DBG((stderr, "hpn: icon override '%s'\n", fw->name.name));
has_icon_changed = False;
}
else if (ICON_OVERRIDE_MODE(fw) ==
@@ -3533,7 +3530,6 @@ ICON_DBG((stderr, "hpn: icon override '%s'\n", fw->name.name));
if (WAS_ICON_HINT_PROVIDED(fw) ==
ICON_HINT_MULTIPLE)
{
-ICON_DBG((stderr, "hpn: using further iph '%s'\n", fw->name.name));
has_icon_changed = True;
}
else if (fw->icon_bitmap_file ==
@@ -3541,7 +3537,6 @@ ICON_DBG((stderr, "hpn: using further iph '%s'\n", fw->name.name));
fw->icon_bitmap_file ==
Scr.DefaultIcon)
{
-ICON_DBG((stderr, "hpn: using first iph '%s'\n", fw->name.name));
has_icon_changed = True;
}
else
@@ -3550,24 +3545,20 @@ ICON_DBG((stderr, "hpn: using first iph '%s'\n", fw->name.name));
* hint if the application did
* not provide it from the
* start */
-ICON_DBG((stderr, "hpn: first iph ignored '%s'\n", fw->name.name));
has_icon_changed = False;
}
}
else if (has_icon_window_hint_changed)
{
-ICON_DBG((stderr, "hpn: using iwh '%s'\n", fw->name.name));
has_icon_changed = True;
}
else
{
-ICON_DBG((stderr, "hpn: iwh not changed, hint ignored '%s'\n", fw->name.name));
has_icon_changed = False;
}
}
else /* NO_ICON_OVERRIDE */
{
-ICON_DBG((stderr, "hpn: using hint '%s'\n", fw->name.name));
has_icon_changed = True;
}
@@ -3578,7 +3569,6 @@ ICON_DBG((stderr, "hpn: using hint '%s'\n", fw->name.name));
if (has_icon_change
[PATCH] 1/3 Fix and document "bugopts debugrandr".
The patch makes the bogus "bugopts debugrandr" option actually do
something.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 415a98341f4f33495d58c4b74718a25a3a83eff8 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 10:54:20 +0100
Subject: [PATCH 1/3] Fix and document "bugopts debugrandr".
---
doc/fvwm3/fvwm3.adoc | 2 ++
fvwm/builtins.c | 5 -
fvwm/events.c| 5 -
fvwm/focus.c | 5 -
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/fvwm3/fvwm3.adoc b/doc/fvwm3/fvwm3.adoc
index 8c0b723c..86d7a97d 100644
--- a/doc/fvwm3/fvwm3.adoc
+++ b/doc/fvwm3/fvwm3.adoc
@@ -3094,6 +3094,8 @@ AddToMenu RootMenu
turn the option on or off, or "toggle" to switch is back and forth. If
_bool_ is omitted, the default setting is restored.
+
+_DebugRandR_ activates monitor layout debug messages.
++
_FlickeringMoveWorkaround_ disables ConfigureNotify events that are
usually sent to an application while it is moved. If some windows
flicker annoyingly while being moved, this option may help you. Note
diff --git a/fvwm/builtins.c b/fvwm/builtins.c
index da16be8b..53e6d287 100644
--- a/fvwm/builtins.c
+++ b/fvwm/builtins.c
@@ -3850,7 +3850,10 @@ void CMD_BugOpts(F_CMD_ARGS)
Scr.bo.do_debug_randr = 0;
break;
}
- monitor_dump_state(NULL);
+ if (Scr.bo.do_debug_randr)
+ {
+monitor_dump_state(NULL);
+ }
}
else if (StrEquals(opt, "TransliterateUtf8"))
{
diff --git a/fvwm/events.c b/fvwm/events.c
index 51af3bfe..49c23b79 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -1770,7 +1770,10 @@ void monitor_update_ewmh(void)
struct monitor *m, *mref;
fvwm_debug(__func__, "monitor debug...\n");
- monitor_dump_state(NULL);
+ if (Scr.bo.do_debug_randr)
+ {
+ monitor_dump_state(NULL);
+ }
mref = TAILQ_FIRST(_q);
diff --git a/fvwm/focus.c b/fvwm/focus.c
index bffd3fde..8cb40c3b 100644
--- a/fvwm/focus.c
+++ b/fvwm/focus.c
@@ -671,7 +671,10 @@ static void __activate_window_by_command(
}
m = fw->m;
- monitor_dump_state(m);
+ if (Scr.bo.do_debug_randr)
+ {
+ monitor_dump_state(m);
+ }
do_not_warp = StrEquals(PeekToken(action, NULL), "NoWarp");
if (!do_not_warp)
{
--
2.30.2
Re: [PATCH] 3/3 Correct typo.
Typo in error message.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 2d6ceb2c0650a7b0e30a3be7a04363e59b83370e Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 10:55:53 +0100
Subject: [PATCH 3/3] Correct typo.
---
fvwm/conditional.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fvwm/conditional.c b/fvwm/conditional.c
index f81e5a49..e64cabf6 100644
--- a/fvwm/conditional.c
+++ b/fvwm/conditional.c
@@ -782,7 +782,7 @@ void CreateConditionMask(char *flags, WindowConditionMask *mask)
if (tmp && *tmp)
{
fvwm_debug( __func__,
- "Use comma instead of whiespace to separate "
+ "Use comma instead of whitespace to separate "
"conditions");
} else {
if (allocated_condition != NULL)
--
2.30.2
Re [PATCH] 4/3 Enable EWMH debug messages with "bugopts debugrandr"
Put EWMH_GetWorkAreaIntersection debug messages in the "debugrandr" category.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 367de6c621cf768e13d3edb596c91176e2f62265 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 11:02:48 +0100
Subject: [PATCH 4/4] Enable EWMH debug messages with "bugopts debugrandr".
---
fvwm/ewmh.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/fvwm/ewmh.c b/fvwm/ewmh.c
index 8bbb2e8f..1f00ddb2 100644
--- a/fvwm/ewmh.c
+++ b/fvwm/ewmh.c
@@ -983,9 +983,13 @@ void ewmh_ComputeAndSetWorkArea(struct monitor *m)
width = m->si->w - (left + right);
height = m->si->h - (top + bottom);
- fvwm_debug(__func__, "monitor '%s': {l: %d, r: %d, t: %d, b: %d} "
- "{x: %d, y: %d, w: %d, h: %d}\n", m->si->name,
- left, right, top, bottom, x, y, width, height);
+ if (Scr.bo.do_debug_randr)
+ {
+ fvwm_debug(
+ __func__, "monitor '%s': {l: %d, r: %d, t: %d, b: %d} "
+ "{x: %d, y: %d, w: %d, h: %d}\n", m->si->name,
+ left, right, top, bottom, x, y, width, height);
+ }
if (
m->Desktops->ewmh_working_area.x != x ||
@@ -998,7 +1002,10 @@ void ewmh_ComputeAndSetWorkArea(struct monitor *m)
m->Desktops->ewmh_working_area.width = width;
m->Desktops->ewmh_working_area.height = height;
- fvwm_debug(__func__, "differ, so setting work area\n");
+ if (Scr.bo.do_debug_randr)
+ {
+ fvwm_debug(__func__, "differ, so setting work area\n");
+ }
ewmh_SetWorkArea(m);
}
@@ -1075,10 +1082,15 @@ void EWMH_GetWorkAreaIntersection(
int area_h = m->Desktops->ewmh_working_area.height;
Bool is_dynamic = False;
- fvwm_debug(__func__, "mon: %s {ax: %d, ay: %d, aw: %d, ah: %d\n",
- m->si->name, area_x, area_y, area_w, area_h);
- fvwm_debug(__func__, "mon: %s {x: %d, y: %d, w: %d, h: %d\n",
- m->si->name, *x, *y, *w, *h);
+ if (Scr.bo.do_debug_randr)
+ {
+ fvwm_debug(
+ __func__, "mon: %s {ax: %d, ay: %d, aw: %d, ah: %d\n",
+ m->si->name, area_x, area_y, area_w, area_h);
+ fvwm_debug(
+ __func__, "mon: %s {x: %d, y: %d, w: %d, h: %d\n",
+ m->si->name, *x, *y, *w, *h);
+ }
/* FIXME: needs broadcast if global monitor in use. */
@@ -,8 +1123,13 @@ void EWMH_GetWorkAreaIntersection(
*w = nw;
*h = nh;
- fvwm_debug(__func__, "mon: %s finalising: {x: %d, y: %d, w: %d, h: %d}\n",
- m->si->name, *x, *y, *w, *h);
+ if (Scr.bo.do_debug_randr)
+ {
+ fvwm_debug(
+ __func__,
+ "mon: %s finalising: {x: %d, y: %d, w: %d, h: %d}\n",
+ m->si->name, *x, *y, *w, *h);
+ }
return;
}
--
2.30.2
Re: [PATCH] 2/3 Sanitize screen related code indentation.
(No indentation with spaces.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From e04bcd721ea1ebbbf64eec7463cc4dadde7fb88c Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 14 Nov 2021 10:55:32 +0100
Subject: [PATCH 2/3] Sanitize screen related code indentation.
---
libs/FScreen.c | 85 --
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/libs/FScreen.c b/libs/FScreen.c
index bd274419..32ee78a7 100644
--- a/libs/FScreen.c
+++ b/libs/FScreen.c
@@ -332,7 +332,9 @@ monitor_assign_virtual(struct monitor *ref)
if (m == ref)
continue;
- memcpy(>virtual_scr, >virtual_scr, sizeof(m->virtual_scr));
+ memcpy(
+ >virtual_scr, >virtual_scr,
+ sizeof(m->virtual_scr));
}
}
@@ -443,7 +445,10 @@ scan_screens(Display *dpy)
char *name = XGetAtomName(dpy, rrm[i].name);
if (name == NULL) {
- fprintf(stderr, "%s: couldn't detect monitor with empty name\n", __func__);
+ fprintf(
+stderr,
+"%s: couldn't detect monitor with empty name\n",
+__func__);
exit (101);
}
@@ -570,40 +575,41 @@ monitor_dump_state(struct monitor *m)
}
if (m != NULL && m2 != m)
continue;
- fvwm_debug(__func__,
- "\tName:\t%s\n"
- "\tDisabled:\t%s\n"
- "\tIs Primary:\t%s\n"
- "\tIs Current:\t%s\n"
- "\tOutput:\t%d\n"
- "\tCoords:\t{x: %d, y: %d, w: %d, h: %d}\n"
- "\tVirtScr: {\n"
- "\t\tVxMax: %d, VyMax: %d, Vx: %d, Vy: %d\n"
- "\t\tEdgeScrollX: %d, EdgeScrollY: %d\n"
- "\t\tCurrentDesk: %d\n"
- "\t\tCurrentPage: {x: %d, y: %d}\n"
- "\t\tMyDisplayWidth: %d, MyDisplayHeight: %d\n\t}\n"
- "\tDesktops:\t%s\n"
- "\tFlags:%s\n\n",
- m2->si->name,
- (m2->flags & MONITOR_DISABLED) ? "true" : "false",
- (m2->flags & MONITOR_PRIMARY) ? "yes" : "no",
- (mcur && m2 == mcur) ? "yes" : "no",
- (int)m2->si->rr_output,
- m2->si->x, m2->si->y, m2->si->w, m2->si->h,
- m2->virtual_scr.VxMax, m2->virtual_scr.VyMax,
- m2->virtual_scr.Vx, m2->virtual_scr.Vy,
- m2->virtual_scr.EdgeScrollX,
- m2->virtual_scr.EdgeScrollY,
- m2->virtual_scr.CurrentDesk,
- (int)(m2->virtual_scr.Vx / monitor_get_all_widths()),
- (int)(m2->virtual_scr.Vy / monitor_get_all_heights()),
- monitor_get_all_widths(),
- monitor_get_all_heights(),
- m2->Desktops ? "yes" : "no",
- monitor_mode == MONITOR_TRACKING_G ? "global" :
- monitor_mode == MONITOR_TRACKING_M ? "per-monitor" :
- "Unknown"
+ fvwm_debug(
+ __func__,
+ "\tName:\t%s\n"
+ "\tDisabled:\t%s\n"
+ "\tIs Primary:\t%s\n"
+ "\tIs Current:\t%s\n"
+ "\tOutput:\t%d\n"
+ "\tCoords:\t{x: %d, y: %d, w: %d, h: %d}\n"
+ "\tVirtScr: {\n"
+ "\t\tVxMax: %d, VyMax: %d, Vx: %d, Vy: %d\n"
+ "\t\tEdgeScrollX: %d, EdgeScrollY: %d\n"
+ "\t\tCurrentDesk: %d\n"
+ "\t\tCurrentPage: {x: %d, y: %d}\n"
+ "\t\tMyDisplayWidth: %d, MyDisplayHeight: %d\n\t}\n"
+ "\tDesktops:\t%s\n"
+ "\tFlags:%s\n\n",
+ m2->si->name,
+ (m2->flags & MONITOR_DISABLED) ? "true" : "false",
+ (m2->flags & MONITOR_PRIMARY) ? "yes" : "no",
+ (mcur && m2 == mcur) ? "yes" : "no",
+ (int)m2->si->rr_output,
+ m2->si->x, m2->si->y, m2->si->w, m2->si->h,
+ m2->virtual_scr.VxMax, m2->virtual_scr.VyMax,
+ m2->virtual_scr.Vx, m2->virtual_scr.Vy,
+ m2->virtual_scr.EdgeScrollX,
+ m2->virtual_scr.EdgeScrollY,
+ m2->virtual_scr.CurrentDesk,
+ (int)(m2->virtual_scr.Vx / monitor_get_all_widths()),
+ (int)(m2->virtual_scr.Vy / monitor_get_all_heights()),
+ monitor_get_all_widths(),
+ monitor_get_all_heights(),
+ m2->Desktops ? "yes" : "no",
+ monitor_mode == MONITOR_TRACKING_G ? "global" :
+ monitor_mode == MONITOR_TRACKING_M ? "per-monitor" :
+ "Unknown"
);
}
}
@@ -973,7 +979,9 @@ int FScreenParseGeometry(
if (scr != NULL) {
m = monitor_resolve_name(scr);
- fprintf(stderr, "Found monitor with name of: %s (%s)\n", scr, m->si->name);
+ fprintf(
+ stderr, "Found monitor with name of: %s (%s)\n", scr,
+ m->si->name);
x = m->si->x;
y = m->si->y;
w = m->si->w;
@@ -1055,7 +1063,8 @@ int FScreenGetGeometry(
arg.mouse_ev = NULL;
arg.name = scr;
- FScreenGetScrRect(, FSCREEN_BY_NAME, _x, _y, _w, _h);
+ FScreenGetScrRect(
+ , FSCREEN_BY_NAME, _x, _y, _w, _h);
/* II. Interpret and fill in the values */
--
2.30.2
v3 changes
Thanks folks for keeping fvwm alive. I didn't find a reason to switch from 2.6.8 until now (it doesn't compile on Devuan 4 any more). About some immediately visible changes: * No problem with output going into a separate logfile. Destination could be sett-able on the command line instead of the environment. * Love the asciidoc documentation sources. The old change in documentation format back in the old days was part of the reason I didn't work on fvwm any more. * FvwmCpp is gone. Okay, can be easily replaced by scripting. No hard feelings. * No more errors with plain "-Wall -Werror". Good. * INSTALL file is gone. Bad. Required by GNU standards. * Third party (Go) sources in distribution = license trouble. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [fvwmorg/fvwm3] f51066: read: remove custom fgets logic and use fparseln()
On Thu, May 16, 2019 at 03:24:27AM -0700, Thomas Adam wrote: > When reading in a configuration file (or anything which uses the > Read/PipeRead command), there's always been a hard-limit of a > configuration line being no more than 1024 bytes. This was fine > historically, but this restriction is now rather limiting. Note that we've never really removed the limit because longer lines break the module interface. I.e., if a long line is transferred over the module pipe, strange things can happen because of mutilated lines. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fvwm 2.6.x title vs icon title bug
On Sat, Feb 18, 2017 at 11:35:48AM +0700, ?? wrote:
> Hello.
>
> 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.
> So, if someone is affected too by strangely behaving titles of
> _some_ apps, here is a patch.
>
> --- fvwm-2.6.7.o/fvwm/add_window.c
> +++ fvwm-2.6.7/fvwm/add_window.c
> @@ -586,7 +586,7 @@
> {
> format = (style->flags.has_icon_title_format_string) ?
> SGET_ICON_TITLE_FORMAT_STRING(*style) :
> - DEFAULT_TITLE_FORMAT;
> + DEFAULT_ICON_TITLE_FORMAT;
There's more broken than just the default format ffor icon titles.
> } else {
> format = (style->flags.has_title_format_string) ?
> SGET_TITLE_FORMAT_STRING(*style) :
> --- fvwm-2.6.7.o/fvwm/style.c
> +++ fvwm-2.6.7/fvwm/style.c
> @@ -2978,7 +2978,7 @@
>
> if (fmt_string == NULL)
> {
> - fmt_string = DEFAULT_TITLE_FORMAT;
> + fmt_string = DEFAULT_ICON_TITLE_FORMAT;
> }
>
> if (!__validate_titleformat_string(fmt_string))
> --- fvwm-2.6.7.o/fvwm/style.h
> +++ fvwm-2.6.7/fvwm/style.h
> @@ -5,6 +5,7 @@
>
> /* The default title in case the user doesn't supply one. */
> #define DEFAULT_TITLE_FORMAT "%n"
> +#define DEFAULT_ICON_TITLE_FORMAT "%i"
>
> /* access to the special flags of a style */
> /* call these with a pointer to a style_flags struct */
>
> --
> HTH, lynx.
> 494 lives.
>
>
>
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: CVS domivogt: * Write fvwm in lower case everywhere
Log message: * Write fvwm in lower case everywhere I disagree with this policy. (sigh, FVWM has been popping up all over the place since the last time I cahanged this).. That's because lower case acronyms are counter-intuitive uncommon. My opinion is that * Acronyms are counter-intuitive and uncommon. * Words written in capital letters offend the eye and are difficult to read. * Fvwm is just a name. Almost nobody cares what the letters stand for or whether they stand for anything. * In common language, words are written in lower case. * Documents teeming with MWM, EWMH, GNOME, FVWM, WINDOWFOO.PL, TAB, SPACE, META, KDE, QT, GTK, XPM, PNG, SVG, ICCCM, GTK+ etc. are simply difficult to read. * There have always been much more places where fvwm was written that FVWM. * Writing acronyms in capitals is technically wrong. EMWH does not stand for Enhanced Window Manager Hints (which is incorrect in English language) but for enhanced window manager hints. * In common language, words are written in lower case. * The executable's name is fvwm. * The tarball's name is fvwm-something.tar.gz. * Nobody who thinks FVWM is the better name ever made any effort to unify the spelling (which means to edit hundreds of files manually). The standard convention is to spell acronyms in capitals. I never thought of fvwm as an acronym. Ciao Dominik ^_^ ^_^ -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Re: PictureImageLoader stuff broken when using --without-xpm-library
Probably some of the latest changes is breaking this.
The attached patch fixes these errors and some more warnings.
Can someone please commit it?
*
In file included from /usr/include/zlib.h:34,
from /usr/include/png.h:398,
from Fpng.h:12,
from PictureImageLoader.c:46:
/usr/include/zconf.h:265: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'typedef'
/usr/include/zconf.h:274: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'Bytef'
In file included from /usr/include/png.h:398,
from Fpng.h:12,
from PictureImageLoader.c:46:
/usr/include/zlib.h:83: error: expected specifier-qualifier-list before
'Bytef'
/usr/include/zlib.h:114: error: expected specifier-qualifier-list before
'Bytef'
/usr/include/zlib.h:538: error: expected ';', ',' or ')' before '*' token
/usr/include/zlib.h:736: error: expected ';', ',' or ')' before '*' token
/usr/include/zlib.h:1009: error: expected ')' before '*' token
/usr/include/zlib.h:1024: error: expected ')' before '*' token
/usr/include/zlib.h:1047: error: expected ')' before '*' token
/usr/include/zlib.h:1260: error: expected ';', ',' or ')' before '*' token
/usr/include/zlib.h:1285: error: expected ';', ',' or ')' before '*' token
PictureImageLoader.c: In function 'PImageLoadCursorFromFile':
PictureImageLoader.c:873: error: 'FxpmInfo' undeclared (first use in this
function)
PictureImageLoader.c:873: error: (Each undeclared identifier is reported
only once
PictureImageLoader.c:873: error: for each function it appears in.)
PictureImageLoader.c:873: error: expected ';' before 'xpm_info'
PictureImageLoader.c:875: warning: implicit declaration of function
'XpmReadFileToXpmImage'
PictureImageLoader.c:875: error: 'xpm_info' undeclared (first use in this
function)
make[2]: *** [PictureImageLoader.o] Error 1
make[2]: *** Waiting for unfinished jobs
mv -f .deps/Parse.Tpo .deps/Parse.Po
make[2]: Leaving directory
`/var/tmp/portage/x11-wm/fvwm--r12/work/fvwm/libs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/x11-wm/fvwm--r12/work/fvwm'
make: *** [all] Error 2
*
It just compiles fine if I configure without the
--without-xpm-library flag.
Ciao
Dominik ^_^ ^_^
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
diff -u -x Makefile.in -x aclocal.m4 -x config.h.in -x configure -r fvwm-snap-20070716.orig/ChangeLog fvwm-snap-20070716/ChangeLog
--- fvwm-snap-20070716.orig/ChangeLog 2007-07-16 10:00:02.0 +0200
+++ fvwm-snap-20070716/ChangeLog 2007-07-16 12:34:22.0 +0200
@@ -1,5 +1,17 @@
2007-07-16 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
+ * libs/Fxpm.h:
+ fixed compile error
+
+ * libs/PictureImageLoader.c:
+ cleanup
+ (PImageLoadCursorFromFile):
+ fixed compilation without xpm library
+ (PImageLoadPng):
+ fixed compiler warning without png library
+
+2007-07-16 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
+
* libs/PictureImageLoader.c (PImageLoadCursorFromFile):
* fvwm/cursor.c (CMD_CursorStyle):
fixed compiler warning
diff -u -x Makefile.in -x aclocal.m4 -x config.h.in -x configure -r fvwm-snap-20070716.orig/libs/Fxpm.h fvwm-snap-20070716/libs/Fxpm.h
--- fvwm-snap-20070716.orig/libs/Fxpm.h 2007-07-16 10:00:02.0 +0200
+++ fvwm-snap-20070716/libs/Fxpm.h 2007-07-16 11:21:25.0 +0200
@@ -28,12 +28,12 @@
char *name;
char *value;
Pixel pixel;
-} FxpmColorSymbol;
+} FxpmColorSymbol;
typedef struct {
char *name;
unsigned int nlines;
char **lines;
-} FxpmExtension;
+} FxpmExtension;
typedef struct {
char *string;
char *symbolic;
@@ -41,7 +41,7 @@
char *g4_color;
char *g_color;
char *c_color;
-} FxpmColor;
+} FxpmColor;
typedef int (*FxpmAllocColorFunc)(
#ifdef __STDC__
Display*,Colormap,char*,XColor*,void*
@@ -88,7 +88,7 @@
FxpmAllocColorFunc alloc_color;
FxpmFreeColorsFunc free_colors;
void *color_closure;
-} FxpmAttributes;
+} FxpmAttributes;
typedef struct {
unsigned int width;
unsigned int height;
@@ -96,12 +96,12 @@
unsigned int ncolors;
FxpmColor *colorTable;
unsigned int *data;
-} FxpmImage;
+} FxpmImage;
typedef struct {
unsigned long valuemask;
unsigned int x_hotspot;
unsigned int y_hotspot;
-} FxpmInfo
+} FxpmInfo;
#endif
/* global definitions - */
diff -u -x Makefile.in -x aclocal.m4 -x config.h.in -x configure -r fvwm-snap-20070716.orig/libs/PictureImageLoader.c fvwm-snap-20070716/libs/PictureImageLoader.c
--- fvwm-snap-20070716.orig/libs/PictureImageLoader.c 2007-07-16 10:00:02.0 +0200
+++ fvwm-snap-20070716/libs/PictureImageLoader.c 2007-07-16 12:15:15.0 +0200
@@ -108,7 +108,7 @@
ext = path + strlen(path) - 3;
}
/* first try to load by extension */
- while(!done ext != NULL
Re: Condition Visible does not seem to work when xcompmgr is running.
On Mon, Jul 02, 2007 at 09:52:46PM +0200, Micha?? Kazior wrote: Hello, I posted about this issue on the fvwm forum at fvwm.lair.be and got redirected here. I would like to auto-iconify windows that are not visible on the screen anymore (i.e. the got totally overlapped by other windows). However the following code, does not work when xcompmgr is running at the same time: --begin-- All (CurrentPage, !Visible) Iconify True --end-- I have also tried running xcompmgr with different arguments, but with no effect. The Visible condition works perfectly if xcompmgr is not running though. I do not know if it is FVWM or xcompmgr that is at fault. I can only guess that xcompmgr suppresses VisibilityNotify events for windows. I use fvwm 2.5.21 (with support for: ReadLine, Stroke, XPM, PNG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XFT, NLS), xorg-server 1.3.0. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de signature.asc Description: Digital signature
Re: CVS renato: * Created function module_add_to_fdsets from events.c and module_interface.c
In the tests I'm calling the function GetFdWidth() twice for every
module, which may incur in a bit overhead..
There's a global var called fd_width. I don't know if I should use the
it instead, but supose it should be removed.. I've also considered the
use of a static global var to improve performance.
On the other hand, in this case we don't care for the number of
maximum opened fds - if the number is too big then the open pipe call
will fail. What we want is the max fdset size, so maybe we can just
use FD_SETSIZE.
That's what GetFdWidth() does, but the fd_width variable is there
for exactly this reason. I see the code is a mess now.
Suggestion:
** Remove fd_width in fvwm.c and GetFdWidth() in libs/System.c.
** Add a global variable and a function to fvwmlib.h:
extern const fd_set_size_t fvwmlib_max_fd;
void fvwmlib_init_max_fd(void);
** Define both in libs/System.c:
const fd_set_size_t fvwmlib_max_fd = (fd_set_size_t)-999;
void fvwmlib_init_max_fd(void)
{
/* init fvwmlib_max_fd with code from old
* GetFdWidth() function. */
}
** replace fd_width = GetFdWidth(); in fvwm.c with
fvwmlib_init_mx_fd();.
** Use fvwmlib_max_fd everywhere.
** If you are bored, do the same in all the modules :-P
So what's the best solution?
About the fd_width global, it is used for the select calls. I don't
know if it's better performance-wise to ask for the whole range of
possible pipes (like now) or keep the record of the bigger pipe fd..
Of course it would be faster during the select() calls, but input
is relatively rare. I don't think keeping a sorted list of open
module fds woulb be justified. After all, the fdset is just a
relatively small bit field, not megabytes of memory.
Ciao
Dominik ^_^ ^_^
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: CVS domivogt: * Fixed the TitleWarp menu style.
On Wed, Oct 25, 2006 at 10:37:22AM +0100, Tavis Ormandy wrote: On Mon, Mar 27, 2006 at 02:29:19PM -0600, FVWM CVS wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/03/27 14:29:19 Modified files: . : ChangeLog NEWS fvwm : menus.c modules/FvwmIdent: FvwmIdent.c Log message: * Fixed the TitleWarp menu style. Hello, I really liked this behaviour, is it possible to re-enable it as an option? Ever since this was introduced I've been launching the wrong applications :) What's the problem? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Transparency / Font Shadow weirdness
On Sun, Oct 01, 2006 at 03:17:13PM +0530, Kingsly John wrote: I have a transparent fvwmbutton which uses this colorset and font spec. Colorset 9 fg grey70, fgAlpha 90, Transparent, RootTransparent buffer, IconAlpha 90, fgsh black Font Shadow=1 1 SE:xft:Luxi Sans:Bold:pixelsize=13 When I set the wallpaper using fvwm-root -r the shadow comes out as red in color! Restarting fvwm sets the color right. Can you please provide a minimal config file that demonstrates the problem? (Without the fgsh black part it stays red even after the restart.) You can see the difference here.. http://img441.imageshack.us/img441/7140/fvwmfontcp3.png This doesn't seem to happen with all wallpapers, It happens with this particular one. http://img426.imageshack.us/img426/706/altabadia2lf1.png (around 1.3MB) I'm using fvwm-2.5.16 Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
fvwm-2.5.18 has been released
Tarballs and ANNOUNCE file are in the usual place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On Thu, Aug 31, 2006 at 04:13:56PM +0100, seventh guardian wrote: On 8/31/06, Harald Dunkel [EMAIL PROTECTED] wrote: There is another broken call to XGetWindowProperty() in ewmh.c, which seems to have been introduced recently. Attached is the patch. I guess it was already corrected? I've tried the patch, but it seemed that the changes were already there.. That's because I already committed the fix. There should have been a CVS mail about it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MapWindow directly after UnmapWindow
On Tue, Aug 29, 2006 at 10:18:30PM +0200, Viktor Griph wrote:
[snip]
The idea was to check for a MapRequest of FW_W_PARENT before reparenting
the window, while the server is grabbed, and if sush event exists not
unparent it. The problem is only if the window is mapped again before the
client is reparented to root.
Would this patch really break anything? It does not use the windowid of
the client, but only that of the decorations, and since the decorations
haven't been destroyed yet this can't be a reused window id. It does solve
the problem with the MapWindow immediatly after the UnmapWindow call, and
does so without triggering re-placement of the window.
But if the application has changed any window properties (like the
name etc.), fvwm does not notice.
--- fvwm/events.c 20 Mar 2006 20:32:35 - 1.518
+++ fvwm/events.c 29 Aug 2006 20:07:59 -
@@ -3624,6 +3624,13 @@
XUnmapWindow(dpy,
fw-wmhints-icon_window);
}
}
+ else if (FCheckTypedWindowEvent(
+ dpy, FW_W_PARENT(fw), MapRequest, dummy))
+ {
+ XMapWindow(dpy, te-xunmap.window);
+ MyXUngrabServer(dpy);
+ return;
+ }
else
{
RestoreWithdrawnLocation(fw, False, Scr.Root);
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: MapWindow directly after UnmapWindow
On Tue, Aug 29, 2006 at 10:18:30PM +0200, Viktor Griph wrote:
On Tue, 29 Aug 2006, Viktor Griph wrote:
On Tue, 29 Aug 2006, Dominik Vogt wrote:
On Mon, Aug 28, 2006 at 08:07:31PM +0200, Viktor Griph wrote:
On Mon, 28 Aug 2006, Andreas Ehliar wrote:
I have a problem with fpga_editor as reported in bug 4062. With some
help from #fvwm I managed to find something suspicious. fpga_editor
does an UnmapWindow request and a MapWindow request right after each
other.
An example program that does the same is located at
http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c .
The example program will show a window for 1 second and it will then
disappear if running under fvwm.
The bug seems very similar to the bug reported in this thread:
http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html
This bug is related to the handling of MapRequests in fvwm. (See
http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.)
I know of three different ways to address it, but don't know if there is
any downside to them.
The different approches are
1) Change AddWindow to look at the trigger event for the mapped window if
the window in the execution context is gone. I think this is too late in
the line to address this.
2) Change the Handling of MapRequest to call AddWindow with the window
being mapped in the execution context. (I think this is better than 1)
I don't actually understand the problem or the suggested
solutions. Can you explain it a bit?
The problem is that, if the program calls MapWindow before the window has
been reparented to the root it will get a XMapRequest with window= old
decoration parent window and window set to the client. Handle event sets
the window of the execution context to xany.window (parent in this case)
if the parent window is not root. When this is a destroyed decoration it
will be passed to AddWindow in the function called from HandleMapRequest.
the suggested fix would be to modify the context to have the window of the
MapRequest event set to the context before calling AddWindow if the
trigger event is a MapRequest. (I'm not entirely sure on how
CaptureAllWindows works, but I believe this logic would be ennouh to keep
it working correctly.)
3) Decide that Maps following Unmaps is a bad application behaviour and
have the handling of Unmap check if the window is about to remap before
deciding to destroy it.
That's wrong. If a window is unmapped the window structure must
be destroyed. There is no reliable way to find out if the window
is remapped or if it was destroyed and a different window got the
same id.
The idea was to check for a MapRequest of FW_W_PARENT before reparenting
the window, while the server is grabbed, and if sush event exists not
unparent it. The problem is only if the window is mapped again before the
client is reparented to root.
Would this patch really break anything? It does not use the windowid of
the client, but only that of the decorations, and since the decorations
haven't been destroyed yet this can't be a reused window id. It does solve
the problem with the MapWindow immediatly after the UnmapWindow call, and
does so without triggering re-placement of the window.
--- fvwm/events.c 20 Mar 2006 20:32:35 - 1.518
+++ fvwm/events.c 29 Aug 2006 20:07:59 -
@@ -3624,6 +3624,13 @@
XUnmapWindow(dpy,
fw-wmhints-icon_window);
}
}
+ else if (FCheckTypedWindowEvent(
+ dpy, FW_W_PARENT(fw), MapRequest, dummy))
+ {
+ XMapWindow(dpy, te-xunmap.window);
+ MyXUngrabServer(dpy);
+ return;
+ }
else
{
RestoreWithdrawnLocation(fw, False, Scr.Root);
I have committed a fix for this. At the end of HandleUnmapNotify,
check for pending MapRequests for that window, replace the window
and parent with the client window and root, then call
dispatch_event immediately. (See attached patch).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Index: events.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/events.c,v
retrieving revision 1.518
diff -u -B -b -u -r1.518 events.c
--- events.c20 Mar 2006 20:32:35 - 1.518
+++ events.c30 Aug 2006 09:12:20 -
@@ -3512,11 +3515,15 @@
int dstx, dsty;
Window dumwin;
XEvent dummy;
+ XEvent map_event;
const XEvent *te = ea-exc-x.etrigger;
int weMustUnmap;
Bool focus_grabbed;
Bool must_return = False;
+ Bool do_map = False;
FvwmWindow * const fw = ea-exc-w.fw;
+ Window pw;
+ Window cw;
DBUG(HandleUnmapNotify, Routine Entered);
@@ -3545,6 +3552,8
Re: some 64bit cleanup on CVS head (XGetWindowProperty())
On Sun, Aug 27, 2006 at 10:25:33AM +0200, Harald Dunkel wrote: Harald Dunkel wrote: Hi folks, Attached you can find a patch to fix XGetWindowProperty in various sources. This makes at least Xine work _much_ better on 64bit Debian. PS: Better means: The decorations around the popups and the main window are correct. Okay, I've applied the patch. Can you please provide ChangeLog entries for it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MapWindow directly after UnmapWindow
On Mon, Aug 28, 2006 at 08:07:31PM +0200, Viktor Griph wrote: On Mon, 28 Aug 2006, Andreas Ehliar wrote: I have a problem with fpga_editor as reported in bug 4062. With some help from #fvwm I managed to find something suspicious. fpga_editor does an UnmapWindow request and a MapWindow request right after each other. An example program that does the same is located at http://www.da.isy.liu.se/~ehliar/priv/map_unmap.c . The example program will show a window for 1 second and it will then disappear if running under fvwm. The bug seems very similar to the bug reported in this thread: http://www.mail-archive.com/fvwm@hpc.uh.edu/msg08195.html This bug is related to the handling of MapRequests in fvwm. (See http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15491.html.) I know of three different ways to address it, but don't know if there is any downside to them. The different approches are 1) Change AddWindow to look at the trigger event for the mapped window if the window in the execution context is gone. I think this is too late in the line to address this. 2) Change the Handling of MapRequest to call AddWindow with the window being mapped in the execution context. (I think this is better than 1) I don't actually understand the problem or the suggested solutions. Can you explain it a bit? 3) Decide that Maps following Unmaps is a bad application behaviour and have the handling of Unmap check if the window is about to remap before deciding to destroy it. That's wrong. If a window is unmapped the window structure must be destroyed. There is no reliable way to find out if the window is remapped or if it was destroyed and a different window got the same id. I'm most interested in knowing if there would be any downside with solution 3, in which case solution 2 is the one to take. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Handling of MapRequests
On Sun, Aug 27, 2006 at 08:51:13PM +0200, Viktor Griph wrote: What is the reason to send the parent window in a map request if it's not root? This may cause a window to disappear if it were first unmapped, and then mapped again if fvwm did not reparent it back to the root window before destroying the old parent window (which will be the new window sent to add window in that case). I don't actually understand what you are trying to say. MapRequest ewvents are not sent by fvwm but generated by the X server and sent to fvwm. Is there anything that makes using the xmaprequest.window uncunditionally for all MapRequests? Or should the unmap nofify handler check for pending map requests of the window before destroying it in the first place? No, see my reply in that other thread. Can you please try to explain your question again? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * use ewmh allowed actions to track window movability
On Thu, Aug 10, 2006 at 12:58:06PM +0200, Viktor Griph wrote: On Thu, 10 Aug 2006, Dominik Vogt wrote: On Thu, Aug 10, 2006 at 04:24:48AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/08/10 04:24:48 Modified files: . : NEWS modules: ChangeLog modules/FvwmPager: FvwmPager.h x_pager.c Log message: * use ewmh allowed actions to track window movability in pager Hm, I guess that works, but it ties pager actions to the configuration of the ewmh stuff. I have long been planning to allow the user to disable specific ewmh features. If a user did that, the pager would break. Would an option to disable allowed actions really be useful to a user? I meant an option to disallow window movement via EWMH messages. EWMH applications could be disallowed to move windows this way, but the pager should still be allowed to. it does it to tell applications what actions are possible on a window. The only thing I can think of that can break it is if a EWMHFixedPosition style was added, that makes the ewmh allowed actions differ from the fvwm allowed actions. In event of that allowed actions could be made part of the configure window package. If that's the only pitfall, then currently a comment in is_function_allowed warning about it would be ennough to avoid unintended breakage. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On Wed, Aug 09, 2006 at 12:07:40AM +0200, Viktor Griph wrote: [snip] But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. I'm afraid there is more to the issue than just that. The issue remains, that if, for instance, the style FixedPosition is changed no updated config info is sent to the module, so the flag would get outdated. Of course. Nobody said it would be this easy :-) You have to set the flag flags-do_update_modules_flags in check_window_style_change() (styles.c) to 1. The module message will then be sent. Also, thinking about it: Aren't the pager window movements seen by fvwm as application induced movements since toy use X rather than the fvwm Move builtin? Yes, you're right. This isn't optimal since the action is clearly triggered by the user, not an application. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * don't map picture icon windows on move
On Wed, Aug 09, 2006 at 04:01:13PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 06/08/09 16:01:13 Modified files: . : ChangeLog fvwm : move_resize.c modules: ChangeLog modules/FvwmPager: x_pager.c Log message: * don't map picture icon windows on move * remove invalid icon-bug workaroud The patch is not good. If an icon with a pixmap and a tiltle is moved. the title is gone afterwards. The correct fix is tomap the pixmap/title only if the icon is on the current desk. I've committed a fix. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * if 0 (with comments) questionable code doing double work
On Wed, Aug 09, 2006 at 03:36:12PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 06/08/09 15:36:12 Modified files: modules: ChangeLog modules/FvwmPager: x_pager.c Log message: * if 0 (with comments) questionable code doing double work * all window moves use fvwm builtin * temporary workaround erratic icon behaviour From x_pager.c: /* griph: Why does it move the windows off screen if the * desk has been changed? */ I have no idea what this code was intended for. It's not just useless, it's even buggy: if you move a window from a different desk out of the pager and then cancel the move with the Escape key, it ends up in the void. With your patch it is sent back to the original position when it was dragged out of the pager (which isn't perfect, but much better than just vanishing). /* griph: isn't this almost what Move Pointer does later? */ The additional Move looks pretty useless to me. The new position is overridden immediately by Silent Move Pointer. /* This used to move icon windows with * XMoveWindow, and non-icons with * Silent Move, negative coordinates * corrected by display width and * border width and title hight added. * * The if 0:ed code works as before but * with * fvwm moving the icons. I believe it's * incorrectly using at least the title * height /griph */ I don't know whether the new code is better. I assume you have tested it with titles on all four sides as well as windows without a title. The calculation in the old code is definitely incorrect as it ignores the title direction. /* griph: is't this moving to almost where Move Pointer * will move the window next? */ See above. I think all the code in the #if 0s should be removed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconMan: debug code cleanup
On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: icon movement tracking
On Mon, Aug 07, 2006 at 06:25:18PM +0200, Viktor Griph wrote: Should the flag tracking icon movement be set by MoveToPage? Currently it's not, which makes icons jump back to the initial page if do for example 'Style * IconTitle' if an icon has been moved to another page by MoveToPage. On a sidenote the same problem exists whenever moving icons with the pager, even if they are kept on the same page. That behaviour is certainly wrong. But as far as I know the flag just says that if the window is iconified again it should appear at the same position relative to its page. Instead, moving an icon by one or more full pages should move the underlying window geometries (normal and maximized (if applicable) by the same distance. This is a bit tricky, but if you make an initial patch I would take a look at the issue. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On Tue, Aug 08, 2006 at 04:18:41PM +0100, seventh guardian wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? The very first issue is that there is no defined way of choosing the alias. From what I see in the code, it was suposed to have the very first user argument as an alias (standard). Since some modules don't use (respect?) this, I guess the effort was undermined by the back-compat issues.. But this can be partially tackled if we add a command for the modules to request their alias in the fvwm internal data. Is it worth continuing the job? Is it safer to start an experimental side branch on this? Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. No, it isn't. It has some areas that are hardly tested at all, and some features that can not be released in the current state (see the corresponding to-do file for details). After that we may change everything to our heart's desire (unless we want a 2.8 release before 3.0). It's definitely more stable than some other release programs Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. But there is a soulution. Extend the config win packet with a flag that indicated whether a window can be moved by the user, i.e. the return code of the function that determines whether the window can be moved or not. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconMan: debug code cleanup
On Tue, Aug 08, 2006 at 07:28:32PM +0100, seventh guardian wrote: On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Good, I'll do it then. BTW, do you think typo corrections should be mentioned in the changelog? Only if they are the only change or if they affect functionality (e.g. if a typo in an option name is corrected). I'm tempted to remove them, but need a core-dev We don't have such a concept. Everybody is welcome to help. All I do is try to explain the tiny bits of design that fvwm has and help you with some knowledge about the larger picture (not everything happened by accident). opinion.. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Tracking flag changes from modules
On Mon, Aug 07, 2006 at 07:26:40PM +0200, Viktor Griph wrote: On Mon, 7 Aug 2006, Dominik Vogt wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). I see that the flags are part of M_CONFIGURE_WINDOW. However, this package is not sent when styles that affect flags are changed, so the flags will be outdated until some other window operation that results in a new config message to be sent. Looking at is_function_allowed in decorations.c it seems as if the move action is goverened by the said flag and mwm hints. Would it be wrong to reimplement a check in the pager for if move is allowed? Yes, it would be wrong. To do so the pager would have to know the mwm functions hints and changes in styles would have to generate configure messages. I'm unhappy that the flags are sent at all. It's just a hack. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmIconMan: a few trivial fixes
On Sat, Aug 05, 2006 at 10:09:40PM +0400, Serge (gentoosiast) Koksharov wrote: Hi, From attached patch's ChangeLog: * FvwmIconMan/FvwmIconMan.1.in: documented ShowOnlyFocused option. fixed typo. * FvwmIconMan/readconfig.c (read_in_resources): corrected warning message when an argument to Shape option is omitted. Done. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FvwmForm: WM_DELETE_WINDOW support
On Thu, Aug 03, 2006 at 02:52:34PM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Attached patch adds WM_DELETE_WINDOW support to the 'FvwmForm' module. Note, that if 'GrabServer' command is set, for obvious reasons it is impossible to close window by clicking close button on window's title. Committed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Manpage fix for 2.5.17: Wait command.
On Sat, Jul 29, 2006 at 10:21:35PM +0100, Thomas Adam wrote: On Sat, 29 Jul 2006 10:50:21 +0200 Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006 at 11:30:19AM +0100, Thomas Adam wrote: Scott -- On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley [EMAIL PROTECTED] wrote: Hi Thomas, I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X series is the only one to be fixed) for the Wait command description. The description says initially that the command waits of windowname. This is parly true -- the code in builtins.c apparently also checks for the window's tile, class and resource (just like how the style command works). I feel this needs to be reflected in its description ... +.BI Wait [ windowtitle | windowclass | windowresource ] Personally, I think it would be prudent to stick with windowname here. A novice user might think it appropriate to specify, say, a window resource then be surprised to learn that some other window with a matching _title_ was matched. That's fine, and it makes sense of course. Quite often a window's name (as it appears on the titlebar) is taken from WM_TITLE anyway. How about: Wait windowname This command is intended to be used in fvwm functions only. It causes execution of a function to pause until a new window matching windowname appears. A window can match windowname on either its title, class or resource. This is particularly useful in InitFunction if you are trying to start windows on specific desks or pages: It's still not perfect - any suggested improvements? Why not just use the same text as the style command: stylename can be a window's name, class, or resource string. It may contain the wildcards '*' and '?', which are matched in the usual Unix filename manner. Stylename should be replaced by something neutral, maybe just window. That works for me, but other than agreeing with it, there's nothing more I can do to correct it. :) There is. You could make another patch and hope you'll eventually bother me enough to get commit privileges :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Patching FvwmButtons to use Balloons (tooltips).
On Mon, Jul 31, 2006 at 03:10:08PM +0100, Thomas Adam wrote: Before I attempt to do this, I just wanted to make sure that this is something worthwhile doing. Currently, FvwmPager is about the only module that implements balloons to easily tell which window is which. For a long time now, one of the biggest feature requests has been for FvwmButtons to support a similar feature. (I have no doubt if we get this right, FvwmIconMan might follow, since this has an applicable use for balloons also.) Before I do this though I just want to check with you to make sure my approach is correct. I was thinking of using libs/FTips.h to do this in FvwmButtons since this lib has been present for a while but never used. I assume it is a refactor of what FvwmPager currently has [1]. Yes, this is all correct. How should balloons work in FvwmButtons? I was thinking of something akin to the following: *FvwmButtons: BalloonTitleFormat %t Where '%w' could be the swallowed window's title. I wouldn't mind. Just allow to specify a balloon string manually or display the button's title or swallow string otherwise. Although this represents some problems since not all FvwmButtons have swallowed windows, because they're there to perform some action. So, I am assuming instead such balloons would be used on a per-button basis with the user supplying the string, as in: *FvwmButtons: (12x60, Swallow (...) MyApplication \ Exec exec MyApplication, Balloon This is MyApplication) Within this of course, perhaps one could then use some form of '%t', '%i' symbols to represent a window's title or icon name without having to do it manually for swallowed windows. I would assume that for sundry options such as: BalloonColorset n That would be a global option to FvwmButtons rather than a per-button option? Yes, global. (I say this only because FvwmPager does it this way -- but that doesn't mean to say it's correct. :P) I'm open to suggestions on how to do this -- I can envisage some updates to FTips.h to accommodate some of this. I've not looked too deeply into it yet, and wanted to seek approval/recommendations, etc., before I went ahead to try and do this. We're not using Ftips yet. Feel free to make changes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Manpage fix for 2.5.17: Wait command.
On Fri, Jul 28, 2006 at 11:30:19AM +0100, Thomas Adam wrote: Scott -- On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley [EMAIL PROTECTED] wrote: Hi Thomas, I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X series is the only one to be fixed) for the Wait command description. The description says initially that the command waits of windowname. This is parly true -- the code in builtins.c apparently also checks for the window's tile, class and resource (just like how the style command works). I feel this needs to be reflected in its description ... +.BI Wait [ windowtitle | windowclass | windowresource ] Personally, I think it would be prudent to stick with windowname here. A novice user might think it appropriate to specify, say, a window resource then be surprised to learn that some other window with a matching _title_ was matched. That's fine, and it makes sense of course. Quite often a window's name (as it appears on the titlebar) is taken from WM_TITLE anyway. How about: Wait windowname This command is intended to be used in fvwm functions only. It causes execution of a function to pause until a new window matching windowname appears. A window can match windowname on either its title, class or resource. This is particularly useful in InitFunction if you are trying to start windows on specific desks or pages: It's still not perfect - any suggested improvements? Why not just use the same text as the style command: stylename can be a window's name, class, or resource string. It may contain the wildcards '*' and '?', which are matched in the usual Unix filename manner. Stylename should be replaced by something neutral, maybe just window. That's better. I still think it is wise to specify in the syntax for the command the fact that one can have: windowname, windowclass, windowresource -- and while I realise this forces a slight amount of Xlib knowledge onto the user, it does clarify the list of options one can use to that command. When I first read it I was confused, since it did (to me) read as though the window's name was only considered. Note that in the function example accompanying the Wait command's description, I have taken the liberty of replacing the function's use of the Desk command with GotoDesk since this is now the preferred command to use. Ok. ThisWindow (thomas_adam) Destroy ThisWindow (thomas_adam) Wait godo :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Title font color broken
On Tue, Jun 06, 2006 at 03:29:39PM -0400, Dan Espen wrote: Serge (gentoosiast) Koksharov [EMAIL PROTECTED] writes: On Sun, Jun 04, 2006 at 11:15:29AM +0200, Dominik Vogt wrote: Unfortunately I never got any feedback on this from the person who reported it first. The problem was that in some cases the GC used to draw the title was not set before drawing, but it seems the old code relied on this not being done. I'd be grateful if someone could look into this problem or at least give me a minimal config to reproduce it. I can confirm Dan's bugreport. And it easily reproducable with minimal config: I compile FVWM like this: aclocal autoheader automake --add-missing autoreconf ./configure --prefix=$HOME/usr --oldincludedir=$HOME/usr/include \ --enable-xft --disable-xinerama --enable-iconv --disable-bidi \ --enable-perllib --enable-nls --enable-gtk --with-x --without-rplay-library \ --without-gnome make make install Then I move entire ~/.fvwm directory somewhere: $ mv ~/.fvwm ~/usr/src Create new empty directory: mkdir ~/.fvwm Create '~/.fvwm/config' file consisting of two lines: Style * ForeColor red Style * HilightFore red Launch FVWM and see that titles of both active and inactive windows are black, but not red. I hope you can reproduce it as well and fix this bug. If not, you can provide me with instructions what to do next and I'll be more than glad to help. Dominik posted a patch containing the commit that caused the problem. He asked for help trying to recreate the original problem he was trying to patch. We could just revert his patch, but the original problem would remain unsolved. I haven't had any time to look into this yet. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Where did the MenuStyle ActiveBack go?
I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Ah, It's a relic of the patch splitting AftiveFore and HilightBack. I probably thought about renaming HilightBack, but gave up the idea in favour of the ActiveColorset option. It's safe to remove it from the man page (or replace it with HighlightBack where appropriate). Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: CVS scott fvwm-web: Updated on-line man pages for 2.5.17.
On Fri, Jul 21, 2006 at 10:51:35AM +0100, seventh guardian wrote: Updated on-line man pages for 2.5.17. Could there be an easy way to do the update automatically? There is a script to convert the manpages to php. The problem is that the release building instructions in doc/DEVELOPER don't mention it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: MenuStyle options - negate or not to negate?
On Fri, Jul 21, 2006 at 03:56:00PM +0100, seventh guardian wrote: Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore This is the right decision. or MouseWheel TrianglesUseFore Nope. Let us consider now that the way to negate the styles is now explained on the man page. Note that there are many more styles and options that could have a !-negation, bui I don't want to tackle them now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
fvwm-2.5.17 has been released and uploaded
Tarballs and ANNOUNCE file are in the usual place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Adding the possibility of not compiling deprecated code ?
On Mon, Jul 17, 2006 at 07:46:24PM +0100, Thomas Adam wrote:
On Mon, Jul 17, 2006 at 06:19:48PM +0100, seventh guardian wrote:
This idea just came into my head: why not #ifdef'ing the deprecated
code and having configure.ac option --disable-backcompat?
It's all about compatibility and maintainability. We once had
*13* different configure switches, and just compiling fvwm with
any combination of two options turned on or off took hours. This
(and other reasons explained in detail in the paper #ifdef
considered harmful) is why I don't want any new #ifdefs in the
code.
Since there is so much old and weird stuff in fvwm, we planned to
clean it all up in 3.0 - although there is little hope at the
moment to start this work anytime soon.
Examples:
User A has an old config. So he downloads the new package, compiles it
and installs it just like he allways did.
User B has a new config and wants to compile fvwm so that it doesn't
waste time/space looking for deprecated options. This could make
fvwm run a tiny bit faster (?), and also would allow user B to see
if its config is up-to-date (i.e., not using deprecated options). He
downloads the new package, runs configure --disable-backcompat and
compiles it.
Interesting idea. The only speed increase I can see is that the
parser doesn't have to deal with those options. Above and beyond that,
there's no other speed increase that I can foresee.
Personally though, I'd much rather leave this process to the user.
There have aleady been attempts at writing small parsers such as
fvwm-convert-2.{4,6} -- although they're not briliant they do a good
enough job. I don't know of many people that use them though.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: bug: 'CopyMenuStyle' command don't copies 'TitleColorset'
On Mon, Jul 17, 2006 at 01:55:47PM +0400, Serge (gentoosiast) Koksharov wrote: Hello, I hope I'm not too late and 2.5.17 still not released. Today I found a bug in menu code: 'CopyMenuStyle' don't copies recently introduced 'TitleColorset'. Attached patch fixes this. Happy release have a good time everyone Thanks. I'll apply that patch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Flags - is negation prefered?
On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: bugfix with clearing 'NoIcon' style
On Sat, Jul 15, 2006 at 03:55:17AM +0400, Serge (gentoosiast) Koksharov wrote: On Fri, Jul 14, 2006 at 12:28:45AM +0200, Dominik Vogt wrote: Um, if the manpage is not clear enough, it should be reworded. The NoIcon style is *of course* overridden by specifying an icon, Oh, I missed this nuance. But I still think that my change is useful. Author which implemented current logic most likely assumed that 'NoIcon' hides icon completely. But it's not true. For example, user using 'FvwmIconBox' module may want to change icon of one of his applications. And with current code 'NoIcon' style will be reset which not that he wants. I.e., 'NoIcon' doesn't hide icons, all this style does is hide them from root window but they still can be used in modules. I'm not sure I understand what you are saying. Can you please rephrase that and add an example, that shows in which way things work differently with that patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * add variable filters
On Fri, Jul 14, 2006 at 05:30:03PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 06/07/14 17:30:03 Modified files: . : ChangeLog NEWS fvwm : expand.c fvwm.1.in libs : Strings.c Strings.h Log message: * add variable filters * make backslash escape character within $[...] expressions If you write such patches that are monitored by several developers it would be nice to explain what you are doing and how. We have to be very careful with big changes in the parsing code because it has the potential to break everything. Personally I want to proofread such changes. The syntax I quoted that Mikhael suggested has not really been thought about a lot. It's just an ad-hoc idea. Now that you implemented it, I think it has several general issues: * There is currently no way to quote a literal string, which is a very important feature. It would allow users to write monsters like this more easily: + I PipeRead 'cd $HOME/.fvwm/palettes; /bin/ls *.pal | sed -e \s:\\(.*\\)\\(\\.pal\\):+ \\1 Function SetPalette \\1\\2:\' * The syntax is too verbose. The strings you have to write eat up too much space. Also, the name filters is misleading. I suggest to follow zsh's example: $[(flags)name] Where name is the parameter name itself and flags describes the modifications to apply to the expansion process. Flags: qstyle[n] (quote) Quote the string n times using the given style. style can be one of q quote normally for use as a token mi quote for use as a menu item label mt quote for use as a menu title l (literal) Quote a literal string, i.e. everything up to the closing brace. r0 (recursive expansion off, default) r1 (recursive expansion on) Enable or disable recursive expansion ($[$[X]]) Note: If the flags l and r1 are present, recursive expansion takes place first, and the result is used as literal input for further processing - it is *not* interpreted as a variable name. s[n] (split) Split string into individual tokens (by removing n levels of quotes and whitespace). n defaults to 1. t (tokenize) Treat the resulting string as a single token (Useful in ranges). Examples: With X=foo`bar`, $0=0, $1=1, ... (without the quotes): $[(qq)X] -- 'foo`bar`' $[(s1qq)X] -- 'foo' 'bar' $[(lqq2)foo`bar`] -- 'foo`bar`' $[(lr1)X] -- foo`bar` $[(qq)1-3] -- '1' '2' '3' $[(tqq)1-3] -- '1 2 3' Maybe flags should be separated by colons to allow more and longer flag names like $[(literal:qq)foo bar] Thinks that are not good in the current patch: * I think we shouldn't have different styles of quoting filters. Just quote: should be enough. This is because quoting is just meant to be used *internally by fvwm*. And fvwm does not care wether tokens are quoted by , ', ` or \. Fvwm could just choose the type of quotes that has the shortest result. A string quoted this way can *not* be passed to a shell for example. * It should be possible to add multiple levels of quotes in a single filter (usefull in above example). * The menu: filter should be split into two. In menu titles, the characters ^, @, % and * have to be quoted (by doubling them). In menu item labels, %, and * have to be quoted. In either case, the TAB character has to be quoted too. * The glob: filter seems to promise something it can not live up to. It can *not* be used for shell command quoting. Other than that I see no purpose in that specific filter. It should be removed. * The noquote: filter should be removed. * In constructs like $[$[X]], if X is quote:foo, the result should be the contents of the variable quote:foo, not the quoted result of the variable foo. (I did not check how the code qorks now). Please take this as a base for discussion, *not* as instructions to change the code now! Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: * add variable filters
On Sun, Jul 16, 2006 at 02:42:03PM +0200, Viktor Griph wrote: On Sun, 16 Jul 2006, Dominik Vogt wrote: Please take this as a base for discussion, *not* as instructions to change the code now! So, should the current patch to expand.c and the manpage be reverted until the system has been decided on? The functions in Strings.[ch] would still be usful. Hm, I was thinking about releasing 2.5.17 in the next couple of days, once we have tested the changes in the positional parameter expansion code. Obviously the new code gets in the way. I suggest we * remove the patch for now (note that I reformatted the manpage), * test the positional parameter code thoroughly, * release 2.5.17 * re-apply the patch (or its successor patch). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Fri, Jul 14, 2006 at 09:07:21AM +0200, Viktor Griph wrote: On Fri, 14 Jul 2006, Scott Smedley wrote: I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. There is something wrong with __eae_parse_range. I'm not that good on sscanf, but I think that it will match %u-%n even for 0 and return a good number, meaning that n will have a random value. Yes, one big problem is that %n may or may not increase the return code by one, so if rc = scanf(..., %u-%n, ...); returns one, this can mean is parsed just the integer and stopped, or it parsed the integer, found a '-' and assigned the %n too. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Fri, Jul 14, 2006 at 10:18:28AM +0200, Viktor Griph wrote: On Fri, 14 Jul 2006, Dominik Vogt wrote: On Fri, Jul 14, 2006 at 09:07:21AM +0200, Viktor Griph wrote: On Fri, 14 Jul 2006, Scott Smedley wrote: I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. There is something wrong with __eae_parse_range. I'm not that good on sscanf, but I think that it will match %u-%n even for 0 and return a good number, meaning that n will have a random value. Yes, one big problem is that %n may or may not increase the return code by one, so if rc = scanf(..., %u-%n, ...); returns one, this can mean is parsed just the integer and stopped, or it parsed the integer, found a '-' and assigned the %n too. Fixed. sscanf seems to not be very restrictive when it comes to unsigned integers. It seems as if it accepts signed integers as well. At least $[-1] hang fvwm now. It doesn't actually hang but tries to skip 2^32-1 tokens. It's a but in Parse.c. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, Jul 13, 2006 at 09:16:24AM +0200, Viktor Griph wrote: On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? I use the fvwm prefix to document that we modified its meaning. If we had just #define O_NOFOLLOW 0 someone might rely ona that flag although it's just a dummy to make the compiler happy. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. 3) As I said in an earlier message, PeekToken never returns an empty string. Calling PeekToken(, ...) returns a NULL pointer which the code accessed later. I've fixed all three. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, Jul 13, 2006 at 11:01:13AM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
Is it really neccessary to defene everything with FVWM_ as a prefix? If
it's not already defined, why not define it using the expected name?
I use the fvwm prefix to document that we modified its meaning.
If we had just
#define O_NOFOLLOW 0
someone might rely ona that flag although it's just a dummy to
make the compiler happy.
Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just
O_NOFOLLOW in there as well. It was all the stat-wrappers that I was
concerned about. The code use many of them unwrapped already, so if there
is a chance that some of them might not be defined it would be better to
provide them, with the assumed values you did, under the name expected by
the programmer.
There's really no final word on how to handle portability issues
yet. For maintenance reasons, we need to avoid ifdef'ed code as
much as possible. If we can't cope without ifdefs in some place,
they should be only in a single wrapper file (libs/FShape.h is an
example). Ifdefs in the code can easily be replaced with
constructs like this.
in .c file:
#ifdef FOOBAR
some(code);
#endif
becomes:
in some .h file:
#ifdef FOOBAR
# define USE_FOOBAR 1
#else
# define USE_FOOBAR 0
#endif
and in the .c file:
if (USE_FOOBAR)
{
some(code);
}
A big advantage is that *all* code is compiled, regardless of the
platform's features. The compiler should be smart enough to
optimise code like if (0) some(code);.
The latest way to go is to provide dummy functionality that
satisfies the original interfaces and put it in if (0) when it's
not used.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Removing gnome support from FvwmGtk
On Thu, Jul 13, 2006 at 12:18:02AM +0100, seventh guardian wrote: On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). So, what does this section from the FvwmGtk-manpage mean: .IP *FvwmGtk: RCFile \fBfile\fP Note that this command should be issued before defining any menus or dialog. Hint for GNOME users: If you add instances of this command for the standard GNOME rc files, switching themes via the control-center will apply to FvwmGtk widgets as well, giving a very integrated appearance of the desktop. yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? If you're referring to the gnome libs: FvwmGtk is the orly place where they are needed. If you mean the GNOMe WM hints: we should keep them. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. * Currently, $* is broken too as it does not remove quoting but just copies the input string. * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
Sorry, I've just removed your latest patch. The only difference between the old and new param style is now that $* does not dequote arguments while $[*] does. I'm not sure that this is good. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 05:00:27PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Scott Smedley wrote:
Hi all,
I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:
Echo $[0]
I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:
if (input[m] == ']')
Then I get a SEGV because this is an illegal memory access.
Can anyone else confirm this problem?
I can'tr make it crash with just Echo $[0]. However the following make
it
crash 100%:
AddToFunc TestFunc I Echo $[0]
TestFunc $[0]
I'll investigate that further after breakfast to see if it's the same
crash, or a different one.
There are several bugs/crashes in expand_args_extended():
1) It does not check the range of the positional parameters. It
happily parses and uses for example $[999]. I didn't try it,
but I guess it causes random memory access.
I believe that SkipNTokens just stops when there is no more to consume.
Then $[999] will be empty if there are less then 1000 words in the
string.
2) In the if (is_single_arg) it uses the token returned by
PeekToken as the base for further parsing functions. This is
strictly forbidden because PeekToken returns a pointer to a
static buffer.
Not true. With 'is_single_arg' true 'upper' will always be -1, so no
other
parse-function will be called on the string.
Then, why do you not write
if (is_single_arg)
...
*else* if (upper = 0)
...
?
Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].
--
Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:
* A range of args like $[0-1] is expanded to the original text,
not the unquoted form.
I.e. in 'foo a0 a1 a2'
$[0-1] is expanded to 'a0 a1' but should be expanded to
'a0 a1'.
Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.
* Currently, $* is broken too as it does not remove quoting but
just copies the input string.
See above.
* According to the man page, things like $[*] or $[3-] are
removed from the command line if there are no arguments. This
is wrong as it prevents that the string '$[*]' is passed to
another command. These variable should not be treated
specially. Currently, not even $[0] is identical to $0.
The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?
* The code is written too complicated too understand easily (as
you can see from the fact that I only understood about 50% of
it), and it's nested too deep.
The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.
Waiting for a responce I've done some minor cleanup as suggested, and
removed the range-checks again. One thing that still looks weird to me,
(that wrote it) is the
argument_string = SkipSpaces(
SkipNTokens(argument_string, lower), NULL, 0);
The token parser stops after the first non-token character, e.g. a
space. In your old code, SkipSpaces was necessary, in the patch I
just committed it isn't.
args_end = SkipNTokens(argument_string, upper - lower + 1);
while (argument_string args_end isspace(*(args_end - 1)))
{
args_end--;
}
which seems to assume that SkipNTokens can end with any number of spaces
before or after the next token in the list. Is that so? Or is either
SkipSpaces or the while-loop unneeded?
If the tokens are copied dequoted, trailing spaces have to be
removed. If $[*] does not dequote, it should keep trailing
whitespace.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 06:39:40PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. $* has always worked they way it works as well. I for sure have some functions that rely on passing arguments to other functions, so changing the behaviour of $* would break my config. Also reading the todo-vars file it states that $[number] should be unquoted for backwardscompability. The $[range] can be treated differently as that is a new feature. I see use for both the 'raw' style and the unquoted style, but as I understand the todo it really should be single-quoted as they are niether $[number] not $[range], which are the only exceptions to that rule listed. Regarding the dequoting of the positional parameters I belive the best thing would be to make a function to unquote an entire string. I'm not sure how optimized it is to peek every token just to get rid of the quotings. Also the most flexible code for the argument expansion would be keeping the raw string as long as possible, and then dequote it and possible requote it depending on filter-selection. No, I think that is the wrong approach. Disregarding the fact that there won't be big changes in the parser before 3.0, its job is: * To read in tokens from a command line and provide them to the functions that use the parser. * To allow embedding whitespace and other special characters in tokens, the caller may quote parts of the token with double or single quotes, backticks and backslashes. * The parser has to remove one level of quoting every time it parses a token because *that is what the quoting was made for*. * If a function wants to pass a token to another command or function, it has to quote the token. The problem in fvwm is that there is no safe way to quote a token. The correct fix is to provide that functionality, not to modify the parser to do obscure things. I should never have coded the parameter $* in the way I did but should have called it $@ instead ($@ in shells works as $* now works in fvwm). Maybe the best thing is to remove the $[range] alltogether until the filter-system is ready to not add another exception to how things work. I'd really like to hear Mikhael's opinion on this. Note that passing arguments without dequoting them introduces subtle problems. Assume you have a function that takes a random number of (possibly quoted) arguments and passes them to a shell command: AddToFunc foobar + I Exec ls $* In this case, the arguments are filenames. Since the shell interprets the command, the caller of the function needs to choose a shell-compatible way of quoting. For example, he could say foobar file with spaces with double quotes but not foobar `file with spaces` with backticks. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 06:12:05PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] This construct is not in the manpage (and thus never implemented (at lest not in my version. I've not checked the newcode yet.)) Well, maybe it's not worth the effort after all. Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. This worked with my version. The function should return -1 when it should be copied and 0 when it should be replaced with an empty string. ... and it does work now that I'm comparing integers instead of pointer values ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote: On Tue, 11 Jul 2006, Dominik Vogt wrote: On Tue, Jul 11, 2006 at 10:16:09AM -0500, fvwm-workers wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/11 10:16:09 Modified files: . : ChangeLog NEWS configure.ac modules: ChangeLog modules/FvwmCommand: FvwmCommand.1.in FvwmCommand.c FvwmCommandS.c fifos.c Log message: fix tempfile vulnerabilities in FvwmCommand (bug #2791). Can you explain what you actually did, please? Sure. First: When deciding on the default path the three files that are to be used are tested with lstat (or stat if lstat is unavalable) to have the same owner as the process owner, not have nore than one hard link and not be a directory nor a symbolic link. If any of the tests fail the path will be redirected to $FVWM_USERDIR instead of /var/tmp to avoid attacks blocking the module. If some tests are impossible to do they are concidered OK. Actually, since we are creating the file with O_CREAT | O_EXCL, there is no chance of a symlink attack (because symlinks exist even if they do not point to anything). Second: All open() calls use O_NOFOLLOW if that flag is defined. Good, but I don't want new ifdefs in the code. Instead, please add this to the end of the AH_VERBATIM macro _ZEND_EXPLICIT_DEFINITIONS in configure.ac, beginning at line 1195: #ifndef O_NOFOLLOW #define O_NOFOLLOW 0 #endif This snippet is added to the end of config.h. Afterwards you can use O_NOFOLLOW without ifdefs. As a rule of thumb, never put any ifdefs in a .c file (or better: anywhere). I believe this should be enough, We really shouldn't be using public tempdirs at all. I wasn't aware that we are using /var/tmp. but if one are really paranoid one could add checks of the opened files in FvwmCommand.c to verify that they are fifos with correect permissions. Ah, but it's too late if the file is open already. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug
On Wed, Jul 12, 2006 at 09:50:01AM +0200, Dominik Vogt wrote: On Wed, Jul 12, 2006 at 01:28:45AM +0200, Viktor Griph wrote: Good, but I don't want new ifdefs in the code. Instead, please add this to the end of the AH_VERBATIM macro _ZEND_EXPLICIT_DEFINITIONS in configure.ac, beginning at line 1195: #ifndef O_NOFOLLOW #define O_NOFOLLOW 0 #endif This snippet is added to the end of config.h. I' have done that part myself because I had to include fcntl.h too. The ifdefs in the code still have to be removed. As a rule of thumb, never put any ifdefs in a .c file (or better: anywhere). I.e. fetuere tests belong into configure.ac. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
KillModule fix
The attached patch fixes the broken KillModule command. Can someone please apply it? ChangeLog: 2006-07-11 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de * fvwm/module_interface.c (KillModule, ClosePipes): fixed KillModule Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl module_interface.patch Description: Binary data
Re: CVS griph: fix tempfile vulnerabilities in FvwmCommand (bug #2791).
On Tue, Jul 11, 2006 at 10:16:09AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 06/07/11 10:16:09 Modified files: . : ChangeLog NEWS configure.ac modules: ChangeLog modules/FvwmCommand: FvwmCommand.1.in FvwmCommand.c FvwmCommandS.c fifos.c Log message: fix tempfile vulnerabilities in FvwmCommand (bug #2791). Can you explain what you actually did, please? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: using lstat
On Tue, Jul 11, 2006 at 01:36:53PM +0200, Viktor Griph wrote: Is there some define to check for systems that have lstat? Take a look at configure.ac. Just add lstat to one of the AC_CHECK_FUNCS macros and you will get a #define HAVE_LSTAT in the config.h file. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS domivogt: * Fixed parsing of Periodic option.
On Tue, Jul 11, 2006 at 02:38:56PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: domivogt06/07/11 14:38:56 Modified files: . : ChangeLog fvwm : schedule.c Log message: * Fixed parsing of Periodic option. Some hints for using the parsing functions: - char *PeekToken(char *in, char **next) Takes the input string in and returns a pointer to the token, stored in a static char array. The pointer is invalidated by the next call to PeekToken. If next is not NULL, the pointer to the first character after the token is returned through *next. (Note that next is a char **, not just a char *). - char* GetNextToken(char *in, char **token) Works similary, but: Returns next and stores the token in *token (I know this is confusing). The memory *tokes is allocated with malloc and the calling function has to free() it. If possible, use PeekToken because it's faster and does not risk creating memory leaks. Note that both functions never return an empty token, i.e. a string that consists just of the terminating zero. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On Sun, Jul 09, 2006 at 01:00:08AM +0100, seventh guardian wrote: On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: Well, we have been very *very* conservative in the past about backwards compatibility - and that patch breaks it. It's no longer possible to start fvwm with -blackout. I don't think this is the right time to remove it. Of course it's obsolete and useless, but in the 2.x series we tried to keep compatibility as much as possible. The ominous 3.0 release (which is meant to remove a lot of old and obsolete stuff) would be the place to clean everything up. Well, it wasn't even useful to 2.4, and I doubt people would keep configs from pre-2.4.. So I thought it wouldn't matter. My fault. Sometimes it is surprising how long it can take until everybody has switched to a more recent release. Some people stick to 2.2.x for no other reason than that it is smaller. How can I reverse the change? With a bit of CVS magic. First, find out the revision numbers of the changed files before and after the change. For example, for fvwm.c do $ cvs log -N fvwm.c ... revision 1.375 date: 2006/07/07 23:34:31; author: renato; state: Exp; lines: +0 -8 Removed the warning about the obsolete option -blackout. Removed its reference from the manual. revision 1.374 ... (The relevant numbers are 1.374 and 1.375 here). Next, generate a patch for that change: $ cvs diff -u -r 1.374 -r 1.375 fvwm.c blackout.patch (Double check that the patch contains only the changes you want to reverse; edit the patch file if necessary). Finally reverse-apply the patch: $ patch -p0 -R blackout.patch Repeat this for all affected files. Well, although I've now done the change myself locally, I leave it to you as it is a good practive for using cvs :-) -- While you're at it you can change the warning (and todo-3.0 file) to inform the user that -blackout *will* be removed in 3.0. I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) ... Sorry, you're right.. Won't happen again :) There's really no reason to feel disheartened. I appreciate your work very much and other surely do too. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On Fri, Jul 07, 2006 at 06:34:31PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual. Um, why? We've never had any 'secret' features (at least not on purpose). Every option is documented, even if it's frowned upon. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Separating compat code from libfvwm
On Sat, Jul 08, 2006 at 07:58:46PM +0100, seventh guardian wrote: Hi. What do you think of separating the compatibility code (replacement functions) from libfvwm? Functions like strncasecmp or strdup are spread all over the code. For systems that do not have them availiable, libfvwm is responsible for providing them. But the question is, should this be the responsibility of libfvwm? Or should fvwmlib have only fvwm related functions and leave the system compatibility functions to another lib? What I think: Compatibility functions should be separated from libfvwm, as they are not part of fvwm. They should be linked automatically if needed, but should remain invisible for the libfvwm code. Particulary, the replacement function definitions should be in config.h if needed, instead of fvwmlib.h. It would help on keeping the code clean, as the replacement functions should be stable now, and may even be kept as is to fvwm3.0 (?). I believe (supported by local tests) that this is possible to do without too much fuss or without introducing any bugs. On the other hand, it may be prudent to wait before the 2.5.17 release. I don't get the point of doing that. Whats the difference between having them in libfvwm.a or a different lib? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On Sat, Jul 08, 2006 at 11:48:43PM +0100, seventh guardian wrote: On 7/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 07, 2006 at 06:34:31PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual. Um, why? We've never had any 'secret' features (at least not on purpose). Every option is documented, even if it's frowned upon. The -blackout code was removed a long time ago. The warning I refer to was put there by you in 1999 (pre-2.4) so that people who used to start fvwm with the -blackout option could still do it, even if it didn't do nothing. There was really no option -blackout, fvwm just accepted it and said it doesnt do nothing anymore, instead of refusing to start. It's there (the warning) since 1999, so I guess no one needs that anymore.. Well, we have been very *very* conservative in the past about backwards compatibility - and that patch breaks it. It's no longer possible to start fvwm with -blackout. I don't think this is the right time to remove it. Of course it's obsolete and useless, but in the 2.x series we tried to keep compatibility as much as possible. The ominous 3.0 release (which is meant to remove a lot of old and obsolete stuff) would be the place to clean everything up. I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) Well, I certainly don't want to discourage you from doing usefull work, but please don't become too eager committing potentially harmful changes without discussing them. Compatibility is a sensitive issue, and we have spent lots of time thinking about the right way to go. (The fact that most of us don't have time to write patches nowadays does not mean we don't have the time to argue about patches ;-) ) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: debug.c still useful?
On Fri, Jul 07, 2006 at 07:13:42PM +0100, seventh guardian wrote: After some checking around, it seems that the file libs/debug.c isn't used anymore. The file was created in 1998 as a debuging library, but it seems to have been replaced by simpler solutions. I think Paul Smith put it there for future use back then, but we never started using that library. It's part of libfvwm.a, and the *.c code is surrounded by a #ifdef DEBUG, so never gets compiled. The whole file is empty at the moment, except for an int variable that is there (outside the #ifdef) expressly to prevent an empty file, as some compilers don't like that (it's written on the coments). On the other hand, the header file fvwmlib.h has its macros and structs allways defined, (but there is no compiled code!). Nothing is ever used, so I think it's safe to remove it. Yes, it's definitely safe. These are the only places where you find the macros (which need to be removed): - DB() is in a #if 0 part of module_interface.c (but the rest of the file already uses the DBUG macro) and in focus. - __FILE__ and __LINE__ is in a ifdef'ed to 0 part of focus.h where alternative debuging macros are defined. It's a big decision to remove a whole file, so I need a second opinion.. Is the file still useful or may I remove it? Well, usefull or not - if we don't use it we don't need it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Libtool ltdl on fvwm
On Fri, Jul 07, 2006 at 11:05:36PM +0100, seventh guardian wrote: It all starts with this snip from docs/TODO: - Implement (or at least investigate) dynamic loading of functions on systems that support it? (There is more on that on that file. These are just the first two lines) Recently I began testing GNU's Libtool on a project of mine, particulary using Ltdl. Ltdl is a dynamic library loading framework. It allows dynamic loading of modules for an application, or or as a last resort for systems not supporting it, either preloading (linking just before execution) or static linking (during the compilation time). It's very portable and flexible, as you can see from here: http://www.gnu.org/software/libtool/manual.html#Tested-platforms Anyway, it would be great to have the facility to load new styles or functions from a library (a ltdl module). Minimalistic systems would just load (or compile, depending on the arch) the very basic functions and styles, while more feature-rich systems would load all of them. The unoficial feature patchsets would be replaced by style modules (it has nothing to do with the current fvwm modules).. And so on. The text on docs/TODO explains the whole idea. For those interested in this, you can find libtool's manual here: http://www.gnu.org/software/libtool/manual.html For now I'm studying the fvwm code to see where this fits. I'm thinking of trying it out (in a my local private branch, as this is definitely not a 2.5 feature). If I get to do anything I'll inform you. Paul added this TODO item ages ago. Specifically he suggested to make libfvwm a shared library. I am well aware of Libtool's capabilities, but never was very fond of the idea to use it. No matter how portable it is, we'd ask for a lot of problems with library versioning (modules finding a wrong version of the lib). The idea to allow dynamic loading of features is nice. But frankly I think the fvwm core is nowhere near as modular to allow features being taken out of it. (And even this is an euphemism for the state of the code). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: debug vs fvwm_debug_msgs
On Wed, Jul 05, 2006 at 02:35:10PM +0100, seventh guardian wrote: On 7/5/06, seventh guardian [EMAIL PROTECTED] wrote: Hi. I have found FVWM_DEBUG_MSGS and DEBUG ifdef's all over the code (as expected). But it seems to me they are allways used at the same time, one defining the other, and thus replaceable just by one of them. Is this true or do they have distinct purposes? This supports my theory (from fvwmsignal.c): (...) #ifdef FVWM_DEBUG_MSGS volatile sig_atomic_t debug_term_signal = 0; #endif (...) #ifdef DEBUG debug_term_signal = sig; #endif (...) So if FVWM_DEBUG_MSGS is not defined then we have an error. But for instance FVWM_DEBUG_MSGS is defined by #ifdef DEBUG on FvwmPager, so.. If they are used for the same purpose, then I'll clean the code up to just use DEBUG. After a bit of dig up, I realised that FVWM_DEBUG_MSGS is the true fvwm debug var (it is defined conditionally on config.h by ./configure). Some modules link to libfvwm.a, which should be already compiled (at least after the first module requiring it). The question is, DEBUG is only defined in the modules, which means that libfvwm.c is never compiled with debug support (see the code snipet on the first mail). Can this be confirmed or am I crazy? :) Actually, there is no plan or design behind all the debug code. It just appeared independently in the places where it was needed at the given time. Nowadays nobody can tell between usefull debug code and stuff that is not needed anymore. The only useful module debug code I am aware of is in the FvwmAuto module. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: debug code cleanup patch #1
On Thu, Jul 06, 2006 at 05:20:14PM +0100, seventh guardian wrote: Hi. This is a debug code cleanup patch: It removes most of the FvwmPager debug code (very old), also removing useless debug code from fvwmsignal.c and fvmwsignal.h. It also removes an unused #define from libs/PictureUtils.c, which Olivier forgot to remove :P I've only put safe changes on this patch, but please check if it doesn't remove useful code (or if I was too conservative.. who knows?). The patch looks fine. I'll commit it. By the way, do you have commit privileges for CVS? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: debug vs fvwm_debug_msgs
On Thu, Jul 06, 2006 at 04:22:28PM +0100, seventh guardian wrote: On 7/6/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jul 05, 2006 at 02:35:10PM +0100, seventh guardian wrote: On 7/5/06, seventh guardian [EMAIL PROTECTED] wrote: Hi. I have found FVWM_DEBUG_MSGS and DEBUG ifdef's all over the code (as expected). But it seems to me they are allways used at the same time, one defining the other, and thus replaceable just by one of them. Is this true or do they have distinct purposes? This supports my theory (from fvwmsignal.c): (...) #ifdef FVWM_DEBUG_MSGS volatile sig_atomic_t debug_term_signal = 0; #endif (...) #ifdef DEBUG debug_term_signal = sig; #endif (...) So if FVWM_DEBUG_MSGS is not defined then we have an error. But for instance FVWM_DEBUG_MSGS is defined by #ifdef DEBUG on FvwmPager, so.. If they are used for the same purpose, then I'll clean the code up to just use DEBUG. After a bit of dig up, I realised that FVWM_DEBUG_MSGS is the true fvwm debug var (it is defined conditionally on config.h by ./configure). Some modules link to libfvwm.a, which should be already compiled (at least after the first module requiring it). The question is, DEBUG is only defined in the modules, which means that libfvwm.c is never compiled with debug support (see the code snipet on the first mail). Can this be confirmed or am I crazy? :) Actually, there is no plan or design behind all the debug code. It just appeared independently in the places where it was needed at the given time. Nowadays nobody can tell between usefull debug code and stuff that is not needed anymore. The only useful module debug code I am aware of is in the FvwmAuto module. Hum so what's the wise step? I'm thinking of doing a clean up, but I'm not sure on wich policy to follow.. I think you're taking the right path by creating small individual patches that remove some of the debug code. I'll comment on your first patch in that thread. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: debug code cleanup patch #1
On Thu, Jul 06, 2006 at 08:23:50PM +0100, seventh guardian wrote: On 7/6/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 05:20:14PM +0100, seventh guardian wrote: Hi. This is a debug code cleanup patch: It removes most of the FvwmPager debug code (very old), also removing useless debug code from fvwmsignal.c and fvmwsignal.h. It also removes an unused #define from libs/PictureUtils.c, which Olivier forgot to remove :P I've only put safe changes on this patch, but please check if it doesn't remove useful code (or if I was too conservative.. who knows?). The patch looks fine. I'll commit it. By the way, do you have commit privileges for CVS? No, I don't.. Am I ready for it? :) I think so :-) Any second vote for Renato? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Periodic command
On Tue, Jul 04, 2006 at 06:44:32PM +1000, Scott Smedley wrote: Hi all, Here is a proposed patch to add a new builtin function, Periodic. http://members.optusnet.com.au/scottsmedley/fvwm/periodic.patch Apply with: patch -p0 periodic.patch It is similar to the Schedule builtin except the function is invoked every N milliseconds - even if a grab fails, or the function fails to execute for some other reason. It will allow the user to do something like: Periodic 1000 Echo Testing the Periodic builtin. Deschedule $[schedule.last] Periodic 1000 42 Echo Testing Periodic with explicit command Id. Deschedule 42 Can you have multiple peridic commands or just one? If you can have multiple (which I think is a good thing), I suggest to replace the command Periodic with some option to the Schedule command (in order to reduce the number of commands we have to maintain and describe). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: CVS griph: renamed conflicting getline function to get_line (bug #3772)
On Wed, Jul 05, 2006 at 05:08:19AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: griph 06/07/05 05:08:19 Modified files: modules: ChangeLog modules/FvwmConsole: FvwmConsoleC.c getline.c Log message: renamed conflicting getline function to get_line (bug #3772) Thanks, but please add a NEWS entry too. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Grabbing and complex functions
Without commenting on all particular statement in this discussion, I want to make clear why I think it's a bad idea to leave the decision about grab/nograb to the user: 1) The user has *no* idea of the implications and can not make a proper decision. Hell, even something as simple as this may freeze fvwm: AddToFunc foobar I CursorMove 10p 10p How are we going to explain that to the user? The usability of that feature would be horrible: either we explain it in length. Then nobody would be able to use it. Or we don't explain it at all and everybody writes unsafe functions. 2) It would be a maintenance nightmare. When something strange happens, there is always the possibility of some random interaction that we would never pin down. In my eyes, such a feature is *unmaintainable*. -- On Wed, Jun 28, 2006 at 11:39:13PM +, Mikhael Goikhman wrote: On 29 Jun 2006 00:44:22 +0200, Dominik Vogt wrote: We would have to exclude at least: * Anything that can generate dynamic functions because it is impossible to decide about whether a grab is needed (Read, PipeRead, expanding variables or environment variables). We are speaking about a user who knows what these Read and PipeRead commands do. I am not sure why you insist on automatic detection only. See my reasoning above. The user most certainly does *not* know what he is doing. * Commands calling or manipulating functions (AddToFunc, DestroyFunc, calling a sub-function). Again, these may be pretty safe, a user should be able to specify NoGrab flag here. No, because calling and modifying sub-functions can change whether a function is a valid nograb function or not. * Any other command that may grab the pointer itself (e.g. Exec). The same with Exec (a user knows better). Um, I meant Wait, not Exec. -- I don't think a possible problem with NoGrab are that critical. If a user wants to get some nograb-related failures, he should be able to do so. There is no good reason the user has no relable way to do this currently: DefineFunc UpdateTitlePeriodically NoGrab + I PipeRead `printf SetEnv DATE ; date +%Y-%m-%d` + I SendToModule FvwmButtons-Panel ChangeButton ... $[DATE] + I Schedule 2 UpdateTitlePeriodically Wait a minute, the nograb stuff does *not* solve this problem. It is still possible that a command in a nograb function needs to grab the pointer. It it does not get it, the function is terminated and the command is not rescheduled either (e.g. the Wait command). -- Well, years ago I suggested to make I specifier optional in functions, because 90% of functions are immediate and there is no confusion if I is omitted. But there is abiguity. Fvwm would now be able to distinguish between + Iconify off and + I off as well as + I foobar + I I foobar But there was no agreement. I would say that AllImmediate flag is redundant (may be a default). This may be discussed after 2.6.0. -- @Scott: I was suggesting a whitelist, not a blacklist. I.e. if in doubt, forbid it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Grabbing and complex functions
On Thu, Jun 29, 2006 at 12:12:21AM +1000, Scott Smedley wrote: Hi Mikhael, DefineFunc would behave much like AddToFunc except for 3 differences: 1. It would generate a warning message if the function already existed. This is bad. Configs should usually be re-read-able. Instead, it should silently apply DestroyFunc. In fact, DefineFunc (combining DestroyFunc and AddToFunc) is something I wanted to have for a long time. Good idea. It is ok by me to add DefineFunc before 2.6.0, if it fixes issues. Particularly, will it fix reliability of (re-)Schedule? In my opinion, it's not Schedule that is broken/unreliable. _Any_ function may fail to execute if the pointer is grabbed for ~1 second at the time of execution. With the proposed modifications, NoGrab functions will not be prone, to this failure. ie. if Schedule invokes a NoGrab function, it will execute - even if the pointer is grabbed by some other app. This patch is available at: http://members.optusnet.com.au/scottsmedley/fvwm/defineFunc.patch Apply with: patch -p0 defineFunc.patch A question about the implementation: Given this function DefineFunc MyFunc NoGrab + I Echo hello world + C Echo click should FVWM generate a warning (or error?) about using a non-I (immediate) condition within a NoGrab function? Perhaps reverting the function to a normal Grab function? Well, it has all been discussed in that old thread. The fact that fvwm needs to grab the pointer in some cases is mostly unrelated to the action's type. Some complex functions need to grab the pointer to make sure the user or other applications does not interfere with function execution: * The user might push or release a mouse button which causes EnterNotify/LeaveNotify events that can confuse (immediate) complex functions that raise or lower windows or fiddle with the focus (or do other things that I can not think of). We once tried to remove the grab, and functions using Raise/Lower + WarpPointer + Focus could not do their job anymore. * What would commands like Move or Resize be good for without a grab? Fvwm would freeze until the grab ends. * The PointerWindow command could have very undesirable results without a grab. For example, I have something like this in my config: Key d A SCM my_close AddToFunc my_close + I Silent PointerWindow Close If the pointer can be warped by an application during function execution, a random window might be closed. * You can not even know which commands need to run in case of Read or PipeRead. * What should fvwm do if a function consists of five commands and the third command fails to grab the pointer because the complex function did not bother to acquire the grab? I agree that a failed grab can cause lots of problems. Hopefully it's clear that many immediate functions may need the grab too. But I have no idea how to decide if a certain function needs it or not. The only way would be to write a whitelist of commands that are okay to use in a nograb function. We would have to exclude at least: * Anything that can generate dynamic functions because it is impossible to decide about whether a grab is needed (Read, PipeRead, expanding variables or environment variables). * Commands calling or manipulating functions (AddToFunc, DestroyFunc, calling a sub-function). * Any command that queries or manipulates the pointer (fvwm freezes if it tries to access the pointer while a grab is active). * Any command that relies on EnterNotify or LeaveNotify events (command may have unpredictable results). * Any command that can not cope with the pointer being moved to a different sceen. * Any command that requires a window to operate on, as the user is asked to select a window if none is selected yet. Currently, 34 commands are of that type (Move, Resize, WindowStyle, Close, Focus, PlaceAgain, ...) * Any other command that may grab the pointer itself (e.g. Exec). * Conditional commands that use the HasPointer condition. * Maybe all other conditional commands too. * Possibly many more. This ad-hoc blacklist already rules out many - if not most - of the most important commands. I would agree to a nograb patch if it 1) *enforces* proper operation, i.e. refuses to define nograb functions that are potentially unsafe. AND 2) adds useful functionality (doubtful, considering the length of the blacklist above). Also, I took the liberty of adding an AllImmediate function option which allows the condition to be omitted. For example: DefineFunc MyFunc NoGrab AllImmediate + Echo hello + Echo world which I find much more intuitive. The AllImmediate flag indicates that all actions are I - immediately executed. How do others feel about this option? If there are objections I will happily remove it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc
Re: ModuleListenOnly command
On Mon, Jun 26, 2006 at 01:50:30PM +1000, Scott Smedley wrote: Hi Dominik, That's just one purpose of the command. I was always fond of the idea to prototype or even implement modules as shell scripts. Yes, that would be cool. IMHO, I think it would be prudent to create bashlib (akin to perllib), instead of adding ModuleListenOnly command. Well, the new command is not a big deal. I just needed to add some code to close the fvwm_to_app pipes and modify some places to handle the situation that there is no fvwm_to_app pipe. To comment on the bashlib (which would be unusable for me, as I never use shells that are not either POSIX /bin/sh-compatible or zsh ;-) (Unless force to, of course): I don't have any idea how you could detect the size and byte order of a long (which is the base data type of a module message) from inside a shell script. Well, maybe fvwm could provide this information through the module's environment. But I suppose that should be a 2.6 feature? Um, you probably meant a post-2.6 feature? Yes, I think so, assuming that 2.6 would be released at a not too distant point in time. It is certainly possible to handle input from fvwm to the module in the script itself, but hard to guarantee that the input is processed in a timely fashion Why is that? Because shells were not made to handle input in that way. Look at my script for example. It would need two external triggers for its operations: * input from the fvwm pipe * a certain period of time has passed. Well, with zsh there is zselect that can trigger on both events at the same time (works like select()), but other than that I'd have to make something up with reading the fvwm pipe in a subshell (because it blocks the shell). Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
ModuleListenOnly command
I have just checked in the new command ModuleListenOnly. It works
like Module, but fvwm does not send any messages to such a module.
I am using it to attach a shell script to the module interface
that periodically updates titles of FvwmButtons to display a clock
(in the format I prefer, xclock is too stupid) and the process
that currently consumes most cpu. The setup looks like this:
AddToFunc InitFunction
+ I ModuleListenOnly /home/users/bin/fvwm_periodic \
-u 15 -d 3 -c clock -t topproc
AddToFunc RestartFunction
+ I ModuleListenOnly /home/users/bin/fvwm_periodic \
-u 15 -d 3 -c clock -t topproc
*FvwmButtons(11x1+30+0, Colorset 8, Id clock, Title , Action nop)
*FvwmButtons(12x1+29+4, Colorset 8, Id topproc, Title , Action nop)
(zsh script attached).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
#!/usr/bin/zsh
emulate zsh
setopt HUP
zmodload zsh/zselect
[EMAIL PROTECTED]
MODULE=FvwmButtons
IDCLOCK=
IDPROC=
SECS=15
ISECS=3
usage () {
echo usage: module-args $0 [-c id] [-t id] [-m module] [-u secs] [-d
delay]
echo Update certain button titles in FvwmButtons
echo module-args: filled out by fvwm when started as a module
echo -h: display this help message
echo -c buttonid: update clock at the given button id
echo -t buttonid: update topproc at the given button id
echo -m module:name of the module [$MODULE]
echo -u secs: update buttons every secs seconds [$SECS]
echo -d secs: initial delay [$ISECS]
}
send ()
{
printf \\00\\00\\00\\00\\0240\\00\\00\\00%159s\\00\\00\\00\\00\\n \
$1 $OF
}
#
# parse options
#
if test $# -le 4 echo fvwm_periodic must be started by fvwm 12 exit 1
OF=$1
IF=$2
shift 5
while test ! $# = 0; do
case $1 in
-h|-\?|--help)
usage
exit 0
;;
-c|--clock)
test $# = 1 usage exit 1
shift
IDCLOCK=$1
test ! x$IDCLOCK = x zmodload zsh/datetime
;;
-t|--topproc)
test $# = 1 usage exit 1
shift
IDPROC=$1
;;
-m|--module-name)
test $# = 1 usage exit 1
shift
MODULE=$1
test x$MODULE = x usage exit 1
;;
-u|--update-secs)
test $# = 1 usage exit 1
shift
SECS=$1
SECS=$[SECS]
test $[SECS] -le 0 usage exit 1
;;
-d|--delay-secs)
test $# = 1 usage exit 1
shift
ISECS=$1
ISECS=$[ISECS]
test $[ISECS] -le 0 usage exit 1
;;
**)
break
;;
esac
shift
done
if test ! $[$# 1] = 0; then
usage
echo error: unknown option $1
exit 1
fi
#
# main body
#
trap 0 1 2 3 9 13 15 exit
function update_proc ()
{
local C
local P
local N
ps -A --format %C %P %c | sort -n -r | read C P N
send SendToModule '$MODULE' ChangeButton '$IDPROC' Title '$P $C% $N'
}
function update_clock ()
{
local T
T=`strftime '%R %a %d.%m.' $EPOCHSECONDS`
send SendToModule '$MODULE' ChangeButton '$IDCLOCK' Title '$T'
}
send SET_MASK 0
send SET_MASK 2147483647
S=$ISECS
while true; do
repeat $S; do
zselect -t 100
done
S=$SECS
test ! x$IDCLOCK = x update_clock
test ! x$IDPROC = x update_proc
done
signature.asc
Description: Digital signature
