What is the best way to store some information concerning windows between sessions? Like for example State and decoration?
Why I need it and what I am trying to do: I would like some sort of dynamic tiling in fvwm, and so far I am going to use State command to determine which windows (probably by title) are to be treated in tiling manner and I probably would need small text files to describe ‘tiling layouts’, and I would like these to be changed and modified with hotkeys, without manually writing it all in configuratrion files.
One (stupid) approach I know is to write a script generating config files and Read command, but that’s very dirty.
You see – “store” implies just that – that you can dynamically generate a FVWM config snippet which you can read in. Unfortunately, what most people mean by it is:
“How can I make window specific styles maintain themselves across restarts?”
You can’t – not in a sane manner. I’ve heard people suggest things like storing the window’s class name in a file and using that as a basis to match for to apply styles, etc., but that’s crap because that’s still not referring to that window – the chance is it could be any window that just happened to match that class. Window decoration changes using windowstyle are out of the equation for this.
I’ll give an explanation as to why, because I’m sick of repeating myself.
When you run a program, let’s say “xterm”, here’s what you get:
The FVWM window gets assigned an ID, let’s say “0x12345”. That ID is unique to that window for the duration of that window’s lifetime. When you restart FVWM, the client windows (in this case, xterm itself) is reparented to the root window so we don’t lose it. FVWM then restarts, and recaptures the window, and reparents it into a new FVWM Window. But this new FVWM window will have a different ID. It is highly unlikely to be “0x12345” again.
The WindowStyle command internally uses the window ID of the FVWM window to apply specific settings to that window. It does so because it’s unique – and how you can realise why you can’t use the window’s title, class or resource because it would otherwise match other windows.
However, what you can do is something like this:
AddToFunc StartFunction I Test (ToRestart) DoSomethingPriorToRestart
AddToFunc StartFunction I Test (Restart) ReapplyState
DestroyFunc DoSomethingPriorToRestart
AddToFunc DoSomethingPriorToRestart
+ I All (State n) ......
+ I All (State m) .....
DestroyFunc ReapplyState
AddToFunc ReapplyState
+ I All (State n) .....
+ I All (State m) ....
And note that State here must not be set via a windowstyle command. Hence, instead use the State command. I know it’s confusing having a command and a style option with the same name, but go look it up.
Oh, and rather than reinventing the wheel over this, go and look at a project called FvwmPiazza (github.com/rubykat/FvwmPiazza) – it needs a lot of cleaning up, but it looks as though it’s going to do what you’re about to reinvent.
I’ll take a look at Piazza, but I merely can read Perl and I do not quite understand what this code is intended to do.
Besides, reinventing things is practice to me, I would not understand a thing about fvwm by just following guides and feeling I don’t control things makes me nervous.
Need to think, read and try several things now. )
By the way, launching terminals with certain names and remembering things on windows based on their names might be just fine as I need tiling mostly for terminals.
What is the best way to dump certain window information to file?
I can do something like Pick Exec exec echo $[w.name] > somefile, but I definitely remember I’ve been told not to for some reason, yet I cannot find that thread.
No – that’s not what you want to do. You would have no transitory need to do this at all which you couldn’t do with PIpeRead. Seriously.
Go back to a previous conversation where I drew a diagram and explained why using a window ID is a bad thing to do for persistence.
I’ll ask you again because I am interested: what are you trying to do? – the above only tells me how you think you might solve this idea/problem you’ve got, without telling me what that is – and until I understand that, and can help to educate you on why your thinking is off-kilter, it’s going to really make things tedious for me.
All right, that’s how I assume the whole thing to work:
During session (no persistence meant!) I somehow trigger a function in a window context which takes window info and writes it somewhere. Than a script reads the file and makes decisions about how to place given windows and issues resize and move commands.
Besides, I would like to make some sort of wrapper, which would first look up if there are tiled windows, calculate geometry and ask fvwm to launch an application with it. That wrapper might read the file as well.
The idea is to keep normal floating behaviour but launch some applications in tiled manner. fvwm is not expected to guess which windows to tile, they are to be explicitly told to be treated as tiled.
There is a potential race-condition in writing/reading the file.
The use of a file is a silly thing to do given PipeRead.
You can just use FvwmEvent anyway for this.
Finding my patch to FvwmRearrange to make it ModuleSynchronous would help here.
I’ve always thrown the idea out as being awkward.
Also, on your example, you’ve already mentioned a phrase to me: “trigger a function in a window context”, which makes me wonder, given that why you then need to record the information anywhere, as it’s already available to you.
