Re: [Development] Window{} API for QML
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
Window{ //Not inheriting QQuickItem, creates a new top level window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait, Landscape, Š
}
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
Whoops, that should be http://codereview.qt-project.org/#change,9352 in
qtdeclarative.
I think it's in a good shape for an initial API.
Some missing features can be added later, like min/max size, modality and so on.
Is the Window module really necessary. I think it's a bit redundant to
have Window.Window { }.
Br,
Adriano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Mon, 21 Nov 2011 23:49:27 you wrote:
Mandag 21. november 2011 17.31.30 skrev ext Alan Alpert:
On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
If we mostly agree, then that's a good starting point. I'll start
prototyping a Window{} with the following minimal API in a
QtQuick.Window import (unless someone has a better idea for the
name, as this import could also contain the exposed Screen stuff
that is highly related).
Window{ //Not inheriting QQuickItem, creates a new top level window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait,
Landscape, Š }
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
Whoops, that should be http://codereview.qt-project.org/#change,9352 in
qtdeclarative.
Hi Alan,
I just had a quick look and I'm really looking forward to this kind of qml
element.
I'm a bit puzzled though, this api seems a little to limited for desktop
(no min/max size).
For mobile on the other hand, why would you need x and y?
You'll need an x/y for any form of positioning, so it seems like an essential
- if you were just using the one fullscreen window like the average app you
wouldn't need this element anyways.
But this is just a starting point for the API. Presumably anything else needed
for desktop can be exposed from QWindow later. While we need to be more
careful about adding properties and API to QWindow if it is also exposed to
QML, we certainly can still add that which is necessary.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Tue, 22 Nov 2011 00:50:28 you wrote:
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
Window{ //Not inheriting QQuickItem, creates a new top level window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait,
Landscape, Š }
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
Whoops, that should be http://codereview.qt-project.org/#change,9352 in
qtdeclarative.
I think it's in a good shape for an initial API.
Some missing features can be added later, like min/max size, modality and
so on.
Is the Window module really necessary. I think it's a bit redundant to
have Window.Window { }.
It's a lot redundant, I was just exaggerating it for the examples. Obviously
normal use will be merely
import QtQuick.Window 2.0
Window{
}
But the ability to create new top-level windows sounds like the sort of thing
you might want to turn off in some cases (e.g. if you're writing an
application scriptable in QML). Making it a separate import makes it easier to
turn off later.
Yes, I mean if QtQuick2 is designed to reduce memory footprint for
non-ui applications it makes sense to keep UI components in a separate
module. I'm just arguing that if the Window module will just contain
the Window component, it wouldn't worth it to keep this component in a
separate module, since there are other UI components much less useful
like the Flipable and the Flow components.
Br,
Adriano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
IOW, something like:
import QtQuick 2.0 // or QtQuick.UI 2.0 (if it makes sense)
Window {
}
- Adriano
2011/11/21 Adriano Rezende adriano.reze...@openbossa.org:
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Tue, 22 Nov 2011 00:50:28 you wrote:
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
Window{ //Not inheriting QQuickItem, creates a new top level window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait,
Landscape, Š }
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
Whoops, that should be http://codereview.qt-project.org/#change,9352 in
qtdeclarative.
I think it's in a good shape for an initial API.
Some missing features can be added later, like min/max size, modality and
so on.
Is the Window module really necessary. I think it's a bit redundant to
have Window.Window { }.
It's a lot redundant, I was just exaggerating it for the examples. Obviously
normal use will be merely
import QtQuick.Window 2.0
Window{
}
But the ability to create new top-level windows sounds like the sort of thing
you might want to turn off in some cases (e.g. if you're writing an
application scriptable in QML). Making it a separate import makes it easier
to
turn off later.
Yes, I mean if QtQuick2 is designed to reduce memory footprint for
non-ui applications it makes sense to keep UI components in a separate
module. I'm just arguing that if the Window module will just contain
the Window component, it wouldn't worth it to keep this component in a
separate module, since there are other UI components much less useful
like the Flipable and the Flow components.
Br,
Adriano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Tue, 22 Nov 2011 00:50:28 you wrote:
2011/11/21 Alan Alpert alan.alp...@nokia.com:
On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
Window{ //Not inheriting QQuickItem, creates a new top level
window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait,
Landscape, Š }
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
Whoops, that should be http://codereview.qt-project.org/#change,9352
in qtdeclarative.
I think it's in a good shape for an initial API.
Some missing features can be added later, like min/max size, modality
and so on.
Is the Window module really necessary. I think it's a bit redundant to
have Window.Window { }.
It's a lot redundant, I was just exaggerating it for the examples.
Obviously normal use will be merely
import QtQuick.Window 2.0
Window{
}
But the ability to create new top-level windows sounds like the sort of
thing you might want to turn off in some cases (e.g. if you're writing
an application scriptable in QML). Making it a separate import makes it
easier to turn off later.
Yes, I mean if QtQuick2 is designed to reduce memory footprint for
non-ui applications it makes sense to keep UI components in a separate
module. I'm just arguing that if the Window module will just contain
the Window component, it wouldn't worth it to keep this component in a
separate module, since there are other UI components much less useful
like the Flipable and the Flow components.
QtQuick 2 is designed for GUI applications only. If you don't want a GUI, then
you shouldn't have to import QtQuick 2 at all in your QML application. And we
do segregate some large groups of components for footprint reasons, like how
QtQuick.Particles 2.0 is separated until you want particle effects.
But the Window{} element is segregated because you'll want more control over
it. Let's say no-one ever uses Flow, but there's still no harm to being able
to create a Flow{} if you're feeling quirky that day.
Imagine that you are using QML as a scripting language for your application.
It allows someone to place MyApp.Button{} where ever they want on the input
form. It's reasonable to allow other graphical primitives in there, like a
Rectangle{}, but you don't want them to create a new Window{} and spoof the
main view of the application (no need to make malicious scripts easy). It
hasn't been implemented yet but it should be possible to say, if you control
the QDeclarativeEngine, allow just these modules: MyApp.*, QtQuick 2.0 and
QtQuick.Particles 2.0. That way you have a more controlled scripting
environment that doesn't open your application to the problems of scripts
creating new windows or loading arbitrary C++ plugins.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Tue, 15 Nov 2011 19:30:59 you wrote:
On 15/11/11 10.24, ext Alan Alpert alan.alp...@nokia.com wrote:
On Fri, 11 Nov 2011 15:58:56 ext Alan Alpert wrote:
On Thu, 10 Nov 2011 18:29:58 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
On 11/10/11 1:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything.
Here's
my thoughts:
We need a Window {} element to create surfaces on a physical
screen.
This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit
the Window {} API to the mobile use cases. I'd rather that we
expose
the
full
functionality in one Object, and rather document some of the
differences in behavior between mobile and desktop.
If we mostly agree, then that's a good starting point. I'll start
prototyping
a Window{} with the following minimal API in a QtQuick.Window import
(unless
someone has a better idea for the name, as this import could also contain
the
exposed Screen stuff that is highly related).
Window{ //Not inheriting QQuickItem, creates a new top level window.
property string title
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait, Landscape, Š
}
}
If we get a requested orientation, it would be really nice if it possible
to also get the final sizes (after orientation change). Basically for a
web browser, we want to know that a orientation change is requested. Use
the new sizes to relayout and set up our animation states, then do the
actual orientation change.
As far as I'm aware, this has nothing to do with the orientation change
itself. This is a hint to the windowmanager that you can set when you want the
orientation for this window to be locked to a certain value. The actual change
is notified somewhere else, presumably by the screen, and is not associated
with the window.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Tue, 15 Nov 2011 19:24:50 ext Alan Alpert wrote:
If we mostly agree, then that's a good starting point. I'll start
prototyping a Window{} with the following minimal API in a QtQuick.Window
import (unless someone has a better idea for the name, as this import
could also contain the exposed Screen stuff that is highly related).
Window{ //Not inheriting QQuickItem, creates a new top level window.
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait, Landscape, Š }
}
http://codereview.qt-project.org/#change,9258 in qtdeclarative and
http://codereview.qt-project.org/#change,9254 in qtbase
contains said prototype.
It takes the approach of exposing QQuickCanvas, a QWindow subclass, to QML.
This allows the window properties to be exposed directly from QWindow, which
has advantages and disadvantages. There is the advantage that the properties
are used directly and there's no indirection layer in the way increasing
maintenance and decreasing performance. But it has the downside of making
QWindow public QML API which means even more care needs to be taken when
altering it, as it needs to make sense in QML and C++ - not to mention follow
the QML version compatibility rules on top of the C++ ones.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Fri, 11 Nov 2011 15:58:56 ext Alan Alpert wrote:
On Thu, 10 Nov 2011 18:29:58 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
On 11/10/11 1:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything.
Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen.
This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit
the Window {} API to the mobile use cases. I'd rather that we expose
the
full
functionality in one Object, and rather document some of the
differences in behavior between mobile and desktop.
If we mostly agree, then that's a good starting point. I'll start prototyping
a Window{} with the following minimal API in a QtQuick.Window import (unless
someone has a better idea for the name, as this import could also contain the
exposed Screen stuff that is highly related).
Window{ //Not inheriting QQuickItem, creates a new top level window.
property string title
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait, Landscape, Š }
}
This gives us something to start with, since I don't think we're at the API
freeze for Qt 5 just yet :) . It's also enough for creating new surfaces in
QML, and ensures we can at least do that.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On 15/11/11 10.24, ext Alan Alpert alan.alp...@nokia.com wrote:
On Fri, 11 Nov 2011 15:58:56 ext Alan Alpert wrote:
On Thu, 10 Nov 2011 18:29:58 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
On 11/10/11 1:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything.
Here's
my thoughts:
We need a Window {} element to create surfaces on a physical
screen.
This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit
the Window {} API to the mobile use cases. I'd rather that we
expose
the
full
functionality in one Object, and rather document some of the
differences in behavior between mobile and desktop.
If we mostly agree, then that's a good starting point. I'll start
prototyping
a Window{} with the following minimal API in a QtQuick.Window import
(unless
someone has a better idea for the name, as this import could also contain
the
exposed Screen stuff that is highly related).
Window{ //Not inheriting QQuickItem, creates a new top level window.
property string title
property int x
property int y
property int width
property int height
property bool visible
property Orientation requestedOrientation // { Portrait, Landscape, Š
}
}
If we get a requested orientation, it would be really nice if it possible
to also get the final sizes (after orientation change). Basically for a
web browser, we want to know that a orientation change is requested. Use
the new sizes to relayout and set up our animation states, then do the
actual orientation change.
Kenneth
This gives us something to start with, since I don't think we're at the
API
freeze for Qt 5 just yet :) . It's also enough for creating new surfaces
in
QML, and ensures we can at least do that.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Fri, Nov 11, 2011 at 2:45 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote:
I think the Window element should not inherit from QQuickItem, since
it's not an element in the render tree; it's basically a window
representation that is not affected by parent transformations or
effective opacity. The anchors feature is not a big advantage if it
brings to an API bloat; one could also achieve the same results
creating a wrapper like the following:
Item {
anchors.fill: parent
Window {
x: // map to global
y: // map to global
What do you mean here by 'map to global'? If x/y are global coordinates, then
the anchors won't work because the x/y are set by anchors assuming relative
coordinates. But relative coordinates make no sense if it's not affected by
parent transformations (although you have a point that it probably shouldn't
be).
Well, I'm ignoring parent transformations (rotation, translation, ...)
since it would be a strange behavior to apply rotation to a
sub-window, just because it's 'embedded' in a rotated item. As I see
the Window should not be dictated by local scene transformations.
The anchors would affect just the wrapper's coordinates. If Window
position must be defined as global coordinates we should map (item.x,
item.y) to global. The problem is that this kind of binding would have
a high cost, since we would need to track position changes in all
parent hierarchy in order to keep the global coordinates updated, so
it would be better to set these properties just before opening the
window.
The problem I see with the QQuickItem inheritance is that it brings a
lot of features that would have null effect on a Window unless they
are properly addressed (which is a hard task). Consider the following
use case:
Window {
rotation: 30 // will we support window rotation?
clip: false // what this would mean ?
anchors.fill: parent // It would be really binded to a different
scene coordinate? The user would loose control over x,y Window
position?
}
Internally the Window element could create a (or maybe inherit from)
QQuickCanvas or QQuickView and move its children to a root contentItem
like the Flickable API.
This would provide a more symmetric (and QML oriented) API, since we
could do something like:
// main.qml
Window { // top level window
Item {
Window { // sub window
}
}
}
I can see how it's a bit more symmetric, but doesn't it mean that every Window
must have exactly one child item, which will almost always be an Item{}?
One thing I liked about having Window{} be a QQuickItem was that it had the
one root Item{} built in for convenience. Then you can have multiple children
and anchor to parent and other stuff that requires an Item{} (which you just
manually create if it isn't built in). This invisible Item{} though is what
places it in the render tree.
Yes, the Window would have internally a root Item that will be the
real parent of its children. But the user wouldn't need to create this
Item explicitly, it could work like the Flickable API. So, the
following declaration would work:
Window {
Rectangle { id: rect1; anchors.fill: parent }
Rectangle { id: rect2; anchors.fill: parent }
}
Internally these two items would be parented to Window.contentItem,
but in order to work, the parent should be set before evaluating the
bindings (the anchors in this case).
Br,
Adriano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On 11/10/11 1:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything.
Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen.
This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit the
Window {} API to the mobile use cases. I'd rather that we expose the
full
functionality in one Object, and rather document some of the differences
in behavior between mobile and desktop.
I'm wary of trying to expose desktop APIs for desktop use cases,
especially
before Desktop QML is fully realized. We might end up exposing the wrong
then
and then we're at the same point as before plus we're maintaining and
supporting use-impaired code. I'm also not fond of providing an element
for
use in mobile contexts with functionality that basically says: Don't use
this. If it's not to be used on those platforms, why even have it
available
for those platforms?
I think we have quite some stuff to test it. Jens desktop components are
IMO enough to test all the concepts required in terms of handling top
level windows for the desktop.
As far as I'm aware there is a lot of features in this gap. Window
decorations, modality, even geometry could be construed as desktop only.
Depends. And don't forget there are also devices such as tablets that are
something between desktop and mobile devices.
Using the Window {} object anywhere in QML creates a new top level
window.
This implies that a Window{} as the root item of a QQuickView would
create
an empty QQuickView and a second top-level created through the WIndow
object. But at least this would mean there's no magic involved.
Yep.
Like that we can change the default way of using QML to be symmetric
between Desktop and Mobile. You instantiate a QQuickEngine, and then
load
a QML file that contains a WIndow {} as the outermost element. If we
remove the Window {} in QtComponents and use this instead, we can then
make this fully symmetrical on the QML side between desktop and mobile.
The only difference would be in the default behavior of Window (most
likely full screen on mobile, windowed on desktop).
One of the changes talked about on the qt-components mailing list is that
with
this approach you no longer have a Window{} as the outermost element in
desktop components.
Why not? If you start a QQuickEngine instead of a View, then the Window{}
can still be the outermost element. In fact this would IMO give us
something more consistent. Of course you can still do a QQuickView
directly, but then you don't have a Window as the outermost element
anymore.
I would rather have the C++ controlled windows exposed manually through
C++
and have the QML Window{}'s separate. This sounds easily exposed through
ApplicationWindow{} anyways.
Not sure I understand what you mean here. If you use a QQuickWindow from
C++, you also control it from C++. If you use a QML Window{} you can
control it form QML.
Differentiation between mobile and desktop can then happen on the
ApplicationWindow level in QtComponents, where the ApplicationWindow for
the desktop would support menu- and toolbars, the mobile version would
support pages and whatever else is needed there.
In addition, it should be easy to associate a Window {} with a certain
physical screen. For this I'd propose, we somehow expose the list of
screens as objects in Qt.application, and give Window {} a screen
property
that can be bound to a screen.
So
Window {
screen: Qt.application.primaryScreen // the default behavior
}
would create a Window on the primary screen.
The main question I'm unsure about is what to do with Windows on screens
that are going away (by unplugging the VGA cable going to the
projectorŠ).
I've been thinking about the screen issue, and my conclusion was that
this
approach wouldn't work. Exposing the screens this way through
Qt.application
wasn't deemed useful in the QScreen API thread, and a lot of the same
problems
arise here. Aside from the primary screen, it will be very difficult to
bind
this window to the right other screen, you can't just go off of list
index
(except perhaps in the common case of external displays) so you need to
query
the new screens on screenAdded/startup and imperatively assign windows.
If
you're going to do it the imperative way anyways, you may as well do it
in C++
and just move Window{} objects out of the main QML file into another
canvas
(that way they were created in the same engine and have useful bindings).
I tend to disagree. The reason is that you don't want to do many of these
things from C++. I agree that an imperative API is not ideal, but we're
having similar things in e.g. the PageStack.
So here's my suggestion for what would work. Leave the general case for
C++
Re: [Development] Window{} API for QML
On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
Given that there can be Desktop Components providing the full API for desktop
windows (and this is being discussed on the qt-components ML already), I
propose the following minimal Window{} API for QML core (i.e. inside the
QtDeclarative library)
Window {//Inherits QQuickItem
property string title: untitled
property bool fullscreen: true
property int x
property int y
property int width
property int height
property bool visible
}
Now this item would end up being reparented into another QQuickCanvas on
another window after being created in the same engine as the main file. This
allows bindings to work between windows just fine. Because of the reparenting
though there are a few changes from QQuickItem which is why I've duplicated
x/y/width/height/visible. Arguably it shouldn't be a QQuickItem because of
this, but I think the easy access to anchors is worth it.
I think the Window element should not inherit from QQuickItem, since
it's not an element in the render tree; it's basically a window
representation that is not affected by parent transformations or
effective opacity. The anchors feature is not a big advantage if it
brings to an API bloat; one could also achieve the same results
creating a wrapper like the following:
Item {
anchors.fill: parent
Window {
x: // map to global
y: // map to global
width: parent.width
height: parent.height
}
}
Internally the Window element could create a (or maybe inherit from)
QQuickCanvas or QQuickView and move its children to a root contentItem
like the Flickable API.
This would provide a more symmetric (and QML oriented) API, since we
could do something like:
// main.qml
Window { // top level window
Item {
Window { // sub window
}
}
}
The view could also be retrieved from the C++ side like the following:
QQuickView *view = QQuickView::loadFromFile(main.qml);
Br,
Adriano
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote:
On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
Given that there can be Desktop Components providing the full API for
desktop windows (and this is being discussed on the qt-components ML
already), I propose the following minimal Window{} API for QML core
(i.e. inside the QtDeclarative library)
Window {//Inherits QQuickItem
property string title: untitled
property bool fullscreen: true
property int x
property int y
property int width
property int height
property bool visible
}
Now this item would end up being reparented into another QQuickCanvas on
another window after being created in the same engine as the main file.
This allows bindings to work between windows just fine. Because of the
reparenting though there are a few changes from QQuickItem which is why
I've duplicated x/y/width/height/visible. Arguably it shouldn't be a
QQuickItem because of this, but I think the easy access to anchors is
worth it.
I think the Window element should not inherit from QQuickItem, since
it's not an element in the render tree; it's basically a window
representation that is not affected by parent transformations or
effective opacity. The anchors feature is not a big advantage if it
brings to an API bloat; one could also achieve the same results
creating a wrapper like the following:
Item {
anchors.fill: parent
Window {
x: // map to global
y: // map to global
What do you mean here by 'map to global'? If x/y are global coordinates, then
the anchors won't work because the x/y are set by anchors assuming relative
coordinates. But relative coordinates make no sense if it's not affected by
parent transformations (although you have a point that it probably shouldn't
be).
width: parent.width
height: parent.height
}
}
Internally the Window element could create a (or maybe inherit from)
QQuickCanvas or QQuickView and move its children to a root contentItem
like the Flickable API.
This would provide a more symmetric (and QML oriented) API, since we
could do something like:
// main.qml
Window { // top level window
Item {
Window { // sub window
}
}
}
I can see how it's a bit more symmetric, but doesn't it mean that every Window
must have exactly one child item, which will almost always be an Item{}?
One thing I liked about having Window{} be a QQuickItem was that it had the
one root Item{} built in for convenience. Then you can have multiple children
and anchor to parent and other stuff that requires an Item{} (which you just
manually create if it isn't built in). This invisible Item{} though is what
places it in the render tree.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Thu, 10 Nov 2011 18:29:58 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
On 11/10/11 1:32 AM, Alan Alpert alan.alp...@nokia.com wrote:
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything.
Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen.
This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit the
Window {} API to the mobile use cases. I'd rather that we expose the
full
functionality in one Object, and rather document some of the differences
in behavior between mobile and desktop.
I'm wary of trying to expose desktop APIs for desktop use cases,
especially
before Desktop QML is fully realized. We might end up exposing the wrong
then
and then we're at the same point as before plus we're maintaining and
supporting use-impaired code. I'm also not fond of providing an element
for
use in mobile contexts with functionality that basically says: Don't use
this. If it's not to be used on those platforms, why even have it
available
for those platforms?
I think we have quite some stuff to test it. Jens desktop components are
IMO enough to test all the concepts required in terms of handling top
level windows for the desktop.
Testing it is not the problem. The problem is understanding the needs and use-
cases of desktop QML, of which one research project is not a full sampling.
The approach of QML development so far has been conservative and use-case
driven development. Not putting in features, which would have to be
maintained, unless there is an important use-case which requires such
features. You can always drop down to C++ to do things that aren't exposed to
QML, and I think that's just fine (and necessary while QML is still
developing).
As far as I'm aware there is a lot of features in this gap. Window
decorations, modality, even geometry could be construed as desktop only.
Depends. And don't forget there are also devices such as tablets that are
something between desktop and mobile devices.
Previous generation tablets just used desktop APIs, current generation tablets
just use mobile APIs. I'd wait until they figure out their own personality
before we try to cater for them especially.
Using the Window {} object anywhere in QML creates a new top level
window.
This implies that a Window{} as the root item of a QQuickView would
create
an empty QQuickView and a second top-level created through the WIndow
object. But at least this would mean there's no magic involved.
Yep.
Like that we can change the default way of using QML to be symmetric
between Desktop and Mobile. You instantiate a QQuickEngine, and then
load
a QML file that contains a WIndow {} as the outermost element. If we
remove the Window {} in QtComponents and use this instead, we can then
make this fully symmetrical on the QML side between desktop and mobile.
The only difference would be in the default behavior of Window (most
likely full screen on mobile, windowed on desktop).
One of the changes talked about on the qt-components mailing list is that
with
this approach you no longer have a Window{} as the outermost element in
desktop components.
Why not? If you start a QQuickEngine instead of a View, then the Window{}
can still be the outermost element. In fact this would IMO give us
something more consistent. Of course you can still do a QQuickView
directly, but then you don't have a Window as the outermost element
anymore.
This should work, but I wouldn't think it would be the common case. The common
case of single window applications shouldn't have to look up this element, or
start with a specific root item (not in generic QML at least). I would still
like the ability for the QML using application to disable creation of sub-
windows, which would prevent you from starting with a Window{} in those cases.
I would rather have the C++ controlled windows exposed manually through
C++
and have the QML Window{}'s separate. This sounds easily exposed through
ApplicationWindow{} anyways.
Not sure I understand what you mean here. If you use a QQuickWindow from
C++, you also control it from C++. If you use a QML Window{} you can
control it form QML.
I just mean that I prefer having the root window controllable only via C++,
like we have now, in the default case.
Differentiation between mobile and desktop can then happen on the
ApplicationWindow level in QtComponents, where the ApplicationWindow for
the desktop would support menu- and toolbars, the mobile version would
support pages and whatever else is needed there.
In addition, it should be easy to associate a Window {} with a certain
physical screen. For this I'd propose, we somehow expose the list of
screens as objects in
Re: [Development] Window{} API for QML
On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
I agree with most of the things in this thread, but not everything. Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen. This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit the
Window {} API to the mobile use cases. I'd rather that we expose the full
functionality in one Object, and rather document some of the differences
in behavior between mobile and desktop.
I'm wary of trying to expose desktop APIs for desktop use cases, especially
before Desktop QML is fully realized. We might end up exposing the wrong then
and then we're at the same point as before plus we're maintaining and
supporting use-impaired code. I'm also not fond of providing an element for
use in mobile contexts with functionality that basically says: Don't use
this. If it's not to be used on those platforms, why even have it available
for those platforms?
As far as I'm aware there is a lot of features in this gap. Window
decorations, modality, even geometry could be construed as desktop only.
Using the Window {} object anywhere in QML creates a new top level window.
This implies that a Window{} as the root item of a QQuickView would create
an empty QQuickView and a second top-level created through the WIndow
object. But at least this would mean there's no magic involved.
Yep.
Like that we can change the default way of using QML to be symmetric
between Desktop and Mobile. You instantiate a QQuickEngine, and then load
a QML file that contains a WIndow {} as the outermost element. If we
remove the Window {} in QtComponents and use this instead, we can then
make this fully symmetrical on the QML side between desktop and mobile.
The only difference would be in the default behavior of Window (most
likely full screen on mobile, windowed on desktop).
One of the changes talked about on the qt-components mailing list is that with
this approach you no longer have a Window{} as the outermost element in
desktop components.
I would rather have the C++ controlled windows exposed manually through C++
and have the QML Window{}'s separate. This sounds easily exposed through
ApplicationWindow{} anyways.
Differentiation between mobile and desktop can then happen on the
ApplicationWindow level in QtComponents, where the ApplicationWindow for
the desktop would support menu- and toolbars, the mobile version would
support pages and whatever else is needed there.
In addition, it should be easy to associate a Window {} with a certain
physical screen. For this I'd propose, we somehow expose the list of
screens as objects in Qt.application, and give Window {} a screen property
that can be bound to a screen.
So
Window {
screen: Qt.application.primaryScreen // the default behavior
}
would create a Window on the primary screen.
The main question I'm unsure about is what to do with Windows on screens
that are going away (by unplugging the VGA cable going to the projectorŠ).
I've been thinking about the screen issue, and my conclusion was that this
approach wouldn't work. Exposing the screens this way through Qt.application
wasn't deemed useful in the QScreen API thread, and a lot of the same problems
arise here. Aside from the primary screen, it will be very difficult to bind
this window to the right other screen, you can't just go off of list index
(except perhaps in the common case of external displays) so you need to query
the new screens on screenAdded/startup and imperatively assign windows. If
you're going to do it the imperative way anyways, you may as well do it in C++
and just move Window{} objects out of the main QML file into another canvas
(that way they were created in the same engine and have useful bindings).
So here's my suggestion for what would work. Leave the general case for C++ as
explained above, and offer a convenience of the common case of an external
display. Example:
ExternalDisplay{
Rectangle{
anchors.fill: parent
}
}
Arguably you could require a Window instead and automatically rescreen it, but
I prefer relaxing the restriction to any QQuickItem and it's just like the
root item in another view.
As you can guess, the effect of the ExternalDisplay{} is that it will
dynamically load and unload the child component and place it on any secondary
display when it's available. The root item for that display will be scaled
much like a QQuickView.
I've been trying to prototype it recently, but my efforts are currently
stalled by the XCB plugin crashing when you try to do any GL on a secondary
screen :( . So I'm sorry, but I don't have the code for this yet.
So my proposal would be something exposing most of the QWindow API:
Window {
property Screen screen
property Orientation orientation // { Portrait,
[Development] Window{} API for QML
Samuel's mail about exposing QScreen API mentions that a Window element might
be useful to have in QML, and I concur. One area where you cannot really avoid
splitting your UI across multiple windows is for multiple screens (e.g. an
external display), and without a basic window abstraction in QML you have a
very poor approach available to you for multi-screen apps in QML (you have to
have two completely separate QQuickView's and pass data between via C++).
Given that there can be Desktop Components providing the full API for desktop
windows (and this is being discussed on the qt-components ML already), I
propose the following minimal Window{} API for QML core (i.e. inside the
QtDeclarative library)
Window {//Inherits QQuickItem
property string title: untitled
property bool fullscreen: true
property int x
property int y
property int width
property int height
property bool visible
}
Now this item would end up being reparented into another QQuickCanvas on
another window after being created in the same engine as the main file. This
allows bindings to work between windows just fine. Because of the reparenting
though there are a few changes from QQuickItem which is why I've duplicated
x/y/width/height/visible. Arguably it shouldn't be a QQuickItem because of
this, but I think the easy access to anchors is worth it.
These properties would now refer to the attributes of the window, and be a
two-way binding similar to QQuickView. x/y/width/height would refer to the
geometry of the window and would update when window geometry changes. x/y
would be relative to 0,0 on the parent window, allowing anchors to the root
item of that window to work out properly. And visible would refer to the
window's shown/hide status.
Doing Windows in QML via an element created in the main scene makes the engine
sharing and bindings a lot easier and more useful. To place it on another
screen, my current idea is that it would expose the QQuickCanvas (a QWindow
subclass) in C++ and you could just set the screen from there. It'd be better
not to have to expose the C++ class as public API, but since the screen
assignment ought to happen in C++ I don't think it can be avoided. The C++
API, aside from the above properties, would just be the one function,
QQuickCanvas* canvas(), to get the canvas for alterations (such as setScreen).
There's a prototype of the more extensive desktop version Window{} in
https://qt.gitorious.org/~aalpert/qt-components/aalperts-desktop-components ,
it's the same approach just with more properties and fewer tests ;) . It's at
least a PoC that show the engine sharing and reparenting works (except for
text rendering, because the texture cache isn't shared right between canvases
right now, but that's fixable). Writing that brings up two discussion points.
The first was that this approach isn't a QMainWindow like the old desktop
components Window{}, and this breaks integrating QWidget menus/toolbars.
Ideally we'd want to throw those out of desktop components and replace them
with QML versions, but no-one has really looked into that yet. If anyone has
ideas on how to do menus really well in QML I'd love to see an ML thread on
that :) (remember that the reason QML doesn't have much for desktop yet is not
because it has something against desktops, it's because no-one has had the
time to look into it yet).
The second is that this approach differentiates between the initial view
window and the secondary windows created in QML. There is no API to reposition
or modify the initial window, and I contend that is the correct approach. The
first window is created from C++ either by a custom application (which can set
all these things itself), a program using QML like a scripting language (where
they don't want you screwing with it - might even want to disable Window{}) or
qmlscene/qmlobserver (which is only for debugging or prototyping). I think the
control of the primary window should remain with the QML launch point, and the
Window{} should go in a separate import so that it can be blocked by
environments that want more rigid control.
I'd appreciate feedback on this API before it gets into Qt - we only want the
highest quality APIs after all. In particular it'd be nice to have some
feedback from desktop QML users. While I don't have time to write the desktop
Window{} myself, it should be enabled as much as possible so that it's easy to
write when someone finally finds the time. And ideally it shouldn't suffer a
horrible API because no-one thought of desktop at the offset ;) .
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
Reading Alan's post a couple times, I *think* this summarizes to:
(a)- A new Window{} element is being proposed for QML that is different
from the current QML components. Specifically, the new Window{} is a
top-level concept, where you could have more-than-one, such as one for
each monitor. Other QML components could be instantiated *within* the new
Window{}, but a Window{} itself is a top-level item.
(b)- The new QML Window{} element may break QWidget menus/toolbars within
that Window{}.
(c)- The new QML Window{} behaves differently from other QML components
which may be used *within* that Window{}. Specifically, QML components
can move/resize based on QML source code, but the top-level Window{}
would be anchored/sized based on the launching C++ program (not based on
QML API).
(Please feel free to correct my impression -- Alan's email was fine, my
brain is just small and I'm trying to understand all of the implications
for what Alan is proposing.)
My impressions:
(1) This makes sense to me (I like this proposal). I've tried to create
desktop gadgets with QML, or otherwise have more-than-one top-level QML
window into which I could put QML components, and I think it would be much
easier if we distinguished between these two types of real-estate (e.g.,
IMHO it would be nice to distinguish between top-level real-estate, and
nested QML components that move around that top-level real estate).
Logically, the top-level real-estate represents the device (e.g., like
the whole phone screen), while the nested real estate represents
space-within-that-top-level-device. (This seems elegant.)
(2) I don't have a strong opinion on whether the top-level Window{}
should have size/placement attributes exposed to QML. Alan's proposal to
*not* have that seems fine with me (I just need a way to anchor the
desktop gadget, or place it on the desktop where it needs to go, and it's
fine if I can do it only through the C++ application.) I *assume* the
Window{} will have some kind of frame-with-title on the desktop so the
user could size/move it? If not, no biggie, I can do that myself.
(3) I don't care if menus/toolbars are broken. IMHO, (as Alan suggests),
they would be done again in QML (so they could be skinned/sized
properly), or they would be done with a different metaphor (there are lots).
(4) Perhaps off-topic for this thread, IMHO this type of
desktop-and-mobile-unification is really important to think-through
(that's how I see this proposal). I like what is proposed, but we may need
some iteration as we experiment on both desktop and mobile. I see this
proposal as simpler and more bounded than other unification concerns I have
(for QML), such as skinning-styles and layout.
Do I properly understand what is being proposed?
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Window{} API for QML
On Tue, 8 Nov 2011 05:45:01 ext Charley Bay wrote:
Reading Alan's post a couple times, I *think* this summarizes to:
(a)- A new Window{} element is being proposed for QML that is different
from the current QML components. Specifically, the new Window{} is a
top-level concept, where you could have more-than-one, such as one for
each monitor. Other QML components could be instantiated *within* the new
Window{}, but a Window{} itself is a top-level item.
(b)- The new QML Window{} element may break QWidget menus/toolbars within
that Window{}.
(c)- The new QML Window{} behaves differently from other QML components
which may be used *within* that Window{}. Specifically, QML components
can move/resize based on QML source code, but the top-level Window{}
would be anchored/sized based on the launching C++ program (not based on
QML API).
Not quite. The Window{} in QML would be controllable, at least minimally, from
QML. The QWindow* (probably a QQuickView*) created in C++ would remain
controllable only from C++ - Window{} like API would not be granted to them.
(Please feel free to correct my impression -- Alan's email was fine, my
brain is just small and I'm trying to understand all of the implications
for what Alan is proposing.)
I was invoked with --verbose but I think you got the picture ;) .
My impressions:
(1) This makes sense to me (I like this proposal). I've tried to create
desktop gadgets with QML, or otherwise have more-than-one top-level QML
window into which I could put QML components, and I think it would be much
easier if we distinguished between these two types of real-estate (e.g.,
IMHO it would be nice to distinguish between top-level real-estate, and
nested QML components that move around that top-level real estate).
Logically, the top-level real-estate represents the device (e.g., like
the whole phone screen), while the nested real estate represents
space-within-that-top-level-device. (This seems elegant.)
(2) I don't have a strong opinion on whether the top-level Window{}
should have size/placement attributes exposed to QML. Alan's proposal to
*not* have that seems fine with me (I just need a way to anchor the
desktop gadget, or place it on the desktop where it needs to go, and it's
fine if I can do it only through the C++ application.) I *assume* the
Window{} will have some kind of frame-with-title on the desktop so the
user could size/move it? If not, no biggie, I can do that myself.
It will be a QWindow and so the desktop window manager will have the operation
to decorate it as normal. Technically this is the same for mobile window
managers, but they tend to be simpler.
(3) I don't care if menus/toolbars are broken. IMHO, (as Alan suggests),
they would be done again in QML (so they could be skinned/sized
properly), or they would be done with a different metaphor (there are
lots).
(4) Perhaps off-topic for this thread, IMHO this type of
desktop-and-mobile-unification is really important to think-through
(that's how I see this proposal). I like what is proposed, but we may need
some iteration as we experiment on both desktop and mobile. I see this
proposal as simpler and more bounded than other unification concerns I have
(for QML), such as skinning-styles and layout.
I fully agree. Desktop and mobile unification for QML is not something where
it's clear how to implement it yet, but Qt 5 is the right time to start
thinking about it. Even if 5.0 doesn't manage to bring desktop QML up to par
with desktop widgets, we want to have thought the issues through well enough
that we've left that path open. That is a prerequisite for a QML in the Qt 5.x
series that is great on both mobile and desktop.
Do I properly understand what is being proposed?
So close, but thanks for trying Charley :) .
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
