Re: [Development] Future of java-style iterators?

[Thiago Macieira]

On Tuesday, 5 December 2023 14:02:36 PST Giuseppe D'Angelo via Development 
wrote:
> QDirIterator, QRegularExpressionMatchIterator, (private) QStringIterator
> and similar don't have replacements yet.
> 
> Yes, one can wrap a Java iterator back into a range API (as I've done
> for QREMI, so you can use do `for (auto match : re.globalMatch(subj)`),
> but then one really wants C++20 for the algorithms.

QDirIterator could be rewritten either as an input or a forward Standard 
Library iterator. It wouldn't be a bad idea because its implementation is 
broken: while you're trying to get the information about the current item, 
it's stat()ing the next. It's also hard to guess which element you're getting 
and whether you're accidentally skipping the first entry, or missing the last 
one.

All of which are caused by the fact that it *is* a Java-style iterator.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Future of java-style iterators?

[Giuseppe D'Angelo via Development]

Hello,

Il 05/12/23 22:15, Mathias Hasselmann via Development ha scritto:

would QDirIterator[1] be part of this deprecation? Its API clearly seems
be inspired by the Java-style iterators.

While I do not care much about the other Java-style iterators, I really
like this iterator and use it a lot.
What would be this iterator's modern replacement in Qt?
Some classes still only have Java-like iterators, not STL-like, so it 
would not make sense to deprecate them there.


QDirIterator, QRegularExpressionMatchIterator, (private) QStringIterator 
and similar don't have replacements yet.


Yes, one can wrap a Java iterator back into a range API (as I've done 
for QREMI, so you can use do `for (auto match : re.globalMatch(subj)`), 
but then one really wants C++20 for the algorithms.



Thank you,

--
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

Re: [Development] Future of java-style iterators?

[Jaroslaw Kobus via Development]

https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/filesearch.h

FileContainer & FileContainerIterator could be an inspiration, too.
The SubDirFileContainer enables traversal according to the selected filters and 
exclusion filters.
This all is a part of the Utils lib inside QtCreator.

Jarek


From: Development  on behalf of Andreas 
Aardal Hanssen 
Sent: Tuesday, December 5, 2023 10:26 PM
To: Qt Development
Subject: Re: [Development] Future of java-style iterators?

How about QDir::iterator, QDir::cbegin, basically make QDir a container? Or 
make a new class that serves the same purpose… /me likes the QDir idea.. :-)

Andreas

Tir 5 des 2023 kl. 22:15 skrev Mathias Hasselmann via Development:
Hi,

would QDirIterator[1] be part of this deprecation? Its API clearly seems
be inspired by the Java-style iterators.

While I do not care much about the other Java-style iterators, I really
like this iterator and use it a lot.
What would be this iterator's modern replacement in Qt?

Ciao
Mathias

[1] https://doc.qt.io/qt-6/qdiriterator.html

Am 03.12.2023 um 21:56 schrieb Christian Ehrlicher:
> Hi,
>
> Some days ago we got an error report in the forum about QHashIterator,
> turned out to be a missing documentation for a complete class which
> remained unnoticed since Qt 6.0
> (https://bugreports.qt.io/browse/QTBUG-119461).
> This leads to the question if we should deprecate all java-style
> iterators since they seem to be a) not widely used and b) it looks like
> we don't support them in a way we should.
> What do you think?
>
>
> Cheers,
> Christian
>
>
--
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] Future of java-style iterators?

[Andreas Aardal Hanssen]

How about QDir::iterator, QDir::cbegin, basically make QDir a container? Or 
make a new class that serves the same purpose… /me likes the QDir idea.. :-)

Andreas

Tir 5 des 2023 kl. 22:15 skrev Mathias Hasselmann via Development:
> Hi,
> 
> would QDirIterator[1] be part of this deprecation? Its API clearly seems 
> be inspired by the Java-style iterators.
> 
> While I do not care much about the other Java-style iterators, I really 
> like this iterator and use it a lot.
> What would be this iterator's modern replacement in Qt?
> 
> Ciao
> Mathias
> 
> [1] https://doc.qt.io/qt-6/qdiriterator.html
> 
> Am 03.12.2023 um 21:56 schrieb Christian Ehrlicher:
> > Hi,
> >
> > Some days ago we got an error report in the forum about QHashIterator,
> > turned out to be a missing documentation for a complete class which
> > remained unnoticed since Qt 6.0
> > (https://bugreports.qt.io/browse/QTBUG-119461).
> > This leads to the question if we should deprecate all java-style
> > iterators since they seem to be a) not widely used and b) it looks like
> > we don't support them in a way we should.
> > What do you think?
> >
> >
> > Cheers,
> > Christian
> >
> >
> -- 
> 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] Future of java-style iterators?

[Mathias Hasselmann via Development]

Hi,

would QDirIterator[1] be part of this deprecation? Its API clearly seems 
be inspired by the Java-style iterators.


While I do not care much about the other Java-style iterators, I really 
like this iterator and use it a lot.

What would be this iterator's modern replacement in Qt?

Ciao
Mathias

[1] https://doc.qt.io/qt-6/qdiriterator.html

Am 03.12.2023 um 21:56 schrieb Christian Ehrlicher:

Hi,

Some days ago we got an error report in the forum about QHashIterator,
turned out to be a missing documentation for a complete class which
remained unnoticed since Qt 6.0
(https://bugreports.qt.io/browse/QTBUG-119461).
This leads to the question if we should deprecate all java-style
iterators since they seem to be a) not widely used and b) it looks like
we don't support them in a way we should.
What do you think?


Cheers,
Christian



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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Thiago Macieira]

On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
> 
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at 
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules 
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://www.google.com/search?q=genivi+site%253Ahttps%253A%252F%252Flists.qt-project.org%252Fpipermail%252Fdevelopment%252F

I don't know what kind of API reviews have been done since. But there has been 
no discussion about renaming this module. Therefore, the name it is currently 
using is unauthorised and does not imply a precedent.

-1 on this new module with this name.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Thiago Macieira]

On Tuesday, 5 December 2023 07:54:51 PST Dominik Holland via Development 
wrote:
> It's not a question to import something, the module literally already
> exist here: https://code.qt.io/cgit/qt/qtinterfaceframework.git for
> quite some time and for that there is a source and binary compatibility.

Then why are you asking for a repository if it's already there? When was that 
module approved by the Qt Project? I can't find anything in the email archives.

The first commit in this repository is "First version of the QtGeniviExtras 
module". When was it renamed and who approved it?

That module is not in qt5.git/.gitmodules so it's *not* a Qt module right now. 
Source- and binary-compatibility do not apply.

That Git repository is also not sync'ed to GitHub.

Anyway, I am exercising my right to vote to vote -1 on this repository request 
so long as it is using this name.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Ahmad Samir]

On 30/11/23 12:49, Giuseppe D'Angelo via Development wrote:

Hi,

OpenSSL 1 has reached EOL last September:


https://www.openssl.org/blog/blog/2023/09/11/eol-111/



Qt has supported OpenSSL 3 for a while, and so last week I pushed a
patch to drop OpenSSL 1 support from Qt. "This has made a lot of people
very angry and been widely regarded as a bad move."


It turns out that not every platform officially supported by Qt ships
OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL
1 for a little while longer, for instance Ubuntu 20.04 LTS:


https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro





See this thread started by Albert on the kde-distributions ML about the same 
issue
https://mail.kde.org/pipermail/distributions/2023-November/001459.html

Typically when you plan to support EOL software, you do the extra work on your 
own, that should include e.g. patching Qt to get that support back, and you 
maintain the patches to Qt code on your own too. That is my understanding of how 
corporate Linux support works, and it's confirmed by what Jan Grulich posted in a 
reply to the above KDE ML thread: 
https://mail.kde.org/pipermail/distributions/2023-December/thread.html


(pipermail doesn't show links to the rest of the thread if it spans multiple 
months).



How to move forward from here: "revert the patch", sure, but also not so
fast:

* First and foremost, I'd like a semi-formal insurance from Qt SSL
maintainers that they're willing to maintain OpenSSL 1 code in Qt as
long as needed. This should be done publicly, in docs + blog posts,
because users are going to depend on this information.

* For "how long" is that exactly? Also a very good question. Can we
gather 1) which supported platforms are still offering only OpenSSL 1,
and 2) for how long do they plan to support OpenSSL 1, and 3) for how
long Qt would like to support these platforms? (Basically, assessing
whether the "insurance" above is realistic)



[...]


* Then, a plain revert isn't a good idea either: the whole point of the
original commit is that using OpenSSL 1 is outright dangerous if you
don't know what you're doing. (Using unmaintained security-sensitive
code is a terrible idea). Therefore, a revert must also include make
OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic
detection whatsoever: users of Qt should never ever be enabling it "by
accident".



Just stating the obvious: I agree, must be opt-in with a clear disclaimer "You're 
on your own, if it breaks, you get to keep the pieces".


[...]


My 2p's worth.

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Dominik Holland via Development]

Am 12/5/23 um 16:34 schrieb Thiago Macieira:

On Tuesday, 5 December 2023 04:17:08 PST Dominik Holland via Development
wrote:

Right, but at the same time we cannot change of the module and all it's
classes afterwards.

Yes, you can. Any code imported into the Qt Project is subject to API reviews
and may therefore be different than when originally imported. There is no
source- or binary-compatibility guarantee offered against pre-Qt Project or
Labs implementations.

I insist: find a more precise name for the module. "Interface" is too generic,
you need one more word, at a minimum.


It's not a question to import something, the module literally already 
exist here: https://code.qt.io/cgit/qt/qtinterfaceframework.git for 
quite some time and for that there is a source and binary compatibility.



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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Thiago Macieira]

On Tuesday, 5 December 2023 04:17:08 PST Dominik Holland via Development 
wrote:
> Right, but at the same time we cannot change of the module and all it's
> classes afterwards.

Yes, you can. Any code imported into the Qt Project is subject to API reviews 
and may therefore be different than when originally imported. There is no 
source- or binary-compatibility guarantee offered against pre-Qt Project or 
Labs implementations.

I insist: find a more precise name for the module. "Interface" is too generic, 
you need one more word, at a minimum.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Dominik Holland via Development]

Dominik Holland (5 December 2023 10:03) replied:

The Qt Interface Framework is a module which already exists
(https://doc.qt.io/QtInterfaceFramework) that's what the Reference
APIs are based on.

That doesn't change the fact that the name is rather generic (and leads
to the prefix qtif, which might be mistaken for a reference to an image
format, tiff); and the module seems to be about middleware, so perhaps
Qt Middleware Interface Framework would be a more apt name, or maybe
even just Qt Middleware Framework.  I don't know what this module's
history is, or whether it's previously had its name scrutinised for
compatibility with the rest of the Qt framework, but the fact that
you're asking to add it to qt-labs makes this a moment when such
scrutiny naturally arises.

Right, but at the same time we cannot change of the module and all it's 
classes afterwards. The module exists already since 6.2.
The qt-labs repository is not for the qtinterfaceframework, but for some 
former parts of it which should be moved out of the repository and to 
qt-labs instead.
The naming of that new qt-labs module is still up for discussion, i'm 
open for good suggestions.
If qtif is the problem, we could also write it out, but that will be 
rather long:


qtinterfaceframework-reference-apis


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

Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

[Volker Hilsheimer via Development]

> On 3 Dec 2023, at 12:08, apoenitz  wrote:
> 
> On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development 
> wrote:
>> On 30/11/2023 19:39, apoenitz wrote:
>>> I propose to make this setup an official Module of Qt Creator, and herewith
>>> also nominate Jarek as Maintainer. Jarek has been pushing the idea and is 
>>> the
>>> author of the biggest existing Qt Creator Solution: TaskTree[2], so for me 
>>> this
>>> is the obvious choice.
>>> 
>>> Comments/questions/opinions?
>> 
>> Just wondering if we could extend the scope:
>> do these solutions depend on  QtCreator parts somehow?
> 
> No, and not really planned now, but there are a few potential candidates that
> depend on each other (remote file and remote process access for instance). For
> now the idea is to have only "pure" Qt users there, but if the idea in general
> flies then at some time it's imaginable that "solutions" could depend on each
> other.
> 
>> If not (I've understood that TaskTree specifically
>> doesn't), why not "just" going for a playground module?
> 
> It's not feature-complete yet, and as long as there are still additions 
> expected
> there are benefits to have that in-tree (e.g. atomic commit instead of 
> submodules)
> that we currently believe to outweigh the benefits of a "physical" separation.
> But this also may change at some time.
> 
> Andre’

Makes sense to start by moving code into a module under Qt Creator, and 
evaluate at a later point whether selected solutions could be relevant for Qt 
or generally be spun out into a separate repository.

And +1 for Jarek as maintainer.

Volker



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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Mike Trahearn via Development]

Yes, this is also in line with a request I had made about the same – and the 
documentation has already had some attention in regard to migrating away the 
“reference” APIs to differentiate the “core” APIs to affect wider adoption.

+1 from me.

Mike

Confidentiality Notice: This message (including attachments) is a private 
communication solely for use of the intended recipient(s). If you are not the 
intended recipient(s) or believe you received this message in error, notify the 
sender immediately and then delete this message. Any other use, retention, 
dissemination or copying is prohibited and may be a violation of law, including 
the Electronic Communication Privacy Act of 1986.   ­­
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Edward Welbourne via Development]

On Monday, 4 December 2023 02:10:43 PST Dominik Holland via Development wrote:
>>> the qtinterfaceframework module currently also hosts two reference
>>> APIs (qtifmedia and qtifvehiclefunctions). Both are very much
>>> automotive specific. In order to make the module also available for
>>> other industries we would like to move those two modules to a new
>>> qt-labs repository.
>>>
>>> Name of the repository: qt-labs/qtif-reference-apis.git Description:
>>> Reference modules based on the Qt Interface Framework

Am 12/4/23 um 20:34 schrieb Thiago Macieira:
>> Can we have a more descriptive name than "interface"?
>>
>> Neither QNetworkInterface nor QDBusInterface belong there, therefore
>> there must be a constraint of some sort.

Dominik Holland (5 December 2023 10:03) replied:
> The Qt Interface Framework is a module which already exists
> (https://doc.qt.io/QtInterfaceFramework) that's what the Reference
> APIs are based on.

That doesn't change the fact that the name is rather generic (and leads
to the prefix qtif, which might be mistaken for a reference to an image
format, tiff); and the module seems to be about middleware, so perhaps
Qt Middleware Interface Framework would be a more apt name, or maybe
even just Qt Middleware Framework.  I don't know what this module's
history is, or whether it's previously had its name scrutinised for
compatibility with the rest of the Qt framework, but the fact that
you're asking to add it to qt-labs makes this a moment when such
scrutiny naturally arises.

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

Re: [Development] Future of java-style iterators?

[Marc Mutz via Development]

On 05.12.23 10:06, Giuseppe D'Angelo via Development wrote:
> Il 05/12/23 03:52, Kevin Kofler via Development ha scritto:
>> 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 the STL-style ones (which, as I
>> understand it, is why they were originally added to Qt to begin with).
> 
> The huge downside is that they don't work with any algorithms or 
> range-based facilities. They work, in their little bubble.

Const ones are ok-ish, except they need to maintain two iterators 
instead of one, like STL ones, and the state depends on the history 
(specifically, whether next() or previous() was called). The problem is 
the Mutable ones. Which element does setValue() work on? Which one does 
remove() remove? I don't want to look it up, but I remember there was 
some conceptional problem there.

Also, remove() in a loop is quadratic, and since no-one ever made 
Java-style iterators for C arrays and STL containers, and they hard-code 
the name of the container in the class name without containers providing 
a typedef for them, they cannot possibly be used in generic code.

Thanks,
Marc

-- 
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] Future of java-style iterators?

[Giuseppe D'Angelo via Development]

Il 05/12/23 03:52, Kevin Kofler via Development ha scritto:

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 the STL-style ones (which, as I
understand it, is why they were originally added to Qt to begin with).


The huge downside is that they don't work with any algorithms or 
range-based facilities. They work, in their little bubble.


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

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Dominik Holland via Development]

Am 12/4/23 um 20:34 schrieb Thiago Macieira:

On Monday, 4 December 2023 02:10:43 PST Dominik Holland via Development wrote:

the qtinterfaceframework module currently also hosts two reference APIs
(qtifmedia and qtifvehiclefunctions). Both are very much automotive
specific. In order to make the module also available for other industries
we would like to move those two modules to a new qt-labs repository.

Name of the repository: qt-labs/qtif-reference-apis.git
Description: Reference modules based on the Qt Interface Framework

Can we have a more descriptive name than "interface"?

Neither QNetworkInterface  nor QDBusInterface belong there, therefore there
must be a constraint of some sort.


The Qt Interface Framework is a module which already exists 
(https://doc.qt.io/QtInterfaceFramework) that's what the Reference APIs 
are based on.

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

[Development] Buddy group to help new contributors

[Volker Hilsheimer via Development]

At the Qt Contributors Summit in Berlin last week, we discussed various ideas 
around improving the contribution experience, esp for new people.

One action that came out of that was setting up a gerrit group of people that 
are able and willing to hand-hold new contributors through the process. This 
includes setting up your local development environment, gerrit configuration 
and workflow, and finding out what to work on from e.g. Jira. The basic idea is 
that we establish a (gerrit, probably) group with buddies; we can already 
identify “first gerrit reviews" for a new user, and then we can proactively 
reach out with a welcome message, and add the group of buddies as a reviewer.

A few people raised their hand at the event, but I don’t think anyone took down 
the names, and I was busy juggling microphones. And either way, this is of 
course open to anyone! So please reply to this, either to all or privately to 
me, if you want to be part of that group.

Cheers,
Volker

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