> Same look and feel is just a (unfortunate?) consequence of that.
It's actually a consequence of a strong coupling of GUI and the programs and the unwillingness of developers to refrain from pixel-perfect control. In order to make a program consistent with different interfaces, you need to write them against a "generic" layer. You should declare your screens, menus and visual elements in a GUI-neutral environment and let the specific device use the GUI consistent with it.
In order to make a multi-GUI app you either code for each and every GUI or you give up fine-grained control.
Actually, in order to write an app that runs on both desktop and mobile platforms, you shouldn't mess with visual elements at all. You should just tell the UI layer to display your data/commands/options, and let the UI layer decide how to display them.
Having worked with WPF and trying to write Android-apps it's easy to despair.
They've taken the worst of WPF (XML) without offering any of the goods (data-binding, rapid application development). You feel like you're back in the stone-age of computing, only this time with XML instead of objects.
This often means you have to do lots of UI-wiring in code indirectly, based on handles, and due to Java's lack of functional constructs, even wiring up a simple event-handler becomes 6 lines of tedious, annoymous class instantiation nonsense. It's horrible.
Had anything like WPF been available in any stable or unstable form, I would have jumped at it in an instant.
It's actually a consequence of a strong coupling of GUI and the programs and the unwillingness of developers to refrain from pixel-perfect control. In order to make a program consistent with different interfaces, you need to write them against a "generic" layer. You should declare your screens, menus and visual elements in a GUI-neutral environment and let the specific device use the GUI consistent with it.
In order to make a multi-GUI app you either code for each and every GUI or you give up fine-grained control.