Re: git access
On Sat, Nov 20, 2021 at 10:17 PM Dominik Vogt wrote: > > Sending patches is getting out of hand. I believe I had once > write access to the git repo, but it doesn't work anymore > (permission denied when updating). What do I need to do to > reactivate access? > If you were using a password to access github, that is no longer allowed from the command line. You need to create a personal access token to use. Or an ssh key. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token
Re: Snapping issue
And there's still a bug that had been present in the old code: Assume you have a window on screen and a button bar aligned with the bottom of the screen. Grab the window at the top border and move it past the button bar towards the bottom of the screen. When the top of the window gets close to the bottom screen edge, it snaps to the bottom of the button bar: +-- | | | | | | | page 0 0 | | | | | | | |-| | button bar | +---+--+--+ | | | window | | | +--+ page 0 1 I.e. the top/left/right/bottom border of a window shouldn't snap to the bottom/right/left/top border of a windows if that latter is aligned with a screen edge. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Snapping issue
On Sat, Nov 20, 2021 at 04:17:41PM -0700, Jaimos Skriletz wrote: > On Sun, Nov 14, 2021 at 10:57 AM Dominik Vogt wrote: > > > > The snapping code is really an unmaintainable mess. Some thoughts > > on how it might be rewritten: > > > > Here are some thoughts I have, you can see them in js/snapattract branch. > > I have split the three different snapping checks into individual > functions for Monitor Edges, Windows, and Grid. I have then set up a > priority of Monitor > Windows > Grid, so this way when something is > found to snap too, it stops looking for other things based on the > priority, and this should stop some of the strange interactions > between deciding what to snap too. I also treat horizontal and > vertical independently so it can snap to both a window and a monitor > edge in different directions. Currently the priority is hardcoded, but > since the checks are now individual functions, it could be possible to > set it up so the user can configure what snap priority. Comments > welcome. Thanks! It looks much cleaner now (not tested though). Some comments: 1) Can we safely assume that the "bool" C type is available in every relevant compiler? 2) Please break up the calculations in DoSnapGrid into multiple lines unsing temp variable. It's too hard to read = hard to maintain. The previous un-readability of the code shouldn't be the standard we aim at. ;-) 3) Same for "smap_mon = ...". Ouch. 4) I'm not sure whether screen boundaries should have a higher priority than windows and not equal priorities. That would require scoring. For example, if a window on (0 0) is fullscreen so that the borders are on the adjacent pages. Then you couldn't align a window on (0 1) with that window border because snapping to the screen edge always wins. Shouldn't be too difficult to implement; the new sub functions would simply return a score = the absolute snapping distance that was used, and the lowest one wins. (Gird is still only used if there was no other snapping.) 5) Edge resistance is a kind of reverse snapping with a different snap distance: A window that has been moved past the screen edge "snaps" back until it has moved more than the edge resistance past the edge. This is exactly what snapattraction does, just with the snap distance from a different variable. Can that be merged with the new code? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: git access
On Sun, Nov 21, 2021 at 12:59:17AM +0100, Dominik Vogt wrote: > Sending patches is getting out of hand. I believe I had once Ah. I had thought you were doing this because you preferred this way of working. > write access to the git repo, but it doesn't work anymore > (permission denied when updating). What do I need to do to > reactivate access? You're a member of fvwmorg on github -- so presumably the permission denied you're seeing is an out of date SSH key? > (A quick recap of the procedure involved in getting patches on > master wold help too. I'd also be happy with my own branches > without committing to master myself.) See: https://github.com/fvwmorg/fvwm3/blob/master/dev-docs/DEVELOPERS.md Kindly, Thomas
git access
Sending patches is getting out of hand. I believe I had once write access to the git repo, but it doesn't work anymore (permission denied when updating). What do I need to do to reactivate access? (A quick recap of the procedure involved in getting patches on master wold help too. I'd also be happy with my own branches without committing to master myself.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: fork-bomb like functions
On Sun, Nov 21, 2021 at 12:51:46AM +0100, Dominik Vogt wrote: > How about > > 1. MAX_FUNCTION_DEPTH100 (stricter limit) > 2. MAX_FUNCTION ITEMS 1000 (limit maximum size of functions) > 3. MAX_CMDS_PER_INVOCATION 1 (max. cmds per top level function > invocation) Sounds sensible to me. I say, go for it! Kindly, Thomas
[PATCH/RFC] Xinerama
On Sat, Nov 20, 2021 at 10:24:46PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote:
> > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote:
> > >
> > > > Is Xinerama still useful for anything or can we remove it?
> > > >
> > > It has already been removed. Where are you seeing references to it?
Patch attached. Can you please double check and fill in the gaps?
(see comments belo).
> > ./fvwm/menus.c: fXineramaRoot = False;
> > ./fvwm/menus.c: else if (StrEquals(tok,"xineramaroot"))
Not sure what the right name of the option and the flag variable
should be. There's only a placeholder in the man page either.
> > ./perllib/FVWM/Commands.pm: descr => q{Move a window to another
> > Xinerama screen},
[MOVE_TO_SCREEN]
This one should be just renamed to just "screen"?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 03149ce8658894f22e3c5e17cc8d981bb9563ec8 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 21 Nov 2021 00:27:00 +0100
Subject: [PATCH 1/4] Remove Xinerama leftovers.
---
bin/fvwm-config.in | 6 +++---
doc/fvwm3_manpage_source.adoc| 5 -
fvwm/add_window.c| 3 +--
fvwm/commands.h | 10 -
fvwm/functable.c | 2 +-
fvwm/fvwm.h | 8 +++
fvwm/menuparameters.h| 6 ++
fvwm/menus.c | 27 +++
fvwm/module_interface.h | 1 -
fvwm/move_resize.c | 15 ++---
fvwm/placement.c | 4 ++--
fvwm/screen.h| 1 -
fvwm/style.c | 24 ++---
fvwm/style.h | 8 +++
fvwm/update.c| 6 --
fvwm/windowlist.c| 2 +-
libs/FTips.c | 2 +-
libs/defaults.h | 6 --
modules/FvwmButtons/FvwmButtons.h| 1 -
modules/FvwmForm/FvwmForm.c | 17 ---
perllib/FVWM/Commands.pm | 32 +---
perllib/FVWM/Tracker/GlobalConfig.pm | 7 +++---
22 files changed, 59 insertions(+), 134 deletions(-)
diff --git a/bin/fvwm-config.in b/bin/fvwm-config.in
index 77ea48a3..4ca9edce 100644
--- a/bin/fvwm-config.in
+++ b/bin/fvwm-config.in
@@ -90,9 +90,9 @@ with_shape=@with_shape@
with_shm=@with_shm@
with_sm=@with_sm@
with_xcursor=@with_xcursor@
-with_xinerama=@with_xinerama@
with_xft=@with_xft@
with_xpm=@with_xpm@
+with_xrandr=@with_xinerama@
with_xrender=@with_xrender@
while test $# -gt 0; do
@@ -162,9 +162,9 @@ while test $# -gt 0; do
test "$with_shm"= "yes" && echo "shm"
test "$with_sm" = "yes" && echo "sm"
test "$with_xcursor"= "yes" && echo "xcursor"
- test "$with_xinerama" = "yes" && echo "xinerama"
test "$with_xft"= "yes" && echo "xft"
test "$with_xpm"= "yes" && echo "xpm"
+ test "$with_xrandr" = "yes" && echo "xrandr"
test "$with_xrender"= "yes" && echo "xrender"
;;
@@ -210,9 +210,9 @@ while test $# -gt 0; do
echo " sm (session management): $with_sm"
echo " rsvg (SVG icons and images): $with_rsvg"
echo " xcursor (ARGB/animated cursors): $with_xcursor"
- echo " xinerama (multi-head): $with_xinerama"
echo " xft (FreeType anti-alias font): $with_xft"
echo " xpm: $with_xpm"
+ echo " xrandr (multi-head): $with_xrand"
echo " xrender (XFree86 Xrender extention): $with_xrender"
;;
diff --git a/doc/fvwm3_manpage_source.adoc b/doc/fvwm3_manpage_source.adoc
index 42187d14..dee9a0e0 100644
--- a/doc/fvwm3_manpage_source.adoc
+++ b/doc/fvwm3_manpage_source.adoc
@@ -2264,6 +2264,9 @@ The _context-rectangle_ can be one of:
_Root_:::
the root window of the current screen.
+
+_ScreenRoot_:::
+ !!!???
++
_Mouse_:::
a 1x1 rectangle at the mouse position.
+
@@ -6130,7 +6133,7 @@ it is still possible to move or resize windows across the edge of the
current screen. See also *EdgeThickness*.
The option _EdgeMoveResistance_ makes it easier to place a window
-directly adjacent to the screen's or xinerama screen's border. It
+directly adjacent to the screen's border. It
takes one or two parameters. The first parameter tells how many pixels
over the edge of the screen a window's edge must move before it
actually moves partially off the screen. The optional second parameter
diff --git a/fvwm/add_window.c b/fvwm/add_window.c
index dbd062e2..fd32310f 100644
--- a/fvwm/add_window.c
+++ b/fvwm/add_window.c
@@ -916,8 +916,7 @@ void setup_numeric_vals(FvwmWindow *fw, window_style *pstyle)
fw->edge_delay_ms_resize = DEFAULT_RESIZE_DELAY;
}
fw->edge_resistance_move = pstyle->edge_resistance_move;
- fw->edge_resistance_xinerama_move =
- pstyle->edge_resistance_xinerama_move;
+ fw->edge_resistance_screen_move =
Re: Snapping issue
On Sun, Nov 14, 2021 at 10:57 AM Dominik Vogt wrote: > > The snapping code is really an unmaintainable mess. Some thoughts > on how it might be rewritten: > Here are some thoughts I have, you can see them in js/snapattract branch. I have split the three different snapping checks into individual functions for Monitor Edges, Windows, and Grid. I have then set up a priority of Monitor > Windows > Grid, so this way when something is found to snap too, it stops looking for other things based on the priority, and this should stop some of the strange interactions between deciding what to snap too. I also treat horizontal and vertical independently so it can snap to both a window and a monitor edge in different directions. Currently the priority is hardcoded, but since the checks are now individual functions, it could be possible to set it up so the user can configure what snap priority. Comments welcome. jaimos
Re: [PATCH - parser] (4) updates
On Sat, Nov 20, 2021 at 03:16:02PM +0100, Dominik Vogt wrote: > Look at commit ba9f161998f7da942996bcf0d3f96baa8b249070. You > added new-parser.md, but also committed a complete reindentation > of functions.c. Oh heavens. That's not good at all. Clearly something has run in the background and I had not even noticed at the point I commited that change as I was in no way expecting anything other than that markdown file to have changed. That's why I didn't even check. Sorry about that. I'll have to check to see how that happened. There's a possibility some "helpful" vim plugin has done this, although it hasn't done so in the past. Kindly, Thomas
Re: fork-bomb like functions
On Sat, Nov 20, 2021 at 04:26:13PM +0100, Dominik Vogt wrote: > I wonder if we should do something about these kind of functions: > Theres the definition "MAX_FUNCTION_DEPTH 512" in defaults.h that > prevents functions from nesting infinitely deep: Yeah. How likely is this problem in the real world though? As in, how many people have actually done this? I can't say I've ever had to support a user who has managed to get into this situation. Even then, what's wrong in just keeping it as it is? > I could add an execution counter that limits the total number of > command lines that can be executed from a single top level > function call; maybe limit that to 1000. Maybe, if this is an actual problem... > Another problem: It's possible to add items to functions that are > currently in use. > > addtofunc foo i bar > addtofunc bar i addtofunc foo i bar > # hangs: > foo I can maybe foresee this situation arising. Maybe this is worth fixing? Kindly, Thomas
Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. > > $ rgrep -i xinerama . 2> /dev/null > ./libs/defaults.h:/*** Xinerama ***/ > ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on > by default */ > ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" These can go, and the corresponding callers in FvwmForm can be changed. This looks to be the mechanism module used to use to register Xinerama interest. > ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama > support */ That comment is misleading and can be changed, > ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, > ./modules/FvwmForm/FvwmForm.c: > sizeof(XINERAMA_CONFIG_STRING)-1) == 0) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); > ./modules/FvwmForm/FvwmForm.c:buf, XINERAMA_CONFIG_STRING, > sizeof(XINERAMA_CONFIG_STRING)-1) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); See above. > ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); That's just a function declaration without an implementation and can be removed. > ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly > adjacent to the screen's or xinerama screen's border. It > ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly > adjacent to the screen's or xinerama screen's border. It rerere cache from git so will ignore. > ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama > screen's border. It > ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs > border. It > ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's > border. It > ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama > screen\(cqs border. It > ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama > screen's border. It These can change to either mention RandR, or just "screen". > ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ > ./fvwm/add_window.c: fw->edge_resistance_xinerama_move = > ./fvwm/add_window.c: pstyle->edge_resistance_xinerama_move; > ./fvwm/move_resize.c: * in case Xinerama is used. */ > ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ > ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) Funtionally now referencing RandR and are poorly named as xinerama isn't used. > ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( > ./fvwm/style.c: > SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); > ./fvwm/style.c: unsigned has_xinerama_move; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: has_xinerama_move = 1; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: > ps->flags.has_edge_resistance_xinerama_move = > ./fvwm/style.c: has_xinerama_move; > ./fvwm/style.c: > ps->flag_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: > ps->change_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, > val[1]); > ./fvwm/fvwm.h:char*IconScreen; /* Xinerama > screen */ > ./fvwm/fvwm.h:unsigned has_edge_resistance_xinerama_move : 1; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; As above. This just needs renaming. > ./fvwm/commands.h:F_XINERAMA, > ./fvwm/commands.h:F_XINERAMAPRIMARYSCREEN, > ./fvwm/commands.h:F_XINERAMASLS, > ./fvwm/commands.h:F_XINERAMASLSSCREENS, > ./fvwm/commands.h:F_XINERAMASLSSIZE, > ./fvwm/commands.h:void CMD_Xinerama(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaPrimaryScreen(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaSls(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaSlsScreens(F_CMD_ARGS); >
Re: [PATCH] (6) Man page changes -- second attempt
On Wed, Nov 17, 2021 at 11:20 AM Thomas Adam wrote: > > On Wed, Nov 17, 2021 at 02:35:32PM +0100, Dominik Vogt wrote: > > On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote: > > > This is the full set of patches for splitting the man page, to be > > > applied to master. > > > > Second attempt. The style docs are not moved aound in the man > > page. The .section files have been renamed to .ad because > > asciidoc only evaluates "ifdef" in included files if they have a > > known extesion. ".adoc" cannot be used because the pattern rules > > in the Makefile.am would conflict. > > > > The patch stack has been reshuffled and patches have heen merged, > > and two new ones on top have been added. > > Thanks, Dominik. This applies cleanly now. I've also added an OVERVIEW > section to fvwm3all.adoc explaining how the man page is split up into > different sections. > > I'm going to merge this to master, albeit I'm hoping to create some additional > sections as well so it doesn't feel like this change is incomplete. > Lintian found a few minor typos in the manual pages. Patch attached. jaimos diff --git a/doc/fvwm3_manpage_source.adoc b/doc/fvwm3_manpage_source.adoc index d78b5d22..48f3d3b7 100644 --- a/doc/fvwm3_manpage_source.adoc +++ b/doc/fvwm3_manpage_source.adoc @@ -26,7 +26,7 @@ large, and you can scroll around within the desktop. The multiple disjoint desktops pretend there are really several screens to work at, but each screen is completely unrelated to the others. -Fvwm provides _keyboard accelerators_ that allow to perform practically +Fvwm provides _keyboard accelerators_ that allow one to perform practically all window manager functions, including moving and resizing windows and operating the menus, using keyboard shortcuts. @@ -2493,7 +2493,7 @@ AddToMenu RootMenu Menu styles describe the looks and behaviour like normal styles do for windows. Menu styles are assigned to individual or all menus, -and changing the menu style immediately affects all menus taht use +and changing the menu style immediately affects all menus that use it. (If a menu style is used from within a menu, the changes are applied the next time an affected menu is opened.) @@ -4012,7 +4012,7 @@ 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 +Holding down _Alt_ disables snapping and allows one 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
fork-bomb like functions
I wonder if we should do something about these kind of functions: Theres the definition "MAX_FUNCTION_DEPTH 512" in defaults.h that prevents functions from nesting infinitely deep: addtofunc foo i foo foo => ok But this is not good: addtofunc foo + i foo + i foo h hangs: foo Although functions above the maximum depth abort, it still executes about 2^512 leaf functions before finally exiting, i.e. it never completes. I could add an execution counter that limits the total number of command lines that can be executed from a single top level function call; maybe limit that to 1000. -- Another problem: It's possible to add items to functions that are currently in use. addtofunc foo i bar addtofunc bar i addtofunc foo i bar # hangs: foo Not sure if we should just forbid to add items to running functions. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
[PATCH] (9) master and new parser patches
A couple of small changes for master:
0001: Makes the code in log.c easiert to read.
0002: Ignore emacs backup files.
0003: Clean up a header file.
0004: Remove the unused dependency from libs/vpacket.h to fvwm/fvwm.h.
0005: Your NEW-PARSEER.md patch without the reindentation.
0006: Remove the -D command line option. I'm not sure if we should
really delete this. Should probably rather be a "bugopts" option.
parser branch on top of master:
0007-0009: Current cleaned up version of the parser parches
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From 3f61e78201a452a69c74ccde036e371391e0dfd3 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 20 Nov 2021 14:39:54 +0100
Subject: [PATCH 1/9] Clean up log.c.
---
libs/log.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/libs/log.c b/libs/log.c
index 23f28dcb..877a9f74 100644
--- a/libs/log.c
+++ b/libs/log.c
@@ -55,35 +55,36 @@ void
log_open(const char *fvwm_userdir)
{
char *path, *file_name;
+ char *expanded_path;
if (lib_log_level == 0)
return;
- if (log_file_name != NULL &&
- log_file_name[0] == '-' && log_file_name[1] == 0) {
+ /* determine file name or file path to use */
+ file_name = log_file_name;
+ if (file_name == NULL)
+ {
+ file_name = getenv("FVWM3_LOGFILE");
+ }
+ if (file_name == NULL)
+ {
+ file_name = FVWM3_LOGFILE_DEFAULT;
+ }
+ /* handle stderr logging */
+ if (log_file_name[0] == '-' && log_file_name[1] == 0)
+ {
log_file = stderr;
return;
}
- if ((file_name = log_file_name) == NULL)
- file_name = getenv("FVWM3_LOGFILE");
-
- if (file_name != NULL)
+ /* handle file logging */
+ expanded_path = expand_path(file_name);
+ if (expanded_path[0] == '/')
{
- char *expanded_path;
-
- expanded_path = expand_path(file_name);
- if (expanded_path[0] == '/')
- {
- path = expanded_path;
- }
- else
- {
- xasprintf(, "%s/%s", fvwm_userdir, expanded_path);
- free((char *)expanded_path);
- }
+ path = expanded_path;
}
else
{
- xasprintf(, "%s/%s", fvwm_userdir, FVWM3_LOGFILE_DEFAULT);
+ xasprintf(, "%s/%s", fvwm_userdir, expanded_path);
+ free((char *)expanded_path);
}
log_close();
--
2.30.2
From 7ff0553f89bf5b767a5f67d8bcbdc1c63363a01d Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 20 Nov 2021 11:04:03 +0100
Subject: [PATCH 2/9] .gitignore: Ignore emacs backups.
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index 7ec13d8d..6c538bee 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,6 +7,8 @@
*.o
*.patch
*~
+*#
+.#*
Makefile
Makefile.in
aclocal.m4
--
2.30.2
From 2021ba60dc174b9508f87d4ee7ffb800792cd0ab Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 20 Nov 2021 12:12:13 +0100
Subject: [PATCH 3/9] Header cleanup.
---
libs/vpacket.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/libs/vpacket.h b/libs/vpacket.h
index d0d88b2d..bd549fab 100644
--- a/libs/vpacket.h
+++ b/libs/vpacket.h
@@ -16,7 +16,6 @@
This is the same packet as the M_ADD_WINDOW packet, the
only difference being the type.
*/
-/* RBW- typedef struct config_win_packet */
typedef struct ConfigWinPacket
{
/*** Alignment notes ***/
@@ -33,14 +32,7 @@ typedef struct ConfigWinPacket
unsigned long desk;
unsigned long monitor_id;
unsigned long monitor_name;
- /*
- Temp word for alignment - old flags used to be here.
- - remove before next release.
- RBW - 05/01/2000 - layer has usurped this slot.
- unsigned long dummy;
- */
unsigned long layer;
-
unsigned long hints_base_width;
unsigned long hints_base_height;
unsigned long hints_width_inc;
@@ -56,8 +48,6 @@ typedef struct ConfigWinPacket
unsigned long hints_win_gravity;
unsigned long TextPixel;
unsigned long BackPixel;
-
- /* Everything below this is post-GSFR */
unsigned long ewmh_hint_layer;
unsigned long ewmh_hint_desktop;
unsigned long ewmh_window_type;
--
2.30.2
From 500e6f4b2c532d76581ba055d216a5d63cc93a03 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 20 Nov 2021 11:50:52 +0100
Subject: [PATCH 4/9] Remove libs/vpacket.h depending on fvwm.h.
---
libs/vpacket.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libs/vpacket.h b/libs/vpacket.h
index bd549fab..98eb590c 100644
--- a/libs/vpacket.h
+++ b/libs/vpacket.h
@@ -3,7 +3,6 @@
#ifndef FVWMLIB_VPACKET_H
#define FVWMLIB_VPACKET_H
#include "fvwm_x11.h"
-#include "fvwm/fvwm.h"
/*
All new-style module packets (i.e., those that are not simply arrays
@@ -70,7 +69,7 @@ typedef struct MiniIconPacket
{
Window w;
Window frame;
- FvwmWindow*fvwmwin;
+ void *fvwmwin;
unsigned long width;
unsigned long height;
unsigned long depth;
--
2.30.2
From 01686e05071f7fbd460c73e4e70462136b50eb29 Mon Sep 17 00:00:00 2001
From: Thomas Adam
Date: Thu, 18 Nov 2021 22:47:15 +
Subject: [PATCH 5/9] doc: NEW-PARSER.md
---
dev-docs/NEW-PARSER.md | 4
1 file
Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. No sorry, too complex for me, and I don't know the new implementation. The code in menus.c, move_resize.c etc is non-trivial and maybe still necessary. But wen can't do it with the parser branch pending. It would cause too many conflicts. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Xinerama
On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > Is Xinerama still useful for anything or can we remove it? > > > It has already been removed. Where are you seeing references to it? Everywhere. I'll remove the junk on the parser branch. $ rgrep -i xinerama . 2> /dev/null ./libs/defaults.h:/*** Xinerama ***/ ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on by default */ ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama support */ ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, ./modules/FvwmForm/FvwmForm.c:sizeof(XINERAMA_CONFIG_STRING)-1) == 0) ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmForm/FvwmForm.c: buf, XINERAMA_CONFIG_STRING, sizeof(XINERAMA_CONFIG_STRING)-1) ./modules/FvwmForm/FvwmForm.c: FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly adjacent to the screen's or xinerama screen's border. It ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama screen's border. It ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ ./fvwm/add_window.c:fw->edge_resistance_xinerama_move = ./fvwm/add_window.c:pstyle->edge_resistance_xinerama_move; ./fvwm/move_resize.c:* in case Xinerama is used. */ ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( ./fvwm/style.c: SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); ./fvwm/style.c: unsigned has_xinerama_move; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: has_xinerama_move = 1; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: ps->flags.has_edge_resistance_xinerama_move = ./fvwm/style.c: has_xinerama_move; ./fvwm/style.c: ps->flag_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: ps->change_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, val[1]); ./fvwm/fvwm.h: char*IconScreen; /* Xinerama screen */ ./fvwm/fvwm.h: unsigned has_edge_resistance_xinerama_move : 1; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/commands.h: F_XINERAMA, ./fvwm/commands.h: F_XINERAMAPRIMARYSCREEN, ./fvwm/commands.h: F_XINERAMASLS, ./fvwm/commands.h: F_XINERAMASLSSCREENS, ./fvwm/commands.h: F_XINERAMASLSSIZE, ./fvwm/commands.h:void CMD_Xinerama(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaPrimaryScreen(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSls(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsScreens(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsSize(F_CMD_ARGS); ./fvwm/screen.h:unsigned has_xinerama_state_changed : 1; ./fvwm/module_interface.h:void broadcast_xinerama_state(void); ./fvwm/placement.c: * Xinerama screen. 1: The intuitive way giving a geometry ./fvwm/placement.c: * 2: Do NOT specify a Xinerama screen (or specify it to be ./fvwm/functable.c: /* - Move a window to another Xinerama screen */ ./fvwm/style.h:#define SGET_EDGE_RESISTANCE_XINERAMA_MOVE(s) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move) ./fvwm/style.h:#define SSET_EDGE_RESISTANCE_XINERAMA_MOVE(s,x) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move = (x)) ./fvwm/menuparameters.h:/* A position on the Xinerama screen on which the menu should be ./fvwm/menuparameters.h:/* A position on the
Re: [PATCH - parser] (4) updates
On Sat, Nov 20, 2021 at 11:17:52AM +, Thomas Adam wrote: > On Sat, Nov 20, 2021 at 10:51:51AM +0100, Dominik Vogt wrote: > > It works on my local branch but not the one in Git because of the > > reindentation commit. Can we please not reindent patches that are > > still under development? > > I haven't reindented anything -- at least, not knowingly. Look at commit ba9f161998f7da942996bcf0d3f96baa8b249070. You added new-parser.md, but also committed a complete reindentation of functions.c. > Even then, how did that cause the failure in the first place? The patch also re-ordered the includes in fvwm3.c to an order that did not work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Xinerama
Is Xinerama still useful for anything or can we remove it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH - parser] (4) updates
On Sat, Nov 20, 2021 at 10:51:51AM +0100, Dominik Vogt wrote: > It works on my local branch but not the one in Git because of the > reindentation commit. Can we please not reindent patches that are > still under development? I haven't reindented anything -- at least, not knowingly. Even then, how did that cause the failure in the first place? > I'll ditch the upstream branch for now and start a new one. Well, new-parser builds fine now, thanks. Kindly, Thomas
Re: [PATCH - parser] (4) updates
On Sat, Nov 20, 2021 at 08:51:46AM +, Thomas Adam wrote: > This works, Please revert this and apply the revert patch in my other message. > but I am confused as to why it compiles fine for you: It works on my local branch but not the one in Git because of the reindentation commit. Can we please not reindent patches that are still under development? I'll ditch the upstream branch for now and start a new one. > diff --git a/fvwm/cmdparser_hooks.h b/fvwm/cmdparser_hooks.h > index 42330246b..d8ebde017 100644 > --- a/fvwm/cmdparser_hooks.h > +++ b/fvwm/cmdparser_hooks.h > @@ -3,6 +3,9 @@ > #ifndef FVWM_CMDPARSER_HOOKS_H > #define FVWM_CMDPARSER_HOOKS_H > > +#include "cmdparser.h" > +#include "functions.h" 1) Please no includes in header files. It gets really messy and unmaintainable over time. 2) Including headers from headers potentiall _breaks_ the code. Several header files work differently if some macro is defined when they are included, for example libs/FEvents.h evaluates FEVENT_PRIVILEGED_ACCESS, but since it's included by many other headers, it's more or less random whether execcontext.c includes it before defining that or after. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH - parser] (4) updates
On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote:
> > Can you give me the error messages that cause it?
>
> See fvwm.log attached. It's possible I've missed a patch, but the code
> corresponding to this build is on the new-parser branch in git, FYI.
With the doc patch you also committed changes to functions.c that
cause this problem.
* Reindented whole file.
* Reordered include files, which causes the error.
Patch attached to back out the functions.c changes.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From e599b80d529bd75892e04d47f32558ac17018ec1 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 20 Nov 2021 03:18:31 +0100
Subject: [PATCH] Revert bad functions.c reformatting.
---
fvwm/functions.c | 1170 ++
1 file changed, 667 insertions(+), 503 deletions(-)
diff --git a/fvwm/functions.c b/fvwm/functions.c
index 0754b91c..31fafa2a 100644
--- a/fvwm/functions.c
+++ b/fvwm/functions.c
@@ -26,34 +26,34 @@
#include
#endif
-#include "cmdparser.h"
-#include "cmdparser_hooks.h"
-#include "cmdparser_old.h"
-#include "commands.h"
+#include "libs/fvwm_x11.h"
+#include "libs/fvwmlib.h"
+#include "libs/charmap.h"
+#include "libs/wcontext.h"
+#include "libs/Grab.h"
+#include "libs/Parse.h"
+#include "libs/Strings.h"
+#include "libs/FEvent.h"
+#include "libs/Event.h"
+#include "fvwm.h"
+#include "externs.h"
#include "cursor.h"
-#include "events.h"
#include "execcontext.h"
-#include "expand.h"
-#include "externs.h"
#include "functable.h"
#include "functable_complex.h"
+#include "cmdparser.h"
+#include "cmdparser_hooks.h"
+#include "cmdparser_old.h"
#include "functions.h"
-#include "fvwm.h"
-#include "libs/Event.h"
-#include "libs/FEvent.h"
-#include "libs/Grab.h"
-#include "libs/Parse.h"
-#include "libs/Strings.h"
-#include "libs/charmap.h"
-#include "libs/fvwm_x11.h"
-#include "libs/fvwmlib.h"
-#include "libs/wcontext.h"
-#include "menus.h"
-#include "misc.h"
+#include "commands.h"
+#include "events.h"
#include "modconf.h"
#include "module_list.h"
-#include "repeat.h"
+#include "misc.h"
#include "screen.h"
+#include "repeat.h"
+#include "expand.h"
+#include "menus.h"
/* local definitions -- */
@@ -67,11 +67,11 @@
/* forward declarations --- */
-static void
-execute_complex_function(cond_rc_t *cond_rc, const exec_context_t *exc,
-cmdparser_context_t *pc, FvwmFunction *func, Bool has_ref_window_moved);
+static void execute_complex_function(
+ cond_rc_t *cond_rc, const exec_context_t *exc, cmdparser_context_t *pc,
+ FvwmFunction *func, Bool has_ref_window_moved);
-/* local variables */
+ /* local variables */
/* Temporary instance of the hooks functions used in this file. The goal is
* to remove all parsing and expansion from functions.c and move it into a
@@ -83,12 +83,15 @@ static const cmdparser_hooks_t *cmdparser_hooks = NULL;
/* local functions */
-static int
-__context_has_window(const exec_context_t *exc, execute_flags_t flags)
+static int __context_has_window(
+ const exec_context_t *exc, execute_flags_t flags)
{
- if (exc->w.fw != NULL) {
+ if (exc->w.fw != NULL)
+ {
return 1;
- } else if ((flags & FUNC_ALLOW_UNMANAGED) && exc->w.w != None) {
+ }
+ else if ((flags & FUNC_ALLOW_UNMANAGED) && exc->w.w != None)
+ {
return 1;
}
@@ -102,93 +105,101 @@ __context_has_window(const exec_context_t *exc, execute_flags_t flags)
* Inputs:
* cursor - the cursor to display while waiting
*/
-static Bool
-DeferExecution(exec_context_changes_t *ret_ecc,
-exec_context_change_mask_t *ret_mask, cursor_t cursor, int trigger_evtype,
-int do_allow_unmanaged)
+static Bool DeferExecution(
+ exec_context_changes_t *ret_ecc, exec_context_change_mask_t *ret_mask,
+ cursor_t cursor, int trigger_evtype, int do_allow_unmanaged)
{
- int done;
- int finished = 0;
- int just_waiting_for_finish = 0;
- Window dummy;
- Window original_w;
+ int done;
+ int finished = 0;
+ int just_waiting_for_finish = 0;
+ Window dummy;
+ Window original_w;
static XEvent e;
- Window w;
- int wcontext;
- FvwmWindow *fw;
- int FinishEvent;
-
- fw = ret_ecc->w.fw;
- w = ret_ecc->w.w;
- original_w = w;
- wcontext= ret_ecc->w.wcontext;
+ Window w;
+ int wcontext;
+ FvwmWindow *fw;
+ int FinishEvent;
+
+ fw = ret_ecc->w.fw;
+ w = ret_ecc->w.w;
+ original_w = w;
+ wcontext = ret_ecc->w.wcontext;
FinishEvent = ((fw != NULL) ? ButtonRelease : ButtonPress);
#if 1 /*!!!*/
fprintf(stderr, "!!!%s: A wc 0x%x\n", __func__, wcontext);
#endif
- if (wcontext == C_UNMANAGED && do_allow_unmanaged) {
+ if (wcontext == C_UNMANAGED && do_allow_unmanaged)
+ {
#if 1 /*!!!*/
- fprintf(stderr, "!!!%s: Bf\n",
Re: [PATCH - parser] (4) updates
On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote: > On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote: > > On Fri, Nov 19, 2021 at 03:15:43PM +, Thomas Adam wrote: > > > On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote: > > > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote: > > > > > A couple of patches for the parser branch: > > > > > > > > > > 0001: Some cleanup. > > > > > 0003: Fix function depth handling and an uninitialised function > > > > > argument. > > > > > (I.e. a crash) > > > > > > > > Thanks; applied these two. > > > > > > You'll need to fix some missing #includes though, as the build's failing, > > > but > > > > Builds fine with gcc-10.2.1 in a clean source tree with > > > > $ make CFLAGS="-g3 -O3 -Wall -Werror" -j 4 > > > > Can you give me the error messages that cause it? > > See fvwm.log attached. It's possible I've missed a patch, but the code > corresponding to this build is on the new-parser branch in git, FYI. > > I know I'm being lazy, I could fix this myself, but I'd like you to check, > just in case there's something else missing which you're working on at the > same time... This works, but I am confused as to why it compiles fine for you: diff --git a/fvwm/cmdparser_hooks.h b/fvwm/cmdparser_hooks.h index 42330246b..d8ebde017 100644 --- a/fvwm/cmdparser_hooks.h +++ b/fvwm/cmdparser_hooks.h @@ -3,6 +3,9 @@ #ifndef FVWM_CMDPARSER_HOOKS_H #define FVWM_CMDPARSER_HOOKS_H +#include "cmdparser.h" +#include "functions.h" + /* included header files -- */ /* global definitions - */ Kindly, Thomas
Re: [PATCH] (6) Various small changes
On Sat, Nov 20, 2021 at 03:03:44AM +0100, Dominik Vogt wrote: > For master: > > 0001: Fix uninitialised variables in lib. > 0002: Remove "-blackout" option. > 0003: Docuement -v and alias it to --verbose. > 0004: Don't list all options in the SYNOPSIS. > 0005: Change getpwuid.c interface (for next patch) > 0006: Implement -o/--output-logfile option. > If given, use that logfile (abs or relative path) > If the path is just "-", use stderr > If not present use file from env variable > If not presen, use default. > > fvwm -v -o - ... # to stderr > fvwm -v -o //home/foo/bar # to file > > The patch also fixes a memory leak. Makes sense. Applied, with a few tweaks. Note that the use of stderr is going to be interesting. Unless you've explicitly captured stderr beforehand, some display managers won't capture stderr which is why I didn't previously include it, but then again if you're still starting fvwm via .xsession or .xinitrc, this will be useful. Kindly, Thomas
