4 ms·

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 macO

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.

pjmlp 4y ago
Nope, other 16 bit OSes and UNIXes have them.
genewitch 4y ago
i see to recall america online was fullscreen on macOS 8 and 9.
retrac 4y ago
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.
- jameshart 4y ago
  HyperCard was a fullscreen app. A stack could hide the menu by just… saying ‘hide menuBar’ in its background script.
  - klodolph 4y ago
    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 4y ago
      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 4y ago
        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().
- klodolph 4y ago
  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).
realgeniushere 4y ago
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.
- klodolph 4y ago
  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.
  - kccqzy 4y ago
    That's a Zoom button not a Maximize button. Apps like Safari zoom based on the content, not the screen.
    - klodolph 4y ago
      Sure, under some circumstances it won't fill the screen.
  - musicale 4y ago
    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.
- edgyquant 4y ago
  Maximization of windows most certainly exists in MacOS.
reaperducer 4y ago
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 4y ago
  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 4y ago
>full screen apps are a Windows thing And iOS. Funny, that!
ilyt 4y ago
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 4y ago

Nope, other 16 bit OSes and UNIXes have them.

genewitch 4y ago

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

retrac 4y ago

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.

jameshart 4y ago
HyperCard was a fullscreen app. A stack could hide the menu by just… saying ‘hide menuBar’ in its background script.
- klodolph 4y ago
  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 4y ago
    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 4y ago
      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().
klodolph 4y ago
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).

realgeniushere 4y ago

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.

klodolph 4y ago
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.
- kccqzy 4y ago
  That's a Zoom button not a Maximize button. Apps like Safari zoom based on the content, not the screen.
  - klodolph 4y ago
    Sure, under some circumstances it won't fill the screen.
- musicale 4y ago
  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.
edgyquant 4y ago
Maximization of windows most certainly exists in MacOS.

reaperducer 4y ago

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 4y ago
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 4y ago

>full screen apps are a Windows thing And iOS. Funny, that!

ilyt 4y ago

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