Re: FVWM: Resizing
On Sun, May 14, 2023 at 11:48:51PM +0100, Klaus Ethgen wrote: > Am Mo den 8. Mai 2023 um 19:24 schrieb Thomas Adam: > > On Sun, 7 May 2023 at 09:08, Klaus Ethgen wrote: > > > what is the best method to react to resizing displays? Be it on beamer > > > or in a virtualbox. > > > > > > Usually, fvwm does not apply to such an event and need to be restarted. > > > But this is suboptimal and I would like to find a better solution (even > > > automatic restart would be better). > > > > In fvwm3, randr support supports this without a restart, but it needs more > > testing. > > Well, now I experimented a bit with fvwm3. > > It is true that the desktop resize dynamicly. But not the position of > button box (that I have on the lower right side). > > I also have a problem with icon size in the buttons. I have a screen > with a very high resolution. Usually I set them with xrandr to 1/4 size > (half x and half y) but as I also experimented with true type fonts that > gets correctly resized, I tried the full resulution. > > Long sentences, The problem is, that the icons in FvwmButtons are only > half size now and only filling a part of their buttons. > > How can I resize them to the correct DPI settings (from xrandr or > Xresources)? > > Regards >Klaus > -- > Klaus Ethgen http://www.ethgen.ch/ > pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen > Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C I use .Xresources. Also, some programs like smplayer have a setting that you can adjust to higher DPI to fix the menu and other fonts within that program. Other programs, such as VLC, I haven't found a fix for, yet. -- Regards, Chris Bennet
Re: FVWM: Resizing
Am Mo den 8. Mai 2023 um 19:24 schrieb Thomas Adam: > On Sun, 7 May 2023 at 09:08, Klaus Ethgen wrote: > > what is the best method to react to resizing displays? Be it on beamer > > or in a virtualbox. > > > > Usually, fvwm does not apply to such an event and need to be restarted. > > But this is suboptimal and I would like to find a better solution (even > > automatic restart would be better). > > In fvwm3, randr support supports this without a restart, but it needs more > testing. Well, now I experimented a bit with fvwm3. It is true that the desktop resize dynamicly. But not the position of button box (that I have on the lower right side). I also have a problem with icon size in the buttons. I have a screen with a very high resolution. Usually I set them with xrandr to 1/4 size (half x and half y) but as I also experimented with true type fonts that gets correctly resized, I tried the full resulution. Long sentences, The problem is, that the icons in FvwmButtons are only half size now and only filling a part of their buttons. How can I resize them to the correct DPI settings (from xrandr or Xresources)? Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature
Re: FVWM: Resizing
On Sun, 7 May 2023 at 09:08, Klaus Ethgen wrote: > Hi fvwm folks, > > what is the best method to react to resizing displays? Be it on beamer > or in a virtualbox. > > Usually, fvwm does not apply to such an event and need to be restarted. > But this is suboptimal and I would like to find a better solution (even > automatic restart would be better). In fvwm3, randr support supports this without a restart, but it needs more testing. > > Related to that, how to best set the screen DPI in fvwm config? > You don't. Use xrandr itself along with xft.dpi in your .Xdefaults file. Kindly, Thomas
Re: FVWM: Resizing BarButtons based on display size
On 01/05/18 01:43, Thomas Adam wrote: > On Sun, Apr 29, 2018 at 12:04:49PM +1000, Stuart Longland wrote: >> This works, but I wonder if there's a more elegant way. Is it possible >> to grab the screen size in the .fvwmrc and do the required arithmetic >> for deriving Geometry? > > $[vp.width] > > Then use PipeRead to do whatever you need to do withit. Ahh brilliant, I take it there isn't a way to subtract a number off that without using PipeRead? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: Resizing BarButtons based on display size
On Sun, Apr 29, 2018 at 12:04:49PM +1000, Stuart Longland wrote: > This works, but I wonder if there's a more elegant way. Is it possible > to grab the screen size in the .fvwmrc and do the required arithmetic > for deriving Geometry? $[vp.width] Then use PipeRead to do whatever you need to do withit. -- Thomas Adam
Re: FVWM: Resizing any window to a known geometry
Original Message Subject: Re: FVWM: Resizing any window to a known geometry From: Dan Espen des...@verizon.net Date: Fri, December 14, 2012 11:07 pm To: msib...@crosswire.com Cc: fvwm@fvwm.org msib...@crosswire.com writes: So I am taking your answer to mean: FVWM can't move a window by handing it an X11 formatted geometry string Any particular reason for this void? Void? Fvwm can't support dozens of different command formats. To convert a geometry string write a program that does the conversion and generates the command(s) you want. Then do something like: PipeRead 'MyConverter 800x600+10+10' Please don't top post. -- Dan Espen Howdy, It isn't that FVWM doesn't support it, but rather that FVWM doesn't 'export' it. Right? FVWM runs on top of X11, which itself uses a standard geometry format. But FVWM reinvents the wheel instead of providing a hook into the lower layer. There are a dozen or more application that take the above format on the CLI, including FvwmIconBox I believe, which takes the format as a Style argument. Surprising that FVWM itself, doesn't conform. Feature request? Call the Command MoveX of something? My guess is that the Move, Resize commands already use this format before it punts the request to X. It's probably less than a 50 line patch. I would do it myself, but my C sucks. The PipeRead solution is not a good one. The example above is simplified. If FVWM can take an X11 formatted string, I can get such strings from commonly available libs, and push them with FvwmCommand. I have considered alternatives, and in this case, all other alternatives suck more. So the question is: Can I communicate with FVWM using a standardized format, or do I have to kludge something up? Generally, it is preferable to do IPC with standardized formats. Since the core advantage of FVWM is its ability to do simple IPC with user developed tools, I figured it would be appropriate to ask if the FVWM team would be interested in implementing such a feature if it does not exist. So... Can the FVWM take X11 formatted geometry strings natively? Please, please please? It is Christmas :-) Thanks in advance!
Re: FVWM: Resizing any window to a known geometry
msib...@crosswire.com writes: Original Message Subject: Re: FVWM: Resizing any window to a known geometry From: Dan Espen des...@verizon.net Date: Fri, December 14, 2012 11:07 pm To: msib...@crosswire.com Cc: fvwm@fvwm.org msib...@crosswire.com writes: So I am taking your answer to mean: FVWM can't move a window by handing it an X11 formatted geometry string Any particular reason for this void? Void? Fvwm can't support dozens of different command formats. To convert a geometry string write a program that does the conversion and generates the command(s) you want. Then do something like: PipeRead 'MyConverter 800x600+10+10' Please don't top post. Howdy, It isn't that FVWM doesn't support it, but rather that FVWM doesn't 'export' it. Right? FVWM runs on top of X11, which itself uses a standard geometry format. But FVWM reinvents the wheel instead of providing a hook into the lower layer. There are a dozen or more application that take the above format on the CLI, including FvwmIconBox I believe, which takes the format as a Style argument. Surprising that FVWM itself, doesn't conform. Feature request? Call the Command MoveX of something? My guess is that the Move, Resize commands already use this format before it punts the request to X. It's probably less than a 50 line patch. I would do it myself, but my C sucks. The PipeRead solution is not a good one. The example above is simplified. If FVWM can take an X11 formatted string, I can get such strings from commonly available libs, and push them with FvwmCommand. I have considered alternatives, and in this case, all other alternatives suck more. So the question is: Can I communicate with FVWM using a standardized format, or do I have to kludge something up? Generally, it is preferable to do IPC with standardized formats. Since the core advantage of FVWM is its ability to do simple IPC with user developed tools, I figured it would be appropriate to ask if the FVWM team would be interested in implementing such a feature if it does not exist. So... Can the FVWM take X11 formatted geometry strings natively? Please, please please? It is Christmas :-) Note that it's not really that simple. ResizeMove does a lot more than an X11 geometry string allows for. As always, patches will be reviewed for possible application. -- Dan Espen
Re: FVWM: Resizing any window to a known geometry
Howdy, So I am taking your answer to mean: FVWM can't move a window by handing it an X11 formatted geometry string Any particular reason for this void? Screen resolutions do change. For my intended purpose, that particular condition is not a factor. Thanks in advance! Original Message Subject: Re: FVWM: Resizing any window to a known geometry From: Thomas Adam tho...@fvwm.org Date: Thu, December 13, 2012 5:16 pm To: msib...@crosswire.com Cc: fvwm@fvwm.org On Thu, Dec 13, 2012 at 02:32:25PM -0700, msib...@crosswire.com wrote: Howdy, I'd like to do something like the following: SetEnv CAPGEOM '800x600+10+10' Key F6 A A ThisWindow (!Iconic) Move $[CAPGEOM] The purpose is to stack various windows at exactly the same resolution for consistent screen capturing. What is the best way to move a window to a known static geometry? Is there a command that will move/resize a window based on a formatted X11 geometry string? This is nothing more than a question of semantics, for which you should see the ResizeMove command in your case. Note that offsets for consistent screen capturing as you put it vary with resolution changes. -- Thomas Adam
Re: FVWM: Resizing any window to a known geometry
msib...@crosswire.com writes: So I am taking your answer to mean: FVWM can't move a window by handing it an X11 formatted geometry string Any particular reason for this void? Void? Fvwm can't support dozens of different command formats. To convert a geometry string write a program that does the conversion and generates the command(s) you want. Then do something like: PipeRead 'MyConverter 800x600+10+10' Please don't top post. -- Dan Espen
Re: FVWM: Resizing any window to a known geometry
On Thu, Dec 13, 2012 at 02:32:25PM -0700, msib...@crosswire.com wrote: Howdy, I'd like to do something like the following: SetEnv CAPGEOM '800x600+10+10' Key F6 A A ThisWindow (!Iconic) Move $[CAPGEOM] The purpose is to stack various windows at exactly the same resolution for consistent screen capturing. What is the best way to move a window to a known static geometry? Is there a command that will move/resize a window based on a formatted X11 geometry string? This is nothing more than a question of semantics, for which you should see the ResizeMove command in your case. Note that offsets for consistent screen capturing as you put it vary with resolution changes. -- Thomas Adam
