On Thursday, 28 November 2013 at 16:27:31 UTC, Dicebot wrote:
>> I think Chrome and Opera
> are implemented like that.
>
> And hated for that :P

I love Opera, but I hate Opera ASA for not providing my beloved Linux builds :(((((((

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.

On 2013-11-28 13:13, Chris wrote:

> What I meant was no bindings to native widgets or other toolkits. DWT
> (like SWT) uses the native widgets and needs an interface. I was
> thinking of a toolkit where everything is provided by D and done in D
> without any reference to native frameworks (Cocoa etc.).

It would be quite difficult to not rely on any existing frameworks. Do you want re-implement OpenGL/DirectX :). But yes, I understand that you want a non-native GUI toolkit.

-- 
/Jacob Carlborg

On 2013-11-28 14:30, "Luís Marques" <luis@luismarques.eu>" wrote:

> Whatever API / bindings you use, please don't expose non-native UIs to
> users (drawn from scratch, either mimicking the native UI or not). They
> never completely integrate with the OS, subtly deviating from the native
> behaviour in ways that range from awkward to infuriating, and are always
> playing catch-up to the latest OS changes.
>
> For instance, take Viber for the Mac: what could be a great application
> (most of the complexity of a VoIP app isn't even in the UI), has awkward
> behaviors (e.g., the scrolling panes don't implement rubber banding,
> which makes them feel extremely unresponsive in OS X), badly imitated
> controls (e.g., the chat text box context menu, in OS X at least), etc.
> Features which are both complex and subtle like internationalisation
> also tend to break.
>
> The situation was already bad when the Windows, Mac and Linux interfaces
> were, overall, pretty similar (many of the non-optimal design decisions
> in apps with non-native UIs tended to appear where there were
> differences, such as in OS X global menus vs Windows' per window menus).
> With the trend toward newer and more diverse interface approaches, such
> as attempts to try to bring traditional computers to touch screen
> hardware, non-native UIs will tend to perform even worse, feeling even
> more alien to the end users.

I agree, I prefer a native GUI.

-- 
/Jacob Carlborg

Le 28/11/2013 13:13, Chris a écrit :
> On Thursday, 28 November 2013 at 12:05:09 UTC, Jacob Carlborg wrote:
>> On 2013-11-28 11:12, Chris wrote:
>>
>>> +1 GtkD & Glade (UI builder) are very good (http://gtkd.org/). Hopefully
>>> one day we will have our own pure D GUI toolkit.
>>
>> DWT is a pure D GUI toolkit.
>
> What I meant was no bindings to native widgets or other toolkits. DWT
> (like SWT) uses the native widgets and needs an interface. I was
> thinking of a toolkit where everything is provided by D and done in D
> without any reference to native frameworks (Cocoa etc.).
Dquick goes in this direction.

On 2013-11-28 15:49, Chris wrote:

> 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. I still think it would be good to have an
> independent GUI toolkit, like Java Swing / FX as opposed to SWT.

Using a native toolkit you only need to create bindings to the new features and add them to the API. With a non-native GUI you need to constantly re-implement the native GUI toolkit yourself. Or using a toolkit that doesn't look like any native toolkit at all.

-- 
/Jacob Carlborg

On 2013-11-28 17:22, "Luís Marques" <luis@luismarques.eu>" wrote:

> 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 think the best approach is to use a cross-platform toolkit that sits on top of native toolkit, like DWT. Use this for common widgets like buttons and windows, then add platform specific elements to enhance the look and feel. These addition can use the native toolkit directly.

-- 
/Jacob Carlborg

On 2013-11-28 17:45, Chris wrote:

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

See one of my other posts:

http://forum.dlang.org/thread/ewhdymbhzjmmuxvbssyt@forum.dlang.org?page=2#post-l7878f:24qt5:241:40digitalmars.com

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

I hate that. It's so far from the native toolkit.

-- 
/Jacob Carlborg

Le 28/11/2013 14:30, "Luís Marques" <luis@luismarques.eu>" a écrit :
> On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:
>> What I meant was no bindings to native widgets or other toolkits. DWT
>> (like SWT) uses the native widgets and needs an interface. I was
>> thinking of a toolkit where everything is provided by D and done in D
>> without any reference to native frameworks (Cocoa etc.).
>
> Whatever API / bindings you use, please don't expose non-native UIs to
> users (drawn from scratch, either mimicking the native UI or not). They
> never completely integrate with the OS, subtly deviating from the native
> behaviour in ways that range from awkward to infuriating, and are always
> playing catch-up to the latest OS changes.
>
> For instance, take Viber for the Mac: what could be a great application
> (most of the complexity of a VoIP app isn't even in the UI), has awkward
> behaviors (e.g., the scrolling panes don't implement rubber banding,
> which makes them feel extremely unresponsive in OS X), badly imitated
> controls (e.g., the chat text box context menu, in OS X at least), etc.
> Features which are both complex and subtle like internationalisation
> also tend to break.
>
> The situation was already bad when the Windows, Mac and Linux interfaces
> were, overall, pretty similar (many of the non-optimal design decisions
> in apps with non-native UIs tended to appear where there were
> differences, such as in OS X global menus vs Windows' per window menus).
> With the trend toward newer and more diverse interface approaches, such
> as attempts to try to bring traditional computers to touch screen
> hardware, non-native UIs will tend to perform even worse, feeling even
> more alien to the end users.
For me the main issue of fully custom UI isn't the visual aspect but the ergonomic, it can be hard to let the OS compositor to resize/move custom windows like natives ones.
Everything else isn't so hard to manage.

Take a look to QML with Qt Quick Controls :
http://www.youtube.com/watch?v=_6_F6Kpjd-Q

A multi-plaform UI SDK will tends to unify the way ui works across a larger devices panel.

On 2013-11-28 21:03, Xavier Bigand wrote:

> Take a look to QML with Qt Quick Controls :
> http://www.youtube.com/watch?v=_6_F6Kpjd-Q

That shows the problem with non-native toolkits. When he adds the button to the toolbar in the beginning, the toolbar isn't a native unified toolbar. It's some custom toolbar.

-- 
/Jacob Carlborg