On 10/2/19 5:19 PM, Pierre-Yves Siret wrote:
While using layouts in the Qt Quick world, you use Layout attached
properties to give hints to the layout system :
Sure it is a subset of the options you have with the corresponding
layouts of the widgets world.
It is possible to set the
>
> With Widgets, GraphicsView or my framework the system depends on the
> min/preferred/max hints being evaluated by a size policy. F.e
> QSizePolicy::hasHeightForWidth() tells the layout classes, what to do.
>
> QQuickItem has the implicitSize ( = implicit preferred size ) only - no
> other
On 10/2/19 4:36 PM, Jason H wrote:
There is fontSizeMode: Text.Fit, .HorizontalFit and .VerticalFit.
Horizontal fit is what you want in that situation. But the whole
implementation is lacking because you can't actually ask the Text
what size it used to render so that other text items on the
> Also the implicit size of longish texts is usually irrelevant as in most
> situations the layout needs a height-for-width value. IIRC Qt/Quick does
> not even has a concept for how to deal with this type of constraints.
There is fontSizeMode: Text.Fit, .HorizontalFit and .VerticalFit.
Hi Chris,
should individual items have to know/track this ...
Well, anchoring is also based on size changes, but uses a different type
of notification -> item change listeners.
Not sure why the authors decided to introduce yet another type of
notification - instead of using event + event
Hi Uwe,
On Sat, Sep 28, 2019 at 9:29 PM Uwe Rathmann wrote:
>
> On 9/28/19 8:49 AM, Simon Hausmann wrote:
>
> > Instead of an idle timer, all imperative triggered onFooChange
> > handlers are queued up and called right before the next frame.
>
> Property binding is not the only notification
Hi Simon,
That sort of coalescing solves one problem, but not the other -
specifically, that if the on-change handlers are sufficiently complex,
their evaluation (and/or the evaluation of their side effects) is
likely to take longer than the time available, causing
incompletely-updated state to
Hi,
The idea looks awesome.
This is our rough plan of how we'd like to address one aspect of QML and Qt
> Quick today. We are looking forward to any feedback and questions to help
> us review and refine this design.
>
I was wondering is there any plans to use this pattern in other Qt modules?
> On 1. Oct 2019, at 16:12, Jason H wrote:
>
>
>> I’m all for a more declarative coding style also in C++.
>> I’m wondering if we are re-inventing part of Reactive Programing a la
>> ReactiveX with QProperty, though?
>>
>> The above looks similar to (sodium-cxx):
>>
>>cell_sink
> I’m all for a more declarative coding style also in C++.
> I’m wondering if we are re-inventing part of Reactive Programing a la
> ReactiveX with QProperty, though?
>
> The above looks similar to (sodium-cxx):
>
> cell_sink surname("John");
> cell_sink lastname("Smith”);
> cell
Am 01.10.19 um 15:18 schrieb Eike Ziller:
>
>> On 26. Sep 2019, at 17:02, Simon Hausmann wrote:
>>
>> Hi,
>>
>> Earlier this year, Olivier, Samuel, Auri and I worked on a project to
>> re-evaluate how we could bring the declarative Qt Quick approach of doing
>> user interfaces closer to C++,
> On 26. Sep 2019, at 17:02, Simon Hausmann wrote:
>
> Hi,
>
> Earlier this year, Olivier, Samuel, Auri and I worked on a project to
> re-evaluate how we could bring the declarative Qt Quick approach of doing
> user interfaces closer to C++, in order to allow building and running user
>
On Mon, 30 Sep 2019 at 21:06, Matthew Woehlke wrote:
>
> On 30/09/2019 12.38, Ville Voutilainen wrote:
> > On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
> >>> QProperty fullname;
> >>> fullname.setBinding([&]() { return surname() + " " + lastname(); });
> >>
> >> I suppose this is
On 30/09/2019 15.35, Thiago Macieira wrote:
> On Monday, 30 September 2019 11:06:18 PDT Matthew Woehlke wrote:
>> IOW, the example would look like:
>>
>>
>> fullname.setBinding(
>> [](Foo const* self){
>> return self->surname() + " " + self->lastname();
>> });
>
> How does the
On Monday, 30 September 2019 11:06:18 PDT Matthew Woehlke wrote:
> IOW, the example would look like:
>
>
> fullname.setBinding(
> [](Foo const* self){
> return self->surname() + " " + self->lastname();
> });
How does the QProperty class know about Foo?
--
Thiago Macieira -
On 30/09/2019 12.38, Ville Voutilainen wrote:
> On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
>>> QProperty fullname;
>>> fullname.setBinding([&]() { return surname() + " " + lastname(); });
>>
>> I suppose this is convenient, but it also means creating a new function
>> object for
On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
> > QProperty fullname;
> > fullname.setBinding([&]() { return surname() + " " + lastname(); });
>
> I suppose this is convenient, but it also means creating a new function
> object for *every instance of the type*. A more
On 26/09/2019 11.02, Simon Hausmann wrote:
> I would like to propose an API that replaces the setter and getter
> functions on objects with a new property template class that
> encapsulates the property value instead, and the ability to tie
> binding expressions to these properties for automatic
On 26 Sep 2019, at 17:44, Simon Hausmann wrote:
>>> Yeah, custom setters are required.
>>>
>>> One option would be to say that such properties are implemented
>>> using the traditional property system altogether — bridging will be
>>> necessary anyway.
>>>
>>> Another option would be to implement
On 9/28/19 8:49 AM, Simon Hausmann wrote:
Instead of an idle timer, all imperative triggered onFooChange
handlers are queued up and called right before the next frame.
Property binding is not the only notification mechanism and if its
synchronous character is not appropriate for a specific
Hi,
You’re spot on with your observation. It’s interesting to see how you ran into
the same issues back then :)
Samuel (or was it Olivier?) found a solution to that that I find very elegant
and would like to consider for QtQuick in the future: Instead of an idle timer,
all imperative
Yeah that’s one way that should work for sure.
Simon
> On 26. Sep 2019, at 20:54, Thiago Macieira wrote:
>
> On Thursday, 26 September 2019 08:38:40 PDT Mitch Curtis wrote:
>> https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/qqu
>> ickslider.cpp#n355
>>
>> In the
That’s a neat idea!:)
It may require additional tricks to emphasize compatibility with the underlying
type, but with a bit of luck that’s limited to qml.
Regarding failing setters: Is there another language/ environment where you
have seen this before?
The only one I can think of off the top
Hi Simon,
Nice work! This was one of the things which Aaron mentioned as being
a goal he had for QML way back in the day, and I'm glad to see that
someone is doing the work to make it a reality.
In theory, one of the issues with pull-style bindings is that large
dependency chains can be built
On Thursday, 26 September 2019 13:50:14 PDT Olivier Goffart wrote:
> As for the getter/setter, in addition to what Thiago suggests, we could
> also add template parameters with customization points.
Make them non-template parametres, like QSharedPointer, std::shared_ptr and
std::unique_ptr
On 26.09.19 20:50, Ville Voutilainen wrote:
On Thu, 26 Sep 2019 at 21:08, Pierre-Yves Siret wrote:
I feel like custom getters and the ability to mark a property dirty are needed
too.
You might have a property that's provided by an outside system, and you maybe
don't want to query it every
On 26.09.19 18:22, Julien Cugnière wrote:
Le jeu. 26 sept. 2019 à 17:03, Simon Hausmann a écrit :
I would like to propose an API that replaces the setter and getter functions on
objects with a new property template class that encapsulates the property value
instead, and the ability to tie
On Thursday, 26 September 2019 08:38:40 PDT Mitch Curtis wrote:
> https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/qqu
> ickslider.cpp#n355
>
> In the end the solution was to use "dirty events" (i.e. derive from a
> certain type, implement operator() and pass a pointer the
On Thu, 26 Sep 2019 at 21:08, Pierre-Yves Siret wrote:
>
> I feel like custom getters and the ability to mark a property dirty are
> needed too.
>
> You might have a property that's provided by an outside system, and you maybe
> don't want to query it every time it changes, only when there's an
--Original Message-
> >> From: Development On Behalf Of
> >> Simon Hausmann
> >> Sent: Thursday, 26 September 2019 5:03 PM
> >> To: development@qt-project.org
> >> Subject: [Development] Property bindings in Qt 6
> >>
> >> Hi,
> >
On 9/26/19, Julien Cugnière wrote:
> As a user, I find this project very interesting, as after learning
> QML, I often found myself wanting to use some kind of binding system
> when coding in C++.
>
> One question that comes to mind when you mention lazy evaluation: how
> does this interact with
Le jeu. 26 sept. 2019 à 17:03, Simon Hausmann a écrit :
> I would like to propose an API that replaces the setter and getter functions
> on objects with a new property template class that encapsulates the property
> value instead, and the ability to tie binding expressions to these properties
> On 26 Sep 2019, at 17:44, Simon Hausmann wrote:
>
> Hi,
>
> Yeah, custom setters are required.
>
> One option would be to say that such properties are implemented using the
> traditional property system altogether — bridging will be necessary anyway.
>
> Another option would be to
> Sent: Thursday, September 26, 2019 at 11:44 AM
> From: "Simon Hausmann"
> To: "Mitch Curtis"
> Cc: "development@qt-project.org"
> Subject: Re: [Development] Property bindings in Qt 6
>
> Hi,
>
> Yeah, custom setters are requi
> On 26. Sep 2019, at 17:38, Mitch Curtis wrote:
>
>
>>
>> -Original Message-
>> From: Development On Behalf Of
>> Simon Hausmann
>> Sent: Thursday, 26 September 2019 5:03 PM
>> To: development@qt-project.org
>> Subject
> -Original Message-
> From: Development On Behalf Of
> Simon Hausmann
> Sent: Thursday, 26 September 2019 5:03 PM
> To: development@qt-project.org
> Subject: [Development] Property bindings in Qt 6
>
> Hi,
>
> Earlier this year, Olivier, Samuel, Auri a
Hi,
Earlier this year, Olivier, Samuel, Auri and I worked on a project to
re-evaluate how we could bring the declarative Qt Quick approach of doing user
interfaces closer to C++, in order to allow building and running user
interfaces in very memory and processor-power constrained environments.
37 matches
Mail list logo
