kde-open, raise window and switch to desktop

[Duncan]

Daniel Barna posted on Fri, 01 Apr 2011 16:14:42 +0200 as excerpted:

> Thanks for the answer. Yes, I want exactly that. I also found wmctrl in
> the meantime, but the problem is that if from my script I open the
> document by kde-open, I don't actually know which app will open it (if
> it's a html document, it will be opened in the default browser, which
> may be firefox, rekonq, chrome, etc), therefore I can't use wmctrl.

That /is/ a problem.

Taking a look at packages and dependencies, here on Gentoo at least, kde-
open is part of the kioclient package, which includes kioclient, kde-mv, 
kde-cp, as well.  I checked kioclient but that looked to be a deadend 
(basically a one-command version of all the above).  But kde-open must get 
its mime info from somewhere...

Checking kioclient deps, looks like it depends (unsurprisingly) on 
kdelibs.  kdelibs in turn depends on, among other things, xdg-utils.

NOW we're getting somewhere!  Take a look at the xdg-utils package, which 
seems to be authored in part by kde's own Kevin Krammer, as it happens, 
active on the kde lists.  So maybe he'll step in with some suggestions.

Meanwhile, however, three of the scripts included in xdg-utils are xdg-
mime, xdg-open, and xdg-settings.  xdg-open seems to be the xdg version of 
kde-open, but xdg-mime can query the mimetype of a passed file, with the 
mimetype fed back into another query to get the default app used to open 
it (a *.desktop file is returned, you'd parse it).

And xdg-settings get default-web-browser can be used to get that.  May or 
may not be useful.

IOW, while it'll definitely increase the complexity of your script, you 
should be able to get the app used to open a particular URL or file, then 
use psgrep or whatever to see if that app's already open.  Of course that 
still makes unavoidable assumptions about whether the new entry is opened 
in a tab in an existing window or in a new window, etc.  You can get past 
that as well, but we're quickly getting into application-specific 
handling, and the complexity of your generic script is looking to increase 
geometrically!

That's probably why such scripts tend to be either DE/app specific or user/
installation one-offs, where certain assumptions about the default apps 
can be made and hard-coded into script logic, thus reducing complexity to 
a manageable level once again, rather than generic catch-all solutions.  
When the assumptions change, the hard-coded scripts can then change as 
well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.