4 ms·

Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross p

Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products. Microsoft use to brag that they had more Mac developers than Apple did.

PaulDavisThe1st 4y ago
> But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other similar toolkits, but they are not writing twice the code every time they have do something in the GUI. If I'm wrong, HN is the place to find out.
- scarface74 4y ago
  That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex
  - PaulDavisThe1st 4y ago
    I never said anything about the backend. The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform. The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
    - scarface74 4y ago
      > Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”. The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
      - PaulDavisThe1st 4y ago
        The user clicks on a button or menu item labelled "Do Foo". To "do foo" requires further interaction with the user, and the designers opted to do that in a dedicated dialog. So the program now needs to make a dialog visible to collect information from the user. Simple enough for you? What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platform "toolkit", albeit in-house.
        scarface74 4y ago
        Serious question - are you a developer and what frameworks have you used? The front end already knows the inputs that the backend needs (in this case tte engine). When you click on a menu, it usually brings up another view without ever talking to the backend. I’m sure some companies have a framework that can automatically generate a native view based on an API definition. Even your standard CRUD app you usually have a set of API developers and they may publish their API using something like the OpenAPI specification and then your web developers, Android developers, iOS developers create interfaces to call the API. > What is the code at the call site that opens the dialog? WinUI? Cocoa? This is fundamentally opposite of how development is done in a GUI event driven architecture. The back end is never the “call site” that tells the front end to “bring up a dialog box” The front end calls the back end. Even if it’s not a user generated action, the front end still defines the interfaces and subscribed to an event. In your example: 1. The back end developer (the engine creator) writes code that is usually cross platform if that’s the aim and required certain inputs and raises events. 2. The front end developer creates menus and defines views that are shown when the menu item is selected. The view allows the user to enter the necessary information. 3. The front end then sends all of the information to the backend and probably some type of call back function that the back end should call when it’s done or in the case of error. The back end is never the “call site” nor does it know anything about the front end. This is a standard “onion architecture”

PaulDavisThe1st 4y ago

> But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other similar toolkits, but they are not writing twice the code every time they have do something in the GUI. If I'm wrong, HN is the place to find out.

scarface74 4y ago
That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex
- PaulDavisThe1st 4y ago
  I never said anything about the backend. The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform. The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
  - scarface74 4y ago
    > Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”. The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
    - PaulDavisThe1st 4y ago
      The user clicks on a button or menu item labelled "Do Foo". To "do foo" requires further interaction with the user, and the designers opted to do that in a dedicated dialog. So the program now needs to make a dialog visible to collect information from the user. Simple enough for you? What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platform "toolkit", albeit in-house.
      - scarface74 4y ago
        Serious question - are you a developer and what frameworks have you used? The front end already knows the inputs that the backend needs (in this case tte engine). When you click on a menu, it usually brings up another view without ever talking to the backend. I’m sure some companies have a framework that can automatically generate a native view based on an API definition. Even your standard CRUD app you usually have a set of API developers and they may publish their API using something like the OpenAPI specification and then your web developers, Android developers, iOS developers create interfaces to call the API. > What is the code at the call site that opens the dialog? WinUI? Cocoa? This is fundamentally opposite of how development is done in a GUI event driven architecture. The back end is never the “call site” that tells the front end to “bring up a dialog box” The front end calls the back end. Even if it’s not a user generated action, the front end still defines the interfaces and subscribed to an event. In your example: 1. The back end developer (the engine creator) writes code that is usually cross platform if that’s the aim and required certain inputs and raises events. 2. The front end developer creates menus and defines views that are shown when the menu item is selected. The view allows the user to enter the necessary information. 3. The front end then sends all of the information to the backend and probably some type of call back function that the back end should call when it’s done or in the case of error. The back end is never the “call site” nor does it know anything about the front end. This is a standard “onion architecture”