Create Temporary Desktops For Applications

There are applications which are more or less a mess for a window manager. For example The GIMP opens quite a lot of windows and you want to have all of those windows visible. In general you don’t want to have any other window on the same desktop

The solution to that is to move GIMP on it’s own desktop. But how? We can use static window rules to get this working, but what if there are already windows on that desktop? The perfect solution to that would be to have a desktop which gets created when you open GIMP and gets removed again when GIMP closes.

This was so far not yet possible without manual interaction. But with todays additions to KWin scripting this became possible. Here I present a KWin script which does exactly that:

workspace.clientAdded.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // create a new workspace for the Gimp image window (kind of the main window)
    // switch to the new desktop and send the gimp window to it
    workspace.desktops = workspace.desktops+1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
  } else if (client.resourceClass == "gimp-2.6") {
    // send all other gimp windows to the current desktop
    client.desktop = workspace.currentDesktop;

workspace.clientRemoved.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // when closing the gimp window let's remove the last desktop
    workspace.desktops = workspace.desktops-1;

I should really start to publish the quite useful example scripts I write to test the scripting functionality on places like kde-apps 🙂 The API for 4.9 is documented on Techbase

19 Replies to “Create Temporary Desktops For Applications”

  1. What happens when GIMP is launched a second time? Does a new instance get a new virtual desktop or is it moved to same as the first one?

    1. The script I posted should move it to a new desktop, but the behavior is of course adjustable by extending the script

  2. All this KWin awesomess made me think that we may want to implement “Fuill screen interfaces” ala Lion, actually we have been doing that for years with the alt+f3 menu every app could be “Full screened” (as an example we have the netbook workspace).

  3. What is the user interface for these kind of scripts going to be? For the short/midterm, it makes sense to keep it just put-the-scripts-in-a-folder. For longer term, it would be cool if such a script could take an input argument, and be for instance activated from the window rules kcm.

    1. We have two user interfaces:

      • Desktop Scripting Console: Alt+F2 and wm console
      • A KCM to manage the scripts
      1. This is very cool! Is there GHNS integration in the KCM? (kde-files seems like a better place than kde-apps for the scripts, in my opinion.)

  4. Have you seen the fullscreen effect on OSX Lion? Your post makes me think of it a bit. IMHO the effect is brilliantly done. OSX does indeed create a new virtual desktop when you make an application fullscreen. It also shows up in launchpad.

    Oh an in practice, It works wonderfully; switching between other apps and the fullscreen app was never that easy. (a simple 4-finger swipe/drag on the trackpad). If KDE would have something like that, it would made be a copycat, yet follow some really good innovations.

  5. Hi Martin. A bit off topic but is it possible to memorise the activity an application starts on in the same way it remembers the desktop?

  6. This actually reminds me of the Amiga which had “custom screens” and “public screens” that could be opened by Apps (in 1985, or maybe in a further update, not sure). One could promote each app to a given workspace, with a given screen resolution etc.

  7. I like the idea, but if I’m not mistaken you will have problems doing this with more applications at the same time. Since it seems you cannot create and delete desktops via names the script would remove the wrong desktop in the following scenario:

    1) open gimp
    2) open another program also configured like gimp
    3) close gimp -> it will remove the desktop of the other program

    This will always be a hack until desktops may be referred to by name. But maybe this is already possible – I only took a quick glance at the docs at techbase you linked.

    On another note: is it also possible to include activities in scripting?


    1. Removing the last desktop is just fine and that would work even if another desktop has been created.

      Activity Support is still missing in the API.

      1. Thank you for your reply! Would you mind elaborating why the issue I described does not apply? (I don’t have the opportunity to test trunk at the moment)


        1. Which desktop you remove just does not matter. All windows are moved one desktop up. So everything is just fine.

  8. Ganz nett!

    I might have to go back to KDE full-time, just so I can use this. That is, of course, assuming the Intel driver team have stopped trying to kill Kwin.

Comments are closed.