+-+-+
|o|o| - "o" means a run-button for some office
+-+-+ application
|o|o|
+-+-+
|o| |
+-+-+
|^|v| - "^"/"v" are "up" and "down" buttons
+-+-+
For example you click the “V” (down) button and button page changes to game applications page like this:
+-+-+
|g|g| - "g" means a run-button for some game
+-+-+ application
|g|g|
+-+-+
| | |
+-+-+
|^|v| - "^"/"v" are "up" and "down" buttons
+-+-+
Thus FvwmButtons have few button pages, which can be changed bu clicking “V”/"^".
Which FvwmButtons options can halp me?
Here is a screenshot of my old desktop: linux.org.ru/profile/fifajan … 8uXngJ.jpg , you can see FvwmButtons on right-center part. This is how I want it to look (there are no “V”/"^" buttons yet).
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:
DestroyFunc games_panel
AddToFunc games_panel
+ 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
panel behavior.
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
suppose.
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
elements.
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.
I guess several copies of FvwmButtons (one copy - one button page) is the best way to realize what I want.
OK, we have FvwmOfficeButtons, FvwmGamesButtons and FvwmDevelopButtons for example.
What kind of action I should bind to “V”,"^" buttons to make current FvwmButtons copy hide (become invisible) and visualise (become visible) the next/previous FvwmButtons copy?
I think there is no need of any variables. Each FvwmButtons copy will “know” its next/previous neighbour thus “V”/"^" action will be static.
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
configuration.
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.
Using PipeRead is the right way 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.