Re: [PATCH/RFC] Xinerama
On Tue, Nov 23, 2021 at 01:44:52AM +0100, Dominik Vogt wrote: > Menu foomenu monitor c c > > Should place the menu in the middle of the current monitor. Or Menu foomenu c-20 c+30 should place it 20% of the monitor size left from the center and 30% below the center. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 11:52:38PM +, Thomas Adam wrote: > On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote: > > The old manmage said: > > > > XineramaRoot > > > > the root window of the whole Xinerama screen. Equivalent to > > "root" when Xinerama is not used. > > > > Can you please restate that for me? What is "whole Xinerama > > screen" in xrandr terms? > > >From a quick scan of the code in menus.c where xineramaroot is being used, > it's not entirely clear to me, In the past it referenced the current Xinerama screen, not the whole root window. When a menu is placed the code needs a reference rectangle to calculate the menu position. It can be relative to the pointer, to a window, to the root window, to a monitor etc. > but if this option is meant to do what I think > it is, then this would be taking the width/height of the monitor the > pointer/window is on, rather than referencing the width/height of the entire > root window. That would be correct. Renamed it to "monitor" and "fMonitorContext". There's only one place in the code that evaluates the flag, and that looks fishy. Can you test it? Menu foomenu monitor c c Should place the menu in the middle of the current monitor. The code is on the dv/devel branch (you may not want the top commit on that branch). Ciao Dominik ^_^ ^_^ -- Dominik Vogt
NEW_PARSER.md
The file now contains an overview of the current parser implementation. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [PATCH/RFC] Xinerama
On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote: > The old manmage said: > > XineramaRoot > > the root window of the whole Xinerama screen. Equivalent to > "root" when Xinerama is not used. > > Can you please restate that for me? What is "whole Xinerama > screen" in xrandr terms? >From a quick scan of the code in menus.c where xineramaroot is being used, it's not entirely clear to me, but if this option is meant to do what I think it is, then this would be taking the width/height of the monitor the pointer/window is on, rather than referencing the width/height of the entire root window. Kindly, Thomas
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 10:46:20PM +, Thomas Adam wrote:
> On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> > On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > > 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.
>
> Making that change would be syntactically breaking people's configs, but... I
> bet it's a rarely-used option that should just be "screenroot" or something.
It can have two names, a real one and still "xineramaroot" for
compatibility. Screenroot? Rootscreen? Just tell me a good
name.
The old manmage said:
XineramaRoot
the root window of the whole Xinerama screen. Equivalent to
"root" when Xinerama is not used.
Can you please restate that for me? What is "whole Xinerama
screen" in xrandr terms?
> > > > > ./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"?
>
> Yes please.
Good. It's already part of the patch.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: [RFC] parser branches ready for commit
On Mon, Nov 22, 2021 at 11:26:14PM +0100, Dominik Vogt wrote: > I want to remove completely it once the code has been tested well > enough. It's just there for the moment in case something happens. OK. I'm now about to merge this to master. Thanks, Thomas
Re: [PATCH/RFC] Xinerama
On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > 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.
Making that change would be syntactically breaking people's configs, but... I
bet it's a rarely-used option that should just be "screenroot" or something.
> > > > ./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"?
Yes please.
> Ping.
Sorry, I didn't spot this earlier.
Kindly,
Thomas
Re: [PATCH/RFC] Xinerama
On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> 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"?
Ping.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: [RFC] parser branches ready for commit
On Mon, Nov 22, 2021 at 06:16:02PM +, Thomas Adam wrote: > On Mon, Nov 22, 2021 at 12:02:33AM +0100, Dominik Vogt wrote: > > Mostly done, except a couple of comments where there's still work > > to do. > > OK, I'll wait for those. These won't go away anytime soon. First I'd need to figure out what their mening and context is. :-) > I've not noticed any crashes from running this for three days now. > > Note that I still don't think we should hide the debugging behind > '#define OCP_DEBUG 1' What do you mean with "hide"? > even though it's always set to on at compile time. > Certainly not for new code. > We could make it a BugOpts option if it really > mattered. I'm not saying we need to fix this now, mind you. I want to remove completely it once the code has been tested well enough. It's just there for the moment in case something happens. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: [RFC] Fake a global monitor when RanfR is not available.
On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote: > For debugging I need to run another fvwm in xnest, but that > doesn't support randr. Bloody xnest/xephyr. I suppose this OK, but it bothers me we need to fix it this way... I am not sure though there's a workaround. > The attached patch mocks up a global monitor to use if init fails. > It works at the first glance, but the patch is not very clean. > Please comment. It sucks. Under whar circumstances is this likely to fail? I mean, I appreciate the point you're making, but whatelse am I missing? Kindly, Thomas
Re: [RFC] parser branches ready for commit
On Mon, Nov 22, 2021 at 12:02:33AM +0100, Dominik Vogt wrote: > Mostly done, except a couple of comments where there's still work > to do. OK, I'll wait for those. I've not noticed any crashes from running this for three days now. Note that I still don't think we should hide the debugging behind '#define OCP_DEBUG 1' even though it's always set to on at compile time. Certainly not for new code. We could make it a BugOpts option if it really mattered. I'm not saying we need to fix this now, mind you. Kindly, Thomas
