On 11/22/11 10:53 AM, "ext jens.bache-w...@nokia.com"
wrote:
>>
>> 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 co
>
> 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
2011/11/21 Alan Alpert :
> On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
>> 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
On Tue, 22 Nov 2011 09:10:14 ext Adriano Rezende wrote:
> 2011/11/21 Alan Alpert :
> > On Tue, 22 Nov 2011 00:50:28 you wrote:
> >> 2011/11/21 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:
> >> >> > Window{ //Not
IOW, something like:
import QtQuick 2.0 // or QtQuick.UI 2.0 (if it makes sense)
Window {
}
- Adriano
2011/11/21 Adriano Rezende :
> 2011/11/21 Alan Alpert :
>> On Tue, 22 Nov 2011 00:50:28 you wrote:
>>> 2011/11/21 Alan Alpert :
>>> > On Mon, 21 Nov 2011 17:26:44 ext Alan Alpert wrote:
>>> >>
2011/11/21 Alan Alpert :
> On Tue, 22 Nov 2011 00:50:28 you wrote:
>> 2011/11/21 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:
>> >> > Window{ //Not inheriting QQuickItem, creates a new top level window.
>> >> >
>> >
On Tue, 22 Nov 2011 00:50:28 you wrote:
> 2011/11/21 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:
> >> > Window{ //Not inheriting QQuickItem, creates a new top level window.
> >> >
> >> > property int x
> >> >
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
> > > > prot
2011/11/21 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:
>> > Window{ //Not inheriting QQuickItem, creates a new top level window.
>> >
>> > property int x
>> > property int y
>> > property int width
>> > p
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
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
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 expose
On Tue, 15 Nov 2011 19:30:59 you wrote:
> On 15/11/11 10.24, "ext Alan Alpert" 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" wrote:
> >> > >On Wed, 9 Nov 2011 06:43:34
On 15/11/11 10.24, "ext Alan Alpert" 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" wrote:
>> > >On Wed, 9 Nov 2011 06:43:34 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
>> > >> I
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" 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
On Fri, Nov 11, 2011 at 2:45 AM, Alan Alpert 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
On Thu, 10 Nov 2011 18:29:58 Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
> On 11/10/11 1:32 AM, "Alan Alpert" 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:
> >>
>
On Fri, 11 Nov 2011 05:01:32 ext Adriano Rezende wrote:
> On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert 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 mini
On Mon, Nov 7, 2011 at 5:32 AM, Alan Alpert 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 l
On 11/10/11 1:32 AM, "Alan Alpert" 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
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 representat
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
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, wher
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.
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
25 matches
Mail list logo