Alt-tab now unusable (IN-43727)

Unity Engine
,
1

The beta that this post comes from is feature locked but this alpha can still be saved.

A little taste of this insanity:

Now imagine 2 or 3 projects with a few floating windows each, as is often the case in early dev…

12 Likes
2

+1 to this.

2 Likes
3

Even on a very modern Mac, there’s a lag from Unity and back to unity when using Command + Tab, that doesn’t exist between any other apps, many of which have vastly bigger memory footprints.

2 Likes
4

Bigger lies have never been spread. Please undo this ‘improvement’ that completely breaks alt tab.

  • Editor: Changed to title bars on Windows for editor. Improving upon the existing title bar feature by adding to it.
4 Likes
5

We’re listening to our valued users
This sucks!
We value your feedback! We hear you!
Please, this harms usabili-
This change is an improvement
Wait wha-
Please continue to submit your ideas to the roadmap website <3

8 Likes
6

Then they act all surprised when people start acting aggressively lol

2 Likes
7

Making each windows become its own instance is the most annoying feature that was cause me to avoid paint.net in earlier version. Never thought unity or anyone would repeat the same mistake

3 Likes
8

9126166--1266580--upload_2023-7-5_14-59-33.png

Just deal with it, its suddenly a quirk of windows.

11 Likes
9

has Unity ever done anything wrong, or even slightly sub-optimally?

Of course not! Silly me.

10

This is seriously disappointed. Should we report it as a bug and upvote it

2 Likes
11

I like the native windows and title bars. The workflow is finally (almost) exactly the same on Windows and Linux.

However, the real problem I see is the weird behaviour: why on earth is any sub-window always above the actual editor?
You can’t minimize the main editor window without minimizing all sub-windows as well.

The idea of native windows itself is nice, but the execution is very bad. I’d love to keep bigger windows like ShaderGraph separated, but what’s the point if it always stays on top of every other editor window, including the main editor itself when tabbing in or out of it?
It’s definitely unpolished and needs more work, but completely reverting it would be the wrong decision in my opinion.

We usually have 3 projects open at once. Even before this change it was very bad if used on a single desktop.
I highly recommend using multiple desktops, one for every project with separated task bars. This works very well on Windows 10/11 and Ubuntu.

Another sidenote about the screenshot: on Ubuntu you don’t have this problem. Alt+Tab works exactly as shown on your screenshot, while Win+Tab cycles through app instances, excluding the sub-windows.
I’m not saying you should throw Windows out of the window, but maybe you should consider learning how to use Linux/Ubuntu if you care so much about an optimal workflow.
Of course you still need Windows for publishing and testing, but if you can afford a dedicated Linux workstation (or can live with the downsides of dual-boot), it’s really worth the effort in the long run.
Seriously, even without coding the amount of customization options of the Ubuntu desktop is insane.

3 Likes
12

don’t talk about doing something, do it.

13

I just look at the amount of space wasted by each window by the native title bar, and even more space wasted with the duplicate Unity title bar, I am horrified. How come such changes passed
I guess I’ll stay on 2022.1 for a long time now

1 Like
14

Did you both miss the part where someone already did a bug report and Unity replied it’s a Windows quirk and they won’t fix it?

Submitting bug reports is about as useful as starting online petitions or something.

2 Likes
15

Windows quirk? Damn, you’d think work of a UX developer would be dealing with these quirks, but as it turns out, it actually about doing whatever you want and ignoring any feedback cuz it’s a bit complicated to do it the right way. Nice attitude. And all that while .NET team rewrites half the engine to bring .NET Core, what a joke

3 Likes
16

I agree so much!!
All my bug reports have been classified as “not a bug” “won’t fix” or “duplicated” (of an already fixed bug of course…).
Note that in the last case, it wasn’t a duplicate but anyway it wasn’t such a serious bug after all, I could write a 4 lines of code script which had 100% chances to produce a crash, a perfectly normal feature I guess…
Fortunately they eventually fixed it, I guess someone at Unity stumbled on the bug by chance.

I have stopped submitting bugs when they rejected a bug report without reading it because it was made on a “too old version” (released less than 6 month before…).
My time is better used finding workarounds rather than hoping Unity will fix something.
Which is why I really like when they add features in packages where we can fix the code ourselves.

1 Like
17

Please revert this for anything other than shader graph and similar windows. This is really unusable and looks terrible. At least this shouldn’t be the default behavior.

2 Likes
18

i agree this is a major usability issue for countless developers that rely on years of workflows and “muscle memory” with the previous behaviour in mind. now, there is good and bad news as to where this issue originated and how this can be resolved to satisfy the most possible workflows and developers with a cohesive and consistent user experience.

the bad news:

  • alt + tab in microsoft windows has been unusable for “per app” switching since windows 7. it’s been a “per window” switcher for over a decade. no matter how many windows are open in that app. (assuming the app is actually reporting its child windows to the operating system as expected. also edge browser receives some special treatment with tabs.) microsoft intended to resolve some of this with the since cancelled (or delayed) windows “sets” feature.

  • strictly speaking, as important as the limited legacy functionality is to existing workflows, this issue is not a bug to report to unity (and i don’t believe they will ever see it as a bug.) It may seem blurry where the onus is as the perception is that “everyone knows that microsoft doesn’t care and so you the application developer should figure out a way to fix it”. many developers do make attempts, setting a precedent that maintains this perception. it still remains at the core a feature to request of microsoft to bring back an option to restore how alt-tab used to work in windows xp and older (per application switching) in line with what other operating systems provide. at most this is asking unity to try and fix and massage what is really a microsoft issue (as many developers do --attempting to rectify microsoft’s omissions and limitations for them in countless one-offs that result in fragmented workflows that vary in every application, further delaying and shielding microsoft from receiving the brunt of the feedback and doing something about it.)

  • this is a non-issue on mac os and linux (ubuntu) as their window managers provide features “out of the box” to use alt tab or similar shortcuts to switch “per application” and not just “per window”. the unity editor is finally in line with how microsoft intends for this to work (albeit in a regressed state.) previously the limitation of microsoft windows’ task switcher only being able to switch individual windows (and not whole apps) was being sidestepped by unity’s lack of child window integration with the microsoft windows api.

the good news:

3 Likes
19

I never saw any such request so I browsed through your links and the demand looks very weak.

Anyway, thanks for sharing the fix-hacks.
To save people some time, you can skip the windows xp regedit hack, yes the insanity stops but you lose snapshot and mouse selection.

Bad policy on Unity’s design team part to -again- break user workflow without an option or forum thread assessing demand.

3 Likes
20

Hi there, I work on Unity’s editor design team. The decision was made based on a combination of external requests (as Landon very helpfully pointed out above) as well as internal initiatives for reducing our editor tech debt.
The code involved for us to be able to manage multiple windows while sidestepping the built-in management of Windows OS was quite large, and was very time and effort intensive for us to manage.
Internally, we determined that the benefits of this change (as Landon notes above, including window snapping, accessibility support, integration with virtual desktop and 3rd party organization apps) would be able to outweigh the temporary frustration grating against the user’s muscle memory. We don’t make decisions like this lightly, as the ability for our users to work smoothly is a high priority. We are reviewing comments and reports from you all, and most likely any bug that was filed as “won’t fix” was passed on to the design team to save as a design ticket, as the code itself is working as expected.

6 Likes