Sets – a new Windows interface feature that was first previewed in November 2017 and will make every window into a tabbed window – has been removed from the latest Insider Preview build of Windows 10. Moreover, the Verge is reporting that the feature won’t be coming back in this year’s next major update, due in October.
This marks the second time that Sets have been included in a preview release only to be removed at a later stage prior to the release of an update. When first announcing Sets, Microsoft was careful to note that it wasn’t promising Sets for any particular release – or possibly even ever, given the complexities of application compatibility and uncertainty about how people will actually use the feature.
This is a feature I’m really looking forward to, and it sucks to see it pulled like this, for the second time. I understand the complexities of a feature like this – especially with the vast library of software Windows supports – but that does raise the question if Microsoft’s openness regarding Windows development was a bit too much for this particular feature.
Are they still gonna put tabs in Explorer? I have to use that POS at work, so it would be really nice to have.
They should go back to implement MDI in their applications again and we are there where we were a good decade ago (when user interfaces were designed by a lot smarter people).
Who does not want to use it can switch it off. For the rest of us it is a hugely more efficient way to work.
This is one of the four big reasons I hate the GNOME/Wayland push for CSD. It cripples the desktop’s ability to experiment and innovate on window management. (eg. Fluxbox has had this kind of WM-level tabbing for AGES and and KWin 4.x had it for a while too.)
I firmly believe that KDE has the right of it, extending server-side window decorations to Wayland now and planning to un-mothball their DWD idea once Wayland support is solid. (DWD being in line with the general D-Bus-mediated architectural trend of other technologies like libnotify, KStatusNotifierIcon/appindicator, and Flatpak portals.)
It also makes it much more work to ensure that a broken application that’s not responding can’t cause window management problems. (This is actually something I’ve seen more in Windows than in Linux apps with CSD… probably because so few of the latter existed historically. Win32 applications that don’t process messages in a timely manner can render their titlebars completely unresponsive to input, such as attempts to drag them around. I haven’t used post-XP Windows enough to know if it’s still a problem.)
At least on Linux, most WMs implement Alt+LeftClick (move) and, sometimes, Alt+RightClick (resize) and the GNOME people have said that nothing in the APIs prevent them from implementing a model where the application tells the compositor about regions where it should take responsibility for mapping mouse input to window management without even dispatching an event to the client. (Though I still think it’s a bass-ackwards hack around a bad idea.)
The other reasons are less applicable to Windows, but, for the sake of completeness:
3. CSD forces every application toolkit to reinvent window borders, which are supposed to be just a standard part of the desktop environment. (eg. SDL under Wayland is still relying on the fact that most people aren’t me and run their games full-screen.)
4. On platforms with more than one “standard” UI toolkit (ie. not Windows), it makes it painful to ensure all applications have unified window look and feel with unified customization of titlebar controls.
…and, finally, for GNOME specifically, I think the whole premise of shoving action buttons in the titlebars of dialog windows is fundamentally flawed. (Putting them in the bottom-right corner developed from academic research that determined that dialog windows should read like paper forms, with the action buttons “at the end of the page”.)
…but then it wouldn’t be the first time GNOME did something in direct contradiction to the research that informed MacOS’s design in their pursuit to cargo-cult copy what they perceived it to be.
Edited 2018-06-29 08:33 UTC
Actually, GNOME wasn’t the first to implement CSD’s OS-wide. Xerox was with their GlobalView desktop, over 20 years ago: http://toastytech.com/guis/gv.html
I never said they were… I just think that pure CSDs are an example of an outdated performance hack that hamstrings the system’s potential for improvement, similar to how Win16 put everything in the same address space and multitasked cooperatively.
DWDs (server-side decorations with a defined, high-level IPC API for adding widgets from a predefined set into the titlebar) are a much better balance because they leave common behaviours in the common componentry, limit the ability of application bugs to break things, and provide a declarative API that allows the desktop to innovate on how to actually present the controls to the user.
For example, what if I wanted a WM-level tabbed titlebar with all of the application-provided widgets in a hamburger menu-button on each tab? CSD makes that practically unviable, while DWD would make it trivial to implement.
Edited 2018-06-29 11:42 UTC
That’s it, I’m switching to Haiku for the native tabbed window support!
I’ve had tabbed Windows for years….
Just find the program QTTabBar. It works just fine on Windows 10 Pro as it has on many previous OSes….
Oh and it’s free…..
Admittedly I haven’t tested it myself, but the whole idea seems a bit half-baked. Now we have tabs of applications, in addition to tabs in applications, in addition to tab-like ribbons in other applications, in addition to applications in the taskbar, which does almost the same thing? Seems a lot redundant, potentially confusing, not to mention a poor use of limited vertical space on wide-screen monitors.
Also while I understand the appeal of grouping windows from different applications to gather tools that fit together for one task, I question how much this capability will actually be used. Namely, unlike with browser tabs, where tab groupings arise organically based on following hyperlinks, as far as I can tell creating tab groups from multiple application windows requires pulling them together oneself. I wonder if this feature is really more likely to be used by “the 90%” than something like virtual desktops, which serve more or less the same function – and my guess is not really.
IMHO if MS is going to do fresh innovation on window management they ought to present a unified concept that integrates into the taskbar, not yet another vertical layer at the top.
Edited 2018-06-30 08:29 UTC
but that does raise the question if Microsoft’s openness regarding Windows development was a bit too much for this particular feature.
Like Gmome 3 “features” this feature also stank to high,high heaven, but unlike the clowns running Gnome 3 Microsoft learned from Windows 8 about what happens when you try to force half-baked ideas on a unwilling usebase and scrapped this gargage.
Good for them.
Edited 2018-06-30 17:04 UTC