FVWM: how to prevent involuntary page switching?
Hi, how can I prevent fvwm from automatically switching to the desktop page where an application like gajim receives a message and activates a window (or whatever it does to force this switch)? As you can imagine, it´s very annoying when you´re suddenly switched to a different program residing on a different page, especially while you´re typing somewhere else.
Re: FVWM: how to prevent involuntary page switching?
Michelle, it´s so nice to see a post from you :) I remember you from the debian-users mailing list a long time ago. "Michelle Konzack" writes: > Am DATE hackte AUTHOR in die Tasten: hw >> Hi, >> >> how can I prevent fvwm from automatically switching to the desktop >> page >> where an application like gajim receives a message and activates a >> window (or whatever it does to force this switch)? > > Deactivate the behaviour in the settings... That´s the first thing I tried, and I couldn´t find a way to disable it.
Re: FVWM: how to prevent involuntary page switching?
Robert Brockway writes: > On Thu, 26 Apr 2018, Robert Brockway wrote: > >> On Thu, 26 Apr 2018, hw wrote: >> >>> Hi, >>> >>> how can I prevent fvwm from automatically switching to the desktop page >>> where an application like gajim receives a message and activates a >>> window (or whatever it does to force this switch)? >>> >>> As you can imagine, it?s very annoying when you?re suddenly switched to >>> a different program residing on a different page, especially while >>> you?re typing somewhere else. >> >> Years ago I added this to my config to solve this problem: >> >> DestroyFunc EWMHActivateWindowFunc >> Style * !FPFocusByProgram > > Sorry to follow-up to myself. Looks like I'm also using: > > DestroyFunc UrgencyFunc I simply used all three, and it seems to work :) Thank you all for you help!
FVWM: deprecated? placing firestorm windows?
Hi! Fvwms manpage says: Placement policy options and window stacking !UsePPosition instructs fvwm to ignore the program specified position (PPosition hint) when adding new windows. Using PPosition is required for some applications, but if you do not have one of those it's a real headache. Many programs set PPosition to something obnoxious like 0,0 (upper left corner). Note: !UsePPosition is equivalent to the deprecated option !UsePPosition Is "!UsePPosition" deprecated? I'm trying to figure out how to make it so that when Firefox opens three windows when it's restoring the last session when it's started, these windows are not put on top of each other (at the top left side of the display) but placed according to the placement policy. Some years ago, I had found out that I need to use "FixedPPosition" for Seamonkey to prevent it from creating windows at unreachable places, i. e. way off screen on desktop pages that didn't even exist. So I´m using this option for Firefox now. What option(s) can I use to prevent windows being created by Firestorm at unreachable places and yet have them placed according to the placement policy?
Re: FVWM: deprecated? placing firestorm windows?
Stefan Blachmann writes: > This is a long story... > sessionrestore.js some day years ago got a regression and no longer > did check for out-of-bounds coordinates indicating windows being > placed on other virtual screens, i.e. it placed windows way > off-screen, at crazy coordinates like -4, 3 etc. > > I reported this to Mozilla and asked this to be fixed. This resulted > in the "fix" that all coordinates were clipped to the current virtual > screen size, piling the restored FF windows in the current virtual > screen. I thought FixedPPosition is preventing this? Maybe I´m mistaken: "FixedPPosition and FixedPSize make fvwm ignore attempts of the program to move or resize its windows. [...] If windows are created at strange places, try either the VariablePPosition or !UsePPosition styles." "!UsePPosition instructs fvwm to ignore the program specified position (PPosition hint) when adding new windows." Maybe it works when I use both options. I didn´t realise that one prevents the window from being moved and the other from being created at a particular position by the program that creates the window. But that doesn´t work either, the windows are placed on top of each other again. With !UsePPosition alone, I get the windows placed as I want it, but it means Firefox is moving them rather than that fvwm places them. > I was annoyed and looked into that. > session[re]store.js is a *horrible* mess of code, and to understand > its workings, I just disabled the screen bounds check where > sessionrestore creates the windows from the data in the > sessionrestore.js file and wrote a script that just corrects the > coordinates in the sessionrestore.js file, so that Firefox restores as > it should. > So I could just run the firepox script, after that run FF, it should > restore the windows where they originally were. > > The script might be outdated for new FF versions, as the > sessionrestore code was changed again in the meantime, introducing > again random placement of restored windows. > But reading it might give you some insight of the workings in the > sessionrestore.js files. > > It is on github together with a small intro, here: > https://github.com/kernschmelze/firepox Thanks! I think it must not be possible at all for a program that creates windows to override the very window manager that manages the windows. So this probably needs to be fixed in fvwm. Should I make a bug report?
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Thu, Aug 23, 2018 at 07:10:47PM +0200, hw wrote: >> Hi! >> >> Fvwms manpage says: >> >> >>Placement policy options and window stacking >> !UsePPosition instructs fvwm to ignore the program >> specified position (PPosition hint) when adding new >> windows. Using PPosition is required for some >> applications, but if you do not have one of those it's a >> real headache. Many programs set PPosition to something >> obnoxious like 0,0 (upper left corner). Note: >> !UsePPosition is equivalent to the deprecated option >> !UsePPosition >> >> >> Is "!UsePPosition" deprecated? > > No, it just means that styles nowadays are all negated with a '!' > in front of them and the old names with "No..", "Dont..." etc. > shouldn't be used anymore. There's a type though; the manpge > should state that "NoPPosition" is deprecated. Should make a bug report? >> Some years ago, I had found out that I need to use "FixedPPosition" for >> Seamonkey to prevent it from creating windows at unreachable places, >> i. e. way off screen on desktop pages that didn't even exist. So I??m >> using this option for Firefox now. >> >> What option(s) can I use to prevent windows being created by Firestorm >> at unreachable places and yet have them placed according to the >> placement policy? > > Well, the full array of options to get shitty applications under > control is: > > Style ... fixedpposition, fixedusposition > Style ... fixedpsize, fixedussize > style ... gnomeignorehints, EWMHIgnoreStackingOrderHints > style ... EWMHIgnoreStrutHints, EWMHPlacementIgnoreWorkingArea > style ... EWMHIgnoreStateHints > > (The fixedus... styles make it impossible for the user to move or > resize the window too. If they re the only way to make the > application behave, one could make a script that waits for a few > seconds or until the windows appear and then remove the style.) Thanks! Alas, these options don´t have the desired effect with Firefox. What has an effect is TileManualPlacement (with FixedPPosition): With TileManualPlacement, I get to place the windows manually when Firefox starts. What I want is MinOverlapPlacement, or MinOverlapPercentPlacement. When I use either, the Firefox windows are placed on top of each other. I was wondering if something is going on that prevents fvwm from noticing for the placement that there are windows already there when Firefox suddenly creates its three because it is creating them too fast or somehow not entirely. Yet getting to do manual placement when TileManualPlacement is used would indicate that fvwm does realise that these windows are being created. The manual placement fvwm falls back to, when TileManualPlacement is used, would indicate that fvwm can not find a smart location for these windows. What could be causing this? Is Firefox somehow claiming the entire screen because it tries to place the windows itself, making fvwm figure there is no good place to put them? Without FixedPPosition, the windows are still being placed on top of each other. I´ll resort to TileManualPlacement for now because it´s easier to place the windows where I want them as they are created than it is to move them once they´re all there. > There's also the option > > bugopts explainwindowplacement on > > Which will print a detailed report to the console when new windows > are placed. You mean the FvwmConsole module? Nothing is printed there when I enable this and place any window.
Re: FVWM: deprecated? placing firestorm windows?
Stefan Blachmann writes: > On 8/24/18, hw wrote: > >> But that doesn´t work either, the windows are placed on top of each >> other again. With !UsePPosition alone, I get the windows placed as I >> want it, but it means Firefox is moving them rather than that fvwm >> places them. > > Yes, FF creates its windows with the size given in sessionrestore.js, > *then* moves, retitles and paints them. You can see the detailed > sequence this is done in the sessionrestore code. > You might notice some of these freshly-created windows flashing up for > a *very* brief moment before "disappearing" again. > If you configure FvwmWindowList to show the window coordinates, then > you can easily see "where" the windows are. I can see that they are being placed on top of each other rather than side by side. Fvwm does prevent the windows from being moved. Only it doesn't place them according to the placement policy. It looks as if fvwm doesn't know that there are already windows from Firestorm on the screen when deciding about where to place them. > On 8/25/18, Dominik Vogt wrote: >> It actually is possible. Sort of. If the application claims that >> a requested position is "user specified" instead of "program >> specified", the window manager has no way of knowing that the user >> did not ask for it. Nowadays many programs abuse this hint to >> override the window manager - in clear violation of the >> communication rules set in the ICCCM2 standard. > > Well, Firefox is correct if it says "user specified" position, as > *you* probably were the one who originally specified it by moving the > window. > > Firefox moves windows off-screen when playing something fullscreen by > Flash, and maybe even HLS.js too, so I guess the underlying cause of > our problem is that Firefox stores these temporary positions *instead* > of the original ones (i.e. those before switching to fullscreen > playback) when it does its regular sessionrestore.js file updates. > > So, may I ask, did Firefox crash in full screen video playback mode? > Or what did happen before the problem of incorrect session restore arised? In my case, the problem was with Seamonkey. I'm using a desk with 4 by 4 pages. That makes it possible to place windows like this, the dots being the windows: 1 2 3 4 |---|---|---|---| | | . | | | 1 |---|---|---|---| | . | . | . | | 2 |---|---|---|---| | | . | | | 3 |---|---|---|---| | | | | | 4 |---|---|---|---| On the next start, Seamonkey would restore the session, including this window layout. You can imagine what happens when it does so relative to the window in the middle (the one at (2, 2)) when you start Seamonky on page (1, 1) instead: You can get two unreachable windows. Setting FixedPPosition fixed that for Seamonkey. With Firefox, I think using FixedPPosition, !UsePPosition fix it as well, but the problem is that for some reason, fvwm does not place the windows according to the placement policy. If you want to try: Style * MinOverlapPercentPlacement Style * FixedPPosition Style * !UsePPosition Style * !UseTransientPPosition Style * DecorateTransient Start Firefox and make it so that it has three windows. Now place these windows all side by side on the same desktop page so that they do not overlap any other windows or each other. Close Firefox and see what happens when you restart it: The three windows are being placed on top of each other at the top left corner of the page. Why is that? This is just wrong, isn't it? > Because, maybe the best thing we can do is to collect as much > information about the problem as we can, so we can file a helpful > Firefox bug report that actually enables Mozilla to get that fixed? I'm not sure that fvwm is entirely innocent in this case. I'm not entirely sure that there is something that Mozilla needs to fix because when I let Firefox do its thing, it restores its windows as they were. If they already fixed creating windows at unreachable places, what is left for them to fix? > P.S.: I also had instances of LibreOffice hanging offscreen, in every > case following some (major?) update. Seems it does no version-check > its preferences+session files, as deleting these always fixed the > problem for me. Hm, we use that quite a bit at work, and I actually kinda like how it remembers the position and the size of the window. I´ve never had problems with LO creating windows at unreachable places. Do you still have this problem with the Styles above?
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Fri, Aug 24, 2018 at 10:41:45PM +0200, hw wrote: >> Dominik Vogt writes: >> >> > On Thu, Aug 23, 2018 at 07:10:47PM +0200, hw wrote: > [...] >> > Well, the full array of options to get shitty applications under >> > control is: >> > >> > Style ... fixedpposition, fixedusposition >> > Style ... fixedpsize, fixedussize >> > style ... gnomeignorehints, EWMHIgnoreStackingOrderHints >> > style ... EWMHIgnoreStrutHints, EWMHPlacementIgnoreWorkingArea >> > style ... EWMHIgnoreStateHints >> > >> > (The fixedus... styles make it impossible for the user to move or >> > resize the window too. If they re the only way to make the >> > application behave, one could make a script that waits for a few >> > seconds or until the windows appear and then remove the style.) >> >> Thanks! Alas, these options don??t have the desired effect with Firefox. >> >> What has an effect is TileManualPlacement (with FixedPPosition): With >> TileManualPlacement, I get to place the windows manually when Firefox >> starts. What I want is MinOverlapPlacement, or >> MinOverlapPercentPlacement. When I use either, the Firefox windows are >> placed on top of each other. > > Are you sure that the styles match? If windows would be created > without a name first, the style does not match, and firefox could > do with them what it wants. Ok, let me try ... Style * MinOverlapPercentPlacement Style * FixedPPosition Style * !UsePPosition Style * gnomeignorehints Style * EWMHIgnoreStackingOrderHints Style * EWMHIgnoreStrutHints Style * EWMHPlacementIgnoreWorkingArea Style * EWMHIgnoreStateHints Style * DecorateTransient Style * !UseTransientPPosition No luck, the Firefox windows are still all placed at the top left corner. >> I was wondering if something is going on that prevents fvwm from >> noticing for the placement that there are windows already there when >> Firefox suddenly creates its three because it is creating them too fast >> or somehow not entirely. Yet getting to do manual placement when >> TileManualPlacement is used would indicate that fvwm does realise that >> these windows are being created. >> >> The manual placement fvwm falls back to, when TileManualPlacement is >> used, would indicate that fvwm can not find a smart location for these >> windows. > > You mean as a command or as a style? I mean the placement policy as a style, falling back as described in the manual: , | TileManualPlacement | | This is the same as TileCascadePlacement, but uses ManualPlacement as | the fall-back method. ` That means I do get to manually place the windows when I use TileManualPlacement instead of MinOverlapPercentPlacement or MinOverlapPlacement. I can also see the windows being cascaded on top of each other when I use TileCascadePlacement. I'm finding it suspicious that two placement options work only half-way and two others do not work at all. All these options do have in common that for all of them, the part which is not working is the part where fvwm is supposed to figure out where to place the windows *depending on which other windows they would cover*. It is like fvwm can not figure out that there are windows, or does not consider them when figuring out the placement. >> What could be causing this? Is Firefox somehow claiming the entire >> screen because it tries to place the windows itself, making fvwm figure >> there is no good place to put them? Without FixedPPosition, the windows >> are still being placed on top of each other. >> >> I??ll resort to TileManualPlacement for now because it??s easier to place >> the windows where I want them as they are created than it is to move >> them once they??re all there. >> >> > There's also the option >> > >> > bugopts explainwindowplacement on >> > >> > Which will print a detailed report to the console when new windows >> > are placed. >> >> You mean the FvwmConsole module? Nothing is printed there when I enable >> this and place any window. > > No, in the output of the X server, wherever that goes. After trying to get systemd to create log files, it apparently goes into /var/log/Xorg.0.log (where it might have gone to before). Alas, no output is added to the log file when I use this option and create windows. Do I need to set compile time options for fvwm to make this work? It seems it must be "true" rather than "on", but that doesn't seem to give any output, either.
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Fri, Aug 24, 2018 at 10:58:51PM +0200, hw wrote: >> Stefan Blachmann writes: >> > I was annoyed and looked into that. >> > session[re]store.js is a *horrible* mess of code, and to understand >> > its workings, I just disabled the screen bounds check where >> > sessionrestore creates the windows from the data in the >> > sessionrestore.js file and wrote a script that just corrects the >> > coordinates in the sessionrestore.js file, so that Firefox restores as >> > it should. >> > So I could just run the firepox script, after that run FF, it should >> > restore the windows where they originally were. >> > >> > The script might be outdated for new FF versions, as the >> > sessionrestore code was changed again in the meantime, introducing >> > again random placement of restored windows. >> > But reading it might give you some insight of the workings in the >> > sessionrestore.js files. >> > >> > It is on github together with a small intro, here: >> > https://github.com/kernschmelze/firepox >> >> Thanks! I think it must not be possible at all for a program that >> creates windows to override the very window manager that manages the >> windows. > > It actually is possible. Sort of. If the application claims that > a requested position is "user specified" instead of "program > specified", the window manager has no way of knowing that the user > did not ask for it. Nowadays many programs abuse this hint to > override the window manager - in clear violation of the > communication rules set in the ICCCM2 standard. That's not overriding the window manager, it's overriding what the user wants. IIUC, I explicitly told the window manager to ignore what the program tries to do about the placement of the windows it creates, and yet the window manager still allows the program to do (part of) what it wants rather than what I told the window manager to do about the window placement. So either the window manager is ignoring what I'm telling it to do, or the program is able to override the window manager, or both. Either way, what I´m telling the computer to do is being overridden, and that is not acceptable.
Re: FVWM: deprecated? placing firestorm windows?
Dan Espen writes: > hw writes: > >> Dominik Vogt writes: >>> No, in the output of the X server, wherever that goes. >> >> After trying to get systemd to create log files, it apparently goes into >> /var/log/Xorg.0.log (where it might have gone to before). Alas, no >> output is added to the log file when I use this option and create >> windows. > > It's pretty unlikely the window manager output would go there. > It's much more likely to be somewhere like: > > .xsession-errors > > in your home directory. Hm, I have this file --- last modified in 2014. Hm. .xsession is from 1996 (I better figure out what that does), .xsel.log from 2015, and I can remove .xsession-errors and .xsel-log. So where else might this output go? >> Do I need to set compile time options for fvwm to make this work? > > Nope. > >> It seems it must be "true" rather than "on", but that doesn't seem to >> give any output, either. > > You would see an error message in the same place > if the command had a syntax error. ok It could be so easy if it was showing the debugging output, too. That's what I expected.
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Sun, Aug 26, 2018 at 09:30:14PM +0200, hw wrote: > [...] >> IIUC, I explicitly told the window manager to ignore what the program >> tries to do about the placement of the windows it creates, and yet the >> window manager still allows the program to do (part of) what it wants >> rather than what I told the window manager to do about the window >> placement. >> >> So either the window manager is ignoring what I'm telling it to do, or >> the program is able to override the window manager, or both. > > That's exactly what I wrote. The window manager cannot know that > the application lies about the user's wish. The situation is > impossible to detect. I don't understand: The window manager does not need to detect lies when I tell it not to allow a program to move its windows and not to allow it to create them at a particular position. It only needs to enforce thes policies, and the placement policy. In this case, fvwm appears to be enforcing the creation and movement policies correctly and the placement policy only partially. > [...]
Re: FVWM: deprecated? placing firestorm windows?
Dan Espen writes: > hw writes: > >> Dan Espen writes: >> >>> hw writes: >>> >>>> Dominik Vogt writes: >>>>> No, in the output of the X server, wherever that goes. >>>> >>>> After trying to get systemd to create log files, it apparently goes into >>>> /var/log/Xorg.0.log (where it might have gone to before). Alas, no >>>> output is added to the log file when I use this option and create >>>> windows. >>> >>> It's pretty unlikely the window manager output would go there. >>> It's much more likely to be somewhere like: >>> >>> .xsession-errors >>> >>> in your home directory. >> >> Hm, I have this file --- last modified in 2014. Hm. .xsession is from >> 1996 (I better figure out what that does), .xsel.log from 2015, and I >> can remove .xsession-errors and .xsel-log. >> >> So where else might this output go? > > Maybe if you mentioned the distro you run and the run level you boot to. Fedora 28, booting to console > I'd expect something in $HOME, /tmp, or perhaps /var/tmp. I expected Xorg.0.log in /tmp, but it is in /var/log. Nothing related is in /var/tmp, and I haven't found anything in $HOME. > If you use a .xinitrc you can have the WM output directed where ever > you like otherwise the distro will pick a place. I tried that by redirecting the output of fvwm into a file from within .xinitrc. The file was created buy remained empty. Hm, do I need to redirect fvwms stdderr, too? I think I only redirected stdout. Or does the module create its own output that needs to be redirected when the module is being started?
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Mon, Aug 27, 2018 at 10:43:59PM +0200, hw wrote: >> > If you use a .xinitrc you can have the WM output directed where ever >> > you like otherwise the distro will pick a place. >> >> I tried that by redirecting the output of fvwm into a file from within >> .xinitrc. The file was created buy remained empty. >> >> Hm, do I need to redirect fvwms stdderr, too? > > Of course. ok >> Or does the module create its own output that needs to be >> redirected when the module is being started? > > What module? FvwmConsole
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Mon, Aug 27, 2018 at 10:36:58PM +0200, hw wrote: >> Dominik Vogt writes: >> >> > On Sun, Aug 26, 2018 at 09:30:14PM +0200, hw wrote: >> >> > [...] >> >> IIUC, I explicitly told the window manager to ignore what the program >> >> tries to do about the placement of the windows it creates, and yet the >> >> window manager still allows the program to do (part of) what it wants >> >> rather than what I told the window manager to do about the window >> >> placement. >> >> >> >> So either the window manager is ignoring what I'm telling it to do, or >> >> the program is able to override the window manager, or both. >> > >> > That's exactly what I wrote. The window manager cannot know that >> > the application lies about the user's wish. The situation is >> > impossible to detect. >> >> I don't understand: The window manager does not need to detect lies when >> I tell it not to allow a program to move its windows and not to allow it >> to create them at a particular position. It only needs to enforce thes >> policies, and the placement policy. >> >> In this case, fvwm appears to be enforcing the creation and movement >> policies correctly and the placement policy only partially. > > Then please enlighten us with the output of > > bugopts explainwindowplacement on > > so we can see what's going on. Fvwm just does what it's told, we > haven't coded a glass ball inside it. Thanks to your other post, I finally got this: , | [fvwm][__explain_placement]: placed new window 0x1400010 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (normal placement) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x1400032 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (ignored program specified position) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x1400027 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (ignored program specified position) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x140003d 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (ignored program specified position) | placement method: MinOverlapPercent ` Oh, ok, there is actually four windows, not three. I forgot about the fourth one because I didn't get to see it. A fourth window must somehow have been created after Firefox said it had crashed a Tab and I was missing a window after that. Let's try this with three windows ... The result is the same, all on top of each other at top left: , | [fvwm][__explain_placement]: placed new window 0x110 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (normal placement) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x127 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (ignored program specified position) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x132 'Mozilla Firefox': | initial size 1280x2161 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (ignored program specified position) | placement method: MinOverlapPercent ` This looks to me as if fvwm does not apply MinOverlapPercent after it ignores the program specified position. Let's see what happens when there is a window already on the page when I start Firestorm: , | [fvwm][__explain_placement]: placed new window 0x800e25 'Terminal': | initial size 1146x746 | desk 0 (current desk) | current page | screen: current screen: 0 0 3840x2160 (current screen) | position 0 0, placed by fvwm (normal placement) | placement method: MinOverlapPercent | | [fvwm][__explain_placement]: placed new window 0x110
Re: FVWM: deprecated? placing firestorm windows?
Viktor Griph writes: > Den mån 27 aug. 2018 00:27hw skrev: > >> With Firefox, I think using FixedPPosition, !UsePPosition fix it as >> well, but the problem is that for some reason, fvwm does not place the >> windows according to the placement policy. > > As you describe it it sounds as if Firefox maps the new window before > restroing the size of the window, so Fvwm will do it's placement logic > based on whatever sixe firefix has put on the windows when they are > displayed, What does it mean to "map" a window? Does fvwm not know the size of a window before placing it? > and once placed, Firefox rezises the windows to the old > size. As far as I can see, the windows created by Firefox are each 1/3 the width of the display and full height of the display when they become visible. Apparently, they are not being resized --- unless I can not see that happening. > (It should be obvious from the ExplainWindowPlacement option if > that's the case.) If I could only get that to work ... :) > You can also try to use the "PlaceAgain" comman on the Firefox windows > once they are all restored and see if they pace as you expect then. If > so, you might be able to do some magic with FvwmEvent to trigger a > PlaceAgain automatically on Firefox windows, but I'm not certain it is > possible, or how to configure the module to do it. Interestingly, this option does nothing to the windows of Firefox, and they remain on top of each other. It replaces other windows as expected, though. Oh, and when I manually move the Firefox window which is on top and replace it then, it is being moved to the top left corner of the display so it ends up on top of the other two windows! How come? There must be some bug with fvwm that it can not correctly place the windows of Firestorm.
Re: FVWM: deprecated? placing firestorm windows?
Dominik Vogt writes: > On Tue, Aug 28, 2018 at 03:22:54AM +0200, hw wrote: > [...] >> >> Thanks to your other post, I finally got this: >> >> >> , >> | [fvwm][__explain_placement]: placed new window 0x1400010 'Mozilla Firefox': >> | initial size 1280x2161 >> | desk 0 (current desk) >> | current page >> | screen: current screen: 0 0 3840x2160 (current screen) >> | position 0 0, placed by fvwm (normal placement) >> | placement method: MinOverlapPercent >> | >> | [fvwm][__explain_placement]: placed new window 0x1400032 'Mozilla Firefox': >> | initial size 1280x2161 >> | desk 0 (current desk) >> | current page >> | screen: current screen: 0 0 3840x2160 (current screen) >> | position 0 0, placed by fvwm (ignored program specified position) >> | placement method: MinOverlapPercent > ... >> Oh, ok, there is actually four windows, not three. I forgot about the >> fourth one because I didn't get to see it. A fourth window must somehow >> have been created after Firefox said it had crashed a Tab and I was >> missing a window after that. > > The problem is that the windows are created larger than your > screen. The window height is 2161 pixels but the screen is only > 2160 pixels. Really. Who would have thought of that? After I fit the windows so that they aren't too large, it's working perfectly :) > MinOverlapPercent never places any part outside of the screen. In > this case, the algorithm fails and windows are placed at 0 0. The > message could be improved a bit in that case; I've obviously missed > that case when writing that output. Never happened to me. I think this is worth putting into the documentation so users can be aware that + the policy always fails when a window is too large for the display + and that windows are placed at 0/0 when the placement policy fails. I don't know what exactly goes for which policy. > If you reduce window heigt by a pixel, that should work fine. > > Personally I'm happy with > > Style SeaMonkey MaxWindowSize 99 97 > > which limits the size of Seamonkey windows to 99% of the screen > width and 97% of its height. You may want to try that too (or > even 100%). Cool, I didn't know I could do that. >> BTW, I'm seeing >> >> >> , >> | [fvwm][style_parse_and_set_window_style]: <> Bad style option: >> gnomeignorehints >> ` >> >> >> in the log file. Why is this a bad option? > > The style doesn't exist anymore. Ok, I'll remove it from my configuration. It is still in the man page at several places. Thank you very much for all the help!
FVWM: fvwm3?
Hi, so is there finally a version that works for wayland? What are the differences between fvwm2 and fvwm3?
Re: FVWM: fvwm3?
On Tue, 2024-01-30 at 14:02 -0700, Jaimos Skriletz wrote: > On Tue, Jan 30, 2024 at 1:25 PM hw wrote: > > > > so is there finally a version that works for wayland? > > > No, fvwm only works with xorg and most likely won't be ported. > > > What are the differences between fvwm2 and fvwm3? > > > See https://github.com/fvwmorg/fvwm3/discussions/878 Good pointer, thanks! It's a pity that there's no fvwm for wayland. Xorg doesn't seem to be maintainted anymore and is on the way out. That only leaves us Gnome and KDE. All the diversity we used to have is gone with that.
Re: FVWM: fvwm3?
On Fri, 2024-02-02 at 10:55 -0500, Paul Fox wrote: > I realize this discussion is drifting away from fvwm, but... > > ...a major part of my daily activity has always depended on X11's > ability to function on remote displays. Does that functionality > (i.e. "DISPLAY=remotehost:0" vs. "DISPLAY=:0") exist if either or > both of the hosts is based on Wayland? You'd have to try it out. I can't even try it since I can't tell if I have a configuration with which it could work. It has become a very limited option years ago and is basically obsolete. Just try to run, for example, firefox on a remote host via X11 forwarding. I suspect that anything that might use acceleration powers of a graphics card doesn't work, and that kinda leaves only xterm which would be pointless. It also has always been rather slow (slow on a 1 gigabit network and up to unusably slow over internet (VPN)) and was never a good option. You may be better off setting up xrdp for that, and you can use remmina (which works with wayland) to log in via rdp. It works fine over internet (VPN) as well. Gnome desktop sharing also works great, only you can't log in remotely (yet). You'd have to start a session and enable the sharing first for that. (I've waited over 20 years for a feature like that, and it finally works out of the box!)
Re: FVWM: fvwm3?
On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: > On Fri, 2 Feb 2024, Robert Heller wrote: > > > Afterall, no one needs more then one computer... > > I suppose there is a smiley missing after the sentence :-) > > My usual way of working (post-COVID, from home) involves usually one or > two ssh sessions on two different remote work machines. Quite occasionally > I also activate a VNC viewer with a remote session of a VNC server on one > of the work machines, and run X stuff there. Occasionally I also run a > point-to-point VPN work-home and NFS mount over it, I rsync stuff from > work to home, work on it at home, and rsync back when finished. Very > rarely I edit work files over remote X, and even more rarely over remote > NFS, but that's because I think my connection is low for that. > > At work I used regularly edit across machines over NFS, ssh and > occasionally remote X (but all machines are on a LAN ... some on different > VLANs and I have even expect gatewayed scripts to bypass that) Wireguard works wonders; if set up correctly, it makes no difference if you're at home or at work. NFS only needs a stable connection; if you have that, you can use cachefilesd to make it faster. If your connection isn't stable NFS will suck. For X stuff you can use xrdp. RDP is way faster then VNC. > Independently of all that, I've never considered switching to wayland, and > do not think any colleague does. Our recent standard installation at work > is Xubuntu (it used to be OpenSuse), and I had it mimicked on both the > home desktop (20.04) and home laptop (22.04) ... first thing I did was to > imstall also fvwm, and then run my good old .fvwmrc with the Minimum > Necessary Change. Ugh, Ubuntu ... Wayland is default in Fedora since a while, and I've been reading it's default in Debian as well (but is that true?). > I hope to be able to go on with Xorg until I live. Or use wayland and start living now :) Living in the past seldwhen is a good idea.
Re: FVWM: fvwm3?
On Fri, 2024-02-02 at 22:42 -0600, Jason Tibbitts wrote: > I'm running wayland right now (with the KDE desktop) and can fire up > a local xterm or ssh to a different machine and run xterm and it > works just fine. Does this have to be done from an X11 client (like xterm) so you're doing it from within an Xwayland client? Or does it just work with native wayland clients like gnome terminal with some magic done somehow with the Xwayland process that was started by gnome-shell (or kwin)?
Re: FVWM: fvwm3?
On Sat, 2024-02-03 at 22:05 +, Thomas Adam wrote: > [...] > GTK and QT dropping support for XLib, that's the time to worry -- as there > could, in theory, be a time when Firefox or Chromium no longer run under X > directly, without forcing a Wayland compositor. That's the real > nail-in-the-coffin. It's already there in that the gnome developers seem to be planning to drop all X11 support, and gnome won't run under X11 anymore. Once that happened, there may come up intentions to remove all the X11 cruft from GTK and QT: Who's gona maintain it when it's no longer used anyway? > So, I'll keep fvwm alive for as long as I can, but I really can't see how > there could ever be a Wayland compositor. I still don't see why it shouldn't be possible. I never expected a port, and I understand that the architectures of X11 and Wayland are very different. Yet why shouldn't it be possible to create a compositor that provides the configurability fvwm has and which is so badly lacking in Gnome and KDE? Gnome doesn't even allow you to configure a program to start with floating sticky windows so you have to set that manually every time the program starts, and that totally sucks. Last time I checked, KDE could do it --- and I like KDE better than gnome, but KDE has always been rather slow and too buggy. Fvwm can do tiling very well, using the tiling extension, and neither Gnome nor KDE come anywhere close. I had fvwm configured such that it managed the windows for me. Gnome and KDE will probably never be able to do that and will continue to force me to manage them myself. Is it really impossible to create a wayland compositor that provides the required functionality?
Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 12:38 -0800, mark_at_yahoo wrote: > On 2/7/24 20:09, hw wrote: > > On Sat, 2024-02-03 at 13:53 +0100, Lucio Chiappetti wrote: > > > I hope to be able to go on with Xorg until I live. > > > > Or use wayland and start living now :) Living in the past seldwhen is > > a good idea. > Except when the past is better: More capable, complete, and highly > evolved architectural design. Read and understand Thomas' posts. Is it really better? It seemed to me that wayland scales better in that it leaves each program to work on its own and sending the results of its work to what they call a compositor that pieces it all together whereas Xorg requires a server process to do it all which could be a bottleneck. > Wayland improves performance over X11's client-server model? Does it? > Fine. If it wasn't possible to streamline X11 (I'm not convinced) > then do the full redesign ... but include all the capabilities of > the ICCCM and EWMH APIs. Even via an alternate, lower performance, > internal path if necessary. Who is gona do that? IIUC there are obsolete things that must be supported because the protocol requires them, and apparently the protocol is set in stone. That seems to prevent a redesign, and what would be the advantage of reinventing the wheel in exactly the same undesirable way? On of top that, it might be rather difficult to add new features for technical reasons and simply because nobody really wants to that anymore. > As I said before, Wayland sucks. If for no other reason that it will > force me to use bloated, crap window managers (excuse me: "Desktop > Environments"). You're being forced to use them anyway. The problem is not a particular window manger but other software as well since that software has made it impossible to do basic things like adjusting the font size, and it tends to depend on other software which is part of such so-called desktop environments. For example, try to use Evolution without gnome-keyring or kmail without akonadi, and try to get the fonts readable without gnome or kde. You can more or less do the things you do with software that doesn't depend on a so-called desktop environment, but not really, and what you can still do is more complicated and difficult than just using the software that works with the so-called desktop environment. Having to either hold a magnifying glass in front of the screen to be able to read the fonts or using software that isn't up to the task isn't the only problem, only a very annoying one. > Either that or primitive tiling ones (talk about living in the > past). So you're arguing that not using a so-called desktop environment, like instead of fvwm, means you're living in the past. Maybe try sway or i3 and you'll understand that they aren't primitive at all. > But I guess I'll be able to play live, alpha-blended video as the > background in a terminal window -- a nightmare, I mean utopian > dream, I never knew I had or needed. Maybe --- as long as you're not being forced to do such things, it's fine.
Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 18:10 +, Thomas Adam wrote: > On Thu, Feb 08, 2024 at 05:50:44AM +0100, hw wrote: > > I still don't see why it shouldn't be possible. I never expected a > > port, and I understand that the architectures of X11 and Wayland are > > very different. Yet why shouldn't it be possible to create a > > compositor that provides the configurability fvwm has and which is so > > badly lacking in Gnome and KDE? > > Absolutely it is possible. But then it wouldn't be fvwm. > > > Is it really impossible to create a wayland compositor that provides > > the required functionality? > > I'm not entirely certain you've understood the points in my original email. Maybe --- I don't understand why it shouldn't be possible to make am fvwm that works with wayland. I can understand that wayland refuses to manage windows which might make it difficult to do that, yet it seems to work with gnome. > I also don't want to repeat myself, but... > > To me, the things which make fvwm unique, are: > > 1. Its architecture is tied to X11 -- it uses Xlib directly to render window > frames. This is all using Xlib's graphics backend which has a large array of > 2d drawing routines. There's not a separate library which can be used to > abstract this out to be used elsewhere -- this is the entire point of the > client/server model in X11. > > The only thing which comes close is libcairo (built on pixman) -- and you can > use that with a wlroots-based compositor to generate "SSDs" within a > compositor -- but this doesn't work well for fvwm because it doesn't allow for > shading when filling in rectangles, as well as various other things. > > This is important because, for me, the entire point of fvwm is that it can be > made to look like MWM. I'm serious here -- all of that blocky (even "ugly", > as some people have called it) looking borders is important to me, that's what > I like. Are you saying it's impossible with wayland to draw stuff like window decorations on a display and only X11 can do it? It seems to work just fine with gnome. > 2. Even if 1., were a solved problem, the second issue is a lack of > reparenting. This is a core feature of xlib, and fvwm makes extensive use of > it to be able to function. It makes things like resizing and moving windows > easier. It's also very important for FvwmButtons; the "Swallow" command calls > XReparentWindow() directly. > > I'm really dumbing-down the explanation here, but it's not possible on Wayland > at present. I suspect it will never be. > > Now, even if the graphics side of things from point 1 above were currently > possible under Wayland, the lack of reparenting means you're having to move > the window frame along with the window itself -- the two are not "connected", > which causes all manner of weird glitches. That doesn't seem to be an issue; I can move windows in gnome. > 3. Lack of standards a la ICCCM/EWMH > > Fvwm is the exemplar project for how implementing standards helps > interoperability rules for window governance. Again, because of the X11 > architecture, the XServer would make this easy. Under Wayland, there's > "portals" but they're now selective about what's being implemented. So things > like aspect-ratio resizing doesn't have a portal. There's so much in the > EWMH which makes fvwm behave the way it does with applications, until that's > addressed -- or if it ever is -- you'll probably notice lots missing from a > potential fvwm-compositor under Wayland. What I'm missing in gnome is configurability, and not only in regard to the window manager (and it doesn't really matter if it's called a compositor). So I don't see how ICCCM/EWMH would be relevant; I can only assume they aren't available with wayland, and yet things are working without. > Let's not forget though that fvwm being a reparenting window manager was > always making it an outlier. So does that mean that reparenting is a feature almost no window manager made use of except fvwm? Haven't they been able to do their job because they didn't use this feature? > Widget libraries like GTK and QT have gone way beyond just providing > UI components -- they're now also responsible for CSDs and a myriad > of other crap -- and when you put that into context of what a > Wayland compositor needs to do -- it has fewer options. Styling and > theming becomes the same across Wayland compositors. So you're > losing out on a lot with the Wayland architecture being what it is, > alas. Isn't it one of the purposes of
Re: FVWM: fvwm3?
On Thu, 2024-02-08 at 21:02 +1000, Stuart Longland wrote: > On 8/2/24 13:51, hw wrote: > > It has become a very limited option years ago and is basically > > obsolete. Just try to run, for example, firefox on a remote host via > > X11 forwarding. I suspect that anything that might use acceleration > > powers of a graphics card doesn't work, and that kinda leaves only > > xterm which would be pointless. It also has always been rather slow > > (slow on a 1 gigabit network and up to unusably slow over internet > > (VPN)) and was never a good option. > > Oddly enough, it *does* work, even via SSH over a WAN link, with a few > caveats. > > 1. you must start with `--new-instance` if you have Firefox running on > your local workstation as well; otherwise it'll "talk" to your local > Firefox instance and tell *it* to open a new window > 2. there'll be some noticeable lag, forget watching videos Last time I tried it didn't work at all. And what's the point when it's so slow that it's useless. I guess you can still try to do some web browsing with lynx as well :)
