Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Sat, Dec 31, 2016 at 01:07:59AM +, Thomas Adam wrote: > On Fri, Dec 30, 2016 at 11:20:59PM +0100, Dominik Vogt wrote: > > > EWMHBaseSTruts is not a Style, > > > > What? Should have paid more attention when this stuff was > > written. Got to fix this some time. > > Curious. Why? What benefit would it have to be a style? Flexibility, as always. > If it's about > applying size limits to certain windows, we already have a number of different > ways to specify that. Everything that affects windows affects either a window's state or it's style. We've spent a lot of time to eradicate global window settings; the EwmhBaseStruts command is an anachronism, imposing artificial limitations on windows when it could be expressed as Style * EwmhBaseStruts a b c d as well. > Making it per-screen is a better idea (I've a patch for that in an older CVS > tree, probably on Github). That doesn't rule out making it a style. > EWMHBaseStruts is about screen edges, not windows. It's about areas where windows are not to be placed, so it's clearly about windows. > Don't go perturbing this option. It should be deprecated and made a style instead (or possibly a collection of styles), like everything else related to windows. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Fri, Dec 30, 2016 at 01:46:32PM -0700, Jaimos Skriletz wrote: > Running that command each time you maximize a window is not needed > unless your configuration is constantly resetting the EWMHBaseStruts Likely because of: ewmhiwa -- Thomas Adam
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Fri, Dec 30, 2016 at 11:20:59PM +0100, Dominik Vogt wrote: > > EWMHBaseSTruts is not a Style, > > What? Should have paid more attention when this stuff was > written. Got to fix this some time. Curious. Why? What benefit would it have to be a style? If it's about applying size limits to certain windows, we already have a number of different ways to specify that. Making it per-screen is a better idea (I've a patch for that in an older CVS tree, probably on Github). EWMHBaseStruts is about screen edges, not windows. Don't go perturbing this option. -- Thomas Adam
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Fri, Dec 30, 2016 at 01:46:32PM -0700, Jaimos Skriletz wrote: > On Fri, Dec 30, 2016 at 1:29 AM, Thomas Glanzmann wrote: > > Hello Jaimos, > > > >> This is a setting that doesn't need to be run in the function, as it > >> only needs to be set once. Once this is set, this changes the behavior > >> of Maximize and placement functions. > > > > I tried that first, but that didn't work for me. I put it in my .fvwm2rc > > config at the top: > > > > EWMHBaseStruts 144 0 0 0 > > > > That is all you need. You don not need to run this from the function > each time. You must have something overwriting this setting. > > > I also tried: > > > > Style * EWMHBaseStruts 144 0 0 0 Or just use something like + i thiswindow (!maximized) resizemovemaximize -152p -28p 144p 0p + i testrc (nomatch) thiswindow maximize off > > > > EWMHBaseSTruts is not a Style, What? Should have paid more attention when this stuff was written. Got to fix this some time. > read the man page if you are unsure how > to use it. > > > > > Find my .fvwm2rc here: https://pbot.rmdir.de/HvZifRKhJuAx5HqVKScPEw Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
On Fri, Dec 30, 2016 at 1:29 AM, Thomas Glanzmann wrote: > Hello Jaimos, > >> This is a setting that doesn't need to be run in the function, as it >> only needs to be set once. Once this is set, this changes the behavior >> of Maximize and placement functions. > > I tried that first, but that didn't work for me. I put it in my .fvwm2rc > config at the top: > > EWMHBaseStruts 144 0 0 0 > That is all you need. You don not need to run this from the function each time. You must have something overwriting this setting. > I also tried: > > Style * EWMHBaseStruts 144 0 0 0 > EWMHBaseSTruts is not a Style, read the man page if you are unsure how to use it. > > Find my .fvwm2rc here: https://pbot.rmdir.de/HvZifRKhJuAx5HqVKScPEw This is not complete, you have a Read ~./fvwm2rc-local (well you should but you use PipeRead and cat, just use Read). You also have some other things you don't need but that is beyond this thread. If the line is not working it is because you override it somewhere in your config file and putting it in the function sets it back. You shouldn't need that. When fvwm loads, use FvwmConsole and enter in that EWMHBaseStruts command into the console, it should work. This shows that you have something in your local config that is overriding the setting. Running that command each time you maximize a window is not needed unless your configuration is constantly resetting the EWMHBaseStruts jaimos
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
Hello Jaimos, > This is a setting that doesn't need to be run in the function, as it > only needs to be set once. Once this is set, this changes the behavior > of Maximize and placement functions. I tried that first, but that didn't work for me. I put it in my .fvwm2rc config at the top: EWMHBaseStruts 144 0 0 0 I also tried: Style * EWMHBaseStruts 144 0 0 0 And reloaded fvwm2, new windows where still fullscreen. I'm running the debian stable fvwm2 version: fvwm 2.6.5 compiled on Nov 14 2013 at 13:45:35 Debian: fvwm 2.6.5.ds-3 Find my .fvwm2rc here: https://pbot.rmdir.de/HvZifRKhJuAx5HqVKScPEw Cheers, Thomas
Re: FVWM: Telling fvwm to not use the top left 124x1152 even for maximized windows
Hello Thomas, > > I would like to instruct fvwm not use the top left 124x1152 pixels. > Use EWMHBaseStruts. thanks a lot. I put that in my FullScreen function and it works like a charm: AddToFunc FullScreen + I EWMHBaseStruts 144 0 0 0 + I ThisWindow Maximize + I ThisWindow (!Maximized) WarpToWindow -5p -5p Happy new year and thanks a again for the hint and function. Cheers, Thomas