I asked this question allready in the german debian forum, but there seem to be to few fvwm users around there. Maybe here is a better place to ask…
After updating Debian recently StartsOnPage does not work anymore for liferea (for all other applications it still works). FVWM changed from 2.6.8 to 2.7.0. I also tried to use fvwm3, but the problem remained.
An almost minimum working example is
ModulePath /usr/libexec/fvwm2/2.7.0
DesktopSize 3x3
Style Firefox* StartsOnPage 1 2, SkipMapping
Style Liferea* StartsOnPage 2 2, SkipMapping
AddToFunc InitFunction
+ I Exec firefox
+ I Exec liferea
AddToMenu root_menu "Root menu" Title
+ "xterm" Exec uxterm
+ "Bye" Quit
Mouse 1 R A Popup "root_menu"
From other posts in this forum I tried to use some more styles, but they didn’t work:
Xsession: X session started for berni at Di 12. Mär 16:40:51 CET 2024
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
localuser:berni being added to access control list
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
I also noticed, that, when liferea is started, for a short moment a small window pops up at the right page, but disappears immediately and then the normal sized window appears in the current page.
Does anyone have an idea how to debug this? Or even better a solution for it?
Welcome on board.
Do you want to start applications on specified pages and desks? Your exsample looks complicated. For this, on Fvwm3 I only run this simple script (config), and it works fine. Read autoMoveW.sys
For Liferea, check the actual name with Module FvwmIdent.
And then Style Liferea* StartsOnPage 0 1 0 with 3 desk/page numbers.
If I missed something in your question, others may answer later.
If it doesn’t work for a single application, the one possibility is the class/resource/name of the application has changed, so Liferea* doesn’t match any windows. So double check the class/resource/name matches. Also you can use BugOpts ExplainWindowPlacement True, and you should get some output about what fvwm is doing when placing a window.
[fvwm][Read]: <<ERROR>> file 'autoMoveW.sys' not found in /home/berni/.fvwm or /usr/share/fvwm2
I couldn’t find any documentation about autoMoveW.sys doing internet search, what is this supposed to do?
I tried that, but it didn’t help. As far as I know, StartsOnPage can take 1, 2 or 3 arguments. As I’m only using one desk (but 3x3 pages), I think, the third number is not needed. (And it worked for 25 years.)
I’m sorry about that: I forgot to mention, that I allread tried Style * StartsOnPage 2 2. With that, all other applications appear on page 2 2, but Liferea not.
[fvwm][__explain_placement]: placed new window 0x1800010 'Liferea':
initial size 650x514
desk 0 (current desk)
page 2 2 (specified by style)
screen: current screen: 0 0 1920x1080 (current screen)
(screen area modified by EWMH working area)
position 3840 2160, placed by fvwm (normal placement)
placement method: TileCascade
The output looks, like everything is fine, but actually it isn’t - there is no more output concerning Liferea or any unknown windows. I guess, this is produced from the small window I sometimes glimps poping up for a very short time. For me it looks like, Liferea closes this window immediately and opens a new one, which seems to bypass fvwm mechanisms somehow.
Sorry, my poor instructions… autoMoveW.sys is an invented file name for the AutoMoveWin script in GitHub.
I installed Liferea and tested with this sample style StartsOnPage. It works fine.
In FvwmConsole, run this line with your chosen desk and page. Style Liferea* StartsOnPage 0 1 0
and manually start Liferea. It loads on Desk 0 Page 1 0.
Could it be that your current config is interfering? When I did the test, I did it on the default config of Fvwm which only shows the RightPanel on the right side. Open FvwmConsole, run the style. And then start Liferea.
@rasat Please stop adding noise to this issue, you are only adding confusion.
@berni One possibility is the application is moving itself to the current view port after it is started (applications shouldn’t do this, but not all applications are well behaved). As you said this works fine for other applications and the output you gave shows fvwm is placing the window on the correct page, but the application is moving itself.
One suggestion is to use InitialMapCommand to move the window to the correct page after it is placed, so something like Style liferea InitialMapCommand MoveToPage 2 2. You could also add a delay to try to work around the application moving itself (if that is what is happening) Style liferea InitialMapCommand Schedule 1000 MoveToPage 2 2.
This works, but of course isn’t ideal, because the window first pops up at the wrong page… I will play around a little with the schedule time. Probably 500 is enough…
I agree not ideal, but it appears to me that your application is doing something non standard, and sometimes you have to work around applications that do that. One last suggestion is you could write a custom function that launches this application, and first GotoToPage 2 2, so you are on the page you want it to be on, but then you’ll have to move back to the page you were on if you did this.
Sounds better, but didn’t work yet. First of all, I think it’s GotoPage not GotoToPage, but anyway I don’t know exactly where I should put this in my config-file. On a separate line did not work, nor as a style option for liferea… In the later case I got
@reid had a similar question about Goldendict to start on a different page and return. Didn’t work for Goldendict but with other apps. He concluded with this comment and config.
Looks promising, but I’m still not completely satisfied. The problem is that the wait-command ends, when the small liferea window pops up, then goto jumps back and the large liferea appears on the wrong page.
I don’t mind, if I start at page 2 2. So it’s pretty fine to just add + I GoToPage 2 2 to the start of my init function. Unfortunately, now some xterms appear on 2 2 instead of 0 0. Of course I could add a style for xterms to appear on page 0 0, but in that case all xterm appear there. I only want the xterms from the init function to appear there.
I tried the obvious, to start the xterms on 0 0, wait for them and then switch to 2 2. This works, but ends in some flickering (I’m rather sensitive to flickering, so this is not a solution for me). I’d prefer to go immediately to 2 2 and let all windows appear at the right place in background. Something like “Change style of xterms in init function - start xterms - change style of xterms back” would be, what I need. I could’n figure out, how to do this.
Alternatively, I somewhen read about -geometry option of xterms. When I remember right, there is a posibility to add the pages there. That would also solve my problem. Just couldn’t find out, how…
I installed Liferea to test things out and confirmed the issue, though I do notice that if you remove SkipMapping that it does correctly start on the correct page, but of course then fvwm moves to the page with Liferea running on it. Looking deeper I think I found out what liferea is doing. If you run from the command line and run liferea --debug-gui you will notice that liferea states that it is GUI : Restoring window position, and that is why it is moving to the current page. I can’t find a way to disable this feature, but maybe you should file a bug with liferea and ask for an option to disable this behavior, because in some cases it is the window managers job to control position, not the application.
I did grep the liferea source code as well, I found the function that restores the window position, should be possible to just bypass that function with a hack and rebuild the software if you really want to deal with this issue. Though I would still contact upstream and ask them to add a feature that allows you to disable this to let the window manager/session manager control positioning of the window.
I did the same. Uncommenting gtk_window_move in liferea_shell.c works for me. (And the build process went astonishingly smooth.) Anyway I don’t like this way of hacking, especially, because one has to redo it every time a security issue is found. Therefore…
I’ll give it a try. But even if they accept, it will take years until this change makes it into debian stable…
Many thanks for your deep investigations!
By the way: I’m not much familiar with how window managers work. But I would have thought that the window manager is always able to overrule every decision of an application. I’m now a little bit confused to learn that this is not true…
Hmm – so this window is mapped just for tray icon support? That in itself, seems like a bug to me, and I think the developer should reconsider his stance on that.
