kde-open, raise window and switch to desktop
1i5t5.duncan at cox.net
Fri Apr 1 16:45:08 BST 2011
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
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
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.
More info: http://www.kde.org/faq.html.
More information about the kde