Version: (using KDE KDE 3.3.92) Installed from: Unspecified DCOP interfaces should be standardized as much as possible for certain classes/groups of applications. This would allow for more dynamic scripting and better usability of DCOP in general. In order to do this I have some ideas: Every application that uses dcop should have a isTopLevel() dcop function that return true if it is the current top level application (i.e. the one the user has in focus.) Actually it would be easier if you could do a: dcop localServer getTopLevelApplication() (or some such thing) that would return for example: (web_browsers,konqueror-<pid>) The other ideas are best illustrated by an example, for instance media players are a class of application that share a set of functions that can be standardized across applications. Play, Pause, Stop, Previous, Next, Rewind, isPlaying, etc. By having classes corresponding to groups of applications (by type) it would be easier to establish a standard convention for dcop function names. You could have a DCOPMediaPlayer class that is a subclass of a dcop client (?) and specifies an interface (as virtual methods for example) for common functions like those I listed above. Then all KDE media players can sub class this class and implement the interface. DCOP should also be able to provide a list of all applications using this class and return (in the dcop command like too at least) the application name and ID. Then I can write a script that for example can pause all playing media players, or select the one that is playing and stop it, without having to hard code the dcop functions that each individual media player uses. This is useful for programs like KHotKeys or Lineak that control applications from scripts or keyboard buttons. Other application classes could be editors, mail clients, web browsers, calculators, etc. Building on this further we could have: dcop media_players isPlaying to return a dcop reference to the application(s) that is/are currently playing. dcop localServer getTopLevelApplication() could then return (media_players, amarok) etc. Thanks.
We already have application classes and common interfaces. KIMIface, for example, for instant messaging applications. Look in kdelibs/interfaces/kimproxy/interface for the interface specification and /library for a library that uses KTrader to get a list of all the applications implementing it and dcop to see if they are running. The other idea is interesting. To make it fit with the rest of the dcop syntax, and separate dcop from any knowledge of KDE ServiceTypes and all that (DCOP doesn't know anything about KDE, you see) you could provide a daemon that would take care of resolving a ServiceType to a list of running applications implementing it. This is what is currently done in kimproxy and probably in other places too. Then you would have dcop kded servicediscovery KIMIface -> (kopete,konversation-12345). I'm not sure about the usefulness of knowing the focused app in this context, but it's something KWin should provide
So those applicaiton classes and common interfaces are for DCOP? I'd like to see common application classes that define a dcop interface for a specific class of applications, so that all applications of one class have the same dcop interface for common functions. Those interface classes can be pure virtual classes that are inherited. Knowing the focused app would be of great help for any script or progam (like khotkeys or lineakd) to determine which browser window, for example, to send a reload page command to, out of many instances of konqueror that may be running.
kde applications could set a property with a DCOPRef on their windows and then kwin could tell you the dcop ref if you know the window.. sounds useful and not too hard.
*** This bug has been marked as a duplicate of 34882 ***