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: fvwm2 -> fvwm3 (War: FVWM: Resizing)
Am Do den 11. Mai 2023 um 21:27 schrieb Thomas Adam: > > - FvwmProxy gone > > Correct. Is there any replacement? I was using FvwmProxy quite often as I often have many windows one upon the other and need to find a specific window. It is also helpful to find windows that some cracy applikation set to 1x1 pixel without border. (Don't laugh! I had that several times.) Ah, yes, the focus policy seems to be changed. Especially with SloppyFocus. When my button menu closes it takes the focus from different window. I also found out that the config must not have BOMB marking. (I usually have all files in utf8 encoding with bomb as my vim setup open non-BOMB-files as latin1.) I also found that restart of fvwm3 does iconize some (not all) windows. 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: fvwm2 -> fvwm3 (War: FVWM: Resizing)
tl;dnr ... many thanks to all, but I'm still struggling with the syntax. Can anyone provide me with a config line which does: "For all windows, search the current IconPath for a file .png and use it if found." and, optionally: "... and if not found, use the application-provided icon, or if none, no icon at all" but I'd be happy with anything (except a crash ;) ) in the "not-found" case. (I've had some partial success with "Style ** Icon terminal.png" but I don't want that on all windows, nor to have to add explicit "Style FooApp Icon foo_app.png" lines for everything I use.) On 5/11/23 12:20 PM, Klaus Ethgen wrote: > It might be that the application brings its own icons. Search for > _NET_WM_ICON in the xprop output. Yes, that's what's happening. `xprop` even provides a low-res colored-ascii-block renditoin of the icon. Thanks for clearing up this mystery. > I myself do not use the icons as I use a custom iconize function to > replace the icons with a small snapshot of the content. This sets the > following styles: `WindowStyle IconOverride, Icon > $[FVWM_USERDIR]/icon.tmp.$[w.id].png, StaysOnBottom` That's really cool (and something that, somehow, xterms do on my system), but I'd actually prefer a static icon (as long as it's of my own choosing). > So, the IconOverride here is the key. Again as per the "tl;dnr" above, any help appreciated. On Thu, 11 May 2023 14:38:59 -0700, Thomas Adam wrote: > Setting ImagePath here is a little counter-intuitive. It's a > global command that should be set at the top of your file. See: Thanks for the full documentation. Makes perfect sense, and I'd already made the change at Klaus's suggestion. > Hmm. No. Unless you set IconOverride, the preference is to the > application-provided icon. Again, thanks for clearing up what's been a mystery to me for years. Even before my current spate of problems I've never understood why I get one style of icon for my terminal windows (mate-terminal, KDE konsole, etc) but a different one after a "FvwmCommand restart" (and seemingly sometimes at random, without). > > Q: How can I list the compiled-in default "+" ImagePath, maybe > >with some command in an FvwmConsole? > > You can't easily. Sad, but understandable since I'm probably the first person who's needed it in the 30 year history of Fvwm. > Try the fvwm2 version from git. I think the crash is only happening due to my current problems, and only happens if I forget to un-iconify all windows before doing "restart". (That didn't crash on my previous openSUSE versions, but also didn't work correctly.) If that's the case I'll probably punt and get back to what I'm supposed to be working on instead of fighting these install teething pains. But, yes, my next step was to build 2.x and/or 3.x from source (openSUSE Tumbleweed doesn't provide 3.x despite being a rolling release which claims to track the latest from all projects). If nothing else, I was going to compile the source to add some debug output to print ImagePath.
Re: fvwm2 -> fvwm3 (War: FVWM: Resizing)
On Tue, May 09, 2023 at 08:51:00PM +0100, Klaus Ethgen wrote: > Am Mo den 8. Mai 2023 um 19:24 schrieb Thomas Adam: > > In fvwm3, randr support supports this without a restart, but it needs more > > testing. > > That brings me to the topic I did long postponed. > > How to best move from fvwm2 to fvwm3? Use: fvwm-convert-2.6 Along with release notes: https://github.com/fvwmorg/fvwm3/releases I also recall cks writing a blog post about this: https://utcc.utoronto.ca/~cks/space/blog/unix/Fvwm2ToFvwm3 > I just gave it a try and found several incompatibilities. You will do -- this is now a feature, and not a bug. > First I notice that fvwm3 does log nothing to .xsession-errors by > itself. I have to start it with `-v -o -`. It will log some things to stderr, but given how some display managers now redirect this, it was becoming more and more inconsistent. So yes, if you want to see output from fvwm3, you can use: fvwm3 -v pkill -HUP fvwm3 The signal will toggle the logging. BTW, the default log file location is $FVWM_USERDIR/fvwm3-output.log > The next is that there is somewhere default config that overwrite or > replace parts of my config. No -- no more than fvwm already has. > I just put my current and growed config to [0]. > > - Xinerama (Line 8/9) does not work anymore, what is the correct > replacement? There isn't. You now need to use xrandr(1) or some other tool to represent your monitors, and fvwm3 will automatically use that. > - The Colorset styles seems to be broken that way > - HilightBack and HilightFore style not supported > - Color style not supported Correct. Use colorsets for everything now. > - FvwmProxy gone Correct. > - The title line is completely different now. I use to have blue for > activated window and grey for inactive. Now it is the opposite (Have > to do with HilightFore and HilightBack) Again, use colorsets. > - How to have a config file for both versions with some > in-config-switches to choose between incompatible options? You could use: Test (Version ), but I would suggest converting your config file across. fvwm2 isn't being maintained any more. And fvwm3 was never guaranteed to be backwards compatible with fvwm2 -- it tries to be in that those areas which haven't changed will still work, but at some point things will diverge. Kindly, Thomas
fvwm2 -> fvwm3 (War: FVWM: Resizing)
Am Mo den 8. Mai 2023 um 19:24 schrieb Thomas Adam: > In fvwm3, randr support supports this without a restart, but it needs more > testing. That brings me to the topic I did long postponed. How to best move from fvwm2 to fvwm3? I just gave it a try and found several incompatibilities. First I notice that fvwm3 does log nothing to .xsession-errors by itself. I have to start it with `-v -o -`. The next is that there is somewhere default config that overwrite or replace parts of my config. I just put my current and growed config to [0]. - Xinerama (Line 8/9) does not work anymore, what is the correct replacement? - The Colorset styles seems to be broken that way - HilightBack and HilightFore style not supported - Color style not supported - FvwmProxy gone - The title line is completely different now. I use to have blue for activated window and grey for inactive. Now it is the opposite (Have to do with HilightFore and HilightBack) - How to have a config file for both versions with some in-config-switches to choose between incompatible options? Regards Klaus [0] http(s)://www.ethgen.ch/~klaus/fvwm-config (yes, the certificate is CACert for purpose.) -- 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
FVWM: Resizing
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). Related to that, how to best set the screen DPI in fvwm config? 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 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
FVWM: Resizing BarButtons based on display size
Hi all,
This is a bit of a silly question. I have a FVWM config that's about 10
years old now that I set up to be largely keyboard oriented and maximise
screen real-estate.
For system status and a calendar, I have a BarButtons instance on the
right-hand side of the display which I can call up by hitting Logo, Z.
The problem is every time I've moved to a new machine, I have to edit
the config file to appropriately dimension the panel.
I want the panel to be the full height of the display, minus the height
of the task bar (now, fbpanel; since FVWM have dropped FVWMTaskBar).
Right now I have this:
> DestroyModuleConfig BarButtons: *
> *BarButtons: Fore Black
> *BarButtons: Back #cc
> *BarButtons: Font
> "xft:sans-serif:Bold:pixelsize=10;-*-helvetica-bold-r-*-*-10-*-*-*-*-*-*-*"
> # Geometry - really likes to pick its own size, but giving a position is OK
> # Warning: I've added a size geometry to avoid pbs if the fvwm_icons are
> # not in the image path ! Remove the size in this geometry especially if
> # you add buttons
> #*BarButtons: Geometry 250x568-0+24
> PipeRead "${HOME}/.fvwm/position-barbuttons.sh"
with the script containing this:
> #!/bin/sh
>
> printf '*BarButtons: Geometry 250x%d-0+24\n' $(( \
> $( xdpyinfo | sed -ne \
> '/dimensions/ { s/^.*: \+[0-9]\+x\([0-9]\+\) .*$/\1/; p }' ) -
> 24 ))
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?
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
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
FVWM: Resizing any window to a known geometry
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? Thanks in advance!
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
