Openbox WM - found no window to jump to

[klayman]

Just tried jumpapp under Fedora + OpenBox and I'm unable to switch to any running app. Get the "found running process, but found no window to jump to" error. Both launching a new window with jumpapp as well as simple "wmctrl -a appnamehere" work fine.

[backward-crazy-mage-puppy-36]

@klayman yeah, i faced this issue a while back too, if I remember correctly its because one cannot use the window titles that wmctrl -l gives you with jumpapp. For example: wmctrl -l
trl - l might give you "Google Chrome" as the window title. Jumpapping the entire term "Google Chrome" or its partials "jumpapp Google", "jumpapp Chrome", "jumpapp chrome" etc have a 50 50 chance of working (Google Chrome is a bad example, tested it with jumpapp, all combinations work, :) ). For getting jumpapp to work correctly with your apps you need their command name i.e. the command you type in terminal to launch them. If you do not know the command names for some of the apps, you can go into /usr/share/applications, here you will find icons/shortcuts for most of the applications, you can right click on the shortcuts / icons and click on properties where you can see the command name.
Sometimes the command name are different from app name ex. "Archive Manager" can be launched from the terminal using the command "file-roller". From my experience jumpapp plays nicely with command names and you wont face that problem again. Other user might be able to verify the same.

[klayman]

@KaranR Thanks for a prompt reply. Let's take the last example - file-roller. If I enter jumpapp file-roller for the first time, then the app is launching with no problem. But issuing the same command once again gives Error: found running process for 'file-roller', but found no window to jump to. The thing is - I'm using the command names and jumpapp can find the corresponding process already running, but fails to raise its window. Unfortunately, I'm not good at bash-scripting to nail the bug in the code.

[backward-crazy-mage-puppy-36]

just tried that on my end, jumpapp file-roller twice (second time with a file-roller open), jumpapp switched to file-roller. Are there any settings windows / software updater window / sound / themes windows open when you tried it?

[klayman]

I'm running Fedora minimal installation with Openbox window manager, so there are no any special sofware updater apps. I've tried to run jumpapp file-roller twice with no other windows open (except for terminal) with the same error. Please, tell if I can help with any command output.

[backward-crazy-mage-puppy-36]

Let me look it up. I am on a mint 17 and have used jumpapp (works perfectly) for some time now (almost since launch). Prior to mint i was on crunchbang (for about 6 months) which uses openbox windows manager by default. Let me see if i can throw together an temporary installation of crunchbang on a pendrive and test out your issue. No promises, but i should be able to figure out your issue. I am busy over the next couple of days so it might take a bit longer.

[backward-crazy-mage-puppy-36]

There is something that you can help me out with though, when i meant "software updater window / sound / themes" windows, i meant that on mint 17 cinnamon these actually are the same process / window name. Meaning if i have a window for sound settings open and a window for theme settings open, they both have the same name. When i run a wmctrl -l i see a single name twice. So the output from wmctrl -l after you have run jumpapp file-roller might help me.

[klayman]

Here is the wmctrl -l output:

0x00a0000a -1 N/A tint2
0x02a00003 0 hostname sakura
0x02c00007 0 hostname Archive Manager

If I launch another file-roller process manually, then there is additional line with the same Archive Manager name.

[mkropat]

@klayman Thanks for the bug report. I appreciate knowing when people run into problems so I can try and make jumpapp better.

Can you show me the output of:

• hostname -s
• wmctrl -lpx (note the additional arguments -p and -x)

Since it sounds like no windows from any app can be found, my first guess is that hostname -s is reporting a different name than wmctrl -lpx.

@KaranR Keep up the good work! I appreciate all the debugging work you've done.

[klayman]

Thanks for your help! The problem was that on my distribution the hostname listed in wmctrl -lpx output matches hostname -f (full, with extension) and not the hostname -s. Truncated the hostname extension and jumpapp works fine!

Perhaps, to work out of the box on any system it may be better to compare a hostname provided by wmctrl with both full and short system hostname.

[klayman]

Now there is a problem not related to Openbox. It's the Java - I'm using muCommander file manager written in Java. And the wmctrl -lpx output for its window is rather odd:
0x01a00044 0 10645 sun-awt-X11-XFramePeer.com-mucommander-Launcher hostname /home/semyon/

The error is the same - jumpapp can't find a window for mucommander command. May be it's better to create a new issue for this?

[mkropat]

It turns out jumpapp should just be calling hostname and not hostname -s to get the correct behavior on all systems, so that's now fixed. Let me know if it's not working for anyone.

As for the muCommander issue, would you mind opening a new issue? I'll take a look at it next time I get a chance.

[mkropat]

Since there's not an issue for the muCommander issue yet, and I happened to look into it, I'm posting what I found here:

Since Java seems to set WM_CLASS to the full Java class name, there's no good way for jumapp to match the command to the WM_CLASS name. As a workaround, I recommend using jumpapp's -c option, like so:

jumpapp -c com-mucommander-Launcher ./mucommander.sh

[klayman]

Sorry for late reply. Now both the hostname and muCommander issues are gone.

jumpapp -c com-mucommander-Launcher mucommander

works perfectly for me. Many thanks!

[klayman]

Just a small update: for muCommander 0.9.1 the command line should be:

jumpapp -c com-mucommander-muCommander mucommander