Switch to application if it's already running

[uu-myheart]

When i've opened terminal in ubuntu and i couldn't switch to that terminal again , it just reopen a new terminal.

Any plans to add this feature?

[gornostal]

Hi, I'm not sure what you mean. Could you describe step by step what you do please?

[uu-myheart]

Sorry,
When I opend a window such as chrome, and I switch to another window, then I open launcher and type chrome and press ENTER, can ulauncer switch to chrome and not to open a new chrome window?

[gornostal]

Ah, I see.
I'm not planing to implement this feature, as the main idea of Ulauncher is to launch new instances of applications.
Maybe someone will write an extension though.

For the use case that you described I use Alt+Tab.

---

As I was writing this I thought it may be a useful feature if you could configure Ulauncher to show a list of running apps by default, so you will switch between them.

I'll leave this ticket open. Maybe I'll implement this in some future versions :)

[uu-myheart]

Thank you

[TheMartes]

@gornostal I will really appreaciate this feature in upcoming update. :) Because if i'm working on multiple workspaces, it will be easer to open ulauncher and type name of app, than find correct worksprace where i left this app, and than Alt+Tab

[gornostal]

@TheMartes that's a good use case. Thanks.

[aero31aero]

A suggestion: Use Alt + Enter for trying to switch instead of launching new instance?

[andrej-zirko]

This feature is actually the only reason I keep using Kupfer. It's my most frequently used feature. Kupfer is the only launcher for Linux I know that does it right. You can change default action per app, whether to create new instance or switch to existing one. I keep lot of windows open and Kupfer is so much more convenient, than alt + tab. Nevertheless I keep an eye on modern launchers, which would reimplement this feature. I think Kupfer is a nice inspiration, how it can be done right.

[yh2664]

This will be an awesome feature to have!

[ArturMroz]

I wrote an extension for that, you can get it here: https://github.com/ArturMroz/switcher. It's an alpha version so feedback appreciated.

It's not optimal as I had to make it work with API limitations (objects being serializable by pickle.dumps()).ExtensionResultItem doesn't seem to accept Pixbuf object as icon argument, so as an ugly workaround I'm saving icon for each active application to /tmp and reading from there. However, class ExtensionResultItem contains this:

def get_icon(self):
    if isinstance(self._icon, basestring):
       icon_path = self._icon

       if not icon_path.startswith('/'):
           icon_path = os.path.join(self.extension_path, icon_path)

       return load_image(icon_path, self.ICON_SIZE)
    else:
        # assuming it's GtkPixbuf
        return self._icon

so I would assume passing a Pixbuf object shouldn't be a problem. Is this a bug in API or just a limitation? The error I'm getting:

   Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.7/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.7/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.7/pickle.py", line 425, in save_reduce
    save(state)
  File "/usr/lib/python2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.7/pickle.py", line 655, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.7/pickle.py", line 669, in _batch_setitems
    save(v)
  File "/usr/lib/python2.7/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.7/pickle.py", line 425, in save_reduce
    save(state)
  File "/usr/lib/python2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.7/pickle.py", line 655, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.7/pickle.py", line 669, in _batch_setitems
    save(v)
  File "/usr/lib/python2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.7/pickle.py", line 606, in save_list
    self._batch_appends(iter(obj))
  File "/usr/lib/python2.7/pickle.py", line 621, in _batch_appends
    save(x)
  File "/usr/lib/python2.7/pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "/usr/lib/python2.7/pickle.py", line 425, in save_reduce
    save(state)
  File "/usr/lib/python2.7/pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "/usr/lib/python2.7/pickle.py", line 655, in save_dict
    self._batch_setitems(obj.iteritems())
  File "/usr/lib/python2.7/pickle.py", line 669, in _batch_setitems
    save(v)
  File "/usr/lib/python2.7/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/lib/python2.7/copy_reg.py", line 71, in _reduce_ex
    state = base(self)
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)

[gornostal]

Hi @ArturMroz
Great work with the extension 👍

Regarding this

else:
    # assuming it's GtkPixbuf
    return self._icon

I guess I have put it without testing. Turns out it's not going to work because GdkPixbuf cannot be "pickled". This error is a proof of that.

TypeError: GObject.__init__() takes exactly 0 arguments (1 given)

After a bit of googling I found that there is a workaround for that, but I see more issues than benefits with adding that workaround to Ulauncher. So your approach with saving image to a file is the best one now.

BTW, I noticed that switcher brings a selected window to the front, but doesn't focus on it.
One way to fix that is to use tool like wmctrl in order to focus on a window. Maybe there is a more elegant solution though.

[ArturMroz]

Thanks for pointing out focus problems @gornostal

Problem was, windows.activate() needs to receive server timestamp as argument but I was passing a local one from time.time(). You would think that Wnck would expose a method to get server timestamp but it doesn't. I'm using Gdk.CURRENT_TIME (which is 0 and means 'now' in other gtk libraries). Wnck gives a warning: Wnck-WARNING **: Received a timestamp of 0; window activation may not function properly. but otherwise everything seems to work perfectly. I'll stick to this solution for now.

[friday]

Somewhat related: If I already have gnome-system-monitor open, using Ulauncher to "open it again" won't bring it to focus. This app only supports a single instance and no tabs, but there are other apps like this which still gain focus with ulauncher. For example gnome-settings.

[goodwillcoding]

@friday I'd suggest you file a bug with gnome people about since same problem exists when one runs gnome-system-monitor from the terminal ... that application is not designed to bring up the existing instance when new instance is launched.

Since there is no way for Ulauncher to know which application only supposed to have one instance and which is supposed to have multiple there is no way to actually fix this. One possible solution is to have selected application with a shortcut cut like Ctrl+Enter but whether that feature makes sense for Ulauncher is a different question since it will need to be written and supported

[TheMartes]

Any updates on this?

[friday]

@TheMartes I don't think this will be implemented. You can use jumpapp and similar wrappers however.

Copy the desktop entry (ex: /usr/share/applications/spotify.desktop) to ~/.local/share/applications/ and modify the Exec line so that it starts with jumpapp (ex Exec=jumpapp spotify).

[georgejecook]

total bummer - it's a lovely launcher; but this feature is essential for me. I'll try the extension above, hoping that will be good enough to keep using it. good work all the same. I'll check back if you ever resolve this.

[mamsoudi]

I know that you've already said this isn't going to be implemented, but it's a real bummer. I love the design and the features; not to mention the fantastic list of extensions. But this feature is essential to me. It's so annoying that as a former macOS user, I still think that it will switch to the existing instance of the app.
Even apps like Spotify start in new windows which is really annoying.

[friday]

@mamsoudi You did see my last comment right?

[gornostal]

(deleted my comment)

I found the answers I was looking for in previous comments here.

[gornostal]

I can implement a new event for extensions that will be triggered before app is selected by a users.
Extensions will be able to catch the event and switch to a running app.

This way there will be minimum changes in the Ulauncher code base. Win-win.

[thebigredgeek]

@gornostal any updates on this? happy to provide a bug bounty :)

[gornostal]

@thebigredgeek no updates.
I didn't get to this task yet.

[kevgilmore]

It would be nice to have this as a default option, i.e. without a keyword like 's'.
As to navigate to an open application using the launcher. I often do this with the build in search on Ubuntu by hitting super > then type app name > hit enter.

[aaronjensen]

Just tried to switch from Albert to ulauncher and ran into this right away. This has been the default behavior of every launcher I've ever used on macOS and the default behavior of Gnome's activity search and Albert.

[KuenzelIT]

I can implement a new event for extensions that will be triggered before app is selected by a users.
Extensions will be able to catch the event and switch to a running app.

This way there will be minimum changes in the Ulauncher code base. Win-win.

Does this mean it would be possible for extensions to work without a keyword? This would be really nice.

[gornostal]

Sorry for the late response.
You have convincing arguments @mattwithoos!
If it's still actual for you and you want to implement that, I'll be happy to review your PR.

I also agree that this feature may be challenging. If you don't find a straightforward solution, you can try using wmctrl as a workaround. I think we can add this tool to optional dependencies if people want to enable the feature.

You may also want to use this PR as an example of how to add an extra setting to the Preferences window.

[mattwithoos]

Thanks @gornostal ! Excited to give this a try. I switched to combi and it's great but I'd love to switch back (pun intended) to uLauncher if possible.

Your tips/hints/pointers are also really thoughtful and appreciated.

[WhosyVox]

If such a feature is implemented then I would request it be an optional setting; I doubt I'm alone in fully utilising the existing behaviour of 'Always open a new instance'.
Perhaps I am an outlier but answering the previous question:

Let's be honest here as well - how often do you truly want a second Terminal compared to the number of times you just need to switch back to it?
My answer would be "Pretty much every single time."

[jeff-hykin]

This missing behavior is the only reason I'm not using ULauncher. 75% of all my seach actions are switching back to an existing app so I don't have to alt-tab 12 times. Until this is added I'm going to have to stick with the default Gnome search. Enter = switch, Ctrl + Enter = new window.

[1st1]

For all those who want this, I have a patch that works for me: 1st1@436fb9a

@gornostal The patch is obviously a hack, but this is the only way I could find that allows to fetch the list of all currently running apps in Gnome. Perhaps this can be contributed (after a cleanup, obviously) and hidden behind a preferences checkbox?

[timkgh]

+1 for this feature. Not only this is how the stock Ubuntu launcher and Dock work but in fact trying to start another instance of an app breaks some apps. Spotify is one example.
Could we please get a Preference on how it should behave?

[friday]

+1 for this feature. Not only this is how the stock Ubuntu launcher and Dock work but in fact trying to start another instance of an app breaks some apps. Spotify is one example. Could we please get a Preference on how it should behave?

Personally I think this should be the default and only behavior. I actually have a working solution stashed away somewhere, but the problem is it is introducing a dependency that was only an optional dependency before (hence the 6.0.0 milestone), and it's using the app names to find the launched apps in a way I don't feel is fully safe, but I think it's what everyone else does too.

As I see it it's better to consistently switch to the app if it's open, and if people want to open a new window instead, they can do that with Ctrl+N. It doesn't interrupt their flow, it just adds a step. And if they really don't want that, we can add it as an alternative action (#326)

However this is something that I think needs a discussion first, and it's very low on the list anyway. It is easy to work around the spotify issue as you can see from my earlier comment.

[thiagoa]

Personally, I feel like the cleanest implementation would be:

• Have "Open existing app" as the default behavior
• If holding down Alt while selecting the item, launch a new instance (if possible)

Maybe a dedicated preference for that would be a bit overkill?

[thiagoa]

By the way, I think Pop Shell implements item number 1 ("Open existing app" as the default behavior) but I'm not sure how they do it yet.

[timkgh]

I like the default of switching to the app also, macOS style.

[friday]

By the way, I think Pop Shell implements item number 1 ("Open existing app" as the default behavior) but I'm not sure how they do it yet.

Gnome Shell extensions have access to APIs and can make assumptions that regular apps can't. They only have to support Gnome, so it's easier.

https://github.com/pop-os/shell/blob/acd0001716bce4ffcabd2eb572cdad98028d124b/src/launcher.ts#L242
https://github.com/pop-os/shell/blob/acd0001716bce4ffcabd2eb572cdad98028d124b/src/launcher.ts#L281-L283

[timkgh]

Can Ulauncher detect that it's running under Gnome and work better at least under Gnome by using the same APIs?

[friday]

It's a non-solution. Not going that route.

[troycurtisjr]

Just to add in my vote for retaining at least the option to open new windows, matching the current behavior. I have so many workaround on my work MacOS in order to enable this behavior. I think having it as an alternate action, and also as a preference to default to new windows is the best approach if we can find a way to implement this.

It does seem like it would be worth while to use Gnome to do the launching when available, as there is a decent bit of logic that goes into it. It looks like it should basically just be a dbus Eval call using something like 'Main.Shell.AppSystem.get_default().lookup_app("firefox.desktop").activate(); This method handles desktop awareness and window recency, so it definitely seems like the smoothest solution https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/src/shell-app.c#L414 . For other desktops, there might be similar method, or we may be able to use a more generic method, like with wmctrl or similar. Note that I was able to get that snippet to work using Gnome looking-glass, but I have yet to make it work over DBus. I think that should be solvable though.

[friday]

wmctrl works. I tried, but the solution isn't clean. It's a wrapper wrapping other APIs, so it's handling all the wiring for us, but as I remember it the API it provides for us doesn't use unique keys like "firefox.desktop". It uses a more arbitrary case-insensitive one that I am not sure it can safely determine the right app to activate if you have two apps open and one of them identify as a subtring of the other one's ID, like for example Thunar has another app for Bulk renaming, that might be activated instead. Or if you have for example one app named "YouTube" and another named "YouTube Uploader".

I would much rather try to make this work than implement for specific DEs, since the app launch code is already really convoluted.

And as for the option to open in a new window, that's #476. Maybe we should do that before this issue for that reason.

[troycurtisjr]

Perhaps we could think about making the launching mechanism modularized. It seems like some of the things we run into relate to trying to run in different environments. Instead of trying to make a single code path work correctly in all the environments, we could more explicitly divide out the different mechanisms so that we have a framework for launching applications in the best way possible for a given environment. Also, we could more easily tweak/fix something for one environment, without impacting the executions for other environments. Then it only comes down to the proper "selection" code which properly chooses which launching mechanism to use.

We could have a detection mechanism and also an optional override. It could go something like:

1. Detect Desktop environment -> Use desktop specific launching method (like the Gnome dbus method I mentioned)
2. Detect when running under systemd -> Use systemd launching methods
3. Fallback to default non-systemd approach

This could help provide a way to better integrate ulauncher into different desktop environments, making it excel at launching applications, which is of course the whole point 😄 .

[AdamJel]

Hi, this would be very welcomed feature. I tried to find such an extension, but I wasn't lucky. Can anyone point me to one, if there is any, please? That is an extension, which shows list of currently running applications and allows to switch between them. Preferable in the very same way as Switcheroo (which is Windows only, sadly).

[friday]

This is now in the v6 branch (see PR above) now, which is also the main branch as of recently.

It is impossible to support this cross platform (Troy was right), but I was in the end able to implement it for X11, which is the best we can do.
Ulauncher already has two other features that require using x11, and there are no applications launchers that support this behavior for Wayland unless they were written for a specific DE and window manager as a shell extension and use their APIs.

There are no v6 releases yet, but we are getting there soon I think (pre-releases first).
Follow #869 if you want to be notified of v6 release plans.