> 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”.

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.

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”

Wow. Just wow.

I was the 2nd employee at Amazon. For the last 23 years, I've been the lead developer of Ardour, a cross-platform DAW. I also wrote JACK, the only cross-platform inter-application audio/MIDI routing system, but since that's a system that doesn't require a GUI, it's not really relevant. It did win me an award in the early 2000s though.

What you're describing sounds to me like a process out of 1980s "application development" blended with web stuff blended with contemporary "rapid application development" aka "define the GUI with a GUI tool, and it automatically generates code".

Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.

I asked you a simple question about what the code looks like in an Adobe or Microsoft app that runs on two platforms, the code that opens a dialog to collect information from the user. Nothing in my question makes any reference to tbe backend. All I can guess is that you think that all GUIs are defined via RAD-ish tools. All I can do is to try to use your language: what is it that a front-end developer is doing when they "define views that are shown when the menu item is selected" ?

> Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.

In that case, you know that the call site is never “telling the front end to bring up a dialog box”

> I was the 2nd employee at Amazon

Well I’m the millionth something employee at Amazon :). But as far as generating a view. I’m thinking of something like the home grown (publicly discussed) tools that AWS has so that when the service team introduced a new API, we have tools that can automatically generate SDKs in all of the supported languages and the CLI. Why couldn’t a custom tool create native views? Hey

Again we know for a fact that Adobe has “millions of lines of native Cocoa”. Why is it so hard for you to believe that the front end is hand coded by native developers?

Even at one 200 person company I use to work for we had dedicated web, Android, IOS and desktop developers.

But even when you aren’t using RAD tools, you are still defining your views some kind of way with XML, config files or something. BTW, I’ve been a continuous hands on ”programmer” (we didn’t call ourselves developers back then) since the mid 80s when I was a hobbyist 65C02.