Re: [Development] Moving QDesktopServices from Gui to Core?

[Jaroslaw Kobus via Development]

The basic question: does it mean moving any public class / function from one 
lib into another? If so, how do you want to resolve the BC issue, especially on 
Win?

Jarek


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Monday, May 6, 2024 9:02 AM
To: development@qt-project.org
Subject: [Development] Moving QDesktopServices from Gui to Core?

Hi,

Juha is currently improving the OAuth implementation in QtNetworkAuth.
The protocol involves launching the system browser to get an access
code, in turn used to get access tokens with which services can then be
accessed.

OAuth therefore requires a UI to run the browser in, but not necessarily
a _G_UI (the system browser could be lynx). Even if a CLI tool like a
mail fetcher, backup program, or VPN client will eventually launch
Firefox or Chrome, I think it's too much to ask to link to QtGui just to
do the equivalent of exec xdf-open .

I've looked at the implementation of openUrl(), and the only
Gui-dependency is on the platform helpers. The handler registration is
only using Core functionality.

I would therefore propose to move the services code from Gui to Core
(QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
dependency.

After a quick look, I can see two ways to do that:
- keep the platform handling code in the platform helpers, incl. Gui
dependency, and only move the handler registration to Core
- move the platform url handlers out of the platform helpers into (a
plugin for) Core

The first would enable users to write their own handlers w/o Gui
dependency, but has the disadvantage that the code behaves differently,
depending on whether QtGui is loaded or not.

The second would be more work, but with consistently better user experience.

Is there a reason other than history for the openUrl handlers to be in
the platform handlers? We have XDG-code in QtCore already (mime types),
so we should have all the information in Core already to implement the
functionality, should we not?

Thanks,
Marc

--
Marc Mutz  (he/his)
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?

[Jaroslaw Kobus via Development]

> From: Development  on behalf of Giuseppe 
> D'Angelo via Development 
> Sent: Friday, March 15, 2024 8:58 PM
> To: development@qt-project.org
> Subject: Re: [Development] Should QObject::event() be protected or public?
>
> Il 15/03/24 19:22, Giuseppe D'Angelo via Development ha scritto:
>> Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto:
>>> +1. Typically, the designer of a subclass knows what he is doing. But it
>>>also happens that users of this class know better how to use it :)
>> I'm not sure what this means.
>>
>> If you override `event()` (public in QObject) as e.g. protected, it's
>> either a mistake in good faith (you thought it was protected all along),
>> but it's never a "I know better". You clearly*don't*  know better, as
>> you don't know C++.
>
> I'm really sorry, I just realized that this can be read in a very
> offensive way: the "you" above was in *no* way directed to Jaroslaw
> Kobus. It was a generic "you" -- as opposed as "I know better", for a
> generic subject "I", not necessarily the writer. I apologize to
> Jaroslaw if this caused a misunderstanding.

Don't worry, Peppe, I didn't take it personally, all is fine :)

To the point: we are talking here about decreasing the visibility of a member 
function in a subclass.
The virtuality of the method isn't relevant I guess, is it?
I've never used it personally, but the fact that C++ language designers let it 
compile, even without a warning, makes me wonder that there were some reasons 
for it.
Just found some reasoning, though not sure how much valid it is:
https://www.learncpp.com/cpp-tutorial/hiding-inherited-functionality/

Probably there are more resources about this topic in the internet.

Regards

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

> From: Development  on behalf of Thiago 
> Macieira 
> Sent: Friday, March 15, 2024 7:03 PM
> To: development@qt-project.org
> Subject: Re: [Development] Should QObject::event() be protected or public?
> 
> On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote:
>> I like simple rules. "Overrides should have the same access level as the
>> initial virtual function." is a simple rule.
>
> Amend that to "... unless there's an explicit reason not to". With that, I'm
> ok. As you can still access by casting to a base, that had better be a good
> reason.

+1. Typically, the designer of a subclass knows what he is doing. But it also 
happens that users of this class know better how to use it :)

Jarek
-- 
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] 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] QTimer question

[Jaroslaw Kobus via Development]

> On Tuesday, 30 May 2023 12:25:10 PDT Jaroslaw Kobus wrote:
> > Hi Thiago,
> >
> > thank you for your answer. There are 3 main points:
> >
> > 1. Coarsing is OK and I'm totally fine with having my timers called a bit
> > earlier or later (within 5% accuracy).
> >
> > However, this doesn't explain why I can't rely on the proper order in the
> > given example.
>
> You can today, with the current implementation, but it's not a promise we've
> made in the documentation. Today, it always rounds down to the target
> boundary, never up, and the target boundary only depends on the requested
> timeout. Therefore, two timers with the same timeout will trigger always in
> the order they were started.
>

Yeah, not promising in docs is fine. However, (form the 3rd point)
documenting explicitly, than you can't rely on an intuitive behavior, may help 
some users.

> > Recently I was rewriting the autotests for the TaskTree
> > (https://doc-snapshots.qt.io/qtcreator-extending/tasking-tasktree.html),
> > and wanted to use the simplest possible asynchronous task, instead of a
> > concurrent call. I've concluded it must be a singleShot(). Inside the tests
> > I need to rely on the proper order of timers' timeouts. It would be cool to
> > have it in Qt. Anyway, it looks like currently I need to implement the
> > above solution on my own (at least until it's done in Qt, if decided so).
>
> It's only a matter of documentation, not implementation: do we want to
> establish on stone that the order is and will forever be maintained, per
> timeout value?

I don't know whether setting it in stone is the best possible choice,
since the extra implementation may insignificantly slow down the runtime.
Could it be maybe optional, configurable? I don't know...

> This doesn't apply if you start a timer with 1000 ms and then the next 20
> milliseconds later with 980ms.

It does. It really doesn't matter, in fact.

If you start the first one, say at 12:00:00 [000] ms, and the second one at
12:00:00[020], the crucial thing is what target timestamp both calls register
inside a call to singleShot(). To make it really explicit, the singleShot()
could return the registered expectedTimeoutTimestamp value. In this way
the user may rely on the returned value and may expect the handlers
are executed exactly in the returned timestamp order.

> > 2. Regarding:
> > > It will depend on the timeout too. For single-shot timers, timers below 2
> > > seconds are Precise, which means only those above that threshold will
> > > suffer reordering.
> >
> > It doesn't look so, unfortunately. I've written the following test:
> >
> > QTimer::singleShot(1, this, [&] { log.append(1); });
> > QTimer::singleShot(1, this, [&] { log.append(2); });
> >
> > Both timeouts are 1ms, and I'm observing the opposite order on CI machine:
> > https://codereview.qt-project.org/c/qt-creator/qt-creator/+/480663/1
>
> That shouldn't be happening:
> void QTimerInfoList::timerInsert(QTimerInfo *ti)
> {
> int index = size();
> while (index--) {
> const QTimerInfo * const t = at(index);
> if (!(ti->timeout < t->timeout))
> break;
> }
> insert(index+1, ti);
> }
>
> This should cause the timer to be inserted after the last timer for which its
> timeout wasn't smaller. QTimerInfoList::activateTimers() respects that order,
> so the second should trigger after the first.

I don't know QTimer's internals, so I can't comment on this. However, please
refer to what the CI machine reports for:
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/480663/1

> > Moreover, if I change it to:
> >
> > QTimer::singleShot(1, this, [&] { log.append(1); });
> > QTimer::singleShot(2, this, [&] { log.append(2); });
> >
> > I still observe the opposite order, even when the second shot, executed
> > later, with 100% longer interval, may still come before the first:
> > https://codereview.qt-project.org/c/qt-creator/qt-creator/+/480663/2
> > (the same change, different patchset). So, in this case it looks like the 5%
> > tolerance is beaten considerably up to 100%.
>
> That's not about the 5% tolerance, because 5% of less than 20 rounds down to
> 0. Any timer of less than 20 ms is Precise, and therefore wakes up exactly
> when you asked it to. However, the sleep may have been for more than 1 ms so
> the second timer was expired by the time we woke up.

The basic question is:

If we define a tolerance of 5% for a Course timer, could we also define what 
100% is?

I don't know what "sleep" you are referring to. Please refer to the tests I've 
provided lin

Re: [Development] QTimer question

[Jaroslaw Kobus via Development]

[Re-sending my reply to Thiago to the mailing list, as I think it may be 
possibly interesting for more people.]
[In meantime I've created 
https://codereview.qt-project.org/c/qt/qtbase/+/480703 and waiting for CI 
results.]

> On Monday, 29 May 2023 11:40:14 PDT Jaroslaw Kobus via Development wrote:
> > Hi All,
> > 
> > when I start 2 single shot timers synchronously in a row, with exactly the
> > same interval, from the same thread, can I rely on having their handlers
> > called in the same order in which they were started?
> > 
> > I.e.:
> > 
> > QTimer::singleShot(1000, [] { qDebug() << "1st timer elapsed"; });
> > QTimer::singleShot(1000, [] { qDebug() << "2nd timer elapsed"; });
> > 
> > Should I always see the:
> > 
> > 1st timer elapsed
> > 2nd timer elapsed
> > 
> > on the output, or should I expect the random order?
> 
> Strictly speaking, no, you can't. Because timers aren't precise, timers can 
> be 
> delivered early or late by 5% if they are Coarse. Therefore, the order will 
> depend on which direction the rounding went, which depends on how long it 
> took 
> you between scheduling those two timers.
> 
> It will depend on the timeout too. For single-shot timers, timers below 2 
> seconds are Precise, which means only those above that threshold will suffer 
> reordering.
> 
> For non-QTimer::singleShot, all timers are Coarse by default.

Hi Thiago,

thank you for your answer. There are 3 main points:

1. Coarsing is OK and I'm totally fine with having my timers called a bit
earlier or later (within 5% accuracy).

However, this doesn't explain why I can't rely on the proper order in the given 
example.
I can imagine that the expected order is preserved even when having coarse 
timers.
The simple implementation could look like:

Keeping a global hash (per thread?) of started timers together
with their expected timeout timestamp, and the opposite map:

QHash timerIdToDeadline;
QMap deadlineToTimerId;

Whenever calling the singleShot(), the implementation should add and item to 
the map and hash.
The expectedTimeoutTimestamp would be set:
expectedTimeoutTimestamp = currentTime + timerInterval;

Whenever any timer (timer X) timeouts, and before it emits a timeout signal 
publicly,
it could lookup the hash for its expectedTimeoutTimestamp.
Before emitting the timer X's timeout, it should emit timeouts for timers that 
have their
expectedTimeoutTimestamp lower than the timer X's expectedTimeoutTimestamp
(i.e. those, that are before the timer X's expectedTimeoutTimestamp inside the 
deadlineToTimerId map).
In this case, all the extra timers that emitted their timeout should be removed
from map and hash, and later, when theirs internal activation signal comes - 
the public emission
should be omitted.

When adding a mutex to the map and hash, it could probably also work for all 
threads.

Recently I was rewriting the autotests for the TaskTree
(https://doc-snapshots.qt.io/qtcreator-extending/tasking-tasktree.html),
and wanted to use the simplest possible asynchronous task, instead of a 
concurrent call.
I've concluded it must be a singleShot(). Inside the tests I need to rely on 
the proper order
of timers' timeouts. It would be cool to have it in Qt. Anyway, it looks like 
currently I need
to implement the above solution on my own (at least until it's done in Qt, if 
decided so).

I may create a task request ticket for it, if you want me to.

2. Regarding:

> It will depend on the timeout too. For single-shot timers, timers below 2 
> seconds are Precise, which means only those above that threshold will suffer 
> reordering.

It doesn't look so, unfortunately. I've written the following test:

QTimer::singleShot(1, this, [&] { log.append(1); });
QTimer::singleShot(1, this, [&] { log.append(2); });

Both timeouts are 1ms, and I'm observing the opposite order on CI machine:
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/480663/1

Moreover, if I change it to:

QTimer::singleShot(1, this, [&] { log.append(1); });
QTimer::singleShot(2, this, [&] { log.append(2); });

I still observe the opposite order, even when the second shot, executed later,
with 100% longer interval, may still come before the first:
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/480663/2
(the same change, different patchset). So, in this case it looks like the 5%
tolerance is beaten considerably up to 100%.

I may create a bugreport for it, if you want me to.

3. Despite of how 1. and 2. will be proceeded, I think we should clearly 
document it.
It's really not obvious that Qt users can't rely on the proper order of 
timeouts.

I may create a bugreport for doc team, if you want me to.

Best regards

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

[Development] QTimer question

[Jaroslaw Kobus via Development]

Hi All,

when I start 2 single shot timers synchronously in a row, with exactly the same 
interval, from the same thread, can I rely on having their handlers called in 
the same order in which they were started?

I.e.:

QTimer::singleShot(1000, [] { qDebug() << "1st timer elapsed"; });
QTimer::singleShot(1000, [] { qDebug() << "2nd timer elapsed"; });

Should I always see the:

1st timer elapsed
2nd timer elapsed

on the output, or should I expect the random order?

Asking here, since I can't find the answer in Qt docs.

Br,

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

Re: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style

[Jaroslaw Kobus via Development]

> - drop the requirement for () in lambdas
> 
> Rationale: this was a word-around for older MSVCs. The standard doesn't
> require the empty parameter list (except when adorning the lambda with
> noexcept etc, and then the compiler complains) and people have voted
> with their feet: we now have many uses of [] {} in Qt already.

I support it and we have such a rule in QtC already. However, please note that 
when you specify the return type of
the lambda or define it mutable, the compiler issues the following warnings 
currently:

int bla = 0;
const auto foo = [] -> int { return 0; };
const auto bar = [bla] mutable { bla = 4; return 0; };

warning: parameter declaration before lambda trailing return type only optional 
with ‘-std=c++2b’ or ‘-std=gnu++2b’
   72 | const auto foo = [] -> int { return 0; };
  | ^~
warning: parameter declaration before lambda declaration specifiers only 
optional with ‘-std=c++2b’ or ‘-std=gnu++2b’
   73 | const auto bar = [bla] mutable { bla = 4; return 0; };
  |^~~

When you add empty (), the compiler is silent.

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

Re: [Development] API style guide: scoped enum or not?

[Jaroslaw Kobus via Development]

>> On 4 May 2023, at 17:34, Marc Mutz via Development 
>>  wrote:
>>
>> On 04.05.23 15:38, Volker Hilsheimer via Development wrote:
>>> Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or 
>>> QSlider::Orientation::Horizontal?
>>
>> Without looking at the docs, tell me what QSplitterHandle::orientation()
>> means :)
>
> The same that it would mean if it would return Qt::Orientation::Horizontal or 
> Qt::HorizontalOrientation :)
>
> I’m guessing: whether the handle gets dragged horizontally or vertically, ie 
> the opposite of what one would expect (whether the handle is v horizontal or 
> vertical line). In which case the problem is the name of the property not of 
> the enum type.

I remember that couple of years ago Eike did a pool on how name actions 
regarding horizontal and vertical splitting inside QtCreator. So, for some, the 
"horizontal" means that they want to see a horizontal splitter bar after the 
split, and for others it means that they want to see horizontally arranged 
editors (from left to right). The outcome was that we have now "Split" and 
"Split Side by Side" actions.

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

Re: [Development] API style guide: scoped enum or not?

[Jaroslaw Kobus via Development]

"enum class" has one advantage over "enum" inside a "class" : you may forward 
declare the "enum class", while the other not. That's quite often case that 
your header must include the other header just because you use the "enum" in 
"class" in your API and nothing more.

Jarek


From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Wednesday, May 3, 2023 7:39 PM
To: Macieira, Thiago
Cc: development@qt-project.org
Subject: Re: [Development] API style guide: scoped enum or not?



On 3 May 2023, at 19:22, Thiago Macieira  wrote:

I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're sufficiently descriptive already.

Agreed, and this is also what our current API design guide says:


API Design Principles - Qt 
Wiki
wiki.qt.io
[favicon.ico]


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

Re: [Development] Nominating Marcus Tillmanns as Approver

[Jaroslaw Kobus via Development]

+1

Good job, Marcus!

Jarek


From: Development  on behalf of Cristian 
Adam via Development 
Sent: Tuesday, November 22, 2022 10:39 PM
To: A. Pönitz; development@qt-project.org
Subject: Re: [Development] Nominating Marcus Tillmanns as Approver

+1

Cheers,
Cristian.

Disclaimer: I work with Marcus in the same team.


From: Development  on behalf of A. Pönitz 

Sent: Tuesday, November 22, 2022 22:27
To: development@qt-project.org 
Subject: [Development] Nominating Marcus Tillmanns as Approver



I'd like to nominate Marcus Tillmanns as an approver for the Qt project.

Marcus has been working on Qt Creator since April, mostly on Docker
support and remote file access/command execution, but also on LLDB
support and various other changes across the code base.

He made already several excellent contributions, most notably authored
the remote filesystem browsing capabilities in Creator 9.

I trust him to be a good approver.

Link to his gerrit dashboard:

Patches:
https://codereview.qt-project.org/q/owner:marcus.tillmanns%2540qt.io
Reviews:
https://codereview.qt-project.org/q/reviewer:marcus.tillmanns%2540qt.io

We are working in the same team, and share an office.

Andre'

___
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] How qAsConst and qExchange lead to qNN

[Jaroslaw Kobus via Development]

> 1. Use overloads for methods that take views or spans. In new API we can
> omit the methods that take owning containers. If the overload set grows
> out of hand, don't add the view/span alternative until we can remove
> something. By Thiago's argument, that means not to convert existing
> methods to QStringView for now.
> 
> 2. Use the postfix "View", "Span" or "Generator" for methods that return
> views, spans or generators rather than owning containers. This way it's
> harder for users to mess up the life time.

Ad 1. Having overloads sometimes causes issues, like e.g. can't be a slot due to
ambiguity when making a signal-slot connection. For this reason I believe that
most (all?) of signals overloads were removed in Qt 6. The similar issues may
be encountered when using QtConcurrent API.

So, if you suggest suffix for Ad 2, maybe make it consistent and use the same 
suffix for Ad 1, too?

Disclaimer: I'm not saying that adding "view" and "span" functionality into Qt 
is a good idea.
It's a bit like giving a raw pointer of some part of your internal data into 
the public API
(however, wrapped nicely with a fashionable envelope - so it shouldn't look so 
bad, right?).
Yeah, in some cases it may save 1 ns for containers having thousands of items. 
But will it make
e.g. rendering QGradient faster (when gradient stops are wrapped with span, as 
Mark suggested)?
Especially, as it was mentioned, typical case is 2, max 3 items?

Qt was always cute, because its API was designed so that it's really hard to 
mess things up.
It looks like we are slowly dropping this beautiful keynote, unfortunately.

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

Re: [Development] Qt 6.2.6 LTS Commercial released

[Jaroslaw Kobus]

Wow!

This thread already generated 12 messages - this one is the 13th. How many 
possible future commercial release e-mails could substitute all the posts from 
this thread? Would we be around 2024 already or later, isn't it?

Is there really no bigger problem in the cruel world right now these days than 
wondering whether the sent e-mail with info about commercial release can or 
can't be filtered conveniently enough out by interested people?

How many of subscribers receive this e-mail thread and feel much more 
uncomfortable with this thread comparing to the rare info about commercial 
release (unwanted by some, apparently wanted by others)?

Keep safe!

Jarek


From: Development  on behalf of Albert 
Astals Cid 
Sent: Wednesday, September 28, 2022 9:58 PM
To: development@qt-project.org
Subject: Re: [Development] Qt 6.2.6 LTS Commercial released

El dimecres, 28 de setembre de 2022, a les 21:23:57 (CEST), Lorn Potter va
escriure:
> On 27/9/2022 9:28 pm, Konstantin Ritt wrote:
> > Please stop announcing this kind of updates through the development
> > mailing list!
>
> Please do *not* stop sending releasing information emails on this list.
> I kinda like knowing about them.
>
> Release information, regardless of open source or commercial licensing,
> is relevant to Qt development, even if you are an open source purist
> and/or understand the realities of the software industry.

If you want to learn about release announcements of Qt, you should subscribe
to the list that precisely is about release announcements of Qt.

https://lists.qt-project.org/listinfo/announce

Best Regards,
  Albert



___
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

[Development] Fw: How to do deprecation

[Jaroslaw Kobus]

"So instead of

#if QT_DEPRECATED_SINCE(6, 4)

QT_DEPRECATED_VERSION_X_6_4("Use size() or length() instead.")

inline qsizetype count() const { return d.size; }

#endif

You’d have:

QT_DEPRECATED_METHOD(qsizetype count(), 6, 4, "Use size() or length() 
instead.”)
"

Hi,

it would be really cool to have it like this. However, just joining 
QT_DEPRECATED_SINCE with QT_DEPRECATED_VERSION_X_Y_Z would also be a small and 
simple step forward.

Jarek



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

Re: [Development] Nominating Ievgenii Meshcheriakov for approver

[Jaroslaw Kobus]

+1

Disclaimer: nothing to disclaim, +1 fully deserved.


From: Development  on behalf of Edward 
Welbourne 
Sent: Wednesday, April 6, 2022 2:13 PM
To: Alex Blasche
Cc: development@qt-project.org
Subject: Re: [Development] Nominating Ievgenii Meshcheriakov for approver

Alex Blasche (6 April 2022 14:05) wrote:
> I'd like to nominate Ievgenii Meshcheriakov as approver in the Qt Project.

+1

> Disclaimer: I am Ievgenii's line manager in TQtC and as such have a close 
> working relationship with him.

and I'm in the team he leads,

Eddy.
___
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] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Jaroslaw Kobus]

+1


From: Development  on behalf of Richard 
Gustavsen 
Sent: Tuesday, January 25, 2022 9:38 AM
To: Qt development mailing list
Subject: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt 
Widgets

Hi all!

I would like to propose a change in the maintenance of Qt Widgets [1]. I’m the 
current maintainer of the module, but I’m happy to inform you that Volker 
Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
biggest contributors to Widgets [2], and has been helping out maintaining the 
module for a long time already. So let’s make it formal as well!

[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

___
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] Nominating Sona Kurazyan as maintainer of qt5compat

[Jaroslaw Kobus]

+1

Sone indeed does a very good job!

Best regards

Jarek


From: Development  on behalf of Cristián 
Maureira-Fredes 
Sent: Tuesday, January 18, 2022 3:10 PM
To: development
Subject: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

Hello,

I would like to nominate Sona as maintainer [1]
for the qt5compat module, which at the moment doesn't
have one. Even if it's a special module we have around
only for Qt6, we need a responsible person in charge of it.

She has been working mainly in qtbase in the last years
and took care of many tasks when the module was created [2].

Due to her contributions in qtbase and other modules [3],
I firmly believe she will manage to maintain it.

Cheers


[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2]
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged
[3]
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged

--
Dr. Cristián Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

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] Nominating Andreas Buhr as approver

[Jaroslaw Kobus]

+1


From: Development  on behalf of Paul 
Wicking 
Sent: Thursday, April 29, 2021 8:20 AM
To: development
Subject: [Development] Nominating Andreas Buhr as approver

Hi all,


I’d like to nominate Andreas Buhr as approver for the Qt Project.

Andreas has been working with Qt since he joined the Qt Company as a full-time 
employee in Germany about a year ago. I believe his patches [0] spesk for 
themselves. He has also participated actively in reviewing others’ work [1]. My 
impression is that Andreas holds quality in high regard in production code, 
tests, and in documentation, and that he tirelessly works to further our 
quality in all these areas.

I trust he'll use the approver rights responsibly.

[0] - https://codereview.qt-project.org/q/owner:andreas.buhr%2540qt.io
[1] - https://codereview.qt-project.org/q/reviewer:andreas.buhr%2540qt.io

//! Paul
___
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] Nominating Andrei Golubev as Approver

[Jaroslaw Kobus]

+1

Disclosure: I've only collaborated remotely with Andrei, however it was always 
a pleasure.


From: Development  on behalf of Edward 
Welbourne 
Sent: Thursday, March 18, 2021 3:00 PM
To: development
Subject: [Development] Nominating Andrei Golubev as Approver

Hi all,

I'd like to nominate Andrei Golubev as an Approver.
He has been doing sterling work reviewing changes for the last year.
Here's a list of what he's reviewed
https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io
and his own changes
https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io

Full disclosure: although I've not worked from it since he joined, we
nominally share an office,

Eddy.
___
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

[Development] Question about the lifetime of references taken from QHash

[Jaroslaw Kobus]

Hi All,

asking it here, as I couldn't find any clear answer in QHash docs.

Provided I have only one instance of my QHash (so, no detaches are being done), 
and the only API of the QHash I'm using is: insert(), remove(), contains() and 
operator[], how long I may rely on the reference to value returned by 
QHash::operator[]?
E.g.:

QHash hash;
hash.insert(1, MyValue(...));
hash.insert(2, MyValue(...));

MyValue  = hash[1];
hash.remove(2);

// May I rely that now my reference is still valid? Wondering, if any 
internal rehash on remove could copy internal data, so that it invalidates the 
reference obtained earlier.

Assuming that I keep and use this reference only until I explicitly called 
hash.remove() for the key associated with my reference - may I assume that this 
reference will be valid?

Best regards

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

Re: [Development] Request to rename module qtscxml to qtstatemachine

[Jaroslaw Kobus]

+1

The new name reflects the content of the module much better.

Regards

Jarek


From: Development  on behalf of Edward 
Welbourne 
Sent: Thursday, January 21, 2021 11:14 AM
To: Karsten Heimrich
Cc: development@qt-project.org
Subject: Re: [Development] Request to rename module qtscxml to qtstatemachine

Karsten Heimrich (21 January 2021 10:49) wrote:
> [...] I would like to propose/request to rename the module to
> qtstatemachine to reflect the widened code base. Jira task:
> QTBUG-89837

Sounds like a more accessible name to me - I'd have had to look up SCXML
to find out what it means, where the proposed name gives me a fairly
good clue to what it means.  So

+1

Eddy.
___
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] Repository request: qlitehtml

[Jaroslaw Kobus]

+1

This may be potentially easily reused in e.g. standalone assistant.

Jarek


From: Development  on behalf of Eike Ziller 

Sent: Tuesday, January 19, 2021 5:01 PM
To: development@qt-project.org
Subject: Re: [Development] Repository request: qlitehtml


> On Jan 19, 2021, at 16:30, Eike Ziller  wrote:
>
> Hi,
>
> I’d like to request a new repository on codereview.qt-project.org
>
> Name and description: qlitehtml - Lightweight HTML/CSS viewer for Qt, using 
> litehtml (https://github.com/litehtml/litehtml)
> Responsible person: Eike Ziller (eike.zil...@qt.io)
> Desired repository name: playground/qlitehtml
> URL of existing code:
>
> https://git.qt.io/eiziller/qlitehtml
>
> This is extracted from the code that so far lives within the Qt Creator 
> repository at 
> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/qlitehtml
>  , with the goal of making it more easily shareable.

And the corresponding JIRA task here
https://bugreports.qt.io/browse/QTQAINFRA-4201

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://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

[Development] The ssh issue after updating to Fedora 33

[Jaroslaw Kobus]

Hi all,

just in case when someone wants to update to Fedora 33 (or already did it): a 
potential issue with connection to gerrit may appear. It asks you to make sure 
you have the correct access rights and the repository exists. It mentions also: 
Permission denied (publickey).

The fix is to regenerate your ssh keys with a magic -t option and upload the 
public one to gerrit. I did it with:

ssh-keygen -t ecdsa

and it was enough. More info here: 
https://www.reddit.com/r/Fedora/comments/jhxbdh/no_ssh_public_key_auth_after_upgrade_to_fedora_33/

Regards

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

[Development] Fw: Important recent changes in QList/QString/QByteArray

[Jaroslaw Kobus]

> 
> From: Development  on behalf of Giuseppe 
> D'Angelo via Development 
> Sent: Wednesday, September 2, 2020 9:37 PM
> To: Andrei Golubev; development@qt-project.org; Ville Voutilainen
> Subject: Re: [Development] Important recent changes in  
> QList/QString/QByteArray
>
> On 02/09/2020 21:18, Andrei Golubev wrote:
> > Also not sure whether it is an implementation detail or the behavior
> > that should always be anticipated.
>
> People build performance sensitive code assuming the cost of certain
> operations -- like, assuming that erasing elements from a vector never
> reallocates it; and that the only operation that sheds capacity is
> squeeze(), everything else (incl. clear(), incl. resize(0)) keeps the
> capacity (*). We should stop backstabbing them...

People sometimes care about memory consumption, too. If user's object
contains a vector consisting of exactly one element, he may be surprised
that it still consumes a place for one million elements, just because one
minute ago he removed 999.999 items. If he is creating hundreds
of such objects sequentially, his app may not run at all (however, will perform 
very well).

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

Re: [Development] QHelpEngineCore::documentsForIdentifier

[Jaroslaw Kobus]

Hi Martin,

sorry for not answering earlier.

I've just prepared a patch that should fix it. The assumption before was that 
at some point the default for using new filter engine will change to true. 
However, since it didn't happen so far, I'm providing a full fix for old 
filtering system, too.

The patch is here: https://codereview.qt-project.org/c/qt/qttools/+/312105

Could you please confirm it fixes your issue?

Thanks and best regards

Jarek


From: Development  on behalf of Martin 
Koller 
Sent: Friday, August 28, 2020 2:09 PM
To: Edward Welbourne; development@qt-project.org; Samuel Gaist
Subject: Re: [Development] QHelpEngineCore::documentsForIdentifier

On Freitag, 28. August 2020 08:38:45 CEST Samuel Gaist wrote:
> Hi,
>
> > On 27 Aug 2020, at 19:07, Edward Welbourne  wrote:
> >
> > Martin Koller (14 August 2020 17:06) wrote:
> >
> >> I found myself getting an empty list when using
> >> QHelpEngineCore::documentsForIdentifier(id) but getting 1 element when
> >> using the deprecated QHelpEngineCore::linksForIdentifier(id).
> >
> > Definitely sounds like a bug, although I find no
> > QHelpEngineCore::linksForIdentifier() - did you mean
> > QHelpCollectionHandler::linksForIdentifier() ?
> >
> >> Checking the code I stumbled over something which I believe is a bug:
> >>
> >> QHelpEngineCore::documentsForIdentifier(const QString , const
> >> QString ) does
> >>
> >> if (!d->setup() || !d->usesFilterEngine)
> >>return QList();
> >>
> >> so it checks if the new filter engine is active, but I think this is
> >> not needed here, since in this code, the filter engine is not used at
> >> all, since the filterName is already given as argument.
> >
> > Sounds plausible.
> > Also, QHelpEngineCore::documentsForIdentifier(const QString ) calls
> > documentsForIdentifier(const QString , const QString )
> > passing a filterName that it determines based on d->usesFilterEngine,
> > which rather suggests it thinks d->usesFilterEngine isn't a prerequisite
> > of getting any entries.
> >
> >> Since I ported older code to the new api but did not call
> >> setUsesFilterEngine(true) (which I believe should not be needed when I
> >> don't work with filters), this check was hit and I get no results.
> >>
> >> Am I right ?
> >
> > I don't know this code at all but it sounds like reasonable grounds to
> > submit a patch to Gerrit and ask for review by folk implicated in the
> > review that added this code (this March):
> > https://codereview.qt-project.org/c/qt/qttools/+/291144
> >
> > Eddy.
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> You need to enable the new filter engine using:
>
> https://doc.qt.io/qt-5/qhelpenginecore.html#setUsesFilterEngine
>
> The documentation has been modified for the next release to make it clearer.

You mean as a workaround ? Yes, this is what I did - as a workaround.

But my question was about the - in my view - wrong code,
where Edward also seems to share my opinion.
I assume I should not be forced to us a filter engine when I already can
pass a filter to this method (and to be honest I have no idea what the 
filterEngine
does and have no need for filtering)

--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at


___
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] QHelpEngineCore::documentsForIdentifier

[Jaroslaw Kobus]

Hi Martin,

sorry for not answering earlier.

I've just prepared a patch that should fix it. The assumption before was that 
at some point the default for using new filter engine will change to true. 
However, since it didn't happen so far, I'm providing a full fix for old 
filtering system, too.

The patch is here: https://codereview.qt-project.org/c/qt/qttools/+/312105

Could you please confirm it fixes your issue?

Thanks and best regards

Jarek


From: Development  on behalf of Martin 
Koller 
Sent: Friday, August 28, 2020 2:09 PM
To: Edward Welbourne; development@qt-project.org; Samuel Gaist
Subject: Re: [Development] QHelpEngineCore::documentsForIdentifier

On Freitag, 28. August 2020 08:38:45 CEST Samuel Gaist wrote:
> Hi,
>
> > On 27 Aug 2020, at 19:07, Edward Welbourne  wrote:
> >
> > Martin Koller (14 August 2020 17:06) wrote:
> >
> >> I found myself getting an empty list when using
> >> QHelpEngineCore::documentsForIdentifier(id) but getting 1 element when
> >> using the deprecated QHelpEngineCore::linksForIdentifier(id).
> >
> > Definitely sounds like a bug, although I find no
> > QHelpEngineCore::linksForIdentifier() - did you mean
> > QHelpCollectionHandler::linksForIdentifier() ?
> >
> >> Checking the code I stumbled over something which I believe is a bug:
> >>
> >> QHelpEngineCore::documentsForIdentifier(const QString , const
> >> QString ) does
> >>
> >> if (!d->setup() || !d->usesFilterEngine)
> >>return QList();
> >>
> >> so it checks if the new filter engine is active, but I think this is
> >> not needed here, since in this code, the filter engine is not used at
> >> all, since the filterName is already given as argument.
> >
> > Sounds plausible.
> > Also, QHelpEngineCore::documentsForIdentifier(const QString ) calls
> > documentsForIdentifier(const QString , const QString )
> > passing a filterName that it determines based on d->usesFilterEngine,
> > which rather suggests it thinks d->usesFilterEngine isn't a prerequisite
> > of getting any entries.
> >
> >> Since I ported older code to the new api but did not call
> >> setUsesFilterEngine(true) (which I believe should not be needed when I
> >> don't work with filters), this check was hit and I get no results.
> >>
> >> Am I right ?
> >
> > I don't know this code at all but it sounds like reasonable grounds to
> > submit a patch to Gerrit and ask for review by folk implicated in the
> > review that added this code (this March):
> > https://codereview.qt-project.org/c/qt/qttools/+/291144
> >
> > Eddy.
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> You need to enable the new filter engine using:
>
> https://doc.qt.io/qt-5/qhelpenginecore.html#setUsesFilterEngine
>
> The documentation has been modified for the next release to make it clearer.

You mean as a workaround ? Yes, this is what I did - as a workaround.

But my question was about the - in my view - wrong code,
where Edward also seems to share my opinion.
I assume I should not be forced to us a filter engine when I already can
pass a filter to this method (and to be honest I have no idea what the 
filterEngine
does and have no need for filtering)

--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail
/\- against proprietary attachments

Frühstück, Geschenkideen, Accessoires, Kulinarisches: www.lillehus.at


___
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] QProperty and library coding guide

[Jaroslaw Kobus]

> From: Development  on behalf of Ulf 
> Hermann 
>>> However, for Q_GADGET this would fall apart.
>
> Actually, with a Q_GADGET you usually don't have a private object.
> That's the whole point of it. Then you don't need property wrappers, either.

Just for clarification: actually you usually do have a private object (at least 
in Qt classes) in gadgets. Examples:

QPainter
QFont
QTextFormat
QKeySequence
QPalette
QDBusConnection

and I think that more Qt's gadgets have a private object than those that don't.

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

Re: [Development] QString and related changes for Qt 6

[Jaroslaw Kobus]

> From: Development  on behalf of Thiago 
> Macieira 
> Sent: Wednesday, May 13, 2020 6:21 PM
> To: development@qt-project.org
> Subject: Re: [Development] QString and related changes for Qt 6
> 
> On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote:
> > That's why I've mentioned the better option: aggregation: QStringView could
> > be a member of QString. However, the downside would be that every time you
> > want to call a const method for QString, you would need to first get access
> > to the QStringView member. The advantage is that in this way you may easily
> > integrate different interfaces inside one class.
> 
> This is more or less what we want to do. QString in Qt 6 is {begin, size, d}
> and QStringView has always been {begin, size}. So, yeah, it can be done.
> 
> The idea is indeed to offload the majority of the non-mutating methods to the
> same functions, from inline code. There's no reason to have both
> QString::indexOf and QStringView::indexOf entry points in the library.

Good to hear. And I hope that Marc will resurrect soon after his veto.

Regards

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

Re: [Development] QString and related changes for Qt 6

[Jaroslaw Kobus]

> From: Development  on behalf of Thiago 
> Macieira 
> Sent: Tuesday, May 12, 2020 10:42 PM
> To: development@qt-project.org
> Subject: Re: [Development] QString and related changes for Qt 6

> > On 2020-05-12 11:31, Jaroslaw Kobus wrote:
> > >So, just an idea: instead of repeating the common API part in QString
> > > and QStringView, what about making it one common? E.g. what about:

[...]

> > > or (maybe even better):
> > > - aggregating QStringView object as a part of QString API and giving

[...]
>
> QStringView::mid(), for example, returns QStringView, but QString::mid()
> returns QString.
> 
> QString is neither a specialisation nor a broadening of QStringView.

The first option (inheritance) just gives the idea for simple, not perfect 
solution.

That's why I've mentioned the better option: aggregation: QStringView could be 
a member
of QString. However, the downside would be that every time you want to call a 
const method
for QString, you would need to first get access to the QStringView member. The 
advantage
is that in this way you may easily integrate different interfaces inside one 
class.

Anyway, if you are saying the APIs of QString and QStringView are not the same, 
and they
should still differ, than forget about the above.

Regards

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

Re: [Development] QString and related changes for Qt 6

[Jaroslaw Kobus]

> From: Development  on behalf of Lars 
> Knoll 
> Sent: Tuesday, May 12, 2020 9:49 AM
> To: Qt development mailing list
> Subject: [Development] QString and related changes for Qt 6
>
>
> * QStringView and QByteArrayView need to be completed to implement all const 
> methods of QString/QByteArray

Wondering about this point. Looks like we aim for:

QString API = QStringView API (const API) + mutator API

So, just an idea: instead of repeating the common API part in QString and 
QStringView, what about making it one common? E.g. what about:
- deriving QString from QStringView (and adding mutator API)
or (maybe even better):
- aggregating QStringView object as a part of QString API and giving accesor 
for it, like:

QStringView QString::stringView();

In this way we are getting access to read-only API part of QString API. And we 
are not anymore worried about manual sync of the QString const API part and 
QStringView API. The same of course regards to QByteArray & QByteArrayView...

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jaroslaw Kobus]

There are cases, where the name of the function contains the "list", like:

QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = 
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList 
QLowEnergyAdvertisingParameters::whiteList() const;
etc...

So, subWindowList() returning the vector?

Changing QList to QVector may in consequence require even more API changes.

Jarek


From: Development  on behalf of André 
Somers 
Sent: Thursday, April 23, 2020 11:21 AM
To: development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,


On 23-04-20 10:55, Simon Hausmann wrote:
Hi,

So take for example this function in QIconEngine:

virtual QList availableSizes(QIcon::Mode mode = Icon::Normal, 
QIcon::State state = QIcon::Off) const;

If we change that to QVector, we require our users to clutter their code base 
with #ifdefs. If we keep it with QList but use QVector in all non-virtual 
functions, then we create a less consistent API.

Do you think the #ifdefs or inconsistency is worth the proximity to the 
standard? (despite QVector not being like std::vector due to CoW semantics)

I may be missing the obvious, but I really fail to see the problem if you 
change the signature to

   virtual QVector availableSizes(...);


If we have that

template using QList = QVector;


a subclass reimplementing using QList should just work in both Qt5 and Qt6, 
right? So what #ifdef's would be needed?


And yes, I _do_ think staying close to the established meaning of what is a 
vector and what is a list is good. Getting list of QList (which is not a list) 
brings us closer to that goal.


André



Simon

From: Daniel Engelke 

Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann 
Cc: development@qt-project.org 

Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,

I think having a name that is close to the standard is very important as it 
makes it easy to find the Qt counterpart.
Back in the days I had to ask a StackOverflow question to find Qts unique_ptr 
(QScopedPointer), because I couldn't find it due to the naming.

Dmitriy also has a very valid point. It is burned in a lot of peoples heads 
that using QList is a bad idea.

I don't see a lot of work in string replacing QList with QVector and 
QStringList with whatever it would be, as long as the API is compatible.
It's even less work if auto has been used.

Dan


From: Simon Hausmann 
To: Dmitriy Purgin 
Cc: "development@qt-project.org" 

Sent: 4/23/2020 10:27 AM
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Dmitriy,

No, this is not an April's Foolk joke.

Previous discussions were largely centred around the implementations and 
bringing them together. With this thread my concern is the API and the churn 
our users would have to apply to their code base in order to use Qt 5 and Qt 6.


Simon

From: Dmitriy Purgin 
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann 
Cc: development@qt-project.org 

Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,

I hope it's not a belated April's Fool joke? As far as I can remember, for the 
past few years, one would read everywhere to switch to QVector from QList 
because of this and that, and to choose QVector as the default choice container 
instead of QList like it was back in the days. I can't give the exact 
references but that's just the feeling I get from reading the docs and the Qt 
mailing lists.

Cheers
Dmitriy

On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:
Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

(1) Use the same type throughout the public API of Qt.

(2) Make it easy for our users to maintain a code base that works with Qt 5 
and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to QVector. In the light of that, I would like to propose simply 
deprecating QVector and stick to QList everywhere.


What do you think?


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


___
Development mailing list

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jaroslaw Kobus]

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:

Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

(1) Use the same type throughout the public API of Qt.

(2) Make it easy for our users to maintain a code base that works with Qt 5 
and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to QVector. In the light of that, I would like to propose simply 
deprecating QVector and stick to QList everywhere.


What do you think?


Simon
___
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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Jaroslaw Kobus]

Allan Sandfeld Jensen (27 February 2020 23:03) replied:
> That is how I see it too. It essentially violates Qt code guidelines. If it
> was a normal method we would name it "emitEmptied()", so far we have just
> lived with "emit emptied()" instead.

The issue is that if you want to emit a signal, "emitEmptied()" sounds OK, 
while when you want to connect to it, you don't want to connect to 
"emitEmptied", but to "emptied".

Just my 4 cents (this amount wasn't offered in this thread, yet).

Jarek

From: Development  on behalf of Edward 
Welbourne 
Sent: Friday, February 28, 2020 10:34 AM
To: Allan Sandfeld Jensen
Cc: development@qt-project.org
Subject: Re: [Development] A modest proposal: disable lower-case
keywords(emit, foreach, forever, signals, slots) by default


On 26/02/2020 07.42, Tor Arne Vestbø wrote:
>>> As others have argued, a signal is not special, in the sense that any
>>> function can do anything, including emitting signals, so annotating it
>>> doesn’t seem critical, as we apparently are fine without in all other
>>> cases.

On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
>> Taking a step back... I think some of the reason for the current
>> situation has to do with API design. Which of these is easier to understand?
>>
>>   if (map.empty())
>> emptied();
>>
>> - vs. -
>>
>>   if (map.isEmpty())
>> emit emptied();
>>
>> One reads like plain English. The other is missing words in a way that
>> can confuse readers.

Allan Sandfeld Jensen (27 February 2020 23:03) replied:
> That is how I see it too. It essentially violates Qt code guidelines. If it
> was a normal method we would name it "emitEmptied()", so far we have just
> lived with "emit emptied()" instead.

Indeed; most of the case for "emit" can be answered by a sensible naming
convention.  Even the case of "functions that trigger signals" can be
handled by that, when it really matters.

The only problem is that (as a legacy of having had a "keyword" for so
long) we have a bunch of signals whose names don't conform to that
convention.  No-one has suggested we abolish "emit" overnight; so there
shall be time to change the names of things during the course of the
transition to retiring it.

Eddy.
___
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] Moving math3d classes from GUI to CORE

[Jaroslaw Kobus]

From: Laszlo Agocs 
Sent: Friday, January 24, 2020 11:17 AM
To: Jaroslaw Kobus; KDAB Mike Krus; Konstantin Tokarev
Cc: Konstantin Shegunov; development@qt-project.org
Subject: RE: [Development] Moving math3d classes from GUI to CORE


>> So it looks like there is a need to have something like Eigen in Qt, at 
>> least for Qt 3D purposes (faster, better optimized classes, more complete 
>> API).

>Not sure how that conclusion was drawn. 

This is a conclusion based on previous statements, that it would be good to 
focus the energy on improving performance (via SSE, NEON) in math3D, and the 
statement, that Eigen already has that. So the other conclusion is that 
currently we probably sacrifice some performance due to not using Eigen nor 
optimized classes in Qt 3D.

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

Re: [Development] Moving math3d classes from GUI to CORE

[Jaroslaw Kobus]

From: Laszlo Agocs 
Sent: Thursday, January 23, 2020 5:26 PM
To: KDAB Mike Krus; Konstantin Tokarev
Cc: Konstantin Shegunov; Jaroslaw Kobus; development@qt-project.org
Subject: RE: [Development] Moving math3d classes from GUI to CORE

> Indeed, getting some of the SSE work from Qt 3D into Gui could be useful as 
> well.

> When it comes to 3rd party solutions, the graphics stack would most likely be 
> fine and happy with using glm (and so math3d could just go away), but that 
> would mean pulling in more 3rd party dependencies, which is not necessarily 
> ideal either. (in any case, that's a topic to be discussed separately)

> And yes, Eigen is probably a good example of something Qt should not be 
> pretending to be competing with.

So it looks like there is a need to have something like Eigen in Qt, at least 
for Qt 3D purposes (faster, better optimized classes, more complete API).
So either we use it directly (this option is rather not possible, looking at 
the previous feedback: licensing issues, big codebase, etc...) or we start 
developing it in Qt.
Yeah, definitely a topic for a separate discussion :) And there is a good time 
now for this discussion I guess.

Just my 2 cents.

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

Re: [Development] Moving math3d classes from GUI to CORE

[Jaroslaw Kobus]

From: Lars Knoll 
Sent: Thursday, January 23, 2020 3:07 PM
To: Laszlo Agocs
Cc: Konstantin Shegunov; Jaroslaw Kobus; Qt development mailing list
Subject: Re: [Development] Moving math3d classes from GUI to CORE

> Hi,

> After some thinking, I pretty much agree with Laszlo. QVectorND, QMatrix4x4 
> and most other classes in math3d are really tuned towards graphics, and thus 
> make little sense in Qt Core. So +1 for keeping them where they are and in 
> addition a +1 for deprecating QGenericMatrix.

> But I think that in this case would make sense to add the QMatrix3x3 class 
> now instead of returning a std::array. We could keep the class fairly minimal 
> in 5.15 so that it in practice is not much more than a wrapper around 
> float[3][3]. But we’d have the right type then and can add API for it as 
> needed for Qt 6.

Hi again,

I've just created https://bugreports.qt.io/browse/QTBUG-81655 for this. I list 
there some issues to be solved / decided, before the work can be started. 
Please comment.

Thanks and regards

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

Re: [Development] Moving math3d classes from GUI to CORE

[Jaroslaw Kobus]

Resending it to development list, it was the original intention, but it went to 
another list.

BR

Jarek


From: Jaroslaw Kobus
Sent: Tuesday, January 21, 2020 1:33 PM
To: Qt Development
Subject: Moving math3d classes from GUI to CORE

Hi All,

one of the tasks planned for Qt 6 is to move the math3D classes from QtGui to 
QtCore (https://bugreports.qt.io/browse/QTBUG-46653).
I've done some reconnaissance and detected some issues that need to be decided 
before the task is done:

1. QMatrix4x4 class (to be moved into Core) uses QTransform class (which is 
currently a part of Gui lib, inside paining dir):

QTransform QMatrix4x4::toTransform() const;

We may deprecate this method and introduce e.g.:

static QTransform QTransform::fromMatrix(const QMatrix4x4 );

Or we may consider moving QTransform class together with other math3d classes. 
IMO this would be a nice way to go, since QTransform is only a data class (+ 
some useful methods) which could be potentially used outside of GUI scope, too. 
However, QTransform::map() methods use classes like: QPainterPath, QPolygon and 
QRegion. So in turn, we would meet the similar problem again - what to do with 
them? We could either move these methods outside of QTransform, like:

QPolygon QTransform::map(const QPolygon ) const; -> QPolygon 
QPolygon::map(const QTransform ) const;

The other option would be to move these classes together with QTransform into 
the same common place. This would probably be too difficult due to the fact, 
that these classes are not just pure data holders with some access / mutators / 
transform methods, but looks like they are quite deeply integrated into GUI lib.

2. Old QMatrix class, which is to be ultimately deprecated in Qt 5.15, is a 
field member of:

a) QTransform::affine - matrix is a private field of a public header. Thus the 
options for Qt 6 are:
- replace it with a vector of qreal
- replace it with a QMatrix3x3 or QGenericMatrix of qreal
- provide the d-pointer in the header and move all private data into the 
private implementation, as with many other data classes in Qt. However, this 
class is probably used in many time critical contexts, like graphics rendering, 
where performance is quite important, so the question is: would d-pointer be 
acceptable for this class? I've found a benchmark test for qtransform inside 
Qt, so I could compare the results from before and after the change. Should 
other things be taken into account here?
- other options...?

b) QStyleOptionGraphicsItem::matrix - it's a public field of QMatrix type, 
already obsoleted some time ago. Also, it looks like there are more obsoleted 
fields in QStyleOptionX classes, e.g. QStyleOptionGraphicsItem::levelOfDetail. 
So, should they be direclty removed in Qt 6, or do we need to provide a hack 
like in QStyleOptionTabV4? Maybe QStyleOptionX classes and their obsoleted 
fields are the subject for another story...

3. QMatrix inside QVariant / QMetaType. If we are going to remove QMatrix type 
in Qt 6, we need to remove it from QMetaType::Type enum (current value = 79). 
Then we create a gap at position 79. We may adjust the values for other types 
(like instead of 80 for QTransform we move it to 79, and so on). However, I 
wonder whether it is going to work in cases like data streaming (e.g. someone 
stored the variant using Qt 5.15 and now he want to read it in Qt 6). Or should 
we just leave the gap at 79?

4. Where to place math3d classes? Currently they are in gui/math3d. Should they 
go to corelib/math3d, or should they be added into some already existing dir, 
like corelib/tools?

Any comments are very welcome!

Thanks and regards

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

Re: [Development] QAction in Qt 6 - next step proposal

[Jaroslaw Kobus]

> as discussed on the change, there is not much one can do with the newly
> introduced QGuiAction; it serves as a base class for QAction and
> QQuickAction, The naming follows the Q(Gui)Application pattern.

I didn't know that there is going to be one more subclass. Will QQuickAction be 
a public class?

> This  in my opinion is a no-go, we cannot do source-incompatible changes
> in this area because there have been many deprecations already and code
> needs to compile against 5 and 6 with minimal changes.

We have still some time to add a substitution API for these 6 methods,
which are easy 1:1 in porting, to the 5.15 branch and deprecate there
the old methods. This way we could drop them for Qt 6.

Jarek


From: Development  on behalf of Friedemann 
Kleint 
Sent: Wednesday, November 27, 2019 11:19 AM
To: development@qt-project.org
Subject: Re: [Development] QAction in Qt 6 - next step proposal

Hi,

as discussed on the change, there is not much one can do with the newly
introduced QGuiAction; it serves as a base class for QAction and
QQuickAction, The naming follows the Q(Gui)Application pattern.

 > QMenu *menu() const;
 > -> static QMenu *QMenu::menuForAction(QAction *action);

 > void setMenu(QMenu *menu);
 > -> static void QMenu::setMenuForAction(QAction *action, QMenu *menu);

This  in my opinion is a no-go, we cannot do source-incompatible changes
in this area because there have been many deprecations already and code
needs to compile against 5 and 6 with minimal changes.

Ofc, having one QAction class in QtGui is desirable; but it must not
infer source-incompatible changes (and no, hacks like forward declaring
QWidget from QtGui or similar are also a no-go since it causes trouble
for Qt for Python).

Regards, Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
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

[Development] QAction in Qt 6 - next step proposal

[Jaroslaw Kobus]

Dear Qt friends, hackers and freaks,

recently I've noticed a refactoring changes regarding QAction and QActionGroup,
happening inside "dev" branch of Qt
(https://codereview.qt-project.org/c/qt/qtbase/+/265909). I didn't have a chance
to review it before it got merged, I just missed it. So I took a liberty to look
what we are going to have in Qt 6 and reviewed it "post factum".

I need to admit, that this is a very good change! The main goal, which is
moving QAction out of Widget lib and placing it in some more general lib
in order to use it not only in Widget world, is a really good choice! Good work
Friedemann and all reviewers!

However, when we say A, I'm very tempted to say also B (or even C), so why
not to take one or two more steps with it?

===
The current state in short ("dev" branch of Qt)
===

The QAction (and QActionGroup) has been split into two classes:

- QGuiAction (and QGuiActionGroup) is the base, lives outside of Widget lib,
  contains most of the API of old QAction (QActionGroup) except the API
  referring to Widget lib, like methods containing pointers to QMenu, QWidget.

- QAction (and QActionGroup) is derived from QGuiAction (QGuiActionGroup),
  enriching the base QGuiAction (QAGuictionGroup) a little bit, lives in old
  place inside Widget lib

At a quick glance:

class QAction : public QGuiAction
{
...
QMenu *menu() const;
void setMenu(QMenu *menu);
bool showStatusText(QWidget *widget = nullptr);
QWidget *parentWidget() const;
QList associatedWidgets() const;
QList associatedGraphicsWidgets() const;
};

And nothing really more than the above.

So, QAction is now a small decoration, enriching the QGuiAction with
methods referring to QWidget world.

===
The rationale for further steps
===

While I think the very first step, very good step,
has already been done, I believe we may
do something more to make people more happy.

With the current state users might start wondering:

- There are (will be) libs which instatiate QGuiActions and QActions. How then
  I use them together in one app? E.g. I've received pointer to QGuiAction let's
  say from a lib which implements QML bindings (so I receive an action from QML
  world). Can I put this action into the QMenu directly?
  Probably I need to duplicate the QGuiAction by creating the respective 
QAction,
  keeping them in sync on some map and put the QAction to the QMenu.

- I'm writing my lib (not linked against QtWidgets), and I want to expose
  actions through my API. Should I use QGuiAction in the API? Should I
  instantiate the QGuiAction in my lib? But then the other lib, which is
  dependent on QtWidgets won't be able to use actions returned by my API.

- I'm probably going to introduce quite a lot downcasts in my code nowadays,
  like q-object_cast(q_gui_action_pointer)
  since parts of Qt API are going to use QGuiAction, while other parts are
  going to use QAction.

That's why I believe, that having just one class (QAction) instead of two
(QGuiAction, QAction) would solve all the above concerns.


The next step: keep one class, enrich not by inheritance


Being a fan of a principle "prefer aggregation over inheritance", I would like
to propose the following changes to the current state:

1. Rename QGuiAction (QGuiActionGroup) back to QAction (QActionGroup)
   without any other changes to its current API.
2. Remove current QAction (QActionGroup) subclasses
   (which currently live in QtWidgets lib) and don't introduce any new class 
for it.
   We than need to figure out what to do with the API which currently is there,
   and how to enrich existing QAction, not by inheritance.
3. For the existing QAction's API I propose to move the respective functions
   to the other classes involved (e.g. as static methods), like:

QMenu *menu() const;
-> static QMenu *QMenu::menuForAction(QAction *action);

void setMenu(QMenu *menu);
-> static void QMenu::setMenuForAction(QAction *action, QMenu *menu);

bool showStatusText(QWidget *widget = nullptr);
-> static bool QWidget::showStatusText(QAction *action, QWidget *widget = 
nullptr);

QWidget *parentWidget() const;
-> static QWidget *QWidget::parentWidget(QAction *action);

QList associatedWidgets() const;
-> static QList QWidget::associatedWidgets(QAction *action);

QList associatedGraphicsWidgets() const;
-> static QList 
QGraphicsWidget::associatedGraphicsWidgets(QAction *action);

4. For the QActionGroup it looks like all functions may just disappear,
as they are kind of repetition of functions from QGuiActionGroup. Regarding
triggered() and hovered() signals: we may move them back to the base class, as
currently we have similar signals in the action base class.

=
Further steps
=

1. I 

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

[Jaroslaw Kobus]

> Even if not using the QFormBuilder and a user change all the properties at a 
> widget using the Qt Designer we are subject to the same issue, aren't we?

More or less, that's why I said that QDesigner is full of special cases which 
address some issues.

> More and more this looks to me like a bug that should be addressed.

The raising awareness of issues caused by the lack of orthogonality between 
properties is a good thing.

> Given this is not being done consistently across Qt and/or the meta
> object system lacks these informations, this is all pointing towards
> deprecating QFormBuilder as a "real" utility and being more like some
> just quick-glue code lacking a robust use case.

Well, in fact QFormBuilder is doing very simple thing and IMO it's doing it
in the right way. We may of course deprecate it, which won't change the fact
that Qt properties will remain non-orthogonal and will continue to cause
issues.


From: Hugo Slepicka 
Sent: Tuesday, October 29, 2019 5:48 PM
To: Giuseppe D'Angelo
Cc: Jaroslaw Kobus; Volker Hilsheimer; development@qt-project.org
Subject: Re: [Development] Issues with QFormBuilder - All properties modified & 
Invalid UI

I agree with Giuseppe and I would like to add to it the fact that properties 
are restored in what I could guess as alphabetical order, which in itself 
already causes problems for custom widgets.
That said, when developing custom widgets developers must pay attention to this 
fact of properties that are somewhat interlinked. It comes as a surprise that 
the core Qt code does not take that into consideration.
More and more this looks to me like a bug that should be addressed.
Even if not using the QFormBuilder and a user change all the properties at a 
widget using the Qt Designer we are subject to the same issue, aren't we?


On Tue, Oct 29, 2019 at 4:14 AM Giuseppe D'Angelo via Development 
mailto:development@qt-project.org>> wrote:
On 29/10/2019 11:32, Jaroslaw Kobus wrote:
> Take any of QWidget's properties, e.g. sizePolicy, grep through qt sources
> and search where setSizePolicy is used - QAbstractSlider::setOrientation(),
> so "orientation" property of abstract slider influences "sizePolicy" - 
> non-orthogonality detected.
> If you store both properties, and then read them - the result depend on the 
> read order.

Sorry, I'm lost now. If you store them both and apply them in either
order, shouldn't the result be correct no matter what?

==

If this is not true for some case: we have an API problem, and we can
debate whether it's in the class featuring interlinked properties, or in
the meta property system that is not clearly reflecting the
dependencies, thus making a (de)serializer of such properties impossible
to write correctly. And the latter has way more profound implications
than just serializing the state of a QObject (e.g. thinking of IPC like
DBus, QtRO, etc.).

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com<mailto: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 - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org<mailto: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] Issues with QFormBuilder - All properties modified & Invalid UI

[Jaroslaw Kobus]

> Sorry, I'm lost now. If you store them both and apply them in either
> order, shouldn't the result be correct no matter what?

That doesn't matter in fact. If you change orientation first, then sizePolicy, 
you get the state
which can't be reliably stored / read, unless you explicitly know that there is
hidden dependency (if you know, you may influence the order or storing / 
reading,
but still it's not orthogonal).


From: Giuseppe D'Angelo
Sent: Tuesday, October 29, 2019 12:13 PM
To: Jaroslaw Kobus; Volker Hilsheimer
Cc: development@qt-project.org
Subject: Re: [Development] Issues with QFormBuilder - All properties modified & 
Invalid UI

On 29/10/2019 11:32, Jaroslaw Kobus wrote:
> Take any of QWidget's properties, e.g. sizePolicy, grep through qt sources
> and search where setSizePolicy is used - QAbstractSlider::setOrientation(),
> so "orientation" property of abstract slider influences "sizePolicy" - 
> non-orthogonality detected.
> If you store both properties, and then read them - the result depend on the 
> read order.

Sorry, I'm lost now. If you store them both and apply them in either
order, shouldn't the result be correct no matter what?

==

If this is not true for some case: we have an API problem, and we can
debate whether it's in the class featuring interlinked properties, or in
the meta property system that is not clearly reflecting the
dependencies, thus making a (de)serializer of such properties impossible
to write correctly. And the latter has way more profound implications
than just serializing the state of a QObject (e.g. thinking of IPC like
DBus, QtRO, etc.).

Thanks,
--
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 - The Qt, C++ and OpenGL Experts

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

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

[Jaroslaw Kobus]

> And there you have it: QFormBuilder mustn't save non-STORED properties.
> If it does, it's a bug. And if we have some widget with interlinked
> properties that are not clearly marked as non-STORED, or refactored to
> be grouped together in a proper datatype, that's another bug.

Take any of QWidget's properties, e.g. sizePolicy, grep through qt sources
and search where setSizePolicy is used - QAbstractSlider::setOrientation(),
so "orientation" property of abstract slider influences "sizePolicy" - 
non-orthogonality detected.
If you store both properties, and then read them - the result depend on the 
read order.

QWidget::cursor, modified by QLineEdit::setReadOnly
QWidget::focusPolicy, modified by QGroupBox::setCheckable
...

There are really hundrets of these cases...


From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Tuesday, October 29, 2019 11:00 AM
To: Volker Hilsheimer
Cc: development@qt-project.org
Subject: Re: [Development] Issues with QFormBuilder - All properties modified & 
Invalid UI

Il 29/10/19 10:55, Volker Hilsheimer ha scritto:
> But that’s why QWidget::x is read only, and why QWidget::pos is 
> read/writeable, but flagged as “STORED false” in the metaobject (meaning that 
> it’s just a view on some other property, not backed by its own data member).

And there you have it: QFormBuilder mustn't save non-STORED properties.
If it does, it's a bug. And if we have some widget with interlinked
properties that are not clearly marked as non-STORED, or refactored to
be grouped together in a proper datatype, that's another bug.


> Q(Abstract)FormBuilder doesn’t promise idempotence though, so extending the 
> documentation to state that there’s no guarantee that loading the resulting 
> .ui file will produce an identical GUI, and that the .ui file likely requires 
> post-processing, seems to be the correct fix here.

Then I fail to see the usefulness of QFormBuilder apart from being minor
convenience, and therefore it should be overall deprecated.

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 - The Qt, C++ and OpenGL Experts

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

Re: [Development] Issues with QFormBuilder - All properties modified & Invalid UI

[Jaroslaw Kobus]

> I'm not really convinced of this. Properties that depend on each other
> are a symptom of bad design; we shouldn't discourage QFormBuilder
> because of this possible marginal issue.

I agree in 100%! However, hundreds of QObject / QWidget properties
(and those in their subclasses) in fact depend on each other and are not
orthogonal. That's why the code for QDesigner is full of "special cases" - I 
estimate it's 90% of the code base.
So the right way to fix it is to go through all QObject properties
+ the whole hierarchy and detect all non-orthogonal cases and fix all of them.
A huge work! However, as the result we would get a really robust object system.

As a side note - in theory, the metaobject system may be designed in a way
that it detects non-orthogonal properties automatically. Also a huge work.

Jarek


From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Tuesday, October 29, 2019 10:23 AM
To: development@qt-project.org
Subject: Re: [Development] Issues with QFormBuilder - All properties modified & 
Invalid UI

Il 29/10/19 08:25, Friedemann Kleint ha scritto:
>   > It is for sure a bug, so please report it. I'm not sure how much love
> the widgets designer gets these days, though.
>
> As explained before, it cannot be guaranteed that changing all
> properties in random order works in Widgets.

I'm not really convinced of this. Properties that depend on each other
are a symptom of bad design; we shouldn't discourage QFormBuilder
because of this possible marginal issue.

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 - The Qt, C++ and OpenGL Experts

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

Re: [Development] HEADS-UP: QStringLiteral

[Jaroslaw Kobus]

I propose the following policy regarding any further new string classes / 
wrappers in Qt:

Whenever anyone propose new string class / wrapper in public API of Qt, he is 
obligated to deprecate in parallel at least 2 other string classes / wrappers 
in public API of Qt.

Regards

Jarek


From: Development  on behalf of Tor Arne 
Vestbø 
Sent: Wednesday, August 21, 2019 12:01 PM
To: Bogdan Vatra
Cc: Thiago Macieira; Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development 
>  wrote:
>
> Am I the only one which finds situations silly ? Of course there are more
> examples with the other String wrappers/functions in Qt, but I think is enough
> to show how crazy is the situation.

You are not!

I completely agree, and I think it’s a detriment to Qt’s promise of easy to use 
APIs that these optimised versions are not automagic and hidden behind the 
scenes, or don’t have a clear cut story for when to explicitly use.

> // Even more
> QHash test;
> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong
> again
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
> wrong
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> victory !!!

This should just be test[“key”] = “value”. How do we get there?

Tor Arne
___
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

[Development] Implementing QStateMachine using QtScxml module

[Jaroslaw Kobus]

Hi All,

recently I was investigating the possibility of replacing the internal 
implementation of QStateMachine
with QtScxml module. See https://bugreports.qt.io/browse/QTBUG-70261. Below I 
have gathered
some results and some conclusions. However, at this point it's not clear in 
which direction we should go,
so if anyone is interested in this topic and has some ideas or thoughts - 
please share them! Thanks!


I. The initial idea:


Replace the implementation of QStateMachine with QtScxml module. Upon every 
startup of QStateMachine
we would parse the state machine tree and create internally the 
QScxmlStateMachine document. QtScxml
module would then use it to instantiate QScxmlStateMachine and run it.

Pros:
1) One common codebase for both QStateMachine and QScxmlStateMachine
2) Smaller codebase

Cons:
1) Additional delay upon startup (parsing the QStates hierarchy, constructing 
the scxml document)
2) State machine structure can't be modified when it's running (currently we 
have some autotests
   which modify the structure when running, e.g. eventTransitions(), 
createPointerToMemberSignalTransition(), etc... ).
   This means that API won't change, the behaviour will change.
3) Slower running time due to used mappings (between scxml ids and pointers to 
QState objects)
   and two additional signal/slot connections for every state (connectToState,
   connectToEvent(finished., ...)). For every transition we also provide 
additional transition to be
   invoked by the eventless transitions on startup. Also, for every state we 
provide additional transition
   to react to "done.state." events.
4) Additional memory consumption due to internal scxml state machine

---
Benchmarks:

I've created a test case consisting of the state machine containing 1 
states,
chained together with transitions from state n to state n+1.
Transitions are being triggered by custom event. Whenever the state n
is being reached, it posts a custom event to the state machine,
what causes the next transition to be taken.

Construction of the state machine + startup time
(with new implementation it includes dynamic construction of scxml doc):
[old implementation]: about 50 ms
[new implementation]: about 620 ms

Running time (transitions from state 1 to state 1):
[old implementation]: about 100 ms
[new implementation]: about 220 ms

---
State of the prototype:

Examples:

All examples are working with the new implementation.

Autotests:

3/4 of all statemachine autotests are passing now. Some had to be a bit modified
(e.g. additional call to processEvent()). 89 working out of 122 in total.
To be fixed:
- Handling state machine errors
- Running sub state machine
- Some tests can't be fixed (changes to the state machine structure during 
execution)

The prototype can be found here:

https://codereview.qt-project.org/c/qt/qtbase/+/271082

---
Conclusion:

In this approach we have a lot of data duplicated. We have:
1. QState hierarchy.
2. On state machine startup we create dynamically scxml document.
3. The scxml document is being parsed and scxml tables are being created.

It looks like this approach degrades performance and increases memory 
consumption.

===
II. Comparison:
===
So far I have compared the old implemenation with the new prototype
and the old implementation wins according to the points below.
However, it's not clear yet, and it probably should be investigated,
whether QtScxml is really faster than QStateMachine(!) In the prototype
I have glued together two existing APIs, but it may be worth to check
whether having another API instead of QStateMachine API and gluing it
with QtScxml would speed up execution.

While comparing different implementations of state machine
we should take the following into account:
- What is the ideal case / example / test to compare the speed of state 
machines?
  Is 1 states case OK?
- Should we compare construction time / execution / or both?
- Should we compare memory consumption?

==
III. Other options:
==

Option A)
If we change the API of QStateMachine, so that we don't base QState on QObject,
we could at least save some memory and time spent on constructing the state 
machine.
However, we would have to take into account that QStateMachine
supports animations and property assignments currently, which QtScxml module 
doesn't support
out of the box. Please note that designing new general API is quite time 
consuming task.

Option B)
We could also try to start from refactoring the scxml document API, so that it 
would
serve as a public API, too. Currently there are too much internals and low 
level stuff exposed there,
so it doesn't fit for the public API ATM.

Option C)
?

Option D)
?

Thanks and regards

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

Re: [Development] Assistant WebKit/WebEngine support

[Jaroslaw Kobus]

From: Development  on behalf of Palaraja, 
Kavindra 
Sent: Friday, June 28, 2019 10:56 AM
To: Qt development mailing list
Subject: Re: [Development] Assistant WebKit/WebEngine support

On 28.06.19, 10:24, "Eike Ziller"  wrote:

> On 27. Jun 2019, at 15:46, Palaraja, Kavindra  
wrote:
>
> ...because both you and Andre aren't willing to pay the price...

No Kavindra, please count me in too. And my 13 years old son too, so that we 
are four now. He just told me a story, that he recently saw a video, that some 
simple calculator app required calling privileges during installation on a 
mobile phone. There is a good chance, that soon similar videos will appear 
regarding the installation of offline help for Qt, requesting networking 
privileges.

Best regards

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

Re: [Development] Assistant WebKit/WebEngine support

[Jaroslaw Kobus]

QTextBrowser promises to render rich text - isn’t it what we want for showing 
help? If QTextBrowser isn’t able to render properly the static help files - 
what is the other typical usage of it? Why we claim that QTextBrowser is able 
to do things, which in fact it can't? This doesn't show a fair message to the 
user, if we - for our purposes - don't use tools which we should.

In webkit times I was able to open my bank online page from Assistant, but I 
wasn’t brave enough to log into my account. Do we really want help viewer to be 
full functional web browser? Big companies work hard for a very long time to 
design GUIs, menus, interactions, and we give the people barely the web window? 
I remember how I was confused when I could open my preferred online newspaper 
in Assistant in that time - it looked super unprofessional, without proper, 
typical GUI for web browsers around. Do we still want to pass the same 
impression to our customers?

IMO, we should make a clear requirements on what we want and what we don’t want 
for help viewer. There is no need for networking, means we even shouldn’t try 
to compile it against network module. Turning the networking functionality at 
runtime is not enough. We should make a clear separation, on what the viewer 
should support (like html, css), what it may potentially support in the future 
(we ensure we don’t close the door, e.g. playing offline videos), and what it 
shouldn’t support, never (networking, javascript (???), much more...). We 
should define it first and than choose the right solution. Not like: let’s 
choose webengine, it may do everything. Currently it looks like the webengine 
supports everything and it’s way too much.

In addition, I really don’t like the super fast decisions here. It’s easy to 
say: let’s use webengine, and after we release we will see if more or less 
people complain. Many things may be predicted now. It is a bit like: Would you 
use webengine to implement Qt’s "Hello World" example? One can say: why not, 
web engine may do much more! Is it a way we want to show our users on how to 
use Qt? We could even exchange the implementation of QLabel and use webengine 
for it... Less maintenance, smaller codebase, etc... Sound cosmic? Yeah, 
webengine in Assistant too...

Regarding Kavindra’s message, about not fixing QTextBrowser for years: yes, we 
were probably not having resources to do it so far. So, does that mean we 
should choose the bad further ways as a consequence? Isn’t it now the right 
time to address such long lasting issues? Would it be more interesting for 
users, that in Qt 6 the QTextBrowser is redesigned and can do much more than 
his old brother from Qt 5, instead of e.g. wondering for couple of years 
whether QList should be replaced / renamed / whatever by / to / ... QVector? I 
bet we would gain much more by enhancing QTextBrowser.

Does anyone still cares about what is the right way to do the stuff versus what 
is the fastest and easiest way to make a patch just to make some crying 
customers silent for a minute? Are we still pragmatic? I understand we aim with 
the solution for Qt 6 in any case. I imagine that making webengine pluggable / 
customizable / configurable (so that we even don't compile the stuff we don't 
want) won’t be possible in this timeframe - so, would we have enough time / 
resources to address much more easier changes in QTextBrowser, which would be 
really interesting for broad customer audience? Or we choose the easiest, 
crappy way (sorry for that, it’s just a quotation from this thread) and we just 
advertise it well enough? I bet smart developers (read: the users, which decide 
on whether to use or not to use the certain functionality of Qt in their 
projects) easily differentiate between a good change and a good ad.

Regards

Jarek

PS. Kavindra, yes, the goal of this thread is to address your issues. But 
please, let’s consider all the technical possibilities, before the decision on 
which way to choose is made. And please don’t stop considering changes in 
QTextBrowers, just because noone fixed it so far (for many years). It would be 
really handy if we have a bugreport with exact description of which html tags / 
attributes / css are broken in QTextBrowser. It would give an overview of how 
much needs to be done there. The evidence like: we tried before and failed, 
doesn't tell too much.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Jaroslaw Kobus]

I think the option 2 (enhancements in QTextBrowser) is the best one, since the 
time investment spent on it will benefit for all users of QTextBrowser, not 
only those using Qt help system. So big +1 here!

However, if we go with the webengine (or webkit) way, I would be very happy 
that the existing solution (crappy QTextBrowser) is still there as a fallback, 
even if the content may start to look even more ugly (due to potential "style" 
redesign of qch files, which most probably will happen when we have full 
functional web browser in). I remember the old days, when we had mandatory 
webkit: I never compiled it, since it was a big pain (many external 
dependencies, many times it just didn't compile, very long time spent on 
compilation). Usually the result was that after half a day spent on preparation 
/ compilation, I saw not working help. So I had to use online docs in my 
browser.

Another option which comes to my mind is:

Option 8: Make the webengine project configurable / customizable enough, so 
that we may cut off all networking and stuff we don't need, keeping only the 
pure HTML rendering. This would be also benefit for others - maybe then much 
more people would start using it. I realize that this would probably be a huge 
refactoring and a long term solution. However, maybe it's worth to think about 
it now, before Qt6...

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

Re: [Development] Proposal: New branch model

[Jaroslaw Kobus]

From: Volker Hilsheimer
Sent: Wednesday, January 23, 2019 5:25 PM
To: Jaroslaw Kobus
Cc: Jedrzej Nowacki; development@qt-project.org
Subject: Re: [Development] Proposal: New branch model

On 23 Jan 2019, at 17:08, Jaroslaw Kobus 
mailto:jaroslaw.ko...@qt.io>> wrote:

"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"

No sure I understand the above correctly. Let's say in dev branch some source 
file got refactored completely, so that no single line match the old version 
anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 5.9 branch 
- how in this case you may try to push your fix to dev?

Jarek


That’s where the “with exception of branch specific changes” clause (which the 
** points at) kicks in.

Is the fix needed in dev (or is the bug fixed by the refactoring)?

If yes, then fix it in dev, and then make a separate fix in the relevant LTS 
branches (perhaps starting with the cherry-pick’ed change). Or just accept that 
this bug won’t/can’t be fixed in the pre-refactoring codebase.

If no, then push the fix for the newest branch where it’s needed, from where it 
can be cherry picked further; don’t do anything in dev (including “don’t expect 
someone that knows nothing about your change to deal with the merge conflict”).


Volker


In this case there is additional step then. You would be forced now to check 
first both 5.9 and dev branches and detect if a fix would be "applyable" to the 
dev or not.

Besides, if you decide that your fix goes only to the 5.9 branch - in this case 
you follow the current model anyway, right? So, having two models isn't better 
than having just one I think.

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

Re: [Development] Proposal: New branch model

[Jaroslaw Kobus]

"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"


No sure I understand the above correctly. Let's say in dev branch some source 
file got refactored completely, so that no single line match the old version 
anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 5.9 branch 
- how in this case you may try to push your fix to dev?


Jarek


From: Development  on behalf of Jedrzej 
Nowacki 
Sent: Wednesday, January 23, 2019 4:51:10 PM
To: development@qt-project.org
Subject: [Development] Proposal: New branch model

Hi,

  It is time to rethink our branch model. We are approaching Qt6 development
and I'm worried that what we have now, will simply not scale. As you know, our
branch model is mainly(*) based on merging from stable up to development
branches. In general, it is a very good model, which make sure that release
branches are not getting obsolete too quickly, that most of the fixes are in
the right places, that every commit is only once in the git history. It is a
very clean model. It is also a very slow model, with a single point of
failure.

  It is hard to maintain:
  My impression is that the current model works great for a single release
branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is without
counting temporary patch level branches. Merging through them is hard, we
already had to use "cherry-pick mode" in some places. When we add to the
picture dev and qt6 branches, merging will be very, very hard. It is
practically a full time job to update qt5 repository and coordinate all the
merges now (thank you Liang!), shortly after qt6 branch opening amount of work
will be much bigger.
  It is slow:
  The merges take time. We produce a lot of code, we have a lot of tests that
needs to pass. Even single failure delays merge propagation by at least one
day. If by bad luck, the merge contains some API incompatible changes an
intermediate jump through Qt5 integration is required, that adds at least 3
days of delay.

  --

  Proposal in short: let's use cherry-pick mode everywhere.

  All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5 
(http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
"stable", "LTS". By
default everything would be cherry-picked to qt6 branch unless "no-future" tag
would be given. Of course we can bike-shed about the tag names.

  Advantages:
  - no waiting for merges, a fix can be used right away after integration
  - faster propagation of fixes targeting all branches, as there are no merges
of merges
  - simpler for new contributors, always push to dev
  - in most cases a reviewer does no need to know what the current version
number is
  - conflict resolution is distributed and affects mostly the author of the
change
  - documents a change intent, which may be useful for people keeping own
forks
  - over time with increased amount of conflicts old branches, in natural way,
stay untouched

  Disadvantages:
  - git history would be a bit wilder, "git branch --contains" would not work
  - commit messages in some branches would have kind of ugly footer as an
effect of "cherry-pick -x"
  - there is a chance, that some cherry-picked commits may be left forgotten
in gerrit after a failed integration

  Bot details:

  The bot would listen only for changes in dev, in some unusual cases one
could target an other branch directly, but bot would not trigger automatic
cherry-pick(***). The bot would wait for a successful dev integration before
creating cherry-picked changes. The bot would use cherry-pick -x to annotate
the origin patch. After the cherry-pick creation, it would push it to gerrit,
+2 and stage once. It would be up to the author to re-stage in case of
flakiness. In case of a cherry-pick conflict it should push unresolved conflict
to gerrit and add all reviewers and author to handle the issue.

The list below shows branch targets for automatic cherry-pick based on given
tag.

dev (qt6)
stable (qt6, 5.13)
stable, no-future (5.13)
LTS (qt6, 5.13, 5.12)
LTS-strict (qt6, 5.13, 5.12, 5.9)
LTS, no-future (5.13, 5.12)

That is assuming that we have branches: qt6  dev  5.13  5.13.q  5.12  5.12.w
5.9  5.9.e  5.6  5.6.r
I think we should assume that patch level branches, as well LTS in very strict
state, are handled manually.


  Creation of new branches:
We would branch more or less as usual. The only difference from the current
system is that we would not need the back merge / soft branching 

Re: [Development] New linguist maintainer nomination

[Jaroslaw Kobus]

+1. AFAIRC, Kai's hands were already on this stuff a long time ago, dating 
Trolltech times :)


From: Development  on behalf of Alex 
Blasche 
Sent: Monday, January 7, 2019 1:51:25 PM
To: development
Subject: [Development] New linguist maintainer nomination

Hi,

After Ossi stepping down as maintainer for Linguist and related tools 
(lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a 
long history working on Qt and even more specifically with Qt's translation 
tools.

--
Alex

___
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] qcollectiongenerator merged into qhelpgenerator

[Jaroslaw Kobus]

The answer to the first question is yes. If you want to generate the qhc file 
using Qt < 5.12 you need to use qcollectiongenerator, since merging took place 
in 5.12 branch, not before.


So, I may bring it back if it's needed.


Could you give an example link to the project which is failing now?


Regards


Jarek


From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, December 13, 2018 8:10:33 PM
To: development@qt-project.org
Subject: [Development] qcollectiongenerator merged into qhelpgenerator

Looks like a lot of projects are now failing to compile with Qt 5.12 because
qcollectiongenerator has disappeared. The changelog simply says:

 - Removed qhelpconverter tool.
 - Merged qcollectiongenerator tool into the qhelpgenerator tool.

Should I simply replace "collection" with "help" in whatever builds tried to
use the old tool? Same syntax, no further changes?

Can I also apply the change to projects that must still compile with Qt 5.9 or
older?

If the answer is "no" to any of the questions, please bring
qcollectiongenerator back in 5.12.1 and keep it there until 5.14 or 6.0, even
if all it does is "exec" the qhelpgenerator tool with the correct syntax.
We'll advise Linux distributions to backport the patch.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
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] Building Qt documentation with developer-build

[Jaroslaw Kobus]

Hi,


You may also want to check the https://bugreports.qt.io/browse/QTBUG-65762 - if 
you think the issue is still not solved, you may reopen / report new bug report.


Regards


Jarek

[QTBUG-65762] Compiling qdoc in dev is a big pain - Qt Bug 
...
bugreports.qt.io
I've recently updated my dev branch of qt and I have big issues compiling qdoc. 
For the first machine I've learned (from a colleague) that I need libclang in 
order to compile it.




From: Development  on 
behalf of Mitch Curtis 
Sent: Thursday, October 4, 2018 5:49:35 PM
To: Nils Jeisecke; development@qt-project.org
Subject: Re: [Development] Building Qt documentation with developer-build

Did you set LLVM_INSTALL_DIR before building Qt? If you check the build log you 
should see an error message related to the failure to build qdoc.

> Seems that qdoc was not build at all. Building qdoc as described on
https://wiki.qt.io/Building_Qt_Documentation does not work.

If you forgot LLVM_INSTALL_DIR and are trying to build qdoc separately rather 
than with the rest of Qt, you might run into 
https://bugreports.qt.io/browse/QTBUG-66366, in which case you’ll need to 
rebuild *all of Qt*, unfortunately.

On 10/4/18, 5:35 PM, "Development on behalf of Nils Jeisecke via Development" 
 wrote:

Hi,

While trying improve the documentations to fix QTBUG-32064 I've stumbled
over problems invoking qdoc.

I'd like to use my developer-build to check the result of my changes but
qdoc seems to have been skipped when building with --developer-build.

"make docs" from within my shadow build directory fails:


/Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh:
 line 12: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: No 
such file or directory

/Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh:
 line 12: exec: 
/Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: cannot 
execute: No such file or directory
make[6]: *** [prepare_docs] Error 126
make[5]: *** [debug-prepare_docs] Error 2
make[4]: *** [sub-corelib-prepare_docs] Error 2
make[3]: *** [sub-src-prepare_docs] Error 2
make[2]: *** [module-qtbase-prepare_docs] Error 2
make[1]: *** [html_docs] Error 2
make: *** [docs] Error 2

Seems that qdoc was not build at all. Building qdoc as described on
https://wiki.qt.io/Building_Qt_Documentation does not work.

I've not found any special qdoc configure options so what am I doing
wrong?

This is my configure line:

../../qt512/configure -developer-build -opensource -nomake examples -nomake 
tests -skip qtwebchannel -skip qtscript -skip qt3d -skip qtdatavis3d -skip 
qtremoteobjects -skip qtserialport -skip qtvirtualkeyboard -skip qtwebengine 
-opensource -confirm-license

Any help is appreciated!

Nils
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtScxml module maintainer change

[Jaroslaw Kobus]

+1. Ulf did quite a lot of a good maintenance work already for this module.


Jarek


From: Development  on 
behalf of Simon Hausmann 
Sent: Tuesday, September 4, 2018 1:49:15 PM
To: Erik Verbruggen; 
Subject: Re: [Development] QtScxml module maintainer change



+1



Simon


From: Development  on 
behalf of Erik Verbruggen 
Sent: Tuesday, September 4, 2018 1:48:24 PM
To: 
Subject: [Development] QtScxml module maintainer change


Hi,


I'd like to propose Ulf Hermann as the new maintainer of the QtScxml module.


Officially I'm still the maintainer of the module, but I haven't worked on it 
in quite a while. After discussions, Ulf Hermann kindly volunteered as the new 
maintainer.


-- Erik
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator

[Jaroslaw Kobus]

Of course +1


From: Development  on 
behalf of Tobias Hunger 
Sent: Wednesday, May 2, 2018 12:14:14 PM
To: qt-crea...@qt-project.org; development@qt-project.org
Subject: [Development] Proposing Orgad Shaneh as Maintainer of Version Control 
modules in Qt Creator

Hello,

I want to propose Orgad Shaneh as maintainer of the version control related 
modules in Qt Creator.

So far I have been handling that responsibility, but since I took over the 
project-related Qt Creator plugins, I had way too little time on my hands to 
take a lead in the version management related code.

Orgad has been working in those modules, he did a lion's share of the reviews 
involved and he added functionality during that time and he is willing to take 
on the responsibility involved. So I would like formally propose Orgad as 
maintainer of the version management code. I am sure he will take good care of 
the code, especially of the vcsbase and git plugins.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setters: Clarifying the ownership

[Jaroslaw Kobus]

"give" may be confused with "get", which is usually an accessor. I may also 
think "Am I giving (to QCoreApplication)" or "The QCoreApplication is giving 
(me)". Maybe it is just a matter of the other verb? Absorb, hand over, hand on, 
suck in, swallow...


Jarek


From: Development  on 
behalf of Jesus Fernandez 
Sent: Friday, January 19, 2018 4:15:52 PM
To: development@qt-project.org
Subject: [Development] Setters: Clarifying the ownership

Hi all!

I always found something annoying in the Qt API. The problem comes with the 
setters of our properties. When I want to pass an object to a property I never 
know if I need to take care of the object or relay on parenting system to avoid 
memory leaks.
To know if the object is going to be reparented, I open the assistant and look 
for the setter to try to find the famous "takes ownership of" in the function 
description.

Mårten Nordheim and I were talking about possible solutions to this problem. 
Typical things came to the discussion:
- adding a macro like Q_TAKES_OWNERSHIP to the function that expands to nothing
- wrapping the parameters with a template class (gsl::owner)
- ...

After some discussion he came with the idea of add a different "verb" to the 
setter, replace "set" with "give". So when we are giving the ownership of an 
object to instead of setSomething(); we will write 
giveSomething(); I really like this solution, it will improve a lot the 
readability of the client (and internal) code.

For example: QCoreApplication::setEventDispatcher will be 
QCoreApplication::giveEventDispatcher.

Of course at the beginning this will be a new function and the old set* 
functions will be kept, but marked as deprecated.


--
Best regards,
Jesús
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development