Gala: Minimize as move to new workspace

[donadigo]

Because, we're discouraging from minimize and we're moving away from it, I propose a different way of "minimizing" or rather to make use of workspaces and automate using them:

• Clicking the icon on the dock will move the app with a "slide to right" animation to a new workspace at the end of all workspaces instead of minimizing, this will give a better feel of what's actually happening with a window
• Perhaps, a new button in the titlebar of a window that does that action, because it's performed quite often
• Because now that almost every app has it's own workspace, current Alt+Tab is rendered useless, because it switches only between apps on the current workspace, since every workspace will contain likely one window, Alt+Tab should then switch between all apps, not just current workspace.

Ongoing work here: https://github.com/elementary/gala/tree/minimize-to-new-workspace

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[cassidyjames]

For context, here's the originating discussion from Slack:

Cassidy James Blaede [10:21 AM]
I just had a crazy idea: what if minimizing an app just threw it onto a new workspace in the background (and didn't take the user over to it)?

I'm having a discussion with someone about the differences between minimize and workspaces
and there's a ton of overlap

but right now we don't really do interesting things with the latter because we still sort of support the former

what if our migration/legacy support was to remove explicit minimizing from everywhere we can, and then on the window manager level to just redirect minimize requests to move windows to a new workspace behind the scenes?

Daniel Foré [10:23 AM]
That’s a really interesting approach. I was thinking the other day about how we can push workspaces more

Cassidy James Blaede [10:24 AM]
That seems super wild at first but I honestly think it's really similar (get this window out of here) while always making sure it has a spatial home.

Daniel Foré [10:24 AM]
Right

Cassidy James Blaede [10:24 AM]
And the current ways of un-minimizing would still work fine

i.e. clicking it in the dock, scrolling it in the dock

trying to open a new instance

etc

hmmm

Then we animate "minimized" windows off the right side of the screen instead of down to the dock. It's much more spatial. They always have a physical location.

Peter Uithoven [10:30 AM]
Wouldn't that be annoying for people who pick specifically what they put into workspaces?

Lewis Goddard [10:30 AM]
How would un-minimizing becoming "move back to current workspace" work with apps that were explicitly sent somewhere else?

I click on open apps on another workspace to travel there, not to bring it here.

Peter Uithoven [10:32 AM]
And... the physical location feel of how current minimize works "just" requires a animation towards the Plank?

Maybe it would help if there where top and bottom workspaces as well? just trowing it in some workspace to the right feels random?

Cassidy James Blaede [10:34 AM]
The problem right now with minimizing is that it animates down to the dock, but then it kind of doesn't exist anywhere specifically.

It still exists on that workspace, sort of

Daniel Foré [10:35 AM]
I think we really want to get away from the dock being a window manager

Cassidy James Blaede [10:35 AM]
When you go to the overview it's there alongside other windows

but then it also doesn't really exist anywhere because it shrunk down to its icon

so it's super inconsistent right now

I'm also not saying my crazy new-workspace idea is good, just something that came up in a conversation and I'm throwing at the wall (edited)

Peter Uithoven [10:36 AM]
isn't the issue that Plank doesn't really integrate with the Overviews ?

Cassidy James Blaede [10:37 AM]
It's that minimizing, closing, and workspaces as multitasking concepts are all overlapping and consequently none of them are super good/clear/consistent

Peter Uithoven [10:37 AM]
I always like discussing new ideas, so I appreciate that you are.

what if every workspace had a kind of Drawer (like in a desk) and we include a visualization of it's contents in the overviews?

Cassidy James Blaede [10:40 AM]
kinda like this?

Screenshot from 2018-11-05 10.39.25.png

:stuck_out_tongue_winking_eye:

Or you're saying like, a separate "minimized stuff" drawer?

I think that's adding an extra layer of abstraction to workspaces. I kinda think the extra drawer is another workspace honestly.

Peter Uithoven [10:42 AM]
ha yeah kind of, but that row includes all the apps in the workspaces. I would add another row, with maybe just the icons or smaller previews of the apps from the open workspace that where put into the drawer

it would definantly add and extra concept, making things more complex. The only benefit is that we visualize "minimized" apps in overviews as well, sort of integrating the concepts

Daniel Foré [10:59 AM]
I think the goal is to move away from minimizing and towards working with workspaces

Adam Bieńkowski [11:16 AM]
I think that, when talking about workspaces vs minimize, it is all about what will be faster for the end user and what will be the most "careless" solution

People don't generally use workspaces, because they usually require some sort of setup and more interaction from the user than just clicking "minimize" on a window

…

Back to workspaces, I still think they should be automated / rethought in almost every way if you really want to remove minimize completely (edited)

Cassidy James Blaede [11:25 AM]
Yeah (edited)

…

Adam Bieńkowski [3:43 PM]
So the discussion about workspaces was lost a little bit, could we capitalize on the those issues we currently have and fill them?

…

Adam Bieńkowski [5:32 PM]
MPEG 4 Video
minimize-as-workspace.mp4
4 MB MPEG 4 Video

@cassidyjames is this like what you suggested?

Cassidy James Blaede [5:33 PM]
@donadigo that looks like a "move to next workspace" sorta thing, huh? No, I was thinking put it on a _new_ workspace

i.e. a new blank one at the far-right

Adam Bieńkowski [5:37 PM]
Ah okay

Okay, I got it

I can say that it works really well when you have multiple maximized windows

So that would basically make all apps having their own workspace?

Cassidy James Blaede [5:44 PM]
Yeah if you were minimizing things

Adam Bieńkowski [5:50 PM]
I wonder if this could be a little bit smarter ie. if you sent the app to the last workspace, but stayed on the current workspace, clicking it on the dock would bring it back to the current workspace

Cassidy James Blaede [5:54 PM]
:shrug:

…

Adam Bieńkowski [5:12 PM]
@cassidyjames if you'd like to test it: https://github.com/elementary/gala/tree/minimize-to-new-workspace

Cassidy James Blaede [5:32 PM]
@donadigo do you know why minimizing Slack would move it to the next workspace, and then immediately switch to that workspace?

Adam Bieńkowski [5:33 PM]
@cassidyjames hm, weird, I mean currently the code does unminimize the window when it gets to a new workspace because we have to workaround mutter somehow

Basically, without that the window would be on another workspace, but minimized

Cassidy James Blaede [5:34 PM]
Ah, iirc Chrome/Electron do some funky things with workspaces

so maybe when it unminimizes it also tells the wm to switch to it?

Adam Bieńkowski [5:34 PM]
Well, Chrome works fine for me here (as it doesn't switch to it or anything)

Cassidy James Blaede [5:35 PM]
Yeah I guess Chromium is working fine

Adam Bieńkowski [5:35 PM]
It's very possible

Cassidy James Blaede [5:35 PM]
but the Slack Electron app does some weirdness :stuck_out_tongue: (edited)

Adam Bieńkowski [5:35 PM]
let me install that

Yeah it does switch

It's possible that it focuses and in result switches

Adam Bieńkowski [5:43 PM]
Yeah it's because unminimizing (edited)

Cassidy James Blaede [5:45 PM]
What if switching to the workspace triggered the unminimize instead of doing it instantly?

Adam Bieńkowski [5:45 PM]
Yeah I'm currently trying to do that

Adam Bieńkowski [6:03 PM]
Well, it's complicated.. I'll see if I can do a different thing, but for now I'm out

[cassidyjames]

Re: @donadigo's points in this issue:

Clicking the icon on the dock will move the app with a "slide to right" animation to a new workspace at the end of all workspaces instead of minimizing, this will give a better feel of what's actually happening with a window

Yeah I'd like to explore this. It turns out I hardly ever minimize so it's not really a big difference for my workflow, but I'm dogfooding it for a bit.

Perhaps, a new button in the titlebar of a window that does that action, because it's performed quite often

This I don't really agree with, because it's effectively adding a "Throw to new workspace" button to the header of every single app, whether the user wants to use workspaces or not. I think it's nice to encourage workspaces, but the minimize workaround is really a way to get rid of the weirdness of a super inconsistent concept of minimize. So I don't know that we want to go back to throwing a minimize icon into titlebars.

Because now that almost every app has it's own workspace, current Alt+Tab is rendered useless, because it switches only between apps on the current workspace, since every workspace will contain likely one window, Alt+Tab should then switch between all apps, not just current workspace

I also disagree with this one; I use Alt+Tab to switch between windows on the current workspace all the time and it's really nice to constrain it there. Whereas Super+Tab switches workspaces if you have more of a one-window-per-workspace workflow.

[donadigo]

Following up on the last point:
If I use "minimize" or "put on a new workspace" a lot, Alt+Tab really stops to work, at this point it's a dumb shortcut. Super+Tab doesn't solve that because 1. you can't see all apps at once and choose ie. you have to cycle through each workspace to even see the app you want, 2. it's possibly slower than Alt+Tab.

Whereas Super+Tab switches workspaces if you have more of a one-window-per-workspace workflow.

Well, the issue kind of actually enforces that.

[eljefuri]

@cassidyjames @donadigo I think some context is missing here with the lack of images. Although I reserve total judgment until tesitng it myself, "slide to right on what-was-previously-minimize" sounds crazy. I've setup Elementary systems for almost 20 people now. They can be taught to use the dock icon to minimize applications (as they are used to doing in whatever operating system they are coming from), but having it appear on an entirely new workspace is going to be insanely jarring. What if I had an overlapping set of windows that I was using productively and then it gets moved to another workspace without my explicit consent? I struggle to imagine behavior more frustrating than that.

Also @donadigo if you primarily target full-screen apps, then you don't need workspaces at all right? And also in that case what are all of these widget-type apps in AppCenter for? Sorry if I misunderstand you.

[eljefuri]

For what it's worth I like Elementary's constrained-to-workspace ALT+TAB approach, _and_ the universal-across-Spaces ⌘+TAB application switching of macOS. Both are workflows that I think anyone can get used to. Conveniently, Elementary's constrained-to-workspace approach works as universal for anyone who either doesn't want or doesn't have awareness of workspaces.

[donadigo]

@eljefuri yes, I think that the biggest downside to this is that you can't have multiple windows open on the same workspace anymore and that seriously harms the productivity side, because if you want to be able ie. see two documents at once, now you can't. I opened this issue exactly for suggestions and discussion.

What I want to do is in some way "automate" workspaces. Currently, you have to do some work to basically setup workspaces in the way you want. The elementary team states that minimizing is "inconsistent" and I don't really know in what way that is inconsistent, this has been the topic since ever and the workflow without minimize is still not ideal at all in my opinion. I would like to bring some focus on this issue.

[eljefuri]

@donadigo I get your point, and I will definitely follow this thread with great interest. The final word in workspace/virtual desktop management has certainly not been had and I applaud you guys trying new things.

That said, I personally have not been able to get a single person to tolerate not having a minimize window function. And while I am all for innovating on the desktop, I have reservations about dumping functional, working UX paradigms that are second nature to the majority of people who might pick up and use Elementary. On the other hand, if the assumption is that the migration pattern is (or will be) iPad ⇒ eOS or something like this, then I can at least understand the idea even if I shift my doubts to the result. The medium is the message, after all.

[Blast-City]

Hi.

I don't think this is a good idea. There is other options to achieve the goal of isolating a tab.

I think that Elementary needs to start pushing the idea that the new workspace ( last one ) is the right way to show the desktop/minimize all windows. In my opinion, this is the reason why so many people are used to the minimizing concept.

This is what i would do.

Workflow:

• Super+d would switch between the last workspace and the current one. This would be the show desktop keyboard shortcut.

• Remove all the minimize ability.

• If you need to isolate a window, either put it in fullscreen mode (F11) or move it with super+alt+left/right or super+alt+number.

• fullscreen windows and windows would not be able to cohabit. When you moved a window to a workspace that have a fullscreen window, the workspaces would rearrange by itself.

Plank:

• Clicking the app button would focus the window. If it is already focused it wouldn't do anything. I know some people don't like it, but it it's what makes sense. The same behavior that happens when you scroll on a app icon that only have one window.

• If there is two windows of the same app open and the app is already focused it would open the workspace overview (future window and workspace overview merge) with all the windows of that app open.

• Scroll wheel would show the window switcher (Alt+Tab), but with just the windows of the corresponding app. This would eliminate the issue where, if you scroll and it goes to a window that is in fullscreen mode, suddenly you can't move again using the scroll wheel. An alternative, simpler version would be to show the left click menu (faster), but with just the windows open list and the wheel would scroll through that list.

[yellowgh0st]

That is really interessting idea. Maybe this could be related. I'm not sure. I just really have to ask why there is desktop being displayed under an maximized app window within multitasking view?

Shouldn't be the app in maximized mode represented only by its window?
Probably only in a case when there is no other window.

This

instead of this

[yellowgh0st]

@donadigo

The elementary team states that minimizing is "inconsistent" and I don't really know in what way that is inconsistent, this has been the topic since ever and the workflow without minimize is still not ideal at all in my opinion.

Window which is being minimized goes down into dock. Then when you open multitasking view It is shown righ there. So where exactly is? It feels bit strange. It should be more semantic.

[eljefuri]

@4ugustin We're probably going off topic, but just so that I can understand this better: I would really appreciate seeing a screencast from someone who uses Elementary multitasking view as an indispensible part of their workflow. If I am honest, the only thing I have ever used it for is an (awkward) way to kill hung apps. This is again a case where I have not seen another user discover it and go "oh yes, perfect", and then proceed to integrate it into their day-to-day. I am open to the possibility that we are all missing out by the way, but at the moment I just don't get it. The primary benefit vs simply using plank is the management of multiple windows for a single app?

EDIT: Oh my gosh I did just realize that it would be insanely useful for keyboard users if each window corresponded to a single-letter shortcut key. e.g. press SUPER+DOWN, then the list of windows appears and I can type "A" to instantly surface Firefox window 1, or "B" to instantly surface the first Terminal window, and so on. This is a bit like the keyboard link-jumping feature of Vimperator/cvim/etc except instead we are dealing with whole windows. Gee, I would use _that_ constantly.

[janxkoci]

Please no.

Ok I got couple more points on this:

1. As far as I know, elementary promotes closing apps instead of minimizing them. The app after reopening should look as you left it (which of course doesn't work so well with 3rd party apps like LibreOffice).
2. Moving windows to other workspaces would be super confusing to majority of people I know.
3. This would also break Alt+Tab in severe way (I use both minimizing and throwing window to other workspace regularly in my workflow, for different purposes). And making Alt+Tab switch windows across workspaces would force me away from elementary :/ I'm sooo happy with current Alt+Tab (doesn't group by app, is workspace constrained and puts minimized windows at the end)
4. Scrolling on dock icons is little bit awkward on touchpads.

Sure, this can all probably be solved by "if you loose your window (by minimizing, throwing to other ws, etc), just look for it on the dock" style of behaviour. However I actually use dock rather scarcely, so that wouldn't particularly fit my workflow.