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?
Hi,
I'm not sure what you mean.
Could you describe step by step what you do please?
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?
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 :)
Thank you
@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
@TheMartes that's a good use case. Thanks.
A suggestion: Use Alt + Enter for trying to switch instead of launching new instance?
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.
This will be an awesome feature to have!
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)
Hi @ArturMroz
Great work with the extension :+1:
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.
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.
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.
@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
Any updates on this?
@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).
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.
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.
@mamsoudi You did see my last comment right?
_(deleted my comment)_
I found the answers I was looking for in previous comments here.
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.
@gornostal any updates on this? happy to provide a bug bounty :)
@thebigredgeek no updates.
I didn't get to this task yet.
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.
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.
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.
In my humble opinion, I don't think an extension is the same thing as native support for this feature.
The problem: the user doesn't want to think whether an app is open or not before switching to it; the user doesn't want to add an extra keyword to switch to an app instead of launching a new instance. It all adds friction to the process. The current behavior is erratic: sometimes it will switch to an app, sometimes it will open a new app. It's all random and it doesn't make sense :cry:
I cannot echo @thiagoa 's comments enough, as have others (in just 3 months it has half the thumbs up as the original post from 3 years ago). I think people who have not experienced, or built a habit of, launchers first switching to any active window do not understand the value. And I think programmers and IT specialists use a launcher because it means:
Before I continue, I just want to acknowledge and thank @gornostal for trying to find a middle-ground and even offering such a solution! (that being, the event hook for plugin developers to use). I'd be happy with that outcome; but I might as well try to justify the argument for a native solution (with a toggle-able checkbox option), noting also I am happy to create a PR if you think my rationale is reasonable! :)
Given that assumption is fair, I think alt-tabbing is not efficient compared to proper launcher bindings. For me, I tap SuperL (aka WinKey) with my pinky finger in 0.25 seconds, and because my hands are already in place on the keyboard, it's another 0.5s max to type Chr for Chrome, Ter for Terminal, IDE for whatever IDE you use...
Alt-tabbing can be slower if you aren't sure exactly what layer the window is on, as it requires you to:
Additionally, and I think this is the biggest argument for this feature, What is the count for: # Times an application is first launched vs # Times a running application is switched to / focused on?. 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? I can't think of a single application I use regularly (or even rarely) that I need multiple instances of it more than I need to switch to it.
And this doesn't even factor in accidental opens, where you've assumed it was not open.
I want to thank the contributors for their open-mindedness so far, either way. It's always challenging determining whether a feature request is just a vocal group of users, or whether it has merit. I am here, and possibly also @aaronjensen after using Albert because of the toxicity and hostility and personal attacks by the creator of that repository. So just appreciating you!
If open to this idea, I would be excited to try and offer a PR, with an option to toggle-on (default off, to retain most user's expectations). I recognise, though, that:
TL;DR: Please let me know if open to PR (with toggle-on / default off) for native support to prioritise switching-to over launching, or whether happy to (some day) implement yourself (or if you think this is achievable via writing a plugin - note that none of the plugins get it quite right, eg have to append a letter, poor quality results, etc)!
Most helpful comment
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.