Kde: how to bind permanently an application to a desktop/activity

desktopdesktop-environmentkdekde-activitieswindow-manager

Im pretty new to Kde 4.8 and I can not figure out how to get this behaviour that I used to have in Gnome:

Desktop 1: developer/misc (browser, editor/ide, diff, etc..)
Desktop 2: virtual machines (vbox)
Desktop 3: graphic (gimp, inkscape, phatch)
Desktop 4: file management (ftp, ssh, etc..)

In gnome is possible to configure the windows to always appear in a specific desktop, and this is what I want to achieve in Kde.

I googled around so much, and looks like activities can't do that (yet), becose using the window's menu only works for the current session, and get lost after reboot.

By the way, I suppose that activities can do that, becose in the default activities that come with Kde 4.8 Gimp used to show only in the photo activity (I gave a look to the activity configuration but I didn't find anything about this behavior).

Onestly, my goal is to obtain this scenario, if it is not possible with activities but with desktops, for me is ok.

So, any idea on how to obtain this behavior in Kde 4.8?

I already read this similar question, but im looking for a permanent solution.

Best Answer

This (and much much more) can be done in advanced settings of KDE's window manager KWin. You can get to it if you right click on window titlebar and select Advanced > Special Application Settings (or Special Window Settings if you would like to apply only to specific window and not all windows of this app). Then on the Size and Position tab you can force it to open on specific virtual desktop or in specific activity (for activities you need KDE software compilation version 4.9, if I remember correctly).

Related Solutions

What are the user interface subsystems, their components and responsibilities

First of all, a Display Manager (or DM, e.g. xdm, gdm, kdm) is not the same as a Desktop Environment (or DE, e.g. GNOME, KDE, XFCE).

The Display Manager takes care of graphical login, and decides (or lets you choose) what session to run. Or what session*s* in case you choose the "switch user" menu option.

A Desktop Environment is basically a collection of programs (display manager, window manager, session manager, panels, configuration tools, etc.) and libraries (e.g. Gtk) that intend to give a consistent and integrated environment to work in.

A Window Manager manages windows: where to place them, move them, resize them, minimize/maximize them, tile them, etc.). It also handles the shortcuts to do those things. In some cases the window manager also paints the borders of windows, in other cases this task is off-handed to a "window decorator".

The "Run Application" dialog in GNOME is part of gnome-panel, but in another DE it could be another part of the environment.

Who is in charge of painting windows etc. depends; in case there is a "compositor" in use (often part of the window manager, e.g. in Compiz) then the compositor paints the windows on the screen, otherwise (as was usual in the past) it's the X-server doing that.

The Main Menu(s) are put on the screen by a part of gnome-panel, but the data used comes from a bunch of files in /usr/share/applications/ (possibly combined with an equivalent directory in your home for personal changes). Those files have a structure defined by FreeDesktop.org (a platform for different DEs to collaborate on common infrastructure), so that GNOME and KDE know about the same programs (but still can show them differently, and in some cases prioritize "native" programs over "foreign" ones).

And yes, different users can use a different session configuration (and can even define their own ones). In GDM, try the Session drop-down for the available choices.

Furthermore, it is possible to mix & match several components, but that will sometimes result in less cooperation and a loss of "smoothness" in how things work. One very well known example where things get exchanges is of course Compiz, which replaces Metacity if you want fancy desktop effects. But there are lots of other changes possible.

Bash – Expand KDE activities concept to the shell

Controlling KDE activities via dbus

KDE can be controlled from the command line with qdbus. The general syntax is qdbus COMPONENT PATH METHOD ARGUMENT1... where COMPONENT is typically something like org.freedesktop.Foo or org.kde.Bar, PATH denotes a class exposed by the component, METHOD is the name of a particular action in that class, and there may be further arguments depending on the method.

Here are commands for KDE ≥4.7 to list activities, to get the current activity, and to set the current activity.

qdbus org.kde.kactivitymanagerd /ActivityManager org.kde.ActivityManager.ListActivities
qdbus org.kde.kactivitymanagerd /ActivityManager org.kde.ActivityManager.CurrentActivity
qdbus org.kde.kactivitymanagerd /ActivityManager org.kde.ActivityManager.SetCurrentActivity "activity identifier "

Finding out what dbus can do

KDE's dbus documentation is very poor. Each class is minimally documented, e.g. Activity, DesktopCorona). But you'll probably have to experiment and perhaps read the source (there are links in the API documentation pages) to find out what is available.

If you type qdbus with up to two arguments, it will list the possibilities for the next argument. The following shell snippet lists all available Qt-dbus methods:

for x in $(qdbus | sed '/^:/d'); do
  for y in $(qdbus $x); do
    qdbus $x $y | sed "s~^~$x $y ~"
  done
done 2>/dev/null >qdbus.list

Another way to explore the dbus tree is qdbusviewer in the Qt development tools. There is also a Python qt-dbus interface as part of PyQt.

Getting the shell to react

To make a shell react to external events, the best you can reasonably do is make it check something before displaying a prompt. Bash runs $PROMPT_COMMAND before displaying a prompt, and zsh executes the precmd function. So you can look up the current KDE activity and do something if it's changed from the last time you looked.