4 ms·

On Mac OS, it's extremely rare that 'platform-native' cross-platform GUI libraries actually 'look like your platform'. Most are subtly wrong, feel less usable,

by danudey 12y ago

On Mac OS, it's extremely rare that 'platform-native' cross-platform GUI libraries actually 'look like your platform'. Most are subtly wrong, feel less usable, don't conform to platform guidelines, etc. It's extremely rare to see a cross-platform GUI on OS X that doesn't feel like it's just a reskinned Windows or GTK+ app, which makes it cumbersome to use.

dgellow 12y ago
It's not specific to OS X by the way.
byuu 12y ago
I wrote a cross-platform library that is the thinnest possible layer around Cocoa, and creates the actual Cocoa controls directly. They are truly 100% native widgets. And yet, it's exactly like you say. It has nothing to do with the base widgets. The problem is that to look native on OS X, you have to use widgets that only exist on OS X, like their merged titlebar+toolbar that changes and resizes the entire window content used on preferences dialogs, or the blue left navigation sidepanel, or the big question mark button, or the segmented control, or the color selection popup menu with the wide color boxes in each list item, or the combo box zoom setting in one segment of the status bar. And then your labels have to be right-justified while the controls are left-justified against those. You have to add about three times as much spacing between widgets as on other platforms. You have to have a single menubar that's outside the main window, and always has a "program name" menu where your preferences option has to be, a view menu, a window menu, and a help menu. You have to be sure to tie in to all the OS X only things like AppleScript, Core(Image, Audio, ...), dialog sheets that slide down on a window and then are only modal to just that one window, etc. Your message boxes can't have titles anymore, but everywhere else expects one. Even if you tried to add the extra spacing and hack in those OS X only widgets to Windows and Linux, then the Windows/Linux versions would be super hideous and unnatural. By the time you customize all of that, the code's a bigger mess than just making two separate GUIs. Defeats the entire purpose of using a cross-platform toolkit. Bottom line is that Apple just does way too much stuff differently to be able to craft a cross-platform app that looks great everywhere with no platform-specific customizations. And now Metro, Gnome 3, Unity and KDE 4/5 are trying to go in entirely different directions as well. And iOS and Android are big targets now, too. Sadly, the dream of write-once, run-anywhere and look nice is dead.
- GuiA 12y ago
  > Sadly, the dream of write-once, run-anywhere and look nice is dead. It's a shame no one invented the web browser yet :)
  - ben0x539 12y ago
    Webapps hardly look more native than even unidiomatic cross-platform widget toolkits or whatever.
    - FreakyT 12y ago
      Webapps can "look nice" (the exact words of the parent comment) without being specifically "native", so I think the comment still stands.
      - byuu 12y ago
        In that case, I should have clarified "look nice, and native." I think most Qt applications do look nice on OS X. Nice alone just isn't good enough, though. They want consistency with their other applications.
  - andlabs 12y ago
    I have a very good feeling telling that to byuu isn't going to end well... That being said, byuu is absolutely correct. It's one thing to make a program look like all the other programs on the target platform, but it's something else entirely to make it feel like one as well. You'll need to compromise quite a bit, as even when you go into raw event-handling no two systems are alike. You can see olddocs/areaplan.md in my repo as an example of where this gets especially hair-pulling, or all the places in the documentation where I mark some subtlety as implementation-defined or system-defined. Not even the big packages are immune. Look at Qt's QFormLayout type, which is a dedicated layout for aligning labels properly on each platform. (I'm going to have a similar thing eventually; that's why my docs presently have a TODO on vertical alignment with Label.) And yes, human interface guidelines can differ in very subtle ways. As an example, take multiple-selection listboxes. There are two ways you can implement this: as a normal listbox that you can select multiple items of, or as a list of items with checkboxes that you check to mark as selected. Microsoft's guidelines (http://msdn.microsoft.com/en-us/library/windows/desktop/dn742407%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dn74...) say (emphasis preserved) > Given this clear indication of multiple selection, you > might assume that check box lists are preferable to > standard multiple-selection lists. In practice, few tasks > require multiple selection or use it heavily; using a > check box list in such cases draws too much attention to > selection. Consequently, standard multiple-selection > lists are far more common. GNOME's guidelines (https://developer.gnome.org/hig-book/stable/controls-lists.html.en https://developer.gnome.org/hig-book/stable/controls-lists.h...) say > Consider using a check box list for multiple-selection > lists, as these make it more obvious that multiple > selection is possible: And Apple's guidelines (https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-TP6 https://developer.apple.com/library/mac/documentation/UserEx...) don't say anything too clearly, but DO say that - scrolling lists are selected traditionally (not checkboxed) - but a menu-style list should use check marks instead So there's that.

by danudey 12y ago

dgellow 12y ago

It's not specific to OS X by the way.

byuu 12y ago

I wrote a cross-platform library that is the thinnest possible layer around Cocoa, and creates the actual Cocoa controls directly. They are truly 100% native widgets. And yet, it's exactly like you say. It has nothing to do with the base widgets. The problem is that to look native on OS X, you have to use widgets that only exist on OS X, like their merged titlebar+toolbar that changes and resizes the entire window content used on preferences dialogs, or the blue left navigation sidepanel, or the big question mark button, or the segmented control, or the color selection popup menu with the wide color boxes in each list item, or the combo box zoom setting in one segment of the status bar. And then your labels have to be right-justified while the controls are left-justified against those. You have to add about three times as much spacing between widgets as on other platforms. You have to have a single menubar that's outside the main window, and always has a "program name" menu where your preferences option has to be, a view menu, a window menu, and a help menu. You have to be sure to tie in to all the OS X only things like AppleScript, Core(Image, Audio, ...), dialog sheets that slide down on a window and then are only modal to just that one window, etc. Your message boxes can't have titles anymore, but everywhere else expects one. Even if you tried to add the extra spacing and hack in those OS X only widgets to Windows and Linux, then the Windows/Linux versions would be super hideous and unnatural. By the time you customize all of that, the code's a bigger mess than just making two separate GUIs. Defeats the entire purpose of using a cross-platform toolkit. Bottom line is that Apple just does way too much stuff differently to be able to craft a cross-platform app that looks great everywhere with no platform-specific customizations. And now Metro, Gnome 3, Unity and KDE 4/5 are trying to go in entirely different directions as well. And iOS and Android are big targets now, too. Sadly, the dream of write-once, run-anywhere and look nice is dead.

GuiA 12y ago
> Sadly, the dream of write-once, run-anywhere and look nice is dead. It's a shame no one invented the web browser yet :)
- ben0x539 12y ago
  Webapps hardly look more native than even unidiomatic cross-platform widget toolkits or whatever.
  - FreakyT 12y ago
    Webapps can "look nice" (the exact words of the parent comment) without being specifically "native", so I think the comment still stands.
    - byuu 12y ago
      In that case, I should have clarified "look nice, and native." I think most Qt applications do look nice on OS X. Nice alone just isn't good enough, though. They want consistency with their other applications.
- andlabs 12y ago
  I have a very good feeling telling that to byuu isn't going to end well... That being said, byuu is absolutely correct. It's one thing to make a program look like all the other programs on the target platform, but it's something else entirely to make it feel like one as well. You'll need to compromise quite a bit, as even when you go into raw event-handling no two systems are alike. You can see olddocs/areaplan.md in my repo as an example of where this gets especially hair-pulling, or all the places in the documentation where I mark some subtlety as implementation-defined or system-defined. Not even the big packages are immune. Look at Qt's QFormLayout type, which is a dedicated layout for aligning labels properly on each platform. (I'm going to have a similar thing eventually; that's why my docs presently have a TODO on vertical alignment with Label.) And yes, human interface guidelines can differ in very subtle ways. As an example, take multiple-selection listboxes. There are two ways you can implement this: as a normal listbox that you can select multiple items of, or as a list of items with checkboxes that you check to mark as selected. Microsoft's guidelines (http://msdn.microsoft.com/en-us/library/windows/desktop/dn742407%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dn74...) say (emphasis preserved) > Given this clear indication of multiple selection, you > might assume that check box lists are preferable to > standard multiple-selection lists. In practice, few tasks > require multiple selection or use it heavily; using a > check box list in such cases draws too much attention to > selection. Consequently, standard multiple-selection > lists are far more common. GNOME's guidelines (https://developer.gnome.org/hig-book/stable/controls-lists.html.en https://developer.gnome.org/hig-book/stable/controls-lists.h...) say > Consider using a check box list for multiple-selection > lists, as these make it more obvious that multiple > selection is possible: And Apple's guidelines (https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-TP6 https://developer.apple.com/library/mac/documentation/UserEx...) don't say anything too clearly, but DO say that - scrolling lists are selected traditionally (not checkboxed) - but a menu-style list should use check marks instead So there's that.