After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661768 - [auto-move-windows] activate workspace after window was moved to it
[auto-move-windows] activate workspace after window was moved to it
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: extensions-module
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-14 13:53 UTC by Vasily Khoruzhick
Modified: 2017-11-25 02:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to implement subj feature (1.14 KB, patch)
2011-10-14 13:54 UTC, Vasily Khoruzhick
none Details | Review
Same functionality + configurability (2.39 KB, patch)
2011-10-26 20:52 UTC, Stefan "psYchotic" Zwanenburg
none Details | Review

Description Vasily Khoruzhick 2011-10-14 13:53:46 UTC
It makes sense to activate workspace after window was moved to it, and it looks convenient to me
Comment 1 Vasily Khoruzhick 2011-10-14 13:54:55 UTC
Created attachment 199010 [details] [review]
Patch to implement subj feature
Comment 2 Giovanni Campagna 2011-10-20 07:51:51 UTC
I saw this patch in the mail, and I didn't reply immediately because I'm not convinced this is the right behavior.
Yes, if you're launching an app, and you like on a specific workspace, it makes sense to activate it. But in that case, you can just use standard shell facilities (drag and drop).
On the other hand, I believe auto-move-windows, beside preventing auto collection of workspaces, is designed for fixed workflows where you start apps from a terminal and want them out of sight immediately, or you start multiple apps using scripts, or you resume a saved session. In none of those cases it makes sense to me to activate a specific workspace (among many).
Comment 3 Vasily Khoruzhick 2011-10-20 19:06:10 UTC
I usually use alt+f2 to launch apps, and I like to see app on necessary workspace when it's ready. Anyway, I'm OK with refusing to take this patch upstream, I can patch extension on my PCs easily :P Thanks for review ;)
Comment 4 Stefan "psYchotic" Zwanenburg 2011-10-26 20:51:51 UTC
(In reply to comment #2)
> I saw this patch in the mail, and I didn't reply immediately because I'm not
> convinced this is the right behavior.

I was actually the one that mailed you about that. I'll attached my patch (very similar to Vasily's, except for the fact that I've made the feature configurable).

> Yes, if you're launching an app, and you like on a specific workspace, it makes
> sense to activate it. But in that case, you can just use standard shell
> facilities (drag and drop).
> On the other hand, I believe auto-move-windows, beside preventing auto
> collection of workspaces, is designed for fixed workflows where you start apps
> from a terminal and want them out of sight immediately, or you start multiple
> apps using scripts, or you resume a saved session. In none of those cases it
> makes sense to me to activate a specific workspace (among many).

I see where you're coming from when it comes to the whole workflow thing. However, the way I have been using it is to actually force a workflow (i.e.: my browser gets moved to its own workspace, so it doesn't interfere with whatever I'm doing on the main workspace). But, once again, I can see why people wouldn't want this functionality, which is exactly why I thought it'd be better if it's configurable.
Comment 5 Stefan "psYchotic" Zwanenburg 2011-10-26 20:52:38 UTC
Created attachment 200062 [details] [review]
Same functionality + configurability
Comment 6 Florian Müllner 2017-11-25 02:17:42 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/1.