I have a problem with the StartsOnDesk option. In the .fvwm2rc file I have the following line:
Style "*" StartsOnDesk 0
If a program is started the first time this works fine, the widow is started on desk 0. However if I close the window and reopen it it will be displayed on the current desk. Please note that closing a window does not mean that the program is terminated, its only an unmap of the window. It seems like fvwm remembers where the window was and displays it at that desk.
I tried to solve this problem with
*FvwmEvent: add_window NewWindowFunc
and move ThisWindow to desktop 0 in the NewWindowFunc. This results in the following behaviour: The window is for a split second shown in the current desk and then moved to desk 0. This is also not acceptable for me.
Then I tried to workaround this problem with :
*FvwmEvent: destroy_window OldWindowFunc
and move ThisWindow to desk 0 when it is closed. This results in correct behaviour for me except upon fvwm restart some of the closed screens show up again, some empty, some with content.
So in short I’m looking for an option that makes fvwm forget on which desktop it was and always open it on desk 0.
That’s not true — when you close a window (via the ‘Close’ command) the window is unmapped, yes, but only as a consequence of it being terminated. When a window is mapped initially to the “Withdrawn” state, then it isn’t shown. It would also depend slightly on the application, but I am not prepared to go into all that much detail.
As for why you want all windows to be on desk 0, why not just have one desk 0 with X pages?
This is overkill.
OK, so the flicker is annoying, in which case, I don’t see why you don’t start the applications up off-screen with an insane geometry, such as 5000 5000. As to why applications are “remembered” — they’re not.
If you could, try doing some regression analysis on your config. Upload your config, if you so wish — at this point, I’m willing to surmise you have the order of your “style” lines in the wrong order, as everything else you have noted, and done with FvwmEvent, is complete overkill.
thanks for your answer, it made me rethink my problem… sometimes when I’m troubleshooting I’m deep down to the details and missing the overview…
It appeared that our applications do not ‘close’ their windows, but only hide them.
We created an application that positions windows and moves them to the correct desktop. Everything is user defined, therefor we thought it would be a good idea if all windows start on desk 0 and our application can then - depending on the user - move them. Everything is dynamic, the user can change pos/desk and next time the window appears it must be moved to that new pos/desk.
About having multiple pages instead of multiple desktops, does that make any difference?
You were right there. My assumption about windows being closed was false as they are in fact just hidden (i think an unmanage is performed). On second request of the window is shown again (manage). Can you think af a solution to make these windows appear on desk 0, like when they are created the first time?
That’s OK. I answer a lot of questions (mostly on mailing-lists — I don’t actually like forums one bit) and the degree to which a question is explained varies. Yours is actually rather a good one — but I like to get specific, so that I know I am on track to providing an answer.
Then I would consider that a bug. Assuming this is an X application, then it should be a matter of course that the application in use responds to the delete window protocol. Essentially ‘close’ should just destroy the window, and exit gracefully. Note that if this application does not close, but rather hides its windows, then it does not understand this event. This is a bug, and you should look at fixing it.
Why, may I ask, given that such a task is done through the WM?
But you’re using FVWM — such things are done, and can be done, via it. You’re probably going to run into all sorts of problems if you use your application under FVWM in terms of window positioning. The WM will usually want to take precedence over such decisions.
I assume there’s a reason why this application was written (quite why you don’t leave up to the WM, is not my decision, but it ought to be)? I can only think that you’re doing it because you might want to use other WMs besides FVWM? Either way, running it under FVWM is superfluous.
For instance, what you can tell a window to be sticky:
Style foo Sticky
You can go as far as to make it StickyAcross{Desks,Pages}:
You can also go as far as to (when changing pages/desks) for a particular page (or desk) number, to make the window non-sticky, so that you don’t see if for that page/desk. I’ve a variation on a theme in another posts I will gladly dig-up, if you so wish. (Essentially, this is where ‘PipeRead’ is useful).
Don’t think me rude of my criticism over your application, it’s just that it seems a little odd you should need to use it in FVWM, given that the functionality is already there.
No, not really. But it might make your life only ever so slightly easier. But it’s such a slim difference, that it really doesn’t matter.
See above – I suspect your application doesn’t know how to handle the delete window protocol.
In the past it was decided that the windows should not be closed for performance reasons (it is displayed very fast if opened (read shown) again). Because the number of applications with this behaviour is very large it is not possible to change this
You are correct, but there is more to be done than wat is described here so it was decided to create our own solution that makes use of a WM (currently fvwm, but it could also be another window manager)
Still no solution to my problem, but it is clear now that it is not fvwm’s fault.
