4 ms·

Cross-platform with a single code base has always been a bit of a myth, if only because different platforms have different conventions for things like how to la

Cross-platform with a single code base has always been a bit of a myth, if only because different platforms have different conventions for things like how to lay out dialog boxes or the writing style used for buttons. If you want something that feels like a native application on different platforms, it's always going to require some level of customisation. It's still useful to have a single UI library in your code that you can tell to make a text box or open a menu or draw some graphics and have it translate into the correct API calls on each platform under the hood. For all the much-touted rearrangements of UIs, particularly in recent versions of Windows, the reality is that most of the familiar GUI controls haven't really changed that much in decades. I think the biggest difficulty for any attempt at a cross-platform GUI framework today is probably making sure it does properly handle the widgets or behaviours that really are different or unique on each platform. More generally, if you're building for multiple platforms you also have to deal with all the installation and updating and sandboxing and so on that tends to be completely different from one OS to another, and often the GUI libraries and UI integration is a big part of that too.

derefr 10y ago
Instead of giving me the tools to make a modal pop-up, but then leaving me to match that modal pop-up to the stylistic conventions of each OS GUI, why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS—even going so far as to actually be a modal sheet or a command-line prompt instead? This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.) Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.
- Silhouette 10y ago
  I want to agree with the spirit of what you're saying, but given the potential complexity and uniqueness of a GUI, I think it's an extremely hard problem in practice, if not impossible. You're asking for a toolkit that is both generic enough to provide the common functionality you're describing, yet also comprehensive and flexible enough to cope with the diverse needs of different applications and the diverse conventions and capabilities of different platforms.
  - rer 10y ago
    How hard can it be to build a toolkit that supports a textbox on Mac OS X, Windows, and Linux? For a moment I thought you proposed a solution a thread up: > have it translate into the correct API calls on each platform under the hood. What if instead of writing controls for applications, the applications had low level access to create controls on their own?
    - barrkel 10y ago
      Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are. For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing. Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI. Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
      - rer 10y ago
        I see that the deeper you go, the less you can keep common. I learned a lot from your answers. I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI? I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?

derefr 10y ago

Instead of giving me the tools to make a modal pop-up, but then leaving me to match that modal pop-up to the stylistic conventions of each OS GUI, why can't a UI framework give me a "YesNoModalPopup" that looks and acts however a "YesNoModalPopup" is supposed to act on the respective OS—even going so far as to actually be a modal sheet or a command-line prompt instead? This, I think, is one of the bigger but oft-unstated reasons that people actually prefer to target the web rather than targeting native. Javascript's window.alert() is a function with a semantic behaviour-contract; it will alert the user. It doesn't specify how it'll alert the user, that's up to the browser to define. (And, therefore, up to the user to pick the browser whose definition they enjoy.) Perhaps what I'm really craving, here, is a XAML-like or XUL-like constraint-based declarative view format, which has a very high-level and abstract set of controls available to be specified. Then, different GUIs could have renderer-clients for this system, that rendered those controls in all sorts of different ways. Maybe you could even mix-and-match your favourite concrete controls, like with browser extensions.

Silhouette 10y ago
I want to agree with the spirit of what you're saying, but given the potential complexity and uniqueness of a GUI, I think it's an extremely hard problem in practice, if not impossible. You're asking for a toolkit that is both generic enough to provide the common functionality you're describing, yet also comprehensive and flexible enough to cope with the diverse needs of different applications and the diverse conventions and capabilities of different platforms.
- rer 10y ago
  How hard can it be to build a toolkit that supports a textbox on Mac OS X, Windows, and Linux? For a moment I thought you proposed a solution a thread up: > have it translate into the correct API calls on each platform under the hood. What if instead of writing controls for applications, the applications had low level access to create controls on their own?
  - barrkel 10y ago
    Individual controls aren't the problem. Unique controls and idioms that cover multiple controls are. For example settings dialogs on Mac are usually not modal and usually apply immediately. Meanwhile Windows dialogs are usually modal and transactional, with Cancel button to roll back and Apply to commit without closing. Full fidelity inevitability ends up bifurcating the codebase or compromising the nativeness of the UI. Simple things like button, text box, drop down, check box, radio button that have been in use for 30 years or more are just fine. But look at the list view in Windows; that has grown dozens of options to support Explorer, the file system browser. The deeper you go, the less you can keep common.
    - rer 10y ago
      I see that the deeper you go, the less you can keep common. I learned a lot from your answers. I didn't understand why the nativeness of the UI must bifurcate (fork) the codebase. In your example, can't non-modal on Mac vs modal on Windows be a config value in the cross-platform UI? I also didn't get an answer to one of my questions. Why can't applications have low level access to create controls on their own?