[coldpie]

Yeah, despite 20 years of "progress", I don't see today's desktops being any more usable than Win 95's, for the typical mouse-and-keyboard setup. There's a couple niceties that have been introduced since then, mostly keyboard shortcuts for window management tasks, but otherwise it's all change for the sake of change, and change for the sake of advertisements.

[shantly]

Launch-programs-by-search becoming common is the only significant advance I can think of since the 90s. I've added some keyboard window management to my personal workflow since then but I don't know any non-geeks who do that—hell, most of them don't use launch-by-search either.

[JohnFen]

> Launch-programs-by-search becoming common is the only significant advance I can think of since the 90s.

Windows had this since at least Win 7, so it's not really a recent advance. I dislike that the the Win 10 start menu is essentially unusable enough that it requires actually doing a search, though, which is why I use a replacement start menu.

[shantly]

Well, nine or ten years after the 90s, anyway, haha.

[JohnFen]

Ah, yes, my mistake!

[tasogare]

> Launch-programs-by-search

Which ironically doesn't work well anymore with Windows 10 because the start menu is often too laggy to open, or because it performs any other kind of unwanted search like web search.

[zamadatix]

Compositing was huge. I agree most of the usability stuff is around the window management improvements though. Overall I wouldn't say there has been a lot of change though, you could teleport a Windows 95 user into the present and they'd immediately be running with the current Windows 10 desktop.

[Crinus]

I do not like compositing though, at least not the way it is implemented in pretty much every current desktop environment (including Windows) where the composition is synced to the monitor refresh rate, meaning that it will always be at least ~8ms late on average and that is assuming everything else is synchronized - but this is not the case as applications draw their output offscreen to a surface that is picked up by the compositor (the mechanism of which is irrelevant, the application might just render to a compositor provided resource or the compositor might copy a VRAM surface or it may transfer bytes from the system RAM, it doesn't matter much in what i'm describing) which happens asynchronously and then notify the compositor that the window contents have changed which is again picked by compositor asynchronously. This introduces several frames of delay between the application drawing something and it appearing on your monitor. It is not a big problem when you are passively watching something, like a movie or an animation, but when that "something" that is drawn is an immediate reaction to an action you just did (like resizing a window with your mouse) you can "feel" that delay.

With non-composited window systems (which nowadays is pretty much only Win7 with DWM disabled and pure X11/Xorg) all that overhead goes away since applications draw directly to the video memory that is to be presented to the monitor (the GPU might do some minor composition itself but that is irrelevant as there aren't any delays involved).

Compositing would work if all composition was done on the GPU using dedicated hardware (similar to how the GPU already performs composition for the mouse cursor and an overlay that is often used for HUD-like controls like volume control, but those are not general purpose features that can be used for desktop composition) and applications could draw directly to the video surfaces that would be composited pretty much the same way a non-composited desktop can draw directly to the video memory (this would introduce artifacts like tearing but this is something that could be handled separately and to some - like me - tearing is perfectly acceptable for pretty much all interactive actions).

I am not aware of any GPU or window system that does compositing like this though.

[zozbot234]

Compositing was a hardware change, though. Modern GPU's (including GPU chipsets that are integrated as part of a CPU chip) basically accelerate 2D rendering by managing arbitrary surfaces as glorified sprites, which the hardware can "project" or "render" into other surfaces or on the screen in all sorts of ways, including occlusion, alpha blending, arbitrary 3D transforms etc. Hardware of the Win95 era didn't have anything like this; even moving and resizing windows only "animated" a wireframe rendition of the window, as with twm today.

[bitwize]

Windows 95 was the first release to support dragging of full window contents. I think that hack was even supported in the Windows 95 tech preview for Windows NT 3.51.

[StillBored]

But that was via BLT copy IIRC. Which is why there can be a slight delay filling the part of the screen being unobscured as the overlapped program repainted itself.

[zamadatix]

Compositing required a hardware change to work efficiently but it's not like you just slap a you into a win9x box and your desktop is now composited.

[sdegutis]

Personally I think VS Code is the epitome of the evolution of the ~~Windows~~desktop UI, and it’s one of my favorite UIs ever.