Since neither the actions for the buttons nor the layout can be changed in an FvwmButtons instance, you might consider some workaround:
1, create more FvwmButtons instances, one for every ‘page’
2, make one FvwmButtons instance, which - on every button press - pipereads the output of an executable file called with the proper arguments, like which button was pressed, and which ‘page’ is active. The page number can be stored in an environment variable. Piperead is not necessary though, but the fact you can call fvwm commands makes it more flexible.
For the icon changes, check the ‘sendtomodule’ command.
Well, the easiest, and posibly, faster and more efficient way, is to use
a function which basically would be something in the lines of this example:
+ I KillModule FvwmButtons FvwmButtonsOfficePanel
+ I DestroyModuleConfig FvwmButtonsGamesPanel
+ I *FvwmButtonsGamesPanel: <whatever>
+ I Module FvwmButtons FvwmButtonsGamesPanel -geometry ..... blah blah
Then you bind this function into a button in the office panel. Of course, you
would then need two separate functions for each panel to emulate the next/prev
You could as well pass the panel as a parameter to the function, and use
TestRc (Match) combined with Break to do this in a single function, I
I don’t think that any external stuff is needed just for this simple task.
Piperead should be used only when necesary for this kind of things, cause
shell’ing out functionality is always slow, and locks fvwm while the task
is performed, which is not good when talking about panels and any interface
Remember that you can prefix any line with + I and put it into a function,
so you can bind it to a given key or a button on FvwmButtons.
You could do. But given the number of buttons is finite, for any given state (or clicks of these supposed up/down buttons) is just to reload a preconfigured FvwmButtons alias. No need for scripting there, and would be much faster. YMMV.
Careful… that’s not to be taken as a sweeping statement. Tut. Using PipeRead is the rightway to go for all operations of this kind – in fact, it’s the only way you could do it. It might be a little slow, and it might block, but it’s only ever a problem if the timeout is very very great indeed, but remember you’re in a function to use your example – the grab is then lost whilst the PipeRead executes.
Each of these functions would be something in the lines of the example
function I posted above, but without the panel definition stuff (since
you are going to define the 3 panels outside the functions, like any
regular panel). Once a panel is defined, you can kill and respawn it
many times, as long as you don’t use DestroyModuleConfig to destroy its
So, what these functions would basically do, is to hold a KillModule
(for the current panel) and a Module statement, to load the next or
previous panel. Then you just need to bind the right function to the
“^” or “v” buttons.