...making Linux just a little more fun!
Ben Okopnik [ben at linuxgazette.net]
On Wed, Jun 20, 2007 at 01:20:31PM +0200, Peter Holm wrote:
> I have searched the net (google, newsgroups ...) to find an answer to > this question .- but without success. > > In KDE (for example) you can get individual desktops backgrounds for > each virtual desktop. > Well - i am used to a utility for M$-Windows called Xdesk that also > can set the the desktops to have individual icons / folders. > > I know that in the windows world they change a regkey that tells where > the desktop belongs for each switch so such a 'true virtual desktop' > > I have also in M$-Windows created bathc-files to use with less > intelligence window-managers, theese batch-files separately update the > regkey to get my own way to create 'true virtual desktops' > > Is there any program that i can get to have different desktops-folders > or is there any way to trick either kde / gnomw / idesk to have > different desktops?
I have very little experience with it myself, but based on what I do know, FVWM can probably accomodate you. You would, however, need to learn to write config files for it. I have no doubt that it has some kind of a "DetectDesktopSwitch" function, as well as either the capability of hiding the icons or allowing you to script such a function.
Here's an example of a very complicated (but still readable) FVWM config file:
http://www.cl.cam.ac.uk/~pz215/fvwm-scripts/config
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Thomas Adam [thomas at edulinux.homeunix.org]
On Sat, Jul 14, 2007 at 01:01:36AM -0400, Ben Okopnik wrote:
> Here's an example of a very complicated (but still readable) FVWM config > file: > > `` > http://www.cl.cam.ac.uk/~pz215/fvwm-scripts/config > ''
Readable, yes. Portable? Alas not. Plus the author does some questionable things with function. But this is not a witch hunt. See also:
-- Thomas Adam "He wants you back, he screams into the night air, like a fireman going through a window that has no fire." -- Mike Myers, "This Poem Sucks".
Thomas Adam [thomas at edulinux.homeunix.org]
On Sat, Jul 14, 2007 at 01:01:36AM -0400, Ben Okopnik wrote:
> I have very little experience with it myself, but based on what I do > know, FVWM can probably accomodate you. You would, however, need to > learn to write config files for it. I have no doubt that it has some > kind of a "DetectDesktopSwitch" function, as well as either the > capability of hiding the icons or allowing you to script such a > function.
OK, OK. I'll bite. 
FVWM is a window manager. It has no concept of
anything other than managing windows. Things that fall on the periphery,
such as icons to launch programs, file managers, etc., fall outside of its
remit.
The fundamental problem is that programs such as idesk or rox-filer, etc., need some level of munging to work with the window manager. Because the icons supplied by such programs aren't individual (i.e., they're not part of the icon you can assign individual programs to have) you can't manage any one icon, only all of them en masse.
In the case of rox-filer though you can toggle the pinboard by simply doing:
rox -p= rox -p some_nameThere's any number of ways you can do that from within FVWM. You might have a shortcut for it via a key-binding:
Key I A CM ToggleRoxIconsWhich just tells FVWM that when the combination ALT-CTRL-I is pressed that it is to run 'ToggleRoxIcons'. What this is can only be one of three things as FVWM is concerned (and in this order):
Internal command Function ModuleIt's not an internal command, nor is it a module. It would be a function which looked like this:
DestroyFunc ToggleRoxIcons AddToFunc ToggleRoxIcons + I PipeRead `[ -n "$(pidof rox)" ] && echo "Exec exec rox -p=" \ || echo "Exec exec rox -p someProfile"`What's happening here is that PipeRead spawns a shell, and information is sent back to FVWM in a synchronous manner. Thus what we're doing here is checking to see if rox is running, and if it is, to clear the pinboard, else if not, start it up and use the specified pinboard profile, which would then load up the various sets of icons.
You could do something similar with idesk, but that program is just confusing, IMO.
There is a more... FVWM-centric approach you could use, involving FvwmButtons, the details of which are here:
http://fvwm.org/documentation/faq/#7.13
-- Thomas Adam "He wants you back, he screams into the night air, like a fireman going through a window that has no fire." -- Mike Myers, "This Poem Sucks".
Ben Okopnik [ben at linuxgazette.net]
On Sat, Jul 14, 2007 at 10:43:24PM +0100, Thomas Adam wrote:
> On Sat, Jul 14, 2007 at 01:01:36AM -0400, Ben Okopnik wrote: > > I have very little experience with it myself, but based on what I do > > know, FVWM can probably accomodate you. You would, however, need to > > learn to write config files for it. I have no doubt that it has some > > kind of a "DetectDesktopSwitch" function, as well as either the > > capability of hiding the icons or allowing you to script such a > > function. > > OK, OK. I'll bite.
Not too hard, please - I want to keep all the bits I've got.
I was hoping you'd step up, since you're as close as we can get to an
in-house FVWM expert. For all I know, other WMs can do the same thing as
well, but since you've spent so much time writing up the features of
FVWM, that's what comes up in my mind when somebody mentions an
easily-programmable WM. So it's all your fault no matter how you look at
it.
> FVWM is a window manager. It has no concept of > anything other than managing windows. Things that fall on the periphery, > such as icons to launch programs, file managers, etc., fall outside of its > remit.
Hmm, I had lost track of the fact that icons weren't part of the WM. Oh well.
(I wonder if the OP would be satisfied with launching all the apps that he wants open and having them minimized on a given desktop? That sounds like all-WM territory.)
> The fundamental problem is that programs such as idesk or rox-filer, etc., > need some level of munging to work with the window manager. Because the > icons supplied by such programs aren't individual (i.e., they're not part of > the icon you can assign individual programs to have) you can't manage any > one icon, only all of them en masse.
Actually, having played with "idesk" quite a bit, I can suggest an approach in that direction:
1) Make up multiple versions of the "~/.idesk" subdirectory - say, "~/.idesk1", "~/.idesk2", etc.
2) As you switch desktops, have the WM fire off a script that does an "ln -sf ~/.idesk$DESKTOP_NUM ~/.idesk".
3) restart "idesk".
This would be a little wasteful of resources as well as a bit slow - although "idesk" restarts rather quickly - but it would do what's requested.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
Thomas Adam [thomas at edulinux.homeunix.org]
On Sun, Jul 15, 2007 at 02:38:46PM -0400, Ben Okopnik wrote:
> I was hoping you'd step up, since you're as close as we can get to an > in-house FVWM expert. For all I know, other WMs can do the same thing as > well, but since you've spent so much time writing up the features of > FVWM, that's what comes up in my mind when somebody mentions an > easily-programmable WM. So it's all your fault no matter how you look at > it.
Heh. I spend more time with it than I ought to.
> (I wonder if the OP would be satisfied with launching all the apps that > he wants open and having them minimized on a given desktop? That sounds > like all-WM territory.)
Yes, it is. It's a two-stage process with FVWM. First of all you'd have to set some style lines for those applications:
Style programA StartsOnPage 0 1, StartIconic, SkipMapping Style programB StartsOnDesk 1, StartIconic, SkipMappingNote that I've used StartsOnPage for programA, and StartsOnDesk for programB. SkipMapping tells the window manager not to switch to the page the program appears on when it is mapped (displayed, if you will) to the screen. This is useful if you want to continue doing stuff without being disturbed.
There is a difference between a desk and a page. A Desk contains N number of pages (at least one -- there's no choice in that). A Page is simply one "window" within that desk. The numbers of those desks are dependant on the layout of the DesktopSize. So for instance, I have this in my ~/.fvwm/config file:
DesktopSize 3x3That means that for each desk I define, I have nine pages, and they'd look like this:
+------+------+------+ | | | | | 0 0 | 1 0 | 2 0 | | B | | | +------+------+------+ | | | | | 0 1 | 1 1 | 2 1 | | A | | | +------+------+------+ | | | | | 0 2 | 1 2 | 2 2 | | | | | +------+------+------+I've put the numbers in for reference. In the case of programA above starting in page 0 1, it would place it in square 'A'.
programB is a bit different though in that it's being told to start in a specific desk. Desk 1, in fact. Naming desks is a way of defining them, starting at 0 (which FVWM will take as being the default desk anyway), hence:
DesktopName 0 Main DesktopName 1 Games DesktopName 2 WorkBecause all we've said is for programB to startup on desk 2, it will default to placing that window on page 0 0. What gets even more interesting though is that the StartsOnPage command can accept three arguments as well as one. So you could use this to specify not only the desk programB is to start up onm but the page also (the first number is the desk):
Style programB StartsOnPage 1 2 2I said this was a two-stage process. You now have to tell FVWM to launch your programs. You do this from the StartFunction:
DestroyFunc StartFunction AddToFunc StartFunction + I Exec exec programA + I Exec exec programBAs an example. StartFunction is special in FVWM in that it is always read across startups (what we call 'Init), and restarts of FVWM. This would mean that across restarts of FVWM both programA and programB would get started again. Limiting this to just init is done like this:
DestroyFunc StartFunction AddToFunc StartFunction + I Test (Init) Exec exec programA + I Test (Init) Exec exec programB
> Actually, having played with "idesk" quite a bit, I can suggest an > approach in that direction: > > 1) Make up multiple versions of the "~/.idesk" subdirectory - say, > "~/.idesk1", "~/.idesk2", etc. > > 2) As you switch desktops, have the WM fire off a script that does an > "ln -sf ~/.idesk$DESKTOP_NUM ~/.idesk".
This is why I rambled on about desks and pages earlier -- the act of switch from page to page, or desk to desk, are two separate operations. Confining this to either having just one desk with nine pages (as per my example) is easier, eince you can then do this:
DestroyModuleConfig FE-idesk *FE-idesk: Cmd Function *FE-idesk: new_page RestartIdeskWhich just sets up an FvwmEvent alias and tells it that each time we switch a page, we're going to be calling some function called RestartIdesk. Here's what that would look like:AddToFunc StartFunction I Module FvwmEvent FE-idesk
DestroyFunc RestartIdesk AddToFunc RestartIdesk + I PipeRead `case "$[page.nx] $[page.ny]" in \ "0 0") ln -sf "~/.idesk$[page.nx]$[page.ny]" ~/.idesk && \ doWhateverYouDoToRestartIDesk ;; \ "0 1") ln -sf "~/.idesk$[page.nx]$[page.ny]" ~/.idesk && \ doWhateverYouDoToRestartIDesk ;; \ esac`But then you don't need to check which page you're on. So we can simplify this more:
DestroyFunc RestartIdesk AddToFunc RestartIdesk + I PipeRead `[ -d "$HOME/.idesk$[page.nx]$[page.ny]" ] || echo "Break"` + I PipeRead `ln -sf "$HOME/.idesk$[page.nx]$[page.ny]" $HOME/.idesk && \ doWhateverYouDoToRestartIDesk`We instead break (end running this function) if the directory we're trying to link to for the page we're on doesn't exist. I have no idea what you need to do to restart idesk, so I will leave "doWhateverYouDoToRestartIDesk" to someone who knows.
-- Thomas Adam "He wants you back, he screams into the night air, like a fireman going through a window that has no fire." -- Mike Myers, "This Poem Sucks".