> Why all the ceremony? What people probably want is:
>
> Q_DEFAULT_PROPERTY(int, value)
>
> That would expand to:
>
> Q_PROPERTY(int value READ value WRITE setValue NOTIFY valueChanged)
> public:
> int value() const { return m_value; }
> void setValue(int value)
> ...
...which
Whatever you change, please consider the upgrade path for people using BINDABLE
in many, many places.
E.g. if a new solution can be applied by regexp search & replace, or if Qt
Creator offered an "upgrade fix" via light bulb, that would be great.
I still have nightmares of trying to get warning-
Hi Giuseppe,
>
> Is tmpfs an option?
>
Is it platform-independent? I need at least Windows and Linux support.
It looks rather Linux-only.
Kind regards
Robert
This message and any attachments are solely for the use of the intended
recipients. They may contain p
Hi Shawn,
> FWIW QQuickImageProvider is for images: you can see from its API that it
> generates QImage or QPixmap or a texture.
I would argue that an SVG IS an image, see e.g. the definition from Wikipedia:
" A representation of the form of a person or object[...]"
So why should QQuickImageProvi
Hi,
I immediately jumped on the brand-new VectorImage, and quickly found, to my
disappointment, that I cannot use it, because I am missing an important piece.
How am I supposed to pass a memory-generated SVG via URL?
Normally, I would do that via QQuickImageProvider, but it seems someone forgot
>
> Removing boilerplate from a C++ class that declares properties could be done
> with the help of moc, without creating bindables. I.e. a simplified
> Q_PROPERTY declaration that assumes some convention for
> getter/setter/notify-signal could be enough:
>
> class Object : public QObject
> {
>
> There is "Q_PROPERTY(qreal x MEMBER m_x NOTIFY xChanged)" for the
> really simple cases.
>
> With that you don't need to write any accessors at all. Not even the bindable
> accessor.
>
That neither does the change comparison, nor will it automatically notify about
changes.
You'd have to code bo
Hi,
I can only summarize your message in four letters: ARGH!
We widely use BINDABLE in Q_PROPERTY (>500 places) because it removes a lot of
boilerplate from our C++ classes.
Compare code with BINDABLE:
// ***
Q_PROPERTY(qreal x BINDABLE getX READ default)
QBindable getX() const
{
return m_X
> Webengine and PDF (And qtinsighttracker) are in ‘Extensions’ node staring
> from Qt 6.8.0
Is there some documentation of "Extensions"? Out of the box, despite having the
extension installed (and the include folder containing the same header files in
6.8.2 as in my previous working 6.7 version
Also, why does Qt PDF not have sources under the new extension tree?
Kind regards
Robert
From: Jani Heikkinen
Sent: Friday, 31 January 2025 12:21
To: Schimkowitsch Robert ;
development@qt-project.org
Subject: RE: Qt 6.8.2 Released
CAUTION: External email. Do not click on links or open
Shouldn’t that have been under “important changes” in the 6.8.0 release notes?
From: Jani Heikkinen
Sent: Friday, 31 January 2025 12:21
To: Schimkowitsch Robert ;
development@qt-project.org
Subject: RE: Qt 6.8.2 Released
CAUTION: External email. Do not click on links or open attachments unless
Seems to be missing Qt PDF and Qt WebEngine, when installing from Maintenance
tool.
Kind regards
Robert
From: Development On Behalf Of List for
announcements regarding Qt releases and development via Announce via Development
Sent: Friday, 31 January 2025 10:51
To: List for announcements regar
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
> As a side-effect, that means they can't be extracted by moc using Q_FLAG /
> Q_ENUM. The enumeration values must be in the class body for moc to work.
As a user of Qt, I really hate this restriction.
But what about
> From: Edward Welbourne
[...]
> We currently have a delay between
> * When the replacement API is available and deprecation markers are in
> place and
> * When the deprecation kicks in
I vividly remember the handful of APIs that were deprecated in 5.15 and removed
in 6.0 (with replacement API
If I may add a user's perspective to the discussion.
I know gift season is over, but here is what I (as a user) would ideally get:
1) Things get deprecated, including clear communicating when they are planned
to be removed (e.g. "to be removed in Qt 7" or "to be removed in Qt 8")
2) There is alway
So the request is more to give feedback on specific pages of the documentation?
Which also kinda doesn't feel right, because the other half of the questions
are general, and not targeted at a specific page.
Also, if I use my offline documentation in Qt Creator, I'm probably left out
anyway :-)
To add a user perspective to the discussion: Please keep things simple and
consistent. Consistency is great, especially in large code bases.
Changing access modifiers for an existing interface in a derived class is
confusing. Due to the way the documentation is structured, it’s also hard to
see
17 matches
Mail list logo
