GUI libraries

"Luís "Luís
Thu Nov 28 08:22:56 PST 2013


On Thursday, 28 November 2013 at 14:49:33 UTC, Chris wrote:
> I don't know, but there are apps out there that do their own 
> thing rather than relying on the system. I think Chrome and 
> Opera are implemented like that.

My point was that non-native UIs will result, to different 
degrees, in less than optimal experiences for end users. I accept 
that other (business) concerns may eventually override a 
preference for non-native UIs, although I personally strongly 
discourage it. In the case of a browser like Chrome, you have 
several reasons why the problems with non-native UIs are 
mitigated, although not fully solved:

- A browser mostly displays content, and has little UI "chrome". 
Nevertheless, Chrome (the browser) still has a worse experience 
showing non-content interfaces, such as in plugins (compare, say, 
LastPass for Firefox and for Chrome) and preferences, and has/had 
non-native text rendering issues (antialiasing, etc.).

- Chrome is highly actively maintained, and quickly and 
automatically updated. Still, you still see lag in adoption of OS 
features, like when OS X made scrollbars appear when you rest two 
fingers on the trackpad when the pointer is over a scroll view. 
Chrome lagged in adopting that (it was a subtle feature), when 
fully native applications automatically got the new behavior with 
the old binaries.

- The business model of Chrome benefits somewhat from a lowest 
common denominator approach, where native platform features are 
not celebrated, focusing instead in the strengths of the web.

- Chrome still, nevertheless, uses a lot of native UI/OS 
features. For instance, native download progress indicators in 
the files themselves (viewable in the Finder, etc.).

> Also, when writing bindings to native widgets, you're always 
> playing catch-up too. Once you've got your bindings, the native 
> toolkit has new methods, features and classes.

Yes, but you still automatically get a lot of new 
behaviors/styles with your old application binaries. That's 
especially important for applications that are not as 
aggressively maintained as Chrome is. Also, you don't have to 
have generic UI libraries (or even bindings): a reasonable 
alternative might be the approach of applications like 
Transmission, which have a common core and several native UI 
frontends (Cocoa, GTK, Web, etc.).

I hope I didn't sound too disagreeable :-) thank you for your 
feedback.


More information about the Digitalmars-d mailing list