Support for webapps

[joelostblom]

Hi, I wonder if jumpapp can support webapps, such as Gmail and Google Keep. I use these apps by downloading them from the chromium extensions store online. They are added to the systems program menu and their entry is in the form of usr/bin/chromium-browser --profile-directory=Default --app-id=hmjkjmmepjpkmjkepdijdfohbdki.

Currently, jumpapp will switch to any chromium window when I map this shortcut to a keybinding. I would like it to switch only to the specific window that has the webapp so that the app can work like any other standalone program. I tried with the -p flag and the desktop entry method, but I could not get it to work.

Cheers

[mkropat]

It's a good idea. Take a look at PR #8 for one way to do it. The person who submitted the PR had luck switching between Chromium apps by filtering on the window title. Does that method work for your needs too?

[joelostblom]

Thanks for the quick reply. The tips in that pull request are great, filtering by window title works almost flawlessly! The only problem is that if I launch e.g. Gmail with jumpapp, it will not launch the exact same instance of chromium that is in the app sitting in my dock. So if I then click the dock app to minimize Gmail, it will instead launch a new window. However, it does work the other way around, if I launch Gmail from the dock, using jumpapp will then switch to that window instead of launching a new window.

And thank you so much for making jumpapp! If it didn't exist, I would probably still be stuck on Ubuntu because Unity is the only dock with keyboard shortcuts. Now I can try out Arch without changing my workflow, wohooo! =)

[joelostblom]

To add to the above: When webapps are starting with the jumpapp -t shortcut, they are grouped under the browser window rather than getting their own icon in the Alt+Tab application switcher (naturally, since they launch a browser window rather than the webapp).

[mkropat]

So it sounds like if you could get jumpapp to emulate however the dock app opens Gmail, it should all work. It's probably very doable.

I don't use Chromium apps personally, so I probably won't look into this in the near future, but pull requests are more than welcome. A pull request updating the README explaining how to use jumpapp with Chromium apps (using -t or something like that) would be more than welcome too.

Feel free to leave the issue open as I imagine other people are interested in this functionality as well.

[Lupccs]

I would be in need of such an enhancement too, for the same reason. At the moment I'm using

wmctrl -xa crx_pjkljhegncpnkpknbcohdijeoejaedia || chromium-browser --profile-directory=Default --app-id=pjkljhegncpnkpknbcohdijeoejaedia

Which works fine.If the app isn't running, jumpapp -c won't load it but will just focus on an another chromium app window If the app is running, jumpapp -c won't load it but will just focus on an another chromium app window if there's a non-app chromium window runnning:

Error: found running process for 'chromium-browser', but found no window to jump to

From xprop on the app window

WM_CLASS(STRING) = "crx_pjkljhegncpnkpknbcohdijeoejaedia", "Chromium-browser"

[aaronjensen]

I ran into this as well, the problem would be solved by allowing -c to match on the full class name including instance name that comes back from wmctrl. If no . is in the -c argument, it can match on only the class (the second half of the instance.class string).

In other words, jumpapp -c crx_pjkljhegncpnkpknbcohdijeoejaedia.Chromium-browser chromium-browser --profile-directory=Default --app-id=pjkljhegncpnkpknbcohdijeoejaedia should work if this was implemented.

Would you be open to a PR for this?

[mkropat]

the problem would be solved by allowing -c to match on the full class name including instance name that comes back from wmctrl

Nice, thank you for figuring this out.

How likely do you think such a behavior change could trip up someone using jumpapp -c today? I think it's OK to slightly mess up a few users in exchange for the benefits pointed out on this thread. Especially because we could probably introduce a new option if it turns out such a behvaior change messes anyone's workflow up.

Would you be open to a PR for this?

I'm kind of an absentee maintainer, but chances are I will eventually check-in after a PR is submitted, and I can't think of any reason why I wouldn't merge it, should someone want to put the PR together.