Windows UI

[Radu - Ionut Kurta]

Hello,

I'm curios if for qt5 would it be possible to implement some sort of desktop
components like the ones available now for qml but mimic
the metro look of windows 8 for usage on windows(and if possible maybe on
also desktop platforms).

Thanks,
Radu

[Artur Souza (MoRpHeUz)]

Hello Radu,

On Wed, Sep 21, 2011 at 5:03 AM, Radu - Ionut Kurta

Post by Radu - Ionut Kurta
I'm curios if for qt5 would it be possible to implement some sort of desktop
components like the ones available now for qml but mimic
the metro look of windows 8 for usage on windows(and if possible maybe on
also desktop platforms).

Yes, there is nothing preventing us (you included :) ) to do that and
probably at some point the community is going to implement that.

Besides having that, what I would really like is that we have a
"component set" (at some point in the future I would like to be able
to start calling them "widgets" again, as this is what they are) that
is the same on all platforms.

So, from my point of view we would have:

1 - platform specific qml widgets (I don't care if technically the
desktop widgets share the same implementation and use the QStyle API
to draw them the way they should be - that's actually a good way to
go);

2 - The "Qt set" (that ideally would be qt's default offer - that
works on all the platforms, enabling us to write applications that
would behave and look like the same on all platforms).

IMHO, number 2 is important to allow Qt developers to easily write
cross platform applications without the need to be bounded to specific
platform-widget API/behavior. For example, one would be able to write
an application that would run on linux/windows/osx, knowing that this
widget set would be available in all of them. Of course, the developer
wouldn't be able to use any platform specific API.

Ah, it's worth mentioning that these widgets should be designed and
draw by real designers and not by us (developers). Even if we think
that we have designer skills, we don't ;)

Cheers,

[Radu - Ionut Kurta]

I agree and I and probably other people will be glad in helping out
developing these widgets, now where do we find a designer ? :)

On Wed, Sep 21, 2011 at 11:31 AM, Artur Souza (MoRpHeUz) <

Post by Artur Souza (MoRpHeUz)
Hello Radu,
On Wed, Sep 21, 2011 at 5:03 AM, Radu - Ionut Kurta

Post by Radu - Ionut Kurta
I'm curios if for qt5 would it be possible to implement some sort of

desktop

Post by Radu - Ionut Kurta
components like the ones available now for qml but mimic
the metro look of windows 8 for usage on windows(and if possible maybe on
also desktop platforms).

Yes, there is nothing preventing us (you included :) ) to do that and
probably at some point the community is going to implement that.
Besides having that, what I would really like is that we have a
"component set" (at some point in the future I would like to be able
to start calling them "widgets" again, as this is what they are) that
is the same on all platforms.
1 - platform specific qml widgets (I don't care if technically the
desktop widgets share the same implementation and use the QStyle API
to draw them the way they should be - that's actually a good way to
go);
2 - The "Qt set" (that ideally would be qt's default offer - that
works on all the platforms, enabling us to write applications that
would behave and look like the same on all platforms).
IMHO, number 2 is important to allow Qt developers to easily write
cross platform applications without the need to be bounded to specific
platform-widget API/behavior. For example, one would be able to write
an application that would run on linux/windows/osx, knowing that this
widget set would be available in all of them. Of course, the developer
wouldn't be able to use any platform specific API.
Ah, it's worth mentioning that these widgets should be designed and
draw by real designers and not by us (developers). Even if we think
that we have designer skills, we don't ;)
Cheers,
--
-------------------------------------------------------
Artur Duque de Souza
openBossa
INdT - Instituto Nokia de Tecnologia
-------------------------------------------------------
Blog: http://blog.morpheuz.cc
-------------------------------------------------------

[Artur Souza (MoRpHeUz)]

On Wed, Sep 21, 2011 at 5:50 AM, Radu - Ionut Kurta

I agree and I and probably other people will be glad in helping out
developing these widgets, now where do we find a designer ? :)

Give me a few weeks and I'll probably be able to get the help from a
professional designer to do this :)

Cheers,

[j***@nokia.com]

Post by Artur Souza (MoRpHeUz)
Besides having that, what I would really like is that we have a
"component set" (at some point in the future I would like to be able
to start calling them "widgets" again, as this is what they are) that
is the same on all platforms.

I also secretly call them widgets out of habit. However the distinction is probably useful as to not confuse them with the widget toolkit that will still live side by side with Qt Quick. Perhaps we could use the name "Control" to separate interactive elements from just any Qt Quick component.

Post by Artur Souza (MoRpHeUz)
1 - platform specific qml widgets (I don't care if technically the
desktop widgets share the same implementation and use the QStyle API
to draw them the way they should be - that's actually a good way to
go);
2 - The "Qt set" (that ideally would be qt's default offer - that
works on all the platforms, enabling us to write applications that
would behave and look like the same on all platforms).

I suspect Metro and the Qt set are two rather different things. Metro seems to belong more in category with IOS and Android components than desktop but I have yet to try a Metro enabled application…

The QtDesktop components will most likely map to the traditional windows apps. However even within the Qt Desktop components, I think we will have to add a set of platform specific widgets such as SearchEdit on the mac etc.

Post by Artur Souza (MoRpHeUz)
Ah, it's worth mentioning that these widgets should be designed and
draw by real designers and not by us (developers). Even if we think
that we have designer skills, we don't ;)

I disagree. These widgets should be rendered natively by their respective operating systems as far as it is possible. :)

Cheers,

Jens Bache-Wiig

[Artur Souza (MoRpHeUz)]

Post by j***@nokia.com
I disagree. These widgets should be rendered natively by their respective operating systems as far as it is possible. :)

I agree that for item (1) they should be rendered natively as far as
it possible. I was referring to item (2).

Cheers,

[BRM]

----- Original Message -----

Sent: Wednesday, September 21, 2011 9:05 AM
Subject: Re: [Qt5-feedback] Windows UI

Post by j***@nokia.com
I disagree. These widgets should be rendered natively by their respective

operating systems as far as it is possible. :)
I agree that for item (1) they should be rendered natively as far as
it possible. I was referring to item (2).

One of the biggest attractions to using Qt is the fact that it integrates natively. So I would say that #2 needs to as well.

I honestly don't get the whole Java-like mindset that the application needs to look the same on all platforms.

For the best usability, the application should integrate natively into every platform - so it will look different on Mac, WIndows, X11, Wayland, KDE, GNOME, etc.
But the general usability will remain consistent on all platforms.
That is the strength and draw for Qt.

$0.02

Ben

[Artur Souza (MoRpHeUz)]

Post by BRM
One of the biggest attractions to using Qt is the fact that it integrates natively. So I would say that #2 needs to as well.
I honestly don't get the whole Java-like mindset that the application needs to look the same on all platforms.
For the best usability, the application should integrate natively into every platform - so it will look different on Mac, WIndows, X11, Wayland, KDE, GNOME, etc.
But the general usability will remain consistent on all platforms.
That is the strength and draw for Qt.

That's why I think that #1 should exist anyway: it covers the exact
use case you mentioned.

But from my experience it seems that #1 can only be achieved on
desktop platforms, but it's really really hard to achieve it on mobile
platforms (tables and phones).

This happens because the behavior is so different from one platform to
another that is almost impossible to cover all the use cases and still
have a good API. Compare iOS, Android and MeeGo for example.
Comboboxes don't just look different but also have completely
different behavior and some platforms have some widgets that others
don't.

In order to solve this issue, I think that a good way is for Qt to
provide a minimum qml widget set that is good enough for the
day-to-day development and this would enable the dev to create a real
cross platform application.

For desktops, I really think that #1 is the way to go and completely
agree with your statement. But I think that #2 is valid use case that
we should try to solve as well.

Cheers,

[Adriano Rezende]

Post by j***@nokia.com

Post by Artur Souza (MoRpHeUz)
1 - platform specific qml widgets (I don't care if technically the
desktop widgets share the same implementation and use the QStyle API
to draw them the way they should be - that's actually a good way to
go);
2 - The "Qt set" (that ideally would be qt's default offer - that
works on all the platforms, enabling us to write applications that
would behave and look like the same on all platforms).

I suspect Metro and the Qt set are two rather different things. Metro seems
to belong more in category with IOS and Android components than desktop but
I have yet to try a Metro enabled application…
The QtDesktop components will most likely map to the traditional windows
apps. However even within the Qt Desktop components, I think we will have to
add a set of platform specific widgets such as SearchEdit on the mac etc.

I agree. We need to have two different widget sets, one for desktop and
another one for mobile. The desktop widgets would basically mimic the old
QWidget behavior regarding styling and common properties; it would have good
integration with any platform if using internally the QStyle machinery
(maybe with some improvements? :)). Also, we would need to provide real
layout, with minimumSize and maximumSize properties, for the desktop widget
set or add this support in QML.

The mobile components, on the other side, need some tradeoffs. At this time,
I think it's a bit utopic to think over a common API that integrates well on
any mobile platform without workarounds, and I'm just considering Symbian
and Meego. A good way to go would be to choose one platform to be the
official one or create a trolltech official's one. I think, with that move,
the design team of other platforms would try to think in flows that is
compliant with the official API.

BTW, Symbian design seems more and more similar to the Meego design.


Cheers,
Adriano

[Adriano Rezende]

On Wed, Sep 21, 2011 at 1:15 PM, Adriano Rezende <

Post by Adriano Rezende

Post by j***@nokia.com

Post by Artur Souza (MoRpHeUz)
1 - platform specific qml widgets (I don't care if technically the
desktop widgets share the same implementation and use the QStyle API
to draw them the way they should be - that's actually a good way to
go);
2 - The "Qt set" (that ideally would be qt's default offer - that
works on all the platforms, enabling us to write applications that
would behave and look like the same on all platforms).

I suspect Metro and the Qt set are two rather different things. Metro
seems to belong more in category with IOS and Android components than
desktop but I have yet to try a Metro enabled application…
The QtDesktop components will most likely map to the traditional windows
apps. However even within the Qt Desktop components, I think we will have to
add a set of platform specific widgets such as SearchEdit on the mac etc.

I agree. We need to have two different widget sets, one for desktop and
another one for mobile. The desktop widgets would basically mimic the old
QWidget behavior regarding styling and common properties; it would have good
integration with any platform if using internally the QStyle machinery
(maybe with some improvements? :)). Also, we would need to provide real
layout, with minimumSize and maximumSize properties, for the desktop widget
set or add this support in QML.

Looking at the qt-components repo it seems quite mature the desktop
components. Is there a roadmap in some place?

Regards,
Adriano

[j***@nokia.com]

Looking at the qt-components repo it seems quite mature the desktop components. Is there a roadmap in some place?

I am afraid not. I still consider this a research project, but we are planning to ramp up priorities and manpower later this year. Then we can start detailed planning.
However, the state of the project is as you say is already rather good and it is designed to work with Qt 4.7.4 so people can actually pick it up and use it right now.

I have created a list of known to-do things out of the top of my head here:

Basic missing and required features:
- Create new DateTimeEdit and calendar Components
- Create Standard Dialogs / Integrate with native dialogs
- General work on bugs and missing features
- Add Support for Tree Views (Hard to do without hacks or extending Qt Quick)

Highly desired:
- Write more examples and applications to verify and test the API
- Improve Item View performance
- Improve Documentation
- Work on a test framework
- Integrate into the Qt Creator designer (partially working already)

Things that could need improvement and more research:
- Research how to deal with file IO and System Settings
- Research Layouts. (I am still not sure if creating new QML Layouts are really required, but I would love to see some research on this. Dynamic spacing between different controls is one issue that we do not have a solution for.)
- Research how to deal with Actions. Do we need a new Component for it? Can we extend the action support already in Qt Quick?
- Research how to deal with shortcut scopes
- Research a more abstract ToolBar/Action based API so we could potentially support unified tool bars on mac natively.
- Research how to deal with native windows, popups and menus in Qt5 without depending on widgets
- Refactor QStyle for Qt5 to remove the QWidget dependency

Let me know if you are interested in helping out with any of these issues.

Regards,
Jens bache-Wiig

[Adriano Rezende]

Post by j***@nokia.com
- Add Support for Tree Views (Hard to do without hacks or extending Qt Quick)

I agree. I think TreeView and TableView components need to be
implemented in C++ as a plugin extension or as new components in
QtQuick2. The problem of the first approach is that we would end up
duplicating code to avoid some QML private header dependencies, like
the Flickable API.
Currently, I'm mimicking TableView elements using ListView with
special delegates, like qt-components, but that seems unnatural and it
also generates a great overhead due the delegates' bindings.

Post by j***@nokia.com
- Write more examples and applications to verify and test the API

More examples would be nice.
I think as soon as all the missing features are solved more
applications will come.

Post by j***@nokia.com
- Research Layouts.  (I am still not sure if creating new QML Layouts are really required, but I would love to see some research on this. Dynamic spacing between different controls is one issue that we do not have a solution for.)

A proof-of-concept would be great on this area. Currently, I'm stuck
with some project deadlines, but I think I can look on this in my
spare time.

Post by j***@nokia.com
- Refactor QStyle for Qt5 to remove the QWidget dependency

It would be really nice if this dependency could be removed.
Probably a new style API that renders in a QImage would suffice; using
that image to generate a GL texture in the end. Do you have any
thoughts on this?


Br,
Adriano