www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GUI libraries

reply "DLang Beginner" <repakolius email.cz> writes:
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.
Nov 27 2013
next sibling parent "Olivier Pisano" <olivier.pisano laposte.net> writes:
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.
Nov 27 2013
prev sibling next sibling parent reply "Mike James" <foo bar.com> writes:
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>-
Nov 27 2013
parent reply "Chris" <wendlec tcd.ie> writes:
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.
Nov 28 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
parent reply "Chris" <wendlec tcd.ie> writes:
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.).
Nov 28 2013
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
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.
Nov 28 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
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.
Nov 28 2013
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
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.
Nov 28 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
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.
Nov 28 2013
parent Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
 I think Chrome and Opera


are implemented like that.

And hated for that :P
Nov 28 2013
parent "eles" <eles eles.com> writes:
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 :(((((((
Nov 28 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
prev sibling parent "Baz" <burg.basile yahoo.com> writes:
On Thursday, 28 November 2013 at 14:49:33 UTC, Chris wrote:

 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.


Current Opera stuff is "everything javascript".The setting page 
is a js stuff the download page is a js stuff...And everybody 
complain about this: js ans css.
Seriously, opera is not anymore a good example.
Nov 29 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Nov 28 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 28/11/2013 21:35, Jacob Carlborg a écrit :

 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.


Yep, that the goal, having applications with a real personality. I don't 
think it's an issue especially when application is full screen and 
respect pictographs (icons and texts) standards,...

Having custom UI can help applications to improve ergonomic with 
dedicated behaviors when it's needed.

D itself isn't limited to one policy, you can do objects or not,... the 
only things that is important is to let a strong default couple of style 
and ergonomic without adding complexity for users want do some custom stuff.


What is native on windows ?
  - Win32
  - Winforms
  - Qt Widgets (that is near Win32)?

And on linux ?
  - GTK (with gnome and KDE)
  - Qt QML (KDE future)

A native UI isn't necessary considered as the standard one, maybe Qt 
have a chance to be a real standard (on many platforms).
Nov 28 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand 
wrote:

 Yep, that the goal, having applications with a real 
 personality. I don't think it's an issue especially when 
 application is full screen and respect pictographs (icons and 
 texts) standards,...


It is easier (much much easier) but less desired path. I will 
chose native look & feel over any possible "personality". To be 
honest, personality is the very last thing I want from my 
applications. They are best when I don't notice them.

True cross-platform is a myth. However, I can't imagine anyone 
supporting full scale of popular native toolkits so it remains as 
unfortunate compromise.
Nov 28 2013
prev sibling next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand 
wrote:

 Le 28/11/2013 21:35, Jacob Carlborg a écrit :

 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.




  clip

 What is native on windows ?
  - Win32
  - Winforms
  - Qt Widgets (that is near Win32)?

 And on linux ?
  - GTK (with gnome and KDE)
  - Qt QML (KDE future)


Neither.  Its Motif :o)   Unity!
Actually, I would say Linux doesn't have a native GUI, since 
Qt/GTK are basically cross-platform UI toolkits that sit on top 
of X11/Wayland/Whatever.


 A native UI isn't necessary considered as the standard one, 
 maybe Qt have a chance to be a real standard (on many 
 platforms).
Nov 28 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 01:26:57 UTC, Craig Dillabaugh 
wrote:

 Actually, I would say Linux doesn't have a native GUI, since 
 Qt/GTK are basically cross-platform UI toolkits that sit on top 
 of X11/Wayland/Whatever.


There can't be such thing as native Linux GUI. Linux is a kernel. 
There is a native Gnome GUI, same for KDE, Unity and probably 
some other Linux-based desktop environments. X11 is not a "native 
GUI" either as it is does not have own look & feel.
Nov 28 2013
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Friday, 29 November 2013 at 01:30:46 UTC, Dicebot wrote:

 On Friday, 29 November 2013 at 01:26:57 UTC, Craig Dillabaugh 
 wrote:

 Actually, I would say Linux doesn't have a native GUI, since 
 Qt/GTK are basically cross-platform UI toolkits that sit on 
 top of X11/Wayland/Whatever.


 There can't be such thing as native Linux GUI. Linux is a 
 kernel.


clip

Are you really Richard Stallman? :o)
Nov 28 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 29 November 2013 at 01:43:39 UTC, Craig Dillabaugh 
wrote:

 On Friday, 29 November 2013 at 01:30:46 UTC, Dicebot wrote:

 On Friday, 29 November 2013 at 01:26:57 UTC, Craig Dillabaugh 
 wrote:

 Actually, I would say Linux doesn't have a native GUI, since 
 Qt/GTK are basically cross-platform UI toolkits that sit on 
 top of X11/Wayland/Whatever.


 There can't be such thing as native Linux GUI. Linux is a 
 kernel.


 clip

 Are you really Richard Stallman? :o)


Still lacking proper beard ;)
Nov 28 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:

 Still lacking proper beard ;)


A programmer without a beard! Blasphemy! Witch!

----

But anyway, going along with what you guys are saying, if you've 
ever seen reviews on Android apps, a lot of apps get lots of bad 
reviews for not adhering to the Android design standards. Using 
cross-platform toolkits are usually a death sentence for your 
rating. So, there's a lot to be said about making sure your app 
looks consistent in the OS it's running in.

Some apps do "get away" with something that is somewhat custom. 
Take, for instance, Steam on Windows. It doesn't look like a 
"proper" Windows application, but it works very well for it 
regardless. That said, Steam on Mac is terrible because it feels 
too much like a windows app there (mainly in regards to scrolling 
behavior).

That all said, if I were writing a GUI app in D right now, I 
would probably write my own toolkit and make something super 
simple (but "good" looking) to test out some new ideas. I think 
we really need an easy, straight-forward, and powerful UI toolkit 
that takes advantage of D's unique features (such as compile-time 
specialization, maybe using DSLs that compiled & used at 
compile-time instead of runtime) while reflecting well in 
comparison to the newest paradigms of application design (think 
how Android & iOS apps are made and maybe even a bit of web 
design). I can't quite precisely quantify what we need, but I 
think a fresh approach to the UI programming interface could set 
D apart in this area.

Simply using a translation of an old UI toolkit is "easy" but 
will not make UI applications pleasing to develop.
Nov 28 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 02:00:50 UTC, Chris Cain wrote:

 On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:

 Still lacking proper beard ;)


 A programmer without a beard! Blasphemy! Witch!

 ----

 But anyway, going along with what you guys are saying, if 
 you've ever seen reviews on Android apps, a lot of apps get 
 lots of bad reviews for not adhering to the Android design 
 standards. Using cross-platform toolkits are usually a death 
 sentence for your rating. So, there's a lot to be said about 
 making sure your app looks consistent in the OS it's running in.

 Some apps do "get away" with something that is somewhat custom. 
 Take, for instance, Steam on Windows. It doesn't look like a 
 "proper" Windows application, but it works very well for it 
 regardless. That said, Steam on Mac is terrible because it 
 feels too much like a windows app there (mainly in regards to 
 scrolling behavior).

 That all said, if I were writing a GUI app in D right now, I 
 would probably write my own toolkit and make something super 
 simple (but "good" looking) to test out some new ideas. I think 
 we really need an easy, straight-forward, and powerful UI 
 toolkit that takes advantage of D's unique features (such as 
 compile-time specialization, maybe using DSLs that compiled & 
 used at compile-time instead of runtime) while reflecting well 
 in comparison to the newest paradigms of application design 
 (think how Android & iOS apps are made and maybe even a bit of 
 web design). I can't quite precisely quantify what we need, but 
 I think a fresh approach to the UI programming interface could 
 set D apart in this area.

 Simply using a translation of an old UI toolkit is "easy" but 
 will not make UI applications pleasing to develop.


You actually put into words what I've been thinking. I know that 
people want "native behavior", and maybe one day it will just be 
"intuitive behavior" instead of "corporate OS behavior".[1] But 
with D we have a chance to do what you say in the last paragraph.

[1] What we expect of a UI is what we've been made to believe to 
expect. It all boils down to "Architect or Bee?"
Nov 29 2013
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 29/11/2013 03:00, Chris Cain a écrit :

 On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:

 Still lacking proper beard ;)


 A programmer without a beard! Blasphemy! Witch!

 ----

 But anyway, going along with what you guys are saying, if you've ever
 seen reviews on Android apps, a lot of apps get lots of bad reviews for
 not adhering to the Android design standards. Using cross-platform
 toolkits are usually a death sentence for your rating. So, there's a lot
 to be said about making sure your app looks consistent in the OS it's
 running in.

 Some apps do "get away" with something that is somewhat custom. Take,
 for instance, Steam on Windows. It doesn't look like a "proper" Windows
 application, but it works very well for it regardless. That said, Steam
 on Mac is terrible because it feels too much like a windows app there
 (mainly in regards to scrolling behavior).

 That all said, if I were writing a GUI app in D right now, I would
 probably write my own toolkit and make something super simple (but
 "good" looking) to test out some new ideas. I think we really need an
 easy, straight-forward, and powerful UI toolkit that takes advantage of
 D's unique features (such as compile-time specialization, maybe using
 DSLs that compiled & used at compile-time instead of runtime) while
 reflecting well in comparison to the newest paradigms of application
 design (think how Android & iOS apps are made and maybe even a bit of
 web design). I can't quite precisely quantify what we need, but I think
 a fresh approach to the UI programming interface could set D apart in
 this area.

 Simply using a translation of an old UI toolkit is "easy" but will not
 make UI applications pleasing to develop.


+1

For my work I work on a huge application that was actually only 
available on iOS, with his interface wrote in cocoa. The next version 
will be ported to iOS, Android, Windows and Mac OS X (maybe linux), so 
we completely rewrite the interface with QML, because to increase the 
application identity over multiple platforms and provide something 
really easy to use for customers. Providing an UI that match to mobile 
ones will remove the apprehension of users instead of Widgets making the 
application looks like a professional tool.

I also think that professionals want beautiful apps too, just take a 
look to Visual, less and less developers want use vim or emacs.

A lot of progress have to be done on UI and I don't think that it will 
necessary impulse by OS developers.
Nov 29 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2013-11-30 at 00:10 +0100, Xavier Bigand wrote:
[…]

 available on iOS, with his interface wrote in cocoa. The next version 
 will be ported to iOS, Android, Windows and Mac OS X (maybe linux), so 
 we completely rewrite the interface with QML, because to increase the 
 application identity over multiple platforms and provide something 
 really easy to use for customers. Providing an UI that match to mobile 
 ones will remove the apprehension of users instead of Widgets making the 
 application looks like a professional tool.


[…]

A lot of people are going with QML now that the Trolltech → Nokia →
Digia transition is settling down. I suspect Microsoft (inadvertently?)
gave Qt a great boost by telling Nokia to ditch it in favour of
WindowsPhone. Qt is, all in all, about the best graphics system for
platform independent GUIs. The other candidate is wxWidgets, but that
seems to have lost a bit of momentum compared to the increased momentum
of Qt and especially QML. Gtk isn't really an option on Windows, nor
really OSX.



On Sat, 2013-11-30 at 00:23 +0100, Xavier Bigand wrote:
[…]

 QML and mostly Qt Quick Controls are really young technologies and 
 certainly not finished. The important things of Quick Controls is


that 

 it provides the default skin of the OS and the correct behaviors, but 
 It's preferable to adapt it to import a custom Skin.
 
 Digia certainly think that it's important to simplify the transition 
 between old (OS natvie UI) and new (fully custom UI) usages.


Certainly QtQuick Controls are new, but they were needed, QtQuick 1.0
required people to construct their own – definite #epicfail. QtQuick 2.1
seems to be settling down nicely and is a reasonable base for a vibrant
ecosystem.

A section of Canonical is now firmly behind using QML so as to get the
platform independence across all the platforms they want Ubuntu to work
on. That section is also behind Go (instead of Python or C++) and the
QML/Go combination is developing nicely, albeit very young really. A lot
of the sensible and experience-based grumbles about Go come from these
folk.

I am using QML/Go (and QML/Python, two separate backend implementations
based on the same QML) for a pet project (which as a sideline supports
my Python and Go training courses and is research for a possible
startup). I had been hoping to do QML/D as well but the only graphics
engine that is really viable with D just now is GtkD. I may well try a
GtkD/Vibe.d/D version of this but it is really back burner. If there was
a possibility of QML/Vibe.d/D now that would be really interesting.
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 30 2013
parent reply "Bruno Deligny" <bruno.deligny gmail.com> writes:
On Saturday, 30 November 2013 at 10:02:40 UTC, Russel Winder 
wrote:

 I am using QML/Go (and QML/Python, two separate backend 
 implementations
 based on the same QML) for a pet project (which as a sideline 
 supports
 my Python and Go training courses and is research for a possible
 startup). I had been hoping to do QML/D as well but the only 
 graphics
 engine that is really viable with D just now is GtkD. I may 
 well try a
 GtkD/Vibe.d/D version of this but it is really back burner. If 
 there was
 a possibility of QML/Vibe.d/D now that would be really 
 interesting.
 


You may want take a look at DQuick :
https://github.com/D-Quick/DQuick

It runs on top of openGL too, the main difference is that you 
describe the UI in dedicated script files. Scripts allow to 
provide fully dynamical UIs.

An UI file (original lua script format for the moment) :

GraphicItem
{
     id = "main",

     Image {
         id = "kerningImageButton",

         source = "images/border-image.png",
         width = 300,
         height = 50,

         MouseArea {
             id = "kerningButton",
             width = function()
                 return kerningImageButton.width
             end,
             height = function()
                 return kerningImageButton.height
             end,
         },
     },

     ScrollView {
         id = "scrollView",

         y = function()
             return kerningImageButton.height
         end,
         width = function()
             return main.width
         end,
         height = function()
             return main.height - scrollView.y
         end,

         clip = true,

         Text {
             id = "text",

             wrapMode = Text.WrapMode.WordWrap,

             width = function()
                 return scrollView.width
             end,
             height = function()
                 return scrollView.height
             end,

             text = textFr,
             family = function()
                 if (kerningButton.pressed) then
                     return "AngsanaUPC"
                 end
                 return "Arial"
             end,
             fontSize = 24,
             fontStyle = function()
                 if (kerningButton.pressed) then
                     return Text.FontStyle.Italic
                 end
                 return Text.FontStyle.Regular
             end,
         },
     },
}
Dec 02 2013
next sibling parent reply Danni Coy <danni.coy gmail.com> writes:
AFAIK the linux situation looks like this.

GTK is the current native toolkit for the Gnome based environments and
descendants including Unity.
Canonical are trying to move towards Qt for Unity.
Qt is the standard toolkit for KDE.

However Qt can treat GTK as a native toolkit and will render native
GTK widgets in Gnome as it does render native windows widgets on
windows and native Mac widgets on mac. It does take a bit of work and
testing with margin sizes etc to get a Qt App to look exactly like a
GTK App. Conversely the KDE devs have come up with a fairly nice GTK
theme (oxygen)  that matches the native KDE apps quite closely when
using the default theme (except for the far shitier file dialogs I
guess).
Dec 10 2013
parent reply "Temtaime" <temtaime gmail.com> writes:
GTK is too ugly.
Dec 11 2013
next sibling parent "Mike James" <foo bar.com> writes:
On Wednesday, 11 December 2013 at 20:25:43 UTC, Temtaime wrote:

 GTK is too ugly.


css is good for prettifying it :-)

-=mike=-
Dec 11 2013
prev sibling parent Stefan Scholl <stesch no-spoon.de> writes:
"Temtaime" <temtaime gmail.com> wrote:

 GTK is too ugly.


But it's free.
Dec 12 2013
prev sibling parent "MGW" <mgw yandex.ru> writes:
I wanted to work with Qt from Dlang and do it with QtE.d 
(https://github.com/MGWL/QtE-Qt_for_Dlang_and_Forth)
Dec 11 2013
prev sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 29 November 2013 at 02:00:50 UTC, Chris Cain wrote:

 On Friday, 29 November 2013 at 01:44:34 UTC, Dicebot wrote:

 Still lacking proper beard ;)


 A programmer without a beard! Blasphemy! Witch!

 ----

 But anyway, going along with what you guys are saying, if 
 you've ever seen reviews on Android apps, a lot of apps get 
 lots of bad reviews for not adhering to the Android design 
 standards. Using cross-platform toolkits are usually a death 
 sentence for your rating. So, there's a lot to be said about 
 making sure your app looks consistent in the OS it's running in.

 Some apps do "get away" with something that is somewhat custom. 
 Take, for instance, Steam on Windows. It doesn't look like a 
 "proper" Windows application, but it works very well for it 
 regardless. That said, Steam on Mac is terrible because it 
 feels too much like a windows app there (mainly in regards to 
 scrolling behavior).

 That all said, if I were writing a GUI app in D right now, I 
 would probably write my own toolkit and make something super 
 simple (but "good" looking) to test out some new ideas. I think 
 we really need an easy, straight-forward, and powerful UI 
 toolkit that takes advantage of D's unique features (such as 
 compile-time specialization, maybe using DSLs that compiled & 
 used at compile-time instead of runtime) while reflecting well 
 in comparison to the newest paradigms of application design 
 (think how Android & iOS apps are made and maybe even a bit of 
 web design). I can't quite precisely quantify what we need, but 
 I think a fresh approach to the UI programming interface could 
 set D apart in this area.

 Simply using a translation of an old UI toolkit is "easy" but 
 will not make UI applications pleasing to develop.


+1
This is why with DOOGLE I have made shaders for e.g. controls 
completely overridable at app, system and user levels. Shaders 
control all looks of the app. Although this does mean a bit of 
calculation and binding of information regarding screen and 
component size.

What does this mean? Maintainers for a distro or OS can easily 
make it look like what is expected for that OS.
With regards to feel that would have to be hard coded at this 
point.

Is it just me or is a button a layout? As far as I'm aware most 
gui toolkits think of it as not. It gives much more control over 
it.
Just my 2 cents over how I feel with them.

Eventually I would like to have DOOGLE emit html/css/js and work 
like GWT (Google Web Toolkit [1]). This really would be hugely 
beneficial for making a desktop application into a web app. And 
set it apart.

[1] http://www.gwtproject.org/
Nov 29 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 29 November 2013 at 01:43:39 UTC, Craig Dillabaugh 
wrote:

 Are you really Richard Stallman? :o)


There is one true linux gui: emacs!
Nov 28 2013
prev sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
clip

 What is native on windows ?
 - Win32
 - Winforms
 - Qt Widgets (that is near Win32)?

 And on linux ?
 - GTK (with gnome and KDE)
 - Qt QML (KDE future)


 Neither.  Its Motif :o)   Unity!
 Actually, I would say Linux doesn't have a native GUI, since 
 Qt/GTK are basically cross-platform UI toolkits that sit on top 
 of X11/Wayland/Whatever.


Actually, now that I think about it, Motif never really got used 
much on Linux much if I recall.  I just found out that MS helped 
design Motif, which was very clever of them, designing such an 
ugly toolkit for what was their competition at the time.

Also, I just checked and Unity is based on GTK, so that is out. I 
should research my posts better :o)
Nov 28 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-28 21:54, Xavier Bigand wrote:


 Yep, that the goal, having applications with a real personality. I don't
 think it's an issue especially when application is full screen and
 respect pictographs (icons and texts) standards,...


"real personality", it's more of trying to emulate the native toolkit to 
fails.


 Having custom UI can help applications to improve ergonomic with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or not,... the
 only things that is important is to let a strong default couple of style
 and ergonomic without adding complexity for users want do some custom
 stuff.


 What is native on windows ?
   - Win32
   - Winforms
   - Qt Widgets (that is near Win32)?

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)

 A native UI isn't necessary considered as the standard one, maybe Qt
 have a chance to be a real standard (on many platforms).


There's one thing in creating a completely new GUI, like games do, and a 
completely different thing in trying to emulate a native toolkit and 
fail. The above video is an example of the latter.

-- 
/Jacob Carlborg
Nov 29 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 13:31:34 UTC, Jacob Carlborg wrote:

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


 Yep, that the goal, having applications with a real 
 personality. I don't
 think it's an issue especially when application is full screen 
 and
 respect pictographs (icons and texts) standards,...


 "real personality", it's more of trying to emulate the native 
 toolkit to fails.


 Having custom UI can help applications to improve ergonomic 
 with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or 
 not,... the
 only things that is important is to let a strong default 
 couple of style
 and ergonomic without adding complexity for users want do some 
 custom
 stuff.


 What is native on windows ?
  - Win32
  - Winforms
  - Qt Widgets (that is near Win32)?

 And on linux ?
  - GTK (with gnome and KDE)
  - Qt QML (KDE future)

 A native UI isn't necessary considered as the standard one, 
 maybe Qt
 have a chance to be a real standard (on many platforms).


 There's one thing in creating a completely new GUI, like games 
 do, and a completely different thing in trying to emulate a 
 native toolkit and fail. The above video is an example of the 
 latter.


It's not about emulating. It's about innovating. And as for the 
features of OSes, say the Preferences dialog on OS X, you could 
always interface to that, and only that. As platforms are 
becoming more diverse (Android, Ubuntu, OS X, Windows, Blackberry 
and whatnot) companies and programmers want a 
write-once-run-everywhere toolkit more than ever. Look at Gtk, 
Textadept even delivers the libraries on OS X. Self-catering is 
becoming more and more important as different OSes are being used.
Nov 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 14:53, Chris wrote:


 It's not about emulating. It's about innovating.


Qt tries to emulate the native toolkit, like it or not.

-- 
/Jacob Carlborg
Nov 29 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 14:14:08 UTC, Jacob Carlborg wrote:

 On 2013-11-29 14:53, Chris wrote:


 It's not about emulating. It's about innovating.


 Qt tries to emulate the native toolkit, like it or not.


I don't think it's necessary to do that. You actually only need a 
small set of widgets (text fields, buttons, menus, tabs etc.) The 
rest is just for show (and to tie programmers to one particular 
platform!). Swing is a good example. There are excellent UI apps 
written in Swing that run everywhere. I use jEdit a lot (not 
exclusively but again and again), and it has everything you need. 
A big advantage is cross-platform consistency. I think this is an 
issue that is under-estimated. This is why I like Textadept and 
jEdit.

Native behavior can still be added as in

version (Windows) {
   menuInWindow;
   preferencesIn("Tools (or Edit?)");
}

version (OSX) {
   menuNotInWindow;
   preferencesIn("Preferences ...");
}

A small set of native interfaces (but no dependence on them!).
Nov 29 2013
prev sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 29/11/2013 14:31, Jacob Carlborg a écrit :

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


 Yep, that the goal, having applications with a real personality. I don't
 think it's an issue especially when application is full screen and
 respect pictographs (icons and texts) standards,...


 "real personality", it's more of trying to emulate the native toolkit to
 fails.


 Having custom UI can help applications to improve ergonomic with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or not,... the
 only things that is important is to let a strong default couple of style
 and ergonomic without adding complexity for users want do some custom
 stuff.


 What is native on windows ?
   - Win32
   - Winforms
   - Qt Widgets (that is near Win32)?

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)

 A native UI isn't necessary considered as the standard one, maybe Qt
 have a chance to be a real standard (on many platforms).


 There's one thing in creating a completely new GUI, like games do, and a
 completely different thing in trying to emulate a native toolkit and
 fail. The above video is an example of the latter.


QML and mostly Qt Quick Controls are really young technologies and 
certainly not finished. The important things of Quick Controls is that 
it provides the default skin of the OS and the correct behaviors, but 
It's preferable to adapt it to import a custom Skin.

Digia certainly think that it's important to simplify the transition 
between old (OS natvie UI) and new (fully custom UI) usages.
Nov 29 2013
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand 
wrote:

 What is native on windows ?
  - Win32
  - Winforms
  - Qt Widgets (that is near Win32)?


I would say Win32. Winforms is mostly a thin wrapper over Win32.
However things get more complicated if you take into account WPF 
(completely new written from scratch UI library which makes your 
app look a bit different and start in just 25 seconds ;) ) and 
Win 8 Metro UI, again based on different mechanisms and having 
completely different look and feel.
Nov 29 2013
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 29/11/2013 18:08, thedeemon a écrit :

 On Thursday, 28 November 2013 at 20:55:02 UTC, Xavier Bigand wrote:

 What is native on windows ?
  - Win32
  - Winforms
  - Qt Widgets (that is near Win32)?


 I would say Win32. Winforms is mostly a thin wrapper over Win32.
 However things get more complicated if you take into account WPF
 (completely new written from scratch UI library which makes your app
 look a bit different and start in just 25 seconds ;) ) and Win 8 Metro
 UI, again based on different mechanisms and having completely different
 look and feel.


So you just tell that on Windows itself there is no real native UI, it 
changes. And now when you use Windows 8 you have some old applications 
based on Win32 UI that looks horrible and not well integrated.
In this case "natives" aren't better.
Nov 29 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-28 21:54, Xavier Bigand wrote:


 Yep, that the goal, having applications with a real personality. I don't
 think it's an issue especially when application is full screen and
 respect pictographs (icons and texts) standards,...

 Having custom UI can help applications to improve ergonomic with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or not,... the
 only things that is important is to let a strong default couple of style
 and ergonomic without adding complexity for users want do some custom
 stuff.


 What is native on windows ?
   - Win32
   - Winforms
   - Qt Widgets (that is near Win32)?

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)

 A native UI isn't necessary considered as the standard one, maybe Qt
 have a chance to be a real standard (on many platforms).


I would say that the native GUI is the one that is installed by default 
and you can always rely on being available. Sure, that may mean multiple 
native GUI's.

-- 
/Jacob Carlborg
Dec 01 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-12-02 at 08:42 +0100, Jacob Carlborg wrote:

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

 Yep, that the goal, having applications with a real personality. I don't
 think it's an issue especially when application is full screen and
 respect pictographs (icons and texts) standards,...




Just beware of creating robots with "Genuine People Personality",
remember Marvin :-)


 Having custom UI can help applications to improve ergonomic with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or not,... the
 only things that is important is to let a strong default couple of style
 and ergonomic without adding complexity for users want do some custom
 stuff.


 What is native on windows ?
   - Win32
   - Winforms
   - Qt Widgets (that is near Win32)?

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)




Both on GNOME certainly.


 A native UI isn't necessary considered as the standard one, maybe Qt
 have a chance to be a real standard (on many platforms).


 
 I would say that the native GUI is the one that is installed by default 
 and you can always rely on being available. Sure, that may mean multiple 
 native GUI's.


Running Debian Unstable or Fedora 19, you have both GTK and Qt. But as
noted in the list above Qt works easily on more platforms.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 02 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 2 December 2013 at 09:49:10 UTC, Russel Winder wrote:

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)




 Both on GNOME certainly.


Erm, no? Stock GNOME is pure GTK, if you have something that 
requires Qt in it, must be some customization done by distro.
Dec 02 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-12-02 at 11:57 +0100, Dicebot wrote:

 On Monday, 2 December 2013 at 09:49:10 UTC, Russel Winder wrote:

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)




 Both on GNOME certainly.


 
 Erm, no? Stock GNOME is pure GTK, if you have something that 
 requires Qt in it, must be some customization done by distro.


GNOME itself is pure GTK certainly. My phrasing was poor. What I should
have written is, what you say, that with Debian and Fedora using GNOME
Qt is still a widget set that is usable. I have a large number of
non-GNOME GUI reliant on Qt, and indeed am using QML myself on this
platform.
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 02 2013
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 2 December 2013 at 11:53:30 UTC, Russel Winder wrote:

 GNOME itself is pure GTK certainly. My phrasing was poor. What 
 I should
 have written is, what you say, that with Debian and Fedora 
 using GNOME
 Qt is still a widget set that is usable. I have a large number 
 of
 non-GNOME GUI reliant on Qt, and indeed am using QML myself on 
 this
 platform.


That does not mean that Qt is by any means "native" for Gnome 
desktop environment so I don't see how it fits discussed context. 
How is that different from using the very same GTK/Qt on Windows?
Dec 02 2013
prev sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 02/12/2013 08:42, Jacob Carlborg a écrit :

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


 Yep, that the goal, having applications with a real personality. I don't
 think it's an issue especially when application is full screen and
 respect pictographs (icons and texts) standards,...

 Having custom UI can help applications to improve ergonomic with
 dedicated behaviors when it's needed.

 D itself isn't limited to one policy, you can do objects or not,... the
 only things that is important is to let a strong default couple of style
 and ergonomic without adding complexity for users want do some custom
 stuff.


 What is native on windows ?
   - Win32
   - Winforms
   - Qt Widgets (that is near Win32)?

 And on linux ?
   - GTK (with gnome and KDE)
   - Qt QML (KDE future)

 A native UI isn't necessary considered as the standard one, maybe Qt
 have a chance to be a real standard (on many platforms).


 I would say that the native GUI is the one that is installed by default
 and you can always rely on being available. Sure, that may mean multiple
 native GUI's.


I think you are right
Dec 02 2013
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 28 November 2013 at 13:30:53 UTC, Luís Marques 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.


This is pure Mac talk.
In Windows the "native" UI elements are so scarce and primitive, 
that most apps with decent UI end up making their own. For 
example, one would assume that UI elements that can be found in 
MS Office are native and can be used in other apps. But they are 
not, Office used its own UI library and never shared it with 
anyone. Ribbon implementation that comes with recent Visual 
Studio is a completely different implementation made by custom 
drawing, mimicking the look of Office. Actually, there are even 
several different implementations, for different languages.
Relying purely on native controls leads nowhere.

And Linux notion of "native" is already discussed and destroyed 
before me.
Nov 29 2013
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 29 November 2013 at 17:03:02 UTC, thedeemon wrote:

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


 This is pure Mac talk.


+1


 In Windows the "native" UI elements are so scarce and 
 primitive, that most apps with decent UI end up making their 
 own. For example, one would assume that UI elements that can be 
 found in MS Office are native and can be used in other apps. 
 But they are not, Office used its own UI library and never 
 shared it with anyone. Ribbon implementation that comes with 
 recent Visual Studio is a completely different implementation 
 made by custom drawing, mimicking the look of Office. Actually, 
 there are even several different implementations, for different 
 languages.
 Relying purely on native controls leads nowhere.


Yes.


 And Linux notion of "native" is already discussed and destroyed 
 before me.
Nov 29 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-29 18:03, thedeemon wrote:


 This is pure Mac talk.
 In Windows the "native" UI elements are so scarce and primitive, that
 most apps with decent UI end up making their own. For example, one would
 assume that UI elements that can be found in MS Office are native and
 can be used in other apps. But they are not, Office used its own UI
 library and never shared it with anyone. Ribbon implementation that
 comes with recent Visual Studio is a completely different implementation
 made by custom drawing, mimicking the look of Office. Actually, there
 are even several different implementations, for different languages.
 Relying purely on native controls leads nowhere.

 And Linux notion of "native" is already discussed and destroyed before me.


That's why Mac OS X is so great, it's consistent :). But Apple creates 
custom controls as well. An example is the tabs available in Safari and 
Xcode. Other applications are trying to emulate them with various 
degrees of success. Path Finder does a very good emulation of Safari tabs.

-- 
/Jacob Carlborg
Nov 29 2013
prev sibling next sibling parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Friday, 29 November 2013 at 17:03:02 UTC, thedeemon wrote:

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


 This is pure Mac talk.
 In Windows the "native" UI elements are so scarce and 
 primitive, that most apps with decent UI end up making their 
 own. For example, one would assume that UI elements that can be 
 found in MS Office are native and can be used in other apps. 
 But they are not, Office used its own UI library and never 
 shared it with anyone. Ribbon implementation that comes with 
 recent Visual Studio is a completely different implementation 
 made by custom drawing, mimicking the look of Office. Actually, 
 there are even several different implementations, for different 
 languages.
 Relying purely on native controls leads nowhere.


You are discussing the creation of custom controls, while I was 
discussing the use of GUI libraries that recreate from scratch 
things like:

   - all controls, even the basic ones
   - UI behaviours (e.g., scrolling, double click times, etc.), 
badly mimicking the native system
   - text rendering, unicode/localization processing, etc.
   - integration with the native accessibility features
   - event processing

Is possible to create custom controls while still playing 
relatively nice with the native UI platform, and thus avoid 
*some* of the problems mentioned, by inhering as much from the 
platform as possible (text rendering, scrolling, accessibility, 
etc.). For Apple platforms the advice is to avoid custom controls 
when possible, which became easier in iOS when the native 
controls became more skinnable. When custom controls are needed 
they still integrate with the platform to a reasonable extent, 
and thus while the *look* may be foreign, the *behaviours* tend 
to feel native.
Nov 29 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/29/13 9:03 AM, thedeemon wrote:

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


 This is pure Mac talk.
 In Windows the "native" UI elements are so scarce and primitive, that
 most apps with decent UI end up making their own. For example, one would
 assume that UI elements that can be found in MS Office are native and
 can be used in other apps. But they are not, Office used its own UI
 library and never shared it with anyone. Ribbon implementation that
 comes with recent Visual Studio is a completely different implementation
 made by custom drawing, mimicking the look of Office. Actually, there
 are even several different implementations, for different languages.
 Relying purely on native controls leads nowhere.


I haven't used Windows in a while, but even years ago Office and MSVC 
were heavy-hitters that notably diverged from Windows' own widgets (and 
even interface design guidelines). These were (and are) immense and 
immensely successful applications that for which designing specific 
widgets was a small incremental cost (and I speculate a way to say "we 
own the OS so we may as well design widgets that nobody else got"). Most 
other Windows program were (and may as well still be, I haven't 
followed) totally fine with the stock widgets.


Andrei
Nov 29 2013
prev sibling parent John J <john.joyus gmail.com> writes:
On 11/28/2013 08:30 AM, "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.


A non-native GUI toolkit should improve their standard / skinnable 
design instead of mimicking the native UI of each OS and spend a lot of 
time in catching up those changing native looks. Even Microsoft changes 
their native look as people get bored with it after a few years. A 
breath of fresh air is always welcome, no matter it's native or non-native.

The reason a non-native UI looks ugly is, when it is ugly on its own, 
without needing any comarision with a native UI.
Nov 29 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 28 2013
prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Nov 28 2013
parent reply John J <john.joyus gmail.com> writes:
On 11/28/2013 02:54 PM, Xavier Bigand wrote:

 Dquick goes in this direction.


It appears DQcuik uses Lua scripts for UI design.

1. Do we have to supply these script files along with the executable or 
do they get compiled into the executable?

2. How is the performance?
Nov 29 2013
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 30/11/2013 06:33, John J a écrit :

 On 11/28/2013 02:54 PM, Xavier Bigand wrote:

 Dquick goes in this direction.


 It appears DQcuik uses Lua scripts for UI design.

 1. Do we have to supply these script files along with the executable or
 do they get compiled into the executable?


Lua script have to be accessible as resources, for the moment we don't 
know if it will be possible to do the same thing completely in D. The 
main difficulty is to make the property binding works, it seams feasible 
but it's not on top on our priorities.


 2. How is the performance?


Performances are similar to Qt when we execute property bindings, My 
friend just do some optimizations.

We have some ideas to increase it a lot.
Nov 30 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-30 22:38, Xavier Bigand wrote:


 Lua script have to be accessible as resources, for the moment we don't
 know if it will be possible to do the same thing completely in D. The
 main difficulty is to make the property binding works, it seams feasible
 but it's not on top on our priorities.


Is it be possible to use string imports to bundle the Lua scripts in the 
executable?

-- 
/Jacob Carlborg
Dec 01 2013
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 02/12/2013 08:44, Jacob Carlborg a écrit :

 On 2013-11-30 22:38, Xavier Bigand wrote:


 Lua script have to be accessible as resources, for the moment we don't
 know if it will be possible to do the same thing completely in D. The
 main difficulty is to make the property binding works, it seams feasible
 but it's not on top on our priorities.


 Is it be possible to use string imports to bundle the Lua scripts in the
 executable?


Actually no, but my friend already planed to add it.
Dec 02 2013
prev sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:

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


DOOGLE[1] currently only depends on libfreetype2, (with Windows 
as only target) Windows API and OpenGL. I would remove 
libfreetype2 but.. its basically standard for font rasterization 
cross platform wise.
I have designed it to have its interface abstracted away from the 
implementation fully.

Its current state is well listed on my blog[2] it may not look 
much now and not ready for production use, but definitely should 
be said.

[1] https://github.com/rikkimax/doogle
[2] 
http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html
Nov 28 2013
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 29/11/2013 04:48, Rikki Cattermole a écrit :

 On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:

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


 DOOGLE[1] currently only depends on libfreetype2, (with Windows as only
 target) Windows API and OpenGL. I would remove libfreetype2 but.. its
 basically standard for font rasterization cross platform wise.
 I have designed it to have its interface abstracted away from the
 implementation fully.

 Its current state is well listed on my blog[2] it may not look much now
 and not ready for production use, but definitely should be said.

 [1] https://github.com/rikkimax/doogle
 [2]
 http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html


You may want take a look to DQuick :
https://github.com/D-Quick/DQuick

It's run on top of openGL too, the main difference is that you describe 
the UI in dedicated script files. Scripts provide allow to provide fully 
dynamical UIs.

An UI file (original lua script format for the moment) :

GraphicItem
{	
     id = "main",

	Image {
		id = "kerningImageButton",
		
		source = "images/border-image.png",
		width = 300,
		height = 50,

		MouseArea {
			id = "kerningButton",
			width = function()
				return kerningImageButton.width
			end,
			height = function()
				return kerningImageButton.height
			end,
		},
	},

	ScrollView {
		id = "scrollView",
	
		y = function()
			return kerningImageButton.height
		end,
		width = function()
			return main.width
		end,
		height = function()
			return main.height - scrollView.y
		end,
		
		clip = true,

		Text {
			id = "text",
		
			wrapMode = Text.WrapMode.WordWrap,
		
			width = function()
				return scrollView.width
			end,
			height = function()
				return scrollView.height
			end,

			text = textFr,
			family = function()
				if (kerningButton.pressed) then
					return "AngsanaUPC"
				end
				return "Arial"
			end,
			fontSize = 24,
			fontStyle = function()
				if (kerningButton.pressed) then
					return Text.FontStyle.Italic
				end
				return Text.FontStyle.Regular
			end,
		},
	},
}
Nov 29 2013
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Friday, 29 November 2013 at 23:46:02 UTC, Xavier Bigand wrote:

 Le 29/11/2013 04:48, Rikki Cattermole a écrit :

 On Thursday, 28 November 2013 at 12:13:42 UTC, Chris wrote:

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


 DOOGLE[1] currently only depends on libfreetype2, (with 
 Windows as only
 target) Windows API and OpenGL. I would remove libfreetype2 
 but.. its
 basically standard for font rasterization cross platform wise.
 I have designed it to have its interface abstracted away from 
 the
 implementation fully.

 Its current state is well listed on my blog[2] it may not look 
 much now
 and not ready for production use, but definitely should be 
 said.

 [1] https://github.com/rikkimax/doogle
 [2]
 http://alphaglosined.blogspot.com/2013/11/web-services-and-opengl-oh-my.html


 You may want take a look to DQuick :
 https://github.com/D-Quick/DQuick

 It's run on top of openGL too, the main difference is that you 
 describe the UI in dedicated script files. Scripts provide 
 allow to provide fully dynamical UIs.

 An UI file (original lua script format for the moment) :

 GraphicItem
 {	
     id = "main",

 	Image {
 		id = "kerningImageButton",
 		
 		source = "images/border-image.png",
 		width = 300,
 		height = 50,

 		MouseArea {
 			id = "kerningButton",
 			width = function()
 				return kerningImageButton.width
 			end,
 			height = function()
 				return kerningImageButton.height
 			end,
 		},
 	},

 	ScrollView {
 		id = "scrollView",
 	
 		y = function()
 			return kerningImageButton.height
 		end,
 		width = function()
 			return main.width
 		end,
 		height = function()
 			return main.height - scrollView.y
 		end,
 		
 		clip = true,

 		Text {
 			id = "text",
 		
 			wrapMode = Text.WrapMode.WordWrap,
 		
 			width = function()
 				return scrollView.width
 			end,
 			height = function()
 				return scrollView.height
 			end,

 			text = textFr,
 			family = function()
 				if (kerningButton.pressed) then
 					return "AngsanaUPC"
 				end
 				return "Arial"
 			end,
 			fontSize = 24,
 			fontStyle = function()
 				if (kerningButton.pressed) then
 					return Text.FontStyle.Italic
 				end
 				return Text.FontStyle.Regular
 			end,
 		},
 	},
 }


I know, I've kept an eye on all other GUI toolkits since I 
started work. I'm currently sticking to just plain old class 
objects to build it primarily because of a) efficiency and b) 
extra dependencies.
Eventually there will be a meta based system to configure it. But 
that'll come when I'll start on an IDE.
Nov 29 2013
prev sibling parent "thedeemon" <dlang thedeemon.com> writes:
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 don't know which OS you're interested in, but for Windows I 
enjoyed using DFL, it's pretty good, easy to use and still 
maintained:
https://github.com/Rayerd/dfl
Nov 29 2013