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