[philistine]

Believe it or not, full screen apps are a Windows thing. Apple has added full screen app support only recently, and any Windows convert who has switched to macOS and has problems adapting to its UI has one thing in common: they haven’t let go of the idea that all apps need to use the whole screen at all times.

[realgeniushere]

This is a funny cope.

>Believe it or not, full screen apps are a Windows thing.

Nope. It’s just that maximizing—single action to expand a window the whole screen minus the OS docks/taskbars—is present in every widely used OS except for Mac OS.

>they haven’t let go of the idea that all apps need to use the whole screen at all times

Not sure where you’re getting “at all times” from. Windows and Linux desktops all easily support having windows take up less than the whole screen. In fact, it’s easier than in Mac OS because of window snapping to sides and corners. It’s only that Mac OS makes it very clumsy to get the effect that maximizing has on every other OS.

[lproven]

"Philistine" is right.

Most 21st desktop UIs are, to a greater or a lesser degree, Windows ripoffs. Most of Win95 or later, but sometimes you can trace a specific version -- e.g. KDE apes Windows 98 in program design as well as function.

(Rendering filer window contents as HTML before displaying them using the browser engine: this was designed by Microsoft to evade prosecution by the US DOJ for anticompetitive bundling of IE with Windows. It tried to claim that IE was integral by, for example, rejigging Explorer to render using IE. The Win 95 and 95B versions do not do it; nor did NT 4 at launch.)

If you believe that all GUIs do this, that suggests that the only desktop GUIs you've seen are ones that are copies of the Windows design.

To the best of my ability to recall that long ago, before Windows 3 and OS/2, most GUIs didn't have a maximise function.

Examples: AmigaOS; DR GEM; classic MacOS; Sun OpenLook; Acorn RISC OS.

[klodolph]

Prior to full-screen mode on macOS, you would option-click the window resize button to resize it to the full size of the screen. This still works. It just doesn’t snap.

[musicale]

Seems to work fine on Finder windows in Mac OS 9:

Single-click maximizes to the content size.

Option-click maximizes to full screen minus menu bar and desktop volume icons.

Apps like games and screen savers don't seem top have trouble covering up the entire desktop and menu bar.

I prefer it to the current macOS Finder where zooming covers up the menu bar and desktop volume icons, and where there doesn't seem to be an easy way to zoom to content.

[kccqzy]

That's a Zoom button not a Maximize button. Apps like Safari zoom based on the content, not the screen.

[klodolph]

Sure, under some circumstances it won't fill the screen.

[edgyquant]

Maximization of windows most certainly exists in MacOS.

[ilyt]

It's every other platform thing. Even Amiga did just fine with that fucking arcane (apparently, to Apple) concept that your OS needs to fuck off and let me work/play

[pjmlp]

Nope, other 16 bit OSes and UNIXes have them.

[retrac]

Classic Mac OS supported full screen applications since the beginning. I'm not sure if Apple allowed it or whatever in their very strict interface guidelines, but from a programming perspective you just have to turn off the menu bar and take the entire screen as the GrafPort.

[klodolph]

I think the recommended route is to make a window that fills the screen, rather than taking the entire screen as a GrafPort. If you want the code to be portable, you can make your fullscreen window, draw to an offscreen GWorld, and CopyBits to the window. There’s a whole song and dance that you do in order to make sure that this is fast.

Later on, there was DrawSprocket. It solved the problem of figuring out how to do “portable” and “fast” at the same time, and let you use features like page flipping, if the hardware supported it (saving you the call to CopyBits).

[jameshart]

HyperCard was a fullscreen app. A stack could hide the menu by just… saying ‘hide menuBar’ in its background script.

[klodolph]

You can think of HyperCard as a fullscreen app, and that’s not wrong. Look at it another way, and it’s displaying a 512x342 pixel window. On B&W compact Macs, that’s the size of the display. If you ran Hypercard on a later 640x480 color Mac, you could see the border of the window and move it around.

Later versions of HyperCard let you choose the size of the window. Various extensions would let you use a borderless window for the stack, and put a big black window behind it covering the rest of the screen.

[duskwuff]

HyperCard did some particularly weird things to draw to the screen quickly on older machines. If you try dragging a HyperCard stack window around, you'll notice that its horizontal position is quantized to 8-pixel increments, probably to accelerate drawing on low-bit-depth displays. :)

[klodolph]

Yes, that’s something you’ll need to do if you want to stay on the fast path :-)

The Motorola 68000 does not have a barrel shifter. You want to shift by 4 bits? That’s four cycles, buddy! Avoiding shifts keeps you on the fast path for CopyBits().

[reaperducer]

Apple has added full screen app support only recently

I read somewhere that the reason Apple finally added full-screen support to macOS (back then OS X), wasn't because of the Windows switchers. It was to get a bit more real estate out of the MacBook Air's small screen size.

[deergomoo]

I think it was also to try to get some i(Pad)OS users back to the Mac—one of the major advertised things about OS X Lion (which introduced full screen) was all the iOS stuff they were bringing "back to the Mac".

[dTal]

>full screen apps are a Windows thing

And iOS. Funny, that!

[genewitch]

i see to recall america online was fullscreen on macOS 8 and 9.