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?"

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

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.

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

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

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

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.

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.

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.

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