6 ms·

First word of the headline – it works and feels native to the platform. JetBrains and especially VS Code don’t respect the conventions of macOS software, visual

First word of the headline – it works and feels native to the platform. JetBrains and especially VS Code don’t respect the conventions of macOS software, visually as well as functionally.

nottorp 2y ago
That may be a plus for code editing, for example pgup/pgdown moving the cursor instead of just the view...
- isametry 2y ago
  I'm gonna bite on this example since you chose such a good one: if the convention on the platform is that `Page` buttons are like scrolling – NOT like arrowing – then good applications should respect that convention. You personally list this particular (mis)behavior as a "plus" since you like the PC convention better. But another person will think the opposite. Objectively, it's simply just inconsistent. What we need is "good platform citizen" apps which respect the local conventions, and you as the user get to choose the platform with its set of conventions you prefer. What we DON'T need is apps "unifying" behavior across operating systems based on their own opinion of what's better, ultimately just creating more mess.
  - avarun 2y ago
    No, you don’t get to decide that. Myself and many others have decided they liked this unified behavior just fine, while still preferring to code on macOS.
  - ubermonkey 2y ago
    This 100%. Many of us on the Mac are there in part because the environment and conventions make more sense to us than the conventions on other platforms. X-platform apps typically ignore this. See also https://daringfireball.net/linked/2020/03/20/mac-assed-mac-apps https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
    - nottorp 2y ago
      I like the Mac conventions most of the time. However for keyboard shortcuts said conventions are defined for crippled keyboards without dedicated navigation keys and the extension for PgUp/Down is simply inefficient when programming.
      - tpmoney 2y ago
        The cursor movement conventions have existed in macos since the classic mac days, when Apple was routinely shipping keyboards with "dedicated navigation keys": Up / Down: move cursor one line up or down Left / Right: move cursor one character left or right Option+ Up / Down: Move cursor up or down a whole paragraph Left / Right: move cursor left or right a whole word Command+ Up / Down: Move cursor to the beginning of the document Left / Right: Move cursor to the beginning or end of the document Page Up / Page Down: Move the scrolled display area up or down a "page" without moving the cursor Home / End: Move the scrolled display area to the beginning or end of the document The latter two are nice to have because it means you can scroll up through a window to view something, and start typing to have your view snap back to your cursor position.
        nottorp 2y ago
        > "dedicated navigation keys" I don't think they ever had PgUp and PgDown. Same thin/small fetish as today. Jobs wasn't typing much, I think.
        tpmoney 2y ago
        When I said this convention was old, I meant it: Apple Extended Keyboard M0115 (1987): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard_M0115.jpg https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard_M... Apple Extended Keyboard II M0312/M3501 (1990): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard.jpg https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard.j... Apple Adjustable Keyboard M1242 (1993): https://en.wikipedia.org/wiki/File:Apple_Adjustable_Keyboard_M1242_different_views.jpeg https://en.wikipedia.org/wiki/File:Apple_Adjustable_Keyboard... Apple Design Keyboard M2980 (1994): https://en.wikipedia.org/wiki/File:AppleDesign_Keyboard_black.jpg https://en.wikipedia.org/wiki/File:AppleDesign_Keyboard_blac... Apple USB Keyboard M2453 (1998) (not in their usual position, above the number pad instead): https://en.wikipedia.org/wiki/File:Apple_USB_Keyboard_B.jpg https://en.wikipedia.org/wiki/File:Apple_USB_Keyboard_B.jpg / https://deskthority.net/wiki/Apple_USB_Keyboard https://deskthority.net/wiki/Apple_USB_Keyboard Apple Pro Keyboard M7803 (2000): https://en.wikipedia.org/wiki/File:Apple_Pro_Keyboard_black.jpg https://en.wikipedia.org/wiki/File:Apple_Pro_Keyboard_black.... Apple Keyboard A1048 (2003): https://en.wikipedia.org/wiki/File:Apple_Keyboard_(A1048).jpg https://en.wikipedia.org/wiki/File:Apple_Keyboard_(A1048).jp... Apple Keyboard A1243 (2007): https://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243.png https://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243... Apple Magic Keyboard w/ Numeric Keypad A1843 (2017): https://en.wikipedia.org/wiki/File:Apple_Magic_Keyboard_with_Numeric_Keypad_Traditional_Chinese_(Zhuyin_%26_Cangjie).jpg https://en.wikipedia.org/wiki/File:Apple_Magic_Keyboard_with... Additionally at least as far back as the Powerbook G3 "Wallstreet" in 1998, and including the iBook lines from the same time period, to the best of my knowledge every Apple portable since (as well as any wireless/compact keyboards with Fn keys) then has supported Fn + Left/Right for Home/End respectively and Fn + Up/Down for Page Up / Page Down respectively. They were even marked as such through the early non-unibody MBPs but continue to function that way today even without the markings. While these aren't dedicated keys, they're convenient enough in combination with the other modifiers that you'd be using to move the cursor that I don't personally consider it a significant difference.
  - ascagnel_ 2y ago
    I think there's a somewhat obvious middle ground here: use the platform's default behavior, and surface an option that lets a user decide if they prefer the other version; eg: a PC user should also have the option to treat the page keys as scroll inputs rather than cursor navigation.
    - isametry 2y ago
      No disagreement. But I was talking within the scenario where you only get one. (Should have pointed that out.)
  - nottorp 2y ago
    Answer 1: I don’t use macs because of some religious conviction but because it’s the least shitty platform available. Answer 2: I bought a general purpose computing device and I don’t need the manufacturer to dictate how I use it.
    - tpmoney 2y ago
      Answer to your Answer: Then its on the application developer to give you the option to override the platform convention, but well behaved apps should adhere to the conventions of their platform by default.
lynndotpy 2y ago
On this note, do you have any notes or resources on what makes a MacOS app "native"? It's a quality people discuss but I can't identify. I used MacOS briefly 2000-2004, and then got a Macbook in 2022. Even among Apple's built-in apps, I can't identify why they would be considered "native". For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. One would also expect Applescript / Automator (Apple's built-in macro tool, a-la AutoHotkey / xdotool) to work with native apps, but it doesn't work on ARM Macbooks. Compared to Linux, I think anyone with no experience in it could sort native GTK vs native Qt vs native xMotif applications. But I think "native" as a quality is more of a dependency management and consistency question. The only thing I can recognize from Panic's screenshots that appear "native" is the Preferences page, in the older "grid on a shelf" format. (edit) And the "install applications by dragging to the Applications" folder workflow, which I appreciate very much. All this is to ask, what does "works and feels native" mean and what makes it desirable?
- adolph 2y ago
  > For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. For the grey beards of MacOS: This guy trashes the HIG [Apple Human Interface Guide] the way Johnny Depp trashes a hotel room. He even sports a custom radius on his window corners. No other window on the system has a shape like this. It’s wild. Just wait until the HIG zealots get a load of this guy. https://daringfireball.net/2005/09/anthropomorphized https://daringfireball.net/2005/09/anthropomorphized
- joshstrange 2y ago
  Apple that follow the HIG [0] closely are normally considered "mac native" (though I don't like the word "native" here as I normally use it to differentiate between electron/native). [0] https://developer.apple.com/design/human-interface-guidelines https://developer.apple.com/design/human-interface-guideline...
- crazygringo 2y ago
  > what makes a MacOS app "native"? For me, it has three parts: 1) Does it look native at a pixel level? In other words, does it use a standard Mac window and title bar and buttons and widgets and all the rest? 2) Is it organized according to Mac UX conventions? Does it put commands in the menu bar rather than inside of windows? Are menu items where you'd expect? Is the "Settings..." command where you'd expect, and is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)? 3) Does it respect all standard gestures and shortcuts and animations? If I press opt+left in a textbox, will the cursor jump to the previous word? If I press cmd+right, will it jump to the end of the text? If I scroll down, will it bounce at the bottom? That's what it means. And it's desirable for 1) aesthetics, 2) understandability, and 3) usability directly corresponding to those three points. Aesthetics is less important but it's still nice. Understandability is important because I don't want to hunt for a command when it's not where I'd expect. And usability is critical because when I cmd+right in a text box and it doesn't work, it's incredibly frustrating. Obviously, "native" is not a binary but is rather a continuum. And yes, even Apple's own apps are not always 100% at the "native" end, especially with stuff they've designed in conjunction with iOS. Which I think a lot of Mac users find frustrating.

First word of the headline – it works and feels native to the platform. JetBrains and especially VS Code don’t respect the conventions of macOS software, visually as well as functionally.

nottorp 2y ago

That may be a plus for code editing, for example pgup/pgdown moving the cursor instead of just the view...

isametry 2y ago
I'm gonna bite on this example since you chose such a good one: if the convention on the platform is that `Page` buttons are like scrolling – NOT like arrowing – then good applications should respect that convention. You personally list this particular (mis)behavior as a "plus" since you like the PC convention better. But another person will think the opposite. Objectively, it's simply just inconsistent. What we need is "good platform citizen" apps which respect the local conventions, and you as the user get to choose the platform with its set of conventions you prefer. What we DON'T need is apps "unifying" behavior across operating systems based on their own opinion of what's better, ultimately just creating more mess.
- avarun 2y ago
  No, you don’t get to decide that. Myself and many others have decided they liked this unified behavior just fine, while still preferring to code on macOS.
- ubermonkey 2y ago
  This 100%. Many of us on the Mac are there in part because the environment and conventions make more sense to us than the conventions on other platforms. X-platform apps typically ignore this. See also https://daringfireball.net/linked/2020/03/20/mac-assed-mac-apps https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
  - nottorp 2y ago
    I like the Mac conventions most of the time. However for keyboard shortcuts said conventions are defined for crippled keyboards without dedicated navigation keys and the extension for PgUp/Down is simply inefficient when programming.
    - tpmoney 2y ago
      The cursor movement conventions have existed in macos since the classic mac days, when Apple was routinely shipping keyboards with "dedicated navigation keys": Up / Down: move cursor one line up or down Left / Right: move cursor one character left or right Option+ Up / Down: Move cursor up or down a whole paragraph Left / Right: move cursor left or right a whole word Command+ Up / Down: Move cursor to the beginning of the document Left / Right: Move cursor to the beginning or end of the document Page Up / Page Down: Move the scrolled display area up or down a "page" without moving the cursor Home / End: Move the scrolled display area to the beginning or end of the document The latter two are nice to have because it means you can scroll up through a window to view something, and start typing to have your view snap back to your cursor position.
      - nottorp 2y ago
        > "dedicated navigation keys" I don't think they ever had PgUp and PgDown. Same thin/small fetish as today. Jobs wasn't typing much, I think.
        tpmoney 2y ago
        When I said this convention was old, I meant it: Apple Extended Keyboard M0115 (1987): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard_M0115.jpg https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard_M... Apple Extended Keyboard II M0312/M3501 (1990): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard.jpg https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard.j... Apple Adjustable Keyboard M1242 (1993): https://en.wikipedia.org/wiki/File:Apple_Adjustable_Keyboard_M1242_different_views.jpeg https://en.wikipedia.org/wiki/File:Apple_Adjustable_Keyboard... Apple Design Keyboard M2980 (1994): https://en.wikipedia.org/wiki/File:AppleDesign_Keyboard_black.jpg https://en.wikipedia.org/wiki/File:AppleDesign_Keyboard_blac... Apple USB Keyboard M2453 (1998) (not in their usual position, above the number pad instead): https://en.wikipedia.org/wiki/File:Apple_USB_Keyboard_B.jpg https://en.wikipedia.org/wiki/File:Apple_USB_Keyboard_B.jpg / https://deskthority.net/wiki/Apple_USB_Keyboard https://deskthority.net/wiki/Apple_USB_Keyboard Apple Pro Keyboard M7803 (2000): https://en.wikipedia.org/wiki/File:Apple_Pro_Keyboard_black.jpg https://en.wikipedia.org/wiki/File:Apple_Pro_Keyboard_black.... Apple Keyboard A1048 (2003): https://en.wikipedia.org/wiki/File:Apple_Keyboard_(A1048).jpg https://en.wikipedia.org/wiki/File:Apple_Keyboard_(A1048).jp... Apple Keyboard A1243 (2007): https://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243.png https://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243... Apple Magic Keyboard w/ Numeric Keypad A1843 (2017): https://en.wikipedia.org/wiki/File:Apple_Magic_Keyboard_with_Numeric_Keypad_Traditional_Chinese_(Zhuyin_%26_Cangjie).jpg https://en.wikipedia.org/wiki/File:Apple_Magic_Keyboard_with... Additionally at least as far back as the Powerbook G3 "Wallstreet" in 1998, and including the iBook lines from the same time period, to the best of my knowledge every Apple portable since (as well as any wireless/compact keyboards with Fn keys) then has supported Fn + Left/Right for Home/End respectively and Fn + Up/Down for Page Up / Page Down respectively. They were even marked as such through the early non-unibody MBPs but continue to function that way today even without the markings. While these aren't dedicated keys, they're convenient enough in combination with the other modifiers that you'd be using to move the cursor that I don't personally consider it a significant difference.
- ascagnel_ 2y ago
  I think there's a somewhat obvious middle ground here: use the platform's default behavior, and surface an option that lets a user decide if they prefer the other version; eg: a PC user should also have the option to treat the page keys as scroll inputs rather than cursor navigation.
  - isametry 2y ago
    No disagreement. But I was talking within the scenario where you only get one. (Should have pointed that out.)
- nottorp 2y ago
  Answer 1: I don’t use macs because of some religious conviction but because it’s the least shitty platform available. Answer 2: I bought a general purpose computing device and I don’t need the manufacturer to dictate how I use it.
  - tpmoney 2y ago
    Answer to your Answer: Then its on the application developer to give you the option to override the platform convention, but well behaved apps should adhere to the conventions of their platform by default.

lynndotpy 2y ago

On this note, do you have any notes or resources on what makes a MacOS app "native"? It's a quality people discuss but I can't identify. I used MacOS briefly 2000-2004, and then got a Macbook in 2022. Even among Apple's built-in apps, I can't identify why they would be considered "native". For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. One would also expect Applescript / Automator (Apple's built-in macro tool, a-la AutoHotkey / xdotool) to work with native apps, but it doesn't work on ARM Macbooks. Compared to Linux, I think anyone with no experience in it could sort native GTK vs native Qt vs native xMotif applications. But I think "native" as a quality is more of a dependency management and consistency question. The only thing I can recognize from Panic's screenshots that appear "native" is the Preferences page, in the older "grid on a shelf" format. (edit) And the "install applications by dragging to the Applications" folder workflow, which I appreciate very much. All this is to ask, what does "works and feels native" mean and what makes it desirable?

adolph 2y ago
> For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. For the grey beards of MacOS: This guy trashes the HIG [Apple Human Interface Guide] the way Johnny Depp trashes a hotel room. He even sports a custom radius on his window corners. No other window on the system has a shape like this. It’s wild. Just wait until the HIG zealots get a load of this guy. https://daringfireball.net/2005/09/anthropomorphized https://daringfireball.net/2005/09/anthropomorphized
joshstrange 2y ago
Apple that follow the HIG [0] closely are normally considered "mac native" (though I don't like the word "native" here as I normally use it to differentiate between electron/native). [0] https://developer.apple.com/design/human-interface-guidelines https://developer.apple.com/design/human-interface-guideline...
crazygringo 2y ago
> what makes a MacOS app "native"? For me, it has three parts: 1) Does it look native at a pixel level? In other words, does it use a standard Mac window and title bar and buttons and widgets and all the rest? 2) Is it organized according to Mac UX conventions? Does it put commands in the menu bar rather than inside of windows? Are menu items where you'd expect? Is the "Settings..." command where you'd expect, and is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)? 3) Does it respect all standard gestures and shortcuts and animations? If I press opt+left in a textbox, will the cursor jump to the previous word? If I press cmd+right, will it jump to the end of the text? If I scroll down, will it bounce at the bottom? That's what it means. And it's desirable for 1) aesthetics, 2) understandability, and 3) usability directly corresponding to those three points. Aesthetics is less important but it's still nice. Understandability is important because I don't want to hunt for a command when it's not where I'd expect. And usability is critical because when I cmd+right in a text box and it doesn't work, it's incredibly frustrating. Obviously, "native" is not a binary but is rather a continuum. And yes, even Apple's own apps are not always 100% at the "native" end, especially with stuff they've designed in conjunction with iOS. Which I think a lot of Mac users find frustrating.