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 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
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
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
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
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 required.
>
> One option would be to say that such properties are
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-
>
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
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
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
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
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
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
Hi,
Am 25.09.2019 um 12:33 hat Matthew Woehlke geschrieben:
As a user, I don't want to have to know/measure/compute the DPI of my
display device. I just want to make "stuff" bigger or smaller.
Exactly! As a (Windows) *user* I want Qt based applications (which a
user is probably not aware of
Den tors 26 sep. 2019 kl 04:51 skrev Thiago Macieira
:
>
> On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote:
> > Large parts of the world did not grow up with inches. I know I'd have
> > a hard time to hold up my fingers to show an inch...
>
> For most people, "DPI" is an
28 matches
Mail list logo
