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 up,
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 delet
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 t
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 bin
On Thursday, 26 September 2019 21:07:38 CEST Thiago Macieira wrote:
> On Thursday, 26 September 2019 08:03:32 PDT Edward Welbourne wrote:
> > If possible, I’d like us to move away from relying on setting
> > environment
> > variables, and/or switch to specifying per-screen DPI instea
On Thursday, 26 September 2019 08:03:32 PDT Edward Welbourne wrote:
> If possible, I’d like us to move away from relying on setting
> environment
> variables, and/or switch to specifying per-screen DPI instead of a
> scale
> factor.
>
> On Thursday, 26 September 2019 04:48
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
Hi,
On 26/9/19 3:57 PM, Martin Koller wrote:
What configure line are you using? Are you trying to use -shared ?
${QTDIR}/configure -xplatform wasm-emscripten -nomake examples \
-prefix ${dir}/qt5-installed -opensource -confirm-license \
-openssl-linked
OPENSSL_INCDIR=/home/pvss/branch_3x/build
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
observer bound to that property.
About the
QProperty fullname;
Hi
we’re busy doing the work but have a couple of blog posts in the pipeline.
It’s unclear if we’ll have benchmarks we can share, we’ll see.
Also, those specific changes make a difference in specific conditions so YMMV.
Will keep everyone posted,
Mike
> On 26 Sep 2019, at 08:48, Massimo Callega
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 t
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 implemen
> 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 required.
>
> One option would be to say that such properties are impl
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 implement what you described, perhaps in a more
convenient way though.
Simon
> -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 and I worked on a project to re-
> e
If possible, I’d like us to move away from relying on setting
environment
variables, and/or switch to specifying per-screen DPI instead of a scale
factor.
On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
>>> Sure, but where, on X11?
On Thursday, 26 September
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.
On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> > > If possible, I’d like us to move away from relying on setting
> > > environment
> > > variables, and/or switch to specifying per-screen DPI instead of
Hi,
Brief update on the status of the merge:
After qtbase, the direct leaf modules such as qtsvg, qtimageformats, etc. were
merged. What's left is qtdeclarative and everything that depends on it. While
the actual merge of wip/qt6 went through for qtdeclarative, the combination of
current dev q
On Thursday, 26 September 2019 09:29:10 CEST Shawn Rutledge wrote:
> KDE also needs to set env variables to get correct behavior, right? Which
> ones does it do right? Which ones are wrong or unnecessary in 5.14?
KDE sets the Qt environment variables to set the right scaling. GNOME has
their ow
Hi devs, can someone at KDAB please spend a few words about these "Threading
archtecture" and "Frontend/Backend node sync" overhauls mentioned in the 5.14
changelog?
I'd just like to know if we might expect performance improvements and, if so,
is it possible to see benchmark results before/afte
Hi Erik,
I briefly looked at the two tickets and I think they are sensible use-cases and
your proposed API additions look minimal and good to me, too :)
Unless somebody else can see anything that really makes this not fit, I'd feel
positive about this having a chance of being accepted.
Simon
On Sep 26, 2019, at 9:08, Allan Sandfeld Jensen wrote:
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
>>> If possible, I’d like us to move away from relying on setting environment
>>> variables, and/or switch to specifying per-screen DPI instead of a scale
>>> factor.
>>
On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> > If possible, I’d like us to move away from relying on setting environment
> > variables, and/or switch to specifying per-screen DPI instead of a scale
> > factor.
>
> Sure, but where, on X11?
xrandr?
We read the X11 setting
26 matches
Mail list logo
