My question is that, does `qmlcachegen` compress the bytecode before it
is embedded in the generated C++ source file? If not, is there a plan to
do that or a reason not to do that?
The byte code is not compressed. If it was, we couldn't mmap() it in
straight from the file (which can be paged b
What's the benefit of not generating it on the C++ level? I mean, I
understand you _can_ do that, but I don't quite see why you would prefer
to introduce an inconsistency like that?
QML will need a notification signal if we remove support for bindables
and Robert wants to search-replace his pr
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.
We need to establish some "NOTIFY default" as p
Q_PROPERTY_FULL(int, READ int value() noexcept,
WRITE void setValue(int),
NOTIFY void valueChanged())
Why all the ceremony? What people probably want is:
Q_DEFAULT_PROPERTY(int, value)
That would expand to:
Q_PROPERTY(int value READ value WRI
That neither does the change comparison, nor will it automatically notify about
changes.
You'd have to code both manually. I don't see a major improvement. Also, I
guess this forces me to make the members public.
Not really an alternative.
You don't need to make the members public. The moc-gen
On 3/7/25 10:48, Schimkowitsch Robert wrote:
We widely use BINDABLE in Q_PROPERTY (>500 places) because it removes a lot of
boilerplate from our C++ classes.
> [...]
I have never had any issues using BINDABLE. I have avoided using them in
complex situations, true, but for the simple use case
Hi,
We've had a discussion [1] about QProperty and QBindable during the last
contributors' summit, but unfortunately didn't reach any conclusion.
I'll summarize the most important part of the discussion here:
"There is functionality to retrofit Q_PROPERTY with synthetic bindables."
This may
Hi,
According to `Unit::verifyHeader()` @ `qv4compileddata.cpp`, the version
needs to strictly match:
This is a thorny issue. The Qt version check was put in along with a
number of other checks back when they invented the QML disk cache. There
was no detailed reasoning for the individual che
+1
On 12/1/24 23:42, Jan-Arve Sæther via Development wrote:
+1
I second this. He has been passionately improving the state of Qt Quick
Dialogs and has been the de-facto maintainer for it since it was
rewritten to Qt Quick Controls 2.
Mandatory disclosure: I'm his manager at the Qt Company
How about: "You should order function signature prefixes alphabetically,
but you should not change existing code for only that reason". This will
make things converge eventually and also covers future revelations of
this kind.
best,
Ulf
--
Development mailing list
Development@qt-project.org
ht
I would like to nominate Olivier de Cannière for approver rights for the
Qt project.
+1, he's done great work!
Disclaimer: We're in the same team.
best regards,
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Thank you Mike, My answer is "what it last was before fooObject went
null", and I was use it in my project.
That's conceptually not a binding. A binding is something that updates
whenever any of its depedencies updates. It's value is calculated from
its dependencies. In your case, however, as
Hi,
you should also be able to add a RESET attribute to the property. It is
conveniently triggered when assigning undefined to the property and
resets it to the default value. This may be the cleanest way to deal
with it.
best regards,
Ulf
--
Development mailing list
Development@qt-project.o
Hi,
First things first: Users of Qt are unaffected by most of this. They get
a nicer macro to define static logging categories, but everything else
stays the same for them.
Logging categories have been a source of some frustration in Qt itself
because they tend to create symbols that don't s
Hi,
As noted before, we need to have a discussion on the new Android/Java
bindings and how they fit in with the QML language and various Qt
modules. See for example
https://codereview.qt-project.org/c/qt/qtdeclarative/+/563564 and
various follow-up changes.
I suggest we call the Android/Jav
Hi,
First, I don't think you need a feature freeze exception to write tests,
examples and documentation. Those are not new features, after all.
Second, while I certainly welcome this initiative to produce
Android/Java bindings for QtQuick, we need to have some discussion about
the overall ar
Hi,
Generally, if I read that correctly, a user would rarely need both of
your styles. They either have a Desktop type device or a Mobile type
device and running the other style makes little sense.
Therefore, in your case, I would propose to compile two variants of all
your libraries: one th
I'd like to nominate Lucie Gerard as an approver for the Qt project.
+1, how was she not an approver, yet?!
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi,
there is another category of such API: API for use by generated code
only, such as qqmlprivate.h. This is intentionally undocumented,
intentionally called by generated user code, and the run time guards
around the generated code make sure it's not called if the run time Qt
version does no
Hi,
we cannot retroactively make properties FINAL as that can be source
incompatible in QML. However, FINAL properties result in a significant
performance boost for QML. qmlcachegen, if it can prove that a property
you use in your code is actually the property it expects, does not have
to wra
The one thing where you need NOTIFY or BINDABLE is if you want to expose a
class as a type to QML
AND you want to make its instances usable in bindings; I believe that's where
the warning originates
from. However, that's not your use-case, so it shouldn't matter.
Value types do not need signa
Hi, have you considered how you can keep compatibility, by making this
change either opt-in or opt-out? Since it seems the refactoring is
already done, it feels like you are making a bet that only has a
negative outcome for those porting/trying to keep up. 😊 Good for
maintenance, bad for users?
So, to clarify this some more ... If:
1. you use _multiple_ QML engines in the same process at the same time,
2. you have _different_ import paths, plugin paths, URL interceptors or
network access managers for those engines,
3. you rely on those engines to produce _different results_ for the
_
Hi, have you considered how you can keep compatibility, by making this
change either opt-in or opt-out? Since it seems the refactoring is
already done, it feels like you are making a bet that only has a
negative outcome for those porting/trying to keep up. 😊 Good for
maintenance, bad for users?
Hi,
I'm currently refactoring our QML compilation units to avoid storing
engine-specific data in the global type registry since that is dangerous
and bug-prone. See e.g. QTBUG-120189.
This effectively means that you will be able to re-use compilation units
between different QML engines. On t
+1
Disclosure: Semih is working in my team and we share the same office.
Same for me
best regards,
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
How about conversion:
QVariant(std::optional>).value(); // return U{} if T cannot be
converted; otherwise U(T);
QVariant().value>(); // nullopt, not a std::optional
holding a T{}
QVariant(42).value>(); // std::optional holding 42
QVariant(QSize()).value>(); // probably null
I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf
and Alexey Edelev as maintainer for Qt GRPC. In fact, both have been
working on this code base even before they officially became part of
Qt. I am glad they agreed to continue this work going forward in the
context of Qt Developme
I can confirm a simple:
for (const QString &importPath : parser.values(importOption)){
QByteArray path = qgetenv("PATH");
QByteArray newPath = importPath.toLocal8Bit() + ";";
newPath += path;
qputenv("PATH", newPath);
qDebug() << "Modified PATH:"
Adding a command line option to add dll search paths via
_wpuntenv_s(L"PATH", ...) or SetDLLDirectory(L"...") into qml.exe would
also work, right?
I didn't know this exists. You'd have to add a lot of directories,
though, since it doesn't want to see the QML import path but the paths
to the i
According to dependency scanner it depends on Qt6Qml.dll, Qt6Core.dll
and World.dll. All of these should be either be available from Qt or
from the additional import path I provided. Even when copying the dlls
into the directory, I get the same error.
This is not about the import path but abou
PS C:\Qt\6.7.0\msvc2019_64\bin> /.\qml.exe -I
"C:\Code\Cpp\build-qml-plugin-minimal-Desktop_Qt_6_7_0_MSVC2019_64bit-Release" -f "C:\Code\Cpp\qml-plugin-minimal\Main.qml"
QQmlApplicationEngine failed to load component
file:///C:/Code/Cpp/qml-plugin-minimal/Main.qml:5:1: Die Bibliothek
C:\Code\Cpp
There _is_ consensus. It's in the wiki. And in older modules not
infected by the _clang-format file. Discussions arise because
of .clang-format, not despite it. Afaict, there never was a discussion
about how faithful the _clang-format represents the Qt style before it
was added. If there was _any_
+1, as indicated before
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
==19383==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7f26aec7ae48 in __interceptor_malloc (/usr/lib64/libasan.so.
5+0x109e48)
#1 0x7f26a8bcbc50 (/usr/lib64/libfontconfig.so.1+0xbc50)
#2 0x3d4c4c415f434bff
Hi,
The usual way to request a repository, playground or not, is a mail like
this:
https://lists.qt-project.org/pipermail/development/2022-August/042900.html
If the request is not totally outlandish it's usually granted, possibly
after some bike shedding over the name and location.
AFAIR w
+1
She has helped me more than once with obscure INTEGRITY-related problems.
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
+1
He's doing a great job.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
The bug is not reproduce in Qt 6.4.2, but I can't found a exists
issue in bugreports.qt.io. Maybe my Qt 5 is not latest version? It's Qt
5.15.8, Is this bug fixed in the private Qt code?
https://bugreports.qt.io/browse/QTBUG-97427 is what you're looking for.
I've linked it in QTBUG-111754
QML supports comments, but not multi-line string literals. You can concatenate
them, though.
Sure it does. You can use ECMAScript template strings:
property string longthing: `a multi
line string`
(In fact you can also just sprinkle line breaks into your regular
st
Or QML, in fact:
// Attribution.qml in QtAttribution module:
QtObject {
property string name
property list files
property list upstreamFiles
//
}
// Actual attribution.qml in source tree:
import QtAttribution
Attribution {
// allows comments as much as you like
nam
YAML is really quite terrible. If we're going to switch, let's choose
something else.
Basically, YAML is extremely complex, ambiguous, and incompatible
between different versions. See for example
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell for
an in-depth explanation.
So, how to fix the above? One could easily fix the API break, but one is
left with broken APIs all over the place. There's no straightforward
deprecation mechanism for QML either, and we've dropped versioned includes.
We haven't actually dropped versioned imports. An unversioned import
just al
The above isn't thread-safe, it isn't even re-entrant, in the same way
that iteration using iterators isn't. This is a known issue whenever you
hand out references, and it's nothing that violates our
const-is-thread-safe promise, otherwise
... which is why we prefer to hand out (implicitly share
That's a deep copy. A deep copy of a string is obviously more expensive
than the overhead of calling the QString ctor and dtor.
That remains to be proven. A rule of thumb for atomics is that they're
two orders of magnitude slower than a normal int. They also still act as
optimizer firewalls. Wit
So, if the method immediately converts whatever it gets to QList or
QString, then there is no point in passing it a span or view.
My point is that there _is_. Citing my blog post:
callConsumeQStringHelloWorld():
> [...]
That's the worst case scenario of passing an 8bit string literal to a
Hi Marc,
On 11.11.22 09:35, Ulf Hermann via Development wrote:
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generator APIs in a few relevant cases:
1. Users want to pass a "foreign" container to a Qt function that
doesn't only store it as QList or QS
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generator APIs in a few relevant cases:
1. Users want to pass a "foreign" container to a Qt function that
doesn't only store it as QList or QString. It might merely iterate it or
store it as something else.
2. Assume a cont
Hi,
let me mention that I've been pondering all that hairy stuff just
recently when trying to come up with a solution for how to map QList*> and QQmlListProperty to each other without exposing people to
dangling references and without copying and allocating all the time.
One thing we could do
I don't want to take the Qt containers away from Qt users. I want to get
rid of their use in our APIs, so that both the Qt implementation as well
as our users are free to choose the best container for their needs
instead of having to pick from one of the public Qt containers.
I would like to kno
Once we had QString and QByteArray (and the admittedly ill-conceived
QStringRef). Now we have QStringView, QAnyStringView, QByteArrayView,
... and when asking what the prefered getter/setter-signature for
"Qt-style" interfaces is the answer I get is "We'd guess $X, but the
only guy that knows for
Hi,
One thing I haven't understood about the ordering problem is why we
cannot just define our "invalid" values to always be < any valid one and
equal to other invalid ones. This way we get at least weak ordering for
all our types and we're done.
There may be types where existing operator< w
+1
Unsurprisingly, I'm part of the same team as Sami
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
My question was for the developer's own plugins. Are these tools meant for
the developer to test their QML importing their plugins? It might be
surprising that it cannot find the plugins they've just installed to
QML_PLUGIN_PATH, or worse, finds an older version of them.
Indeed if you actually h
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
And would replacing the Qt 5 versions with Qt 6 be an imperceptible change to
the user? What happens if their own QML content has plugins? I assume Qt
itself ship
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
Well, qml and qmlscene are only equivalent to Qt5 insofar as we consider
the QML language and our QML modules in Qt6 to be equivalent to the ones
in Qt5. There
Hi,
I would consider qml, qmlscene, qmlpreview, qmlprofiler, and qmltime to
be equivalent to their Qt 5 versions, and indeed user-facing.
qmltc is not user-facing. It's a compiler and should live in the same
place as qmlcachegen.
qmljs is a general-purpose JavaScript interpreter. So, it's k
57 matches
Mail list logo
