Volker Hilsheimer via Development wrote:
> I suspect that “Adaptor” will be a good term to use for such a class.
Is this not more commonly spelled "Adapter"?
Kevin Kofler
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Schimkowitsch Robert wrote:
> Also, why does Qt PDF not have sources under the new extension tree?
Unless that changed recently, Qt PDF is built from QtWebEngine sources. It
uses PDFium which comes bundled with Chromium, and the same PDFium sources
are also used to support printing in QtWebEngin
Thiago Macieira wrote:
> All of KDE libraries and applications, for example, don't care about MSVC
> compatibility
Huh, since when?
Last I checked, there were people building KDE Frameworks and several KDE
Applications with MSVC (as well as with MinGW, but there are a few reasons
why they do no
Giuseppe D'Angelo via Development wrote:
> 2) We stop guaranteeing forward binary compatibility within the same
> minor version.
>
> In other words, code compiled against Qt X.Y.Z may or may not work if at
> runtime Qt X.Y.W is used, with W
> Details: no user downgrades Qt and therefore has eve
Giuseppe D'Angelo via Development wrote:
> Innocent users may have their own build scripts that pull OpenSSL 1 and
> build Qt against that, without realizing that they're playing with fire.
> We should never expose users to insecure defaults, hence the opt-in
> flag, and a build error if you ask fo
Marc Mutz via Development wrote:
> Until then, either you want to be notified of sub-optimal APIs asap,
What is "suboptimal" about Java-style iterators, other than that they do not
work the same way as the STL ones? I find the Java-style iterators to be
easier to use and less error-prone than th
On Fri, Sep 29 2023 at 11:25:09 +01:00:00, László Papp
wrote:
> We develop a widgets based application, not qml,
> so QtQml is also out of question for us.
KItemModels can also be built without QML support, then it depens only
on QtCore, not QtQml.
Kevin Kofler
--
Development maili
László Papp wrote:
> Since both QML and KDE have had this use case, and now, I also have it, as
> well as another person on Stack Overflow, should we propose a public API
> in Qt for this?
>
> I think this would be a great addition to the public interface.
>
> For now, I will implement my own ver
Kevin Kofler via Development wrote:
> Qt 4.8 (backported by Than Ngo):
> https://src.fedoraproject.org/rpms/qt/raw/rawhide/f/qt-CVE-2023-34410.patch
PS: Qt 4.8 does NOT include the Windows-specific qsslsocket_schannel.cpp,
which was introduced in Qt 5.13. (Qt 4.8 supported only OpenSSL.)
List for announcements regarding Qt releases and development via Announce
via Development wrote:
> Patches:
> dev: https://codereview.qt-project.org/c/qt/qtbase/+/477560 and
> https://codereview.qt-project.org/c/qt/qtbase/+/480002 Qt 6.5:
> https://codereview.qt-project.org/c/qt/qtbase/+/479276 an
Kevin Kofler via Development wrote:
> Qt 4.8.7, backported by Than Ngo:
> https://src.fedoraproject.org/rpms/qt/raw/rawhide/f/qt-CVE-2023-32573.patch
Oops, sorry, that is for the previous Qt SVG issue. We will have a backport
of this new one shortly.
Kevin Kofler
--
Devel
List for announcements regarding Qt releases and development via Announce
via Development wrote:
> A recent potential divide by zero in Qt SVG has been reported and has been
> assigned the CVE id CVE-2023-32573.
Same as in the more recent Qt SVG CVE: The vulnerable code (the Qt SVG
classes) was
List for announcements regarding Qt releases and development via Announce
via Development wrote:
> Patches:
>
> dev: https://codereview.qt-project.org/c/qt/qtbase/+/476125
> Qt 6.5: https://codereview.qt-project.org/c/qt/qtbase/+/476490 or
> https://download.qt.io/official_releases/qt/6.5/CVE-202
List for announcements regarding Qt releases and development via Announce
via Development wrote:
> This effects all Qt versions up to and including Qt 5.15.14, Qt
> 6.0.0->6.2.8 and Qt 6.3.0->6.5.0
The vulnerable code (the Qt SVG classes) was introduced in Qt 4.1, so Qt
versions prior to 4.1 (i.
Volker Hilsheimer via Development wrote:
> But for the release team, the busy time is shortly before, and
> significantly after the freeze. So from that perspective, having the
> feature freeze either significantly before the summer break, or
> afterwards, makes most sense. They are the ones most i
Volker Hilsheimer via Development wrote:
> The question is whether this is a significant problem in practice. On
> Linux distributions, we can probably assume that Qt Multimedia is present
> if Qt TextToSpeech is present.
On almost all distributions (all those that do dependency tracking, which is
coroberti wrote:
> Since Qt 6.5 drops Mac OS 10.15 Catalina,
> it apparently starts to be irrelevant for at least 95% of Mac Desktops.
>
> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide
See the note on top:
| Apple are incorrectly reporting Big Sur 11 as Catalin 10.15. Y
A. Pönitz wrote:
> [And since we are at it: It would ease my life (but possibly hamper the
> life of my cardiologist) if you wouldn't call it "Qt NIH API". This is
> an open insult to people who actively designed these APIs _with
> different goals_ than the STL. I personally think it's completely f
Marc Mutz via Development wrote:
> Sure, a trivial QWidgets program from the mid-90s may still compile and
> work in Qt 6, but as soon as said program touches Qt container classes,
> it's game over.
A lot of the changes to Qt container classes were either driven by you or at
least praised by you,
Paul Colby wrote:
> Also worth considering
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-guards
>
> SF.8:
>
>> Note Some implementations offer vendor extensions like #pragma once
>> as alternative to include guards. It is not standard and it is not
>> portable. It injects the
Thiago Macieira wrote:
> 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 th
Benjamin TERRIER wrote:
> As much as I dislike The Qt Company unfriendly behaviour toward LGPL users
> and the fact that IMHO The Qt Company seems to be taking decisions that
> should be taken by the Qt Project,
This whole "open governance" thing is and has always been a PR farce. There
is nothin
samuel ammonius wrote:
> Would wrapping the functions make the feature too large to be approved for
> Qt?
I do not see why you want this to be "approved for Qt" to begin with. I
think it is much more practical to keep the C bindings separate, just as all
the other language bindings out there.
E
Karl Semich wrote:
> C bindings are often needed to link with other languages that
> recognise only C linker symbols, or with codebases designed to run on
> embedded systems with no C++ compiler targeting them.
How would you port Qt to those systems?
Kevin Kofler
samuel ammonius wrote:
> I made a mistake in my example of QPushButton_setFlat(). the parameters
> should have been (QPushButton *, bool) instead of just (bool).
But then you probably need to rewrite QT_C_EXPORT as a variadic macro,
unless you want to pass the parameter list twice, because the PA
samuel ammonius wrote:
> What kind of human error would make converting between the
> pointers dangerous? I've never understood the point of C++
> making pointer types incompatible and then introducing templates
> to bypass this by making a new function for each pointer.
Templates in C++ are much
samuel ammonius wrote:
> In the qtc project I linked to earlier, I managed to implement function
> overloading in C using vardiac macro functions that would find the number
> of parameters and add that number to the end of the function. For example,
> QPushButton() would become QPushButton0(), and
samuel ammonius wrote:
> I'm new to contributing to Qt directly, but I've been trying to create
> external C bindings for Qt for a few months now. Since C and C++ are so
> similar, I've recently been thinking it may just be better to add C
> support directly to the Qt headers by checking for the __
Nicolas Fella wrote:
> The fact that KDE does not use Qt6 yet has rather little to do with the
> quality of Qt6.
Where have I claimed that it does? I sense a strawman…
My point is that it takes time for KDE and other downstreams to adopt a new
major release of Qt, no matter the reason why it doe
Ilya Fedin wrote:
> I believe the fact KDE is not ported to Qt 6 yet is more question of
> bureaucracy coordination of a lot of people in different KDE projects.
> That is, deciding that they want to port to Qt 6 takes time, then every
> project maintainer should do the port and it seems they want
Alex Blasche wrote:
> 2.) An alternative might be to make this change in one go for Qt 7. We
> would keep Qt 6.x on the status quo but start adding compatible
> replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
> mind). Users would only be burdened one time (though it being
Hamed Masafi wrote:
> The source is in this github repo:
> https://github.com/HamedMasafi/QInjection
I see the misspelled word "scopped" appearing several times in that
repository. It should be "scoped" with just one 'p'.
Kevin Kofler
__
Albert Astals Cid wrote:
> El dijous, 28 de juliol de 2022, a les 18:13:02 (CEST), Volker Hilsheimer
> va escriure:
>> The agreement is that KDE maintains patches like this for Qt 5 so that
>> they are available on top of the branches that are available to the Open
>> Source community.
>
>> http
Scott Bloom wrote:
> Fully agreed with all your points, but knowing a release is LTS has value
> even for those without support.
>
> I don't see a problem if someone is choosing a the latest LTS version,
> getting that version since the current version is not a LTS.
The Qt Company really needs to
Volker Hilsheimer wrote:
> In the dependency declaration in the current dev branch [1], qtwebengine
> lists qtpositioning, and not qtlocation.
>
> [1] https://code.qt.io/cgit/qt/qtwebengine.git/tree/dependencies.yaml
>
> So I assume that this covers the geolocation functionality that was needed
>
Volker Hilsheimer wrote:
> From what we see (in download numbers and when talking to customers
> waiting for Qt Location), making Qt Location work with Qt 6.2 brings the
> most value to most users, Open Source or otherwise.
Your download counts do not include Open Source users because those get Qt
Volker Hilsheimer wrote:
> - we make Qt Location available as versions that works with Qt 6 LTS
> releases (ie we’ll have something that works with Qt 6.2, but won’t spend
> time on making something that is tested against 6.3 or 6.4).
IMHO, as long as Qt LTS keeps abusing that loophole in the KDE
Ilya Fedin wrote:
>> On another note, just what is org.freedesktop.Application? There are
>> ZERO references to it on freedesktop.org. If this isn't well-defined,
>> should we adventure into it? If this is a D-Bus API, then the
>> questions above about accessing the interface and implementing the
>
Lisandro Damián Nicanor Pérez Meyer wrote:
> The only patch I found is
>
> https://build.opensuse.org/package/view_file/KDE:Qt:6.2/qt6-base/0001-Tell-the-truth-about-private-API.patch?expand=1
>
> which changes the symbol to have the full major.minor.patch version on
> it.
FYI, Fedora also carri
Lisandro Damián Nicanor Pérez Meyer wrote:
> Sorry, that should have been
>
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6_PRIVATE_API
That should really be
_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6.3.0_PRIVATE_API
(or whatever exact version you are building), as in the openSU
Thiago Macieira wrote:
> Whether Fedora decides to up the minimum requirement for a future edition
> is something you'll be in a better position to answer than I am.
So far, I and few others have successfully blocked attempts at upping the
minimum requirement for Fedora. (The requirement for the
Thiago Macieira wrote:
> Clear Linux attempts to use a heuristic to guess which libraries it thinks
> are worth keeping the AVX2 version of. To see which ones it thought of
> qtbase, see https://github.com/clearlinux-pkgs/qtbase/blob/
> e16f08be736d28351219b05e807a6468ea39341b/qtbase.spec#L5771-L59
Thiago Macieira wrote:
> I understand. I have one of those in a cabinet, but it doesn't power on
> (the PSU is bust).
My notebook's power supply adapter went bust in 2019, but thankfully, the
circuitry inside the notebook is fine, only the external adapter had broken
down. So I replaced it with
Cristián Maureira-Fredes wrote:
> Even if it's a special module we have around only for Qt6
Hopefully that will be a long time! I sure hope you are not already planning
yet another backwards-incompatible release. A lot of stuff has not even
moved to Qt 6 yet!
Kevin Kofler
_
Thiago Macieira wrote:
> By default, I'd like us to produce x86-64 v2 code, which is SSE4.
But v1 will still be available for distribution packaging? As long as that
is the case, I do not see a major issue, it will just be one more caveat for
distribution packaging. (Distributions still supporti
Jason H wrote:
> This has forced me to reconsider Qt as essentially closed source, I will
> be brushing up on my web dev skills and just going electron/cordova in the
> future. I wonder what this means for KDE. They probably have enough
> infrastructure to weather this storm, but the average person
Eike Ziller wrote:
> The official git repository is this:
> https://code.qt.io/cgit/qt/qtbase.git/?h=5.15
… and the unofficial one with more fixes is this:
https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15
Kevin Kofler
___
Development mailing
Giuseppe D'Angelo via Development wrote:
> 3) Unrelated to your problem, your code works in Qt 5, but in Qt 6 if
> the QHash gets modified in any way that'll invalidate your entire
> QVector you're keeping as a cache. If you want to future proof your code
> you'll need to redesign that.
This parti
48 matches
Mail list logo
