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