Hello.

I want to make GUI applications with D, but I don't know which are updated and ready to use, which are good and etc. Can you help me with choosing the right one, guys?

I tried to code in C++, but it was too much hard for me and I found D and I like it so much, but I don't know how is D good in creating GUI apps and 3D graphics like OpenGL.

Thank you for replies and sorry for my english.

On Wednesday, 27 November 2013 at 17:07:07 UTC, DLang Beginner wrote:
> Hello.
>
> I want to make GUI applications with D, but I don't know which are updated and ready to use, which are good and etc. Can you help me with choosing the right one, guys?
>
> I tried to code in C++, but it was too much hard for me and I found D and I like it so much, but I don't know how is D good in creating GUI apps and 3D graphics like OpenGL.
>
> Thank you for replies and sorry for my english.

Hello,

I suggest you have a look at gtkd or dwt.

On Wednesday, 27 November 2013 at 17:07:07 UTC, DLang Beginner
wrote:
> Hello.
>
> I want to make GUI applications with D, but I don't know which are updated and ready to use, which are good and etc. Can you help me with choosing the right one, guys?
>
> I tried to code in C++, but it was too much hard for me and I found D and I like it so much, but I don't know how is D good in creating GUI apps and 3D graphics like OpenGL.
>
> Thank you for replies and sorry for my english.

GtkD and Glade works for me.

-<mike>-

On Wednesday, 27 November 2013 at 20:25:30 UTC, Mike James wrote:
> On Wednesday, 27 November 2013 at 17:07:07 UTC, DLang Beginner
> wrote:
>> Hello.
>>
>> I want to make GUI applications with D, but I don't know which are updated and ready to use, which are good and etc. Can you help me with choosing the right one, guys?
>>
>> I tried to code in C++, but it was too much hard for me and I found D and I like it so much, but I don't know how is D good in creating GUI apps and 3D graphics like OpenGL.
>>
>> Thank you for replies and sorry for my english.
>
> GtkD and Glade works for me.
>
> -<mike>-

+1 GtkD & Glade (UI builder) are very good (http://gtkd.org/). Hopefully one day we will have our own pure D GUI toolkit.

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.

-- 
/Jacob Carlborg

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

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.

On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques wrote:
> 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.

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. The thing is that people are getting used to different UIs now, because they use e.g. an iPad, an Android phone and a Windows PC (both privately and at work). So maybe everything is going in the direction of common UI features. Take for example multi-touch. Years ago Apple was way ahead (zooming in and out, rotating pictures etc.). Now most touch screen devices feature the same set of movements (e.g. scroll with middle and ring finger on track pad).

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.

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 think Chrome and Opera
are implemented like that.

And hated for that :P