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.

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

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.

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

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

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

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.

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

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?

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.