GUI libraries

[Chris]

On Thursday, 28 November 2013 at 16:22:58 UTC, Luís Marques wrote:
> 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.

I agree with you, you have a point there, and years ago I would 
have agreed with you. But users are getting more and more 
accustomed to a variety of GUIs (and general GUI logic). I used 
to work a lot with SWT and Cocoa and I know that unless you use 
the native toolkit in a native environment (say Cocoa and Xcode 
on OS X), you will never get the full experience. There are 
always things you cannot get with bindings. And what about the 
cool feature X on the Mac that is not available on Windows or 
Linux? In a way it's always a lowest common denominator thing 
with bindings.

I've come to the conclusion that if you have a language like D 
you must have bindings (useful, necessary but never quite there), 
but your own toolkit in which you can implement your own stuff 
(that is always available, no matter where you run the program) 
is definitely a big plus. Maybe a solution including HTML / CSS 
for the LAF part would be nice.

People are also starting to use GTK based stuff on Windows and 
Mac, which offers a different user experience. Still people cope 
with it.