Re: [PATCH] (2) Remove Dmalloc and Efence support.
On Mon, Nov 15, 2021 at 02:07:58AM +0100, Dominik Vogt wrote: > 0001: Remove Efence and Dmalloc support. > 0002: Remove trailing whitespace. Applied. Thanks! Kindly, Thomas
[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
Re: Removind dmalloc and efence support?
On Mon, Nov 15, 2021 at 01:42:33AM +0100, Dominik Vogt wrote: > Has anybody really used them in the last fifteen years? Since > valgrind has become pretty stable and good I never saw a need for > dmalloc or efence any more. I agree. It can go. There's a chance some distros ship efence (and possibly the BSDs), but it all pales in light of Valgrind. I know Dan used to use one of the proprietary IBM profilers on fvwm's code base from time-to-time as well, but I don't recall what that was called. Kindly, Thomas
Re: Plans for the NEWS file?
On Mon, Nov 15, 2021 at 01:40:40AM +0100, Dominik Vogt wrote: > There probably needs to be some time when we annouce that we're > done removing stuff so that people know that future changes will > no longer break their configs. I'd say the feature set is > unstable at the moment, not the code quality. Right, I understand. Yeah, that's fair. I think the majority of the bigger breaking changes have largely happened (such as deprecating certain modules), but you're right -- we should take stoke of that, and what's left and make that a focus of the release schedule(s). Kindly, Thomas
Re: Paging issue
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. > (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 -- 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. > > 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. We could add the relevant section for .adoc files and then that would also apply to Vim as well (which is what I use). Kindly, Thomas
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
Re: [PATCH] (3) Miscellaneous updates
On Mon, Nov 15, 2021 at 01:26:31AM +0100, Dominik Vogt wrote: > 0001: Improve Snap... docuemntation. > 0002: Improve EdgeMoveDelay documentation. > 0003: Remove superfluous "#if 1". Applied, thanks! Kindly, Thomas
Re: Plans for the NEWS file?
On Mon, Nov 15, 2021 at 01:18:49AM +0100, Dominik Vogt wrote: > Is the NEWS file going to be used for 3.x releases too? I always > found it easier to add new entries when patches are written > instead of reading the whole changelog when making a release. I now autogenerate this at release time 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... HTH, Thomas
[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 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! I think it's best to try and keep line length to <=80 characters, although there's probably going to be times where that's not possible if the formatting rules require lines to exceed that. Kindly, Thomas
Re: 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
Re: [PATCH] Reject out of range windows for Move and Resize commands.
On Mon, Nov 15, 2021 at 01:11:34AM +0100, Dominik Vogt wrote: > Fixes programs going crazy when you accidentally say something like > > all (mplayer) resize 1920 1200 > > instead of > > all (mplayer) resize 1920p 1200p > > (Generates an error message without doing anything else.) Makes sense, Dominik. Will apply. Thanks! Thomas
[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: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. Kindly, Thomas
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 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. :) Kindly, Thomas
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: Paging issue
On Sun, Nov 14, 2021 at 01:55:32PM +0100, Dominik Vogt wrote: > 1) Because the pointer is at the top of the screen, it's > immediately in the one pixel high panning window, so fvwm waits > the configured 500 ms and then switches pages to 0 0 although > neither the window nor the pointer have ever 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? Kindly, Thomas
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
Re: [PATCH] 1/3 Fix and document "bugopts debugrandr".
On Sun, Nov 14, 2021 at 10:58:19AM +0100, Dominik Vogt wrote: > The patch makes the bogus "bugopts debugrandr" option actually do > something. Hi Dominik, Thank you. All four patches have now been merged! Thanks, Thomas
[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_changed)
{
-ICON_DBG((stderr, "hpn: icon changed '%s'\n", fw->name.name));
/* Okay, the icon hint has changed and style
* options tell us to honour this change. Now
* let's see if we have to use the application
diff --git a/fvwm/icons.c b/fvwm/icons.c
index 25579d1c..a329f681 100644
--- a/fvwm/icons.c
+++ b/fvwm/icons.c
@@ -284,7 +284,6 @@ void
[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
