Re: [Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Edward Welbourne via Development]

Eskil Abrahamsen Blomfeldt (13 March 2024 09:15) wrote:
> I would like to nominate Hatem ElKharashy for maintainership of the Qt
> Svg module. This module currently does not have any active maintainer,
> but it has been part of my team's responsibility and backlog within
> The Qt Company.

+1 - it's wonderful to see some features finally getting implemented,
that I've been using in my own SVGs for more than a decade.
QtSvg needs some love - thanks, Hatem, for giving it some,

Eddy.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [Announce] Qt 6.7.0 RC released

[List for announcements regarding Qt releases and development via Announce via Development]

Hi all!

We have released the Qt 6.7.0 RC.  As earlier you can get it via online 
installer. Src packages are also available in the Qt Account and 
download.qt.io. Delta to the beta3 attached.

Please test the RC now to see if it is OK for the final Qt 6.7.0 release and 
report all findings in Jira. Please also make sure all blockers for Qt 6.7.0 
release are visible in Qt 6.7.0 blocker list 
(https://bugreports.qt.io/issues/?filter=25675)

Target is to release Qt 6.7.0 Tue 26th March 2024.



br,

Jani Heikkinen

Release Manager

qt5.git
2ac1bddea454c70fd040c2ac7e3bb3c36035a8cf Provisioning: Fix openssl lib path on 
Debian
67e95f459126ffcb9988ce460d8fdfd4a0a0 Provisioning: Install openssl3 into 
Debian VM
3bbe6f0250ecbdcab9ddbebc4c9a3a922eb67ec1 CI: Use '-qt-doubleconversion' with 
Debian config
3d465d12d9d0f6d5cd5272ab6b55c5852887a063 Adjust submodule branches
cabe404c4afe3ada34ead301d804f5bc26a4416f Upgrade to msys2 20240113 in Windows 
provisioning
9e9dbeafa4b065cf60a1df98426377fa0301e69e COIN: Update used chroot for Debian 
packages
ee0409138b6ea7f7c5cb15c2ef26734071a1be84 Provisioning: Fix re-installing 
ca-certificates on Debian
c582745a66dfd95461ade482c96ff05116d2f19f Use SetEnvVar instead of appending 
.bash_profile with LLVM variables
dc2d69e3f092857b7e20e5917b98500c40377518 wasm: update Emscripten to 3.1.50
708ffa68a709cb39d1e3376fc5c5a34942a4efd0 Update ffmpeg: explicitly refer to the 
latest release 6.1.1
c71b6a534313c27fd4d70507c48e870da5213337 COIN: Disable Debian config from 
modules missing rules
142ffbd208fc95f519a75c7cc56155f057737f97 coin: Update provisioned qdoc, 
qtattributionsscanner binaries
37aed11625bf4b8feffd4090b370eb97fb05cd34 Enable ffmpeg shared libs shipping for 
Windows targets
82db8fadea63d580c92209bf7b294951657b8ef2 Update ffmpeg 6.0 => 6.1 for android 
targets on unix hosts
0abefd8bba53b4e5a11c6b9db729b355bf8724e3 Retain symlinks upon making universal 
macOS binaries
a92bc9040a3448848f06017306fe622f4fb0559c Provisioning: Install libclang on 
Debian 11 template
358a5f58e24f4e8330f72fdac4ef6bdb6a87ece3 Enable automatic gdb stacktrace in 
QTest, in case a test crashes
014ef281e49de61658ca12d8dbb27dc8c0b49e4b Add libprotoc libprotobuf and libgrpc 
to Debian aarch64 provisioning
qt3d:
1ccf4ff51ba2ca281b499a3e12940f4cd0e04c88 RHI: ensure there is always a valid 
m_currentUpdates
836b0f057f284fe04a82588d6658deee40601b26 Fix crash in QPaintedTextureImage when 
never calling repaint()
96f5d91b05fd91de9ae09ce194bf0d95c6a5bd0e ShaderData: Atomically generate 
property values
8cda9f709f29892c1c14c37332815303b010e734 Doc: Move examples to '3D' category
qt5compat:
0fb52b344a14aee079da16fcb6f6b698f1103529 tst_QStringRef: ensure QStringRef 
implicitly converts to QStringView
qtactiveqt:
qtbase:
a1e3d310edfb000ccead035618a40d44a3aedcfe QWindows11Style: Draw ScrollArea 
opaque in QAbstractItemView
d11d503850488d268e856e073672f317ad2d QWindows11Style: Update font size in 
menubar items and spacing between items
1e96139cf273d144e6d90b4b925f7b8670a5f788 Android: Resize QWindow when its 
QtView is resized
0533f7c075863b7c1541a5caa8340158923a8569 Android: Synchronize window creation 
in QtEmbeddedDelegate
44ee8df9c73cc712021f10ecb5df399765a6a6af QWindows11Style: Draw frames HighDPI 
aware
f26e0996c752dfbb5768ac5b0e355638a32b9d72 JNI: Fix error with overload 
resolution when passing string types
7c74a2af73b708902e42bd019651d907159b7836 QFutureInterface: Rename "interface" 
variables to "iface"
157f7b47e460a388baa6f162383462febb2a0877 Handle drag leave when performing 
platform drag of docks or toolbars
2bc6b25c5655e17f65a3a7fd84ba38f203f5cf4a Map drag event positions to global 
during dock/toolbar drag
5605c5a32f36ce0dcc30e435afbbbc7047a086a3 Add include for QT_CONFIG
ad0c09d3632935e9f951f895214ca0f1037a1c78 CMake: Don't add default rpaths to qt 
qml plugins when requested
56d1754c2ea5ef670187b6034421c17d307d3e73 CMake: Fix assignment in 
internal_get_build_vars_for_external_projects
c80f4750552818bf334cf23abf572c98dee675e0 QSpan: add construction from 
initializer_list
9ea3087d365fa9184d06d4f164ad73f905bab7bd Revert "QStringView: simplify the 
constructor from QString"
244618c19af8c5bc5b39c1dc6c0c387e7040b50b QLibrary: remove the unnecessary 
parentheses around dlerror()
8007f6acb160659ae6cb02269c5a92cbb4fa tst_toolsupport: make the i386 case 
really about i386
aeb51edf3399cb65e11232753e81548b64e54353 Add QT_CONFIG(signaling_NaN) around 
the signaling_NaN limit function
bdf324871a7f1d924cf23e7311390db64aa6b99d drm: Fix having more than window over 
the screen's lifetime
e3b2386dd7d3078b398c76a2715e3ff318223982 drm: atomic: Avoid device busy when 
flipping after creating a new window
bfb6f4e86c8d96015d73095e9cc187676129b94c CMake: add options to not generate 
target wrappers
2f50deafbf7320d5a122ae437d6dbff422961336 Revert "Fix export of 
QDeferredDeleteEvent, should be Q_CORE_EXPORT"
c76dd919fd89a9cf4fcbbf162423d12f3b5d6090 Revert "QAndroidPlatformInputContext: 
send composition 

Re: [Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Eirik Aavitsland via Development]

+1 - that would be awesome!

- Eirik Aa.

On 3/13/24 09:15, Eskil Abrahamsen Blomfeldt via Development wrote:

Hi,

I would like to nominate Hatem ElKharashy for maintainership of the Qt 
Svg module. This module currently does not have any active maintainer, 
but it has been part of my team's responsibility and backlog within The 
Qt Company.


Hatem has recently been working on adding support for new SVG features 
in Qt Svg, as well as fixing bugs and greatly improving the test 
coverage in the module. I think he is a great candidate to take on the 
maintainership of this module.


Authored changes:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io 



Reviewed hanges:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io 



--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines

The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io

The Future is Written with Qt

--




--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Should QObject::event() be protected or public?

[Ilya Fedin]

On Wed, 13 Mar 2024 07:58:20 +
Marc Mutz via Development  wrote:

> Hi,
> 
> In API review, we detected some overrides that changed the access 
> specifier vis-a-vis the original virtual function 
> (https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes 
> Item 5.3).
> 
> One of them was a protected reimplementation of QObject::event()
> (which itself is public).
> 
> The reason why QObject::event() is public seems lost to history, but
> the feeling in the review comments¹ was that it should have been
> protected from the get-go (and QObject befriended by whoever delivers
> events).
> 
> If you see any reason for QObject::event() to stay public in Qt 7 and 
> not become protected, please speak up before we fork Qt 7.0 :)
> 
> Thanks,
> Marc
> 
> ¹ 
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/
> 

Telegram Desktop has a use-case that it has a menu bar with actions
having shortcuts like QKeySequence::Copy which are implemented as
sending a QKeyEvent press/release sequence with the appropriate (same)
shortcut to the currently focused widget. This is done using
QObject::event directly to avoid a recursion as the menu bar hijacks
the QKeyEvents if QCoreApplication::sendEvent is used.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Should QObject::event() be protected or public?

[Jaroslaw Kobus via Development]

Most probably making it protected (temporarily) and trying to build everything 
else (including QtCreator) may reveal the original reason for being public.

Jarek


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Wednesday, March 13, 2024 8:58 AM
To: development@qt-project.org
Subject: [Development] Should QObject::event() be protected or public?

Hi,

In API review, we detected some overrides that changed the access
specifier vis-a-vis the original virtual function
(https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes
Item 5.3).

One of them was a protected reimplementation of QObject::event() (which
itself is public).

The reason why QObject::event() is public seems lost to history, but the
feeling in the review comments¹ was that it should have been protected
from the get-go (and QObject befriended by whoever delivers events).

If you see any reason for QObject::event() to stay public in Qt 7 and
not become protected, please speak up before we fork Qt 7.0 :)

Thanks,
Marc

¹
https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/

--
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Should QObject::event() be protected or public?

[Giuseppe D'Angelo via Development]

Il 13/03/24 08:58, Marc Mutz via Development ha scritto:

If you see any reason for QObject::event() to stay public in Qt 7 and
not become protected, please speak up before we fork Qt 7.0 :)



I am *positive* that there's code out there that just calls event() to 
deliver an event.


(Maybe there's even a use case -- attempt a deliver from an event filter.)

So, basically, we dag our own grave there, this has to stay public for 
the future ...


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



smime.p7s
Description: Firma crittografica S/MIME
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

I would like to nominate Hatem ElKharashy for maintainership of the Qt Svg 
module. This module currently does not have any active maintainer, but it has 
been part of my team's responsibility and backlog within The Qt Company.

Hatem has recently been working on adding support for new SVG features in Qt 
Svg, as well as fixing bugs and greatly improving the test coverage in the 
module. I think he is a great candidate to take on the maintainership of this 
module.

Authored changes:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io

Reviewed hanges:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io


--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines



The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io



The Future is Written with Qt

--


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Should QObject::event() be protected or public?

[Marc Mutz via Development]

Hi,

In API review, we detected some overrides that changed the access 
specifier vis-a-vis the original virtual function 
(https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes 
Item 5.3).

One of them was a protected reimplementation of QObject::event() (which 
itself is public).

The reason why QObject::event() is public seems lost to history, but the 
feeling in the review comments¹ was that it should have been protected 
from the get-go (and QObject befriended by whoever delivers events).

If you see any reason for QObject::event() to stay public in Qt 7 and 
not become protected, please speak up before we fork Qt 7.0 :)

Thanks,
Marc

¹ 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] On Removing Public Undocumented/\internal APIs

[Marc Mutz via Development]

TL;DR: Make qdoc openly document \internal members of documented 
classes/namespaces or defined in public headers as "Internal. Subject to 
change without notice. If you feel this function should be public, file 
a bug report with your use-case."?

On 07.03.24 10:09, Volker Hilsheimer wrote:
>> On 4 Mar 2024, at 10:57, Marc Mutz via Development 
>>  wrote:
>>
>> Hi,
>>
>> TL;DR:
>> - Treat all APIs not clearly marked as private (private access, *Private
>>namespace or "We mean it!" comment) as public, in particular keep SC/BC
>>and deprecate before remove.
>> - Avoid adding APIs that aren't clearly private or public in the future.
> 
> […]
> 
>> I would suggest that we treat any entity defined in a header file that
>> is not in a *Private namespace or under the umbrella of an "We mean it!"
>> commant, in short: anything that isn't _visible_ as non-public API _from
>> the header file_, as semi-public, and apply the same rules as for public
>> API: keep BC/SC, deprecate first, remove second, and adjust QUIP-6
>> accordingly.
> 
> I think we have to acknowledge that Qt is 30 years old this year, and over 
> the decades the capabilities of tools, the features of the languages, and the 
> best practices, skills, and awareness of the people working on Qt have 
> changed a lot. What usually hasn’t changed is the *intent* of the class 
> author - even though it might be buried deep in the historical repositories. 
> Stating now that everything that has the technical appearance of a public API 
> cannot be changed, and ignoring the author’s intent, does not seem 
> constructive.

Two users have come out and said that they think public undocumented API 
is fair game. If there's a difference between the expectations of users 
and expectations of API authors, do you _really- propose to pick the 
author's?

> 
>> ¹ Off the top of my head: QString::isSimpleText(), QPen::data_ptr(),
>> QDeferredDeleteEvent
> 
> Undocumented APIs in any SDK are, IMHO, “use at your own risk”. I (or my IDE) 
> might find something promising in some public header, but if I have no 
> information about what the author of that thing is promising me, should I use 
> it in my code? Sometimes it’s more obvious than other times, but what on 
> earth is the semantics of "QString::isSimpleText”? What is that “DataPtr” 
> reference returned by "QPen::data_ptr”? Can anyone use 
> QDeferredDeleteEvent::loopLevel() in a meaningful way without studying the 
> event delivery code?

It's not for me to prove that these functions are useful or not. It's 
for the changers and removers of these functions to prove that no-one 
uses them.

But ok, let's see:

- the data_ptr() could be used as a null-check (there's no QPen::isNull())
- QDeferredDeleteEvent could have been posted to an object in another 
thread, because there was doubt as to whether deleteLater() was actually 
thread-safe, but posting events is known to be (_I_ had to look that up 
myself just now).

I have no use-case for isSimpleText(), but what, exactly, did the Qt 
project gain by removing it instead of deprecating it as "We have found 
no use for this function. If you use it, please report a bug."?

The question that remains unanswered is this: Given that _we_ know how 
to deal with change and _we_ control the changelog, why should our 
_users_ be subjected to unannounced breaks of in-good-faith code?

There's a time for such changes: a major release. A minor release is - 
IMHO - not a time for such changes.

We have all the tools we need to not step on our users' toes here, while 
still pre-programming for a smooth transition for us come Qt 7. If we 
decide to nevertheless do these changes before Qt 7, what, exactly, does 
that say about our priorities?

>> At the same time, we should make sure that we don't accept such
>> semi-public APIs going forward anymore.
> 
> I do agree that we shouldn’t add more such stuff, at least not without making 
> it visible in the header, ideally in a way that makes it visible to code 
> completion (if that’s possible at all).
> 
> For stuff that is there today (e.g. various container types’ “isSharedWith” 
> public member function, usually documented explicitly as \internal, and often 
> used in other modules or in tests so not really practical to do it any other 
> way), should we add a "// internal” comment in the header file?

Why is isSharedWith() \internal in the first place? The containers are 
publicly documented to be implicitly shared, so the likes of isShared(), 
isSharedWith() and detach() should be public documented functions, IMHO.

For new \internal API, something like _internal as part of the function 
name is probably a good idea. Then qdoc could automatically skip them. 
Oh, that gives me an idea: QDoc could take \internal members of a 
documented class/namespace (or defined in a public header) and 
explicitly document them as "Internal, subject to change w/o notice. If 
you feel this entity should be public API, report a bug .".