Forcing new windows to start on a particular desk

One of my favourite features of FVWM is the virtual desktops. However, one thing annoys me much with the virtual desktops: when I start an application from an xterm (rxvt) and then switch to another desktop, the application will end up on the desktop I switched to instead of the one I started it on. For special cases, e.g., the web browser, I tie it to a specific desktop with FVWM styles, but this doesn’t work with things (e.g., rxvt terminals) which I want to start on different desktops.

I know that this is a tricky problem to solve, since it is very hard to actually know from where an application was initially started. The FVWM wiki has a sort-of-solution to this (the site is down so I cannot link it), but that solution requires you to manually specify the name of the application you start, i.e.,

start-on-desk 1 xterm* xterm ...

what I instead would like is to have the application by default start on the desktop it was started on. I have also devised a way of doing this, although it is buggy and not very optimal.

The solution I had in mind is to use Xnest to start a nested X session for each desktop, and then run all windows inside the nested desktops. For example, if I have two desktops, these would be (perhaps) DISPLAY :1 and :2, and an application started on the first desk would automatically end up there - unless DISPLAY is set to :2. Each desk Xnest would run a FVWM “slave” which controls windows on that desktop, and one “master” FVWM would manage the Xnests themselves. The master session has keyboard shortcuts to switch between desks, but otherwise just forwards everything to the slaves managing the Xnest’s. Starting something on another desk is simple: just set DISPLAY before starting it. xmove can be used to move already started windows between desks.

Problems: Xnest is buggy and seems to have problems with the keyboard modifier state, see

blogs.gnome.org/view/markmc/2005/06/22/1

. I’ve tried a quick hack of this idea, and the modifier state is a real problem. The above link contains a fix to Xnest, but I’m really too lazy to rebuild X before I ask you about opinions. Does anyone else have better ideas on how to achieve this? Perhaps even xmove could be used by itself, starting windows on the virtual server xmove provides and then intelligently moving them back to the “normal” server. Ideas?

// Simon

[color=red]Edited by theBlackDragon:
–> Moved from General Fvwm discussion[/color]

Supplying a style line, giving the terminal a unique name or class, is about it. Of course, if the terminal, say, Xterm, support standard X tookit commands, then you can do this at invocation:

 xterm -xrm *Desk 1

There is nothing wrong with that solution, and it is about as good as you’re going to get, currently. What is it you have reservations over?

Using PipeRead and FvwmEvent (assuming you don’t use “SkipMapping”, as a style option) can achieve this.

The other, more saner solution is to just switch to the desktop you want to start the application from, whilst the window is being mapped. :slight_smile:

Overkill.

– Thomas Adam

(Let’s see If I can get the quoting right!)

Well, that would be at least a partial solution to one of the more common situations, I didn’t think of that. Thanks!

The problem is that you have to manually give the StartOnDesk command, and then a matching resource, which I think is a bit much and also just works for programs you start from the terminal. Preferrably, I would have it working for any program, in all situations.

Care to explain this?

:slight_smile: I know, but sometimes the windows take a while to show up, and then you’ll have to stay around waiting for your window. Actually, a real-life situation which I’m bothered by this is when I open windows from a script, which only show up every (say) 20 minutes or so - these would be really nice to have on the desk the script was started on. I use Xnest to handle this, which is how I came up with the overkill solution.

// Simon

Then you’re out of luck – you can’t do it. “StartsOn{Page,Desk}” as a style option relies on the fact that the placement happens once the window has been mapped. This is why, without the “SkipMapping” option the viewport is changed to the window’s started location. Since an unmapped window (that is to say a program that is loading) knows nothing about its default location until after it is mapped, then the only way you’re going to get this to work is to use the Style options.

As for your “terminal” scenario, I don’t follow – even if you start an application from the terminal and change desks before it loads – assuming you have no style options to affect the window placement, it will load on the current page/desk you’re currently viewing.

Sure, it’s on the fvwmwiki – once it’s up and running again, and you’ve already seen it. :slight_smile:

See above.

Hmm, I have a few ideas about this – although don’t hold your breath. I will look into them and get back to you.

– Thomas Adam

And what I found is what I had assumed – it’s semi-sort-of-possible, but really does depend. Where it is possible is if the application in question uses EWMH to place windows. If it does, you can use:

Style * !EWMHIgnoreStateHints

Which may or may not help. And unless the application provides the -xrm resource for “Desk”, then you’re screwed. Use Styles like everyone else. :slight_smile:

– Thomas Adam

Hello there,

I’d like to know if on a similiar note, it’s possible to do the app startup positioning but when using 4 pages per desktop, the viewport feature I think - I hope I’m saying it properly…

I have 1 desktop but with 4 viewports, each the size of my monitor screen, minimize/maximize works for the viewport where the app is at, I can slide apps from viewport to viewport and cicle them all using the mouse and the screen edges, desktop resolution is set to 1024x768 and that’s what I get on each viewport. The wallpaper also “replicates” on each viewport.

The idea would be to define - if possible :
1- which viewport the app is supposed to be upon start-up
2- define coordinates for its positioning inside that viewport
3- using 1, the app getting minimized right away.

Could this be done? Do some of the instructions above solve it already?

Thanks! :slight_smile:

Style foo StartsOnPage <num>

You can sometimes (with a lot of apps) pass a -geometry option to them to specify their position. You can obtain this, by manually placing the window where you want it, and use FvwmIdent to show you the geometry.

See also: Faq #3.18

Style foo StartsIconic

– Thomas Adam

Thank you very much for the reply and explanations, will try it out ASAP! :slight_smile:

(Late reply, I know).

Just wanted to tell you that I solved this problem at least partially with FvwmCommand in a script (kind of as outlined before). Programs which I want to start on a particular desk, I start with the script “here” from an xterm, e.g.,

$ here xxdiff ~/src_old ~/src

Since not all programs have the same window name as the command that started them, my script also refers to a .here.d directory for special cases. Since it’s quite short, I’ll post the script here

#!/bin/sh

usage()
{
    echo "Usage: here COMMAND [args]"
    echo
    echo "Start COMMAND on the current desk"
    exit 1
}

if [ $# -lt 1 ]; then
    usage
fi

if [ -f ~/.here.d/$1 ]; then
    STYLE_NAME=`cat ~/.here.d/$1`
else
    STYLE_NAME=$1
fi

FvwmCommand "Style $STYLE_NAME StartsOnDesk \$[desk.n],SkipMapping"
$*
FvwmCommand "Style $STYLE_NAME"

My only problem is that I’m not sure how to reset the old “StartsOnDesk” style for the command (which most likely isn’t set) - the last FvwmCommand really doesn’t do very much. Oh well, this code works for me and fixes one of my small itches with fvwm.

Thanks for the comments and ideas!
// Simon

That’d be the “DestroyWindowStyle” command, then. Which you can only use via WindowStyle for specific apps — something you ought to use and change in your original scripts, to be honest.

– Thomas Adam