Re: [Development] Do we need version tags in released src packages?

[André Pönitz]

On Fri, Aug 13, 2021 at 07:17:16AM +, Jani Heikkinen wrote:
> Hi!
> 
> We are planning to simplify our packaging and releasing scripts and one thing 
> which
> would simplify our scripts is removal of version tag parsing for src (and 
> example)
> packages. So the question is if we can remove version tag (-alpha, -beta1 
> etc) from
> our src and exmple packages? 

This would effectively separate potentially interesting metainformation from 
actual
contents, so I guess this boils down to the question of who uses the source
packages for what purpose.

The problem I can imagime that people actively using the source packages (who 
would as
long as one can the same contents _plus_ history from git? - but there are 
apparently
such users?) will end up with qt-everywhere.tar.xz in their ~/Downloads and 
have no real
idea what this contains exactly after a few weeks time.

Does it really have an impact on the complexity of the scripts whether the 
-beta1
decoration is on the file name or on the directory name or both?

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

Re: [Development] Changes to Freenode's IRC

[André Pönitz]

On Fri, May 21, 2021 at 07:04:01AM +, Eike Ziller wrote:
> > I hear will be forgotten a few days later. If I hear something important, I 
> > might
> > take a note, in an explicit, extra step. Under no circumstances I will be 
> > able to
> > "remember" something someone said in a room I wasn't in a year ago, my only 
> > chance
> > is to talk to someone who was. And this is a _good_ thing.
> 
> But for IRC this is an illusion.
> Even if you don’t run around with a voice recorder, other people are sitting 
> in these
> rooms with voice recorders and record everything you say.
>
> Even if you forgot what you said, nothing is ever forgotten.

I don't have the illusion that it is truly forgotten. But most people in the 
world
won't have easy access to it. That's the point.

If they had, we wouldn't have that part of the discussion here that tries to 
make a 
point that IRC is bad technology as past communication is not (easily) 
accessible...

> And even though I see (I use Quassel) what the guy asked at 22:00 CET and 
> never got an
> answer to, I’ll never be able to answer him. One lost opportunity to help 
> someone.

And with forced registration that person might not have asked at all. Even if 
possibly
only because going through a "get temporary mail address, use it to register, 
accept
everything, perhaps solve gotcha riddles" ordeal is simply too much to go 
through for
one simple question.

We did see the number of useful comments to release blogs decrease after the 
system
changed, didn't we? I don't wonder why.

In another case, a person who would have been able to help might not have 
joined the
system for a similar reason.

So: No, logged history does not make things uniformly better, it just changes 
the
target group, incidentally closer to the one that is already served by other 
means
like the mailing lists and the web forum.

> So in the end one gets all the disadvantages (nothing is ever forgotten),
> without the advantages (async communication).

"Nothing is ever forgotten" is not the point. Any reasonable person has to 
assume
that this holds true for any word they say in the net.

There are already enough channels people who are fine with registration could 
use
to ask for help with their Qt problems. Forum, mailing lists, and whatever else
was listed already as "modern solutions". I believe there should be one channel
open for people who do not want that. This doesn't have to be IRC but IRC is 
filling
that niche currently. And it's the only input channel with that property we 
have left.

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

Re: [Development] Changes to Freenode's IRC

[André Pönitz]

On Thu, May 20, 2021 at 11:59:31AM +, Andy Nichols wrote:
> >> The chat channels are fragmented these days. There’s the Qt discord 
> >> channels,
> >> QtMob on Slack, Qt and Advanced C++ on Telegram. 
> 
> > Are any of these channels endorsed by the Qt project?  The IRC channels 
> > are, that's
> > why I'm raising the question here.
> 
> They probably should be.  We list those in our "Online Communities" wiki.  
> I'm active
> on the Qt Discord and its quite lively and interesting.
> 
> >> Not to mention freenode ones, that no one uses anymore,
> > This is a falsehood (they're active both in terms of traffic, and 
> > importance of the
> > discussions happening there -- like the release meetings).
> 
> IRC has been relatively "dead" for a while now compared to how it used to be. 
>  Even
> now that we are doing everything remotely IRC is pretty useless compared to 
> other
> chat services for collaboration because everything is so manual (sharing code,
> sharing images, sharing video, having voice calls, sharing a screen). 

And IRC can't make coffee and doesn't fix your bike either.

If you have some tool that happens to have some chat functionality does not 
make other
functionality of that tool a requirement when looking for a chat service.

> To get any history you have to run another service, or look at an archive 
> (which I
> can't even seem to find now for the Qt freenode channels). 

Works as designed. Freenode never endorsed public logging.

Chat is for ephemeral contents, like normal speech.

You don't run around with a running voice recorder all day, or require public 
logging
of everything you and the people around you ever said in real life, do you?

> I expect to be able to log Into chat on any of my machines (and my phone or 
> table)
> and see push notifications when I've been mentioned.

_I_ expect online chat to work similarly to offline chat: when I am in some 
room, I can
hear stuff, when I am not in some room, I don't hear anything, and most of the 
things
I hear will be forgotten a few days later. If I hear something important, I 
might
take a note, in an explicit, extra step. Under no circumstances I will be able 
to
"remember" something someone said in a room I wasn't in a year ago, my only 
chance
is to talk to someone who was. And this is a _good_ thing.

> All of these things we have now with Slack, Discord, Teams, etc.  Those 
> services
> have set a new standard of what we expect for a chat service.  Dealing with 
> IRC has
> the same level of experience now that it did when we dialed in with modems.  

Please don't use "we" unless you are sure you voice a consensus opinion.

I can't say anything about Slack or Discord, as I don't use them, but I do have 
an
opinion about Teams which I am requested to use at work.

For me, Teams has the worst chat-like functionality I've ever used, and that 
includes
'talk' or even telnetting into someone's machine and using 'write' there (so 
yes,
it's been a ride...):

There is no sensible way in Teams to keep up with what people said in various
discussion in various channels without excessive (and time consuming) mousing 
around.
Even individual messages are collapsed if they are "long". There's no way to 
arrange
things to be read linearly without interruption. And even if you expand stuff it
will be collapsed next time you come back. I am quicker browsing "useless" lines
for interesting information than to click around and then to browse that anyway.
And thanks to having no public protocol I don't even have a theoretical chance 
to
get a client that does what I want. So: Thanks, but no, thanks.

And that is just the usability aspect. The deep disrespect of anything in the 
vicinity
of privacy is another sore spot. Ever tried to control your "own" data there? 
Like,
cleaning up your "own" call history?

> As far as what chat service we *should* use that is harder to say (having 
> previously
> did battle inside of tQtc over this very topic for our internal chat and 
> getting
> nowhere).

[...]

> I expect that something like Matrix would be the only thing the more outspoken
> members of our community could handle, and I think that would probably Be a
> reasonable compromise as it does seem to be quite good.  I personally like 
> Discord
> but I can understand why people would have hesitations about that.  I did 
> notice that
> the Godot (open source Game engine) community have recently officially moved 
> there
> development chat to Discord from Freenode (IRC) and The server is very active 
> and
> vibrant.
> 
> I would like to get back to doing more of our development discussions out in 
> the open
> (like it should be), but right now IRC is not something I want to go back to 
> for
> that.

I also think that having development related discussions in internal Teams 
channels
is counterproductive not only for the parts of the community that cannot 
participate.

Using IRC would already (re-)enable that participation. If there is 

Re: [Development] Changes to Freenode's IRC

[André Pönitz]

On Wed, May 19, 2021 at 08:34:50PM +0200, Giuseppe D'Angelo via Development 
wrote:
> On 19/05/2021 19:31, André Pönitz wrote:
> > 
> > And now since we are on it: Can someone please remove the +r from #qt ?
> > All other #qt-* channels at FreeNode are fine without.
> 
> You could just ask... on IRC :-)

I think I did that already one or two times a while ago.
 
> It was done to prevent spam. #qt gets periodically rallied by spambots,
> which tend to ignore the other smaller channels in the #qt-* family.

Last time (memory fades, two years ago) #qt-labs and #qt-creator were
also hit, and switched to +r. But they also switched back afterwards.

Andre'

PS: Thank you.

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

Re: [Development] Changes to Freenode's IRC

[André Pönitz]

On Wed, May 19, 2021 at 05:03:24PM +0200, Ulf Hermann wrote:
> > Rather than just move to another IRC server, we should really take
> > this as an opportunity to move to another chat service as the
> > official Qt Project chat.  IRC has a terrible user experience and is
> > not at all accessible for people who haven't been using it for
> > decades like many of us. It does us a huge disservice when trying to
> > attracting new contributors to point to our IRC.  There are lots of
> > better options out there now (which I see some of you on already), so
> > lets move on already.
> 
> The problematic point is "lots of better options". We need to agree on
> one thing here, and it should be something that doesn't shut down
> tomorrow. Maybe you can share some of the options that people already use.
> 
> Considering that IRC, being all plain text with rather weak
> authentication, was enough so far, I don't think privacy is such a big
> deal here.

Funnily enough, the only _forced_ privacy problem with IRC is that you
have to disclose your IP and that's hard to avoid for technical reason.

> The most important thing are the public channels and those
> are, well, not private.

"Privacy" is not (only) about what you say, it's also about who you
are and what you did last summer.

No registration means gives the possibility to avoid building up
profiles, even in public communication. If you want one, fine, you
can have that too.

> Barrier to entry should indeed be lower than IRC, and for me that means
> there shouldn't be an elaborate registration procedure.

There shouldn't be _any_ mandatory registration.

And now since we are on it: Can someone please remove the +r from #qt ?
All other #qt-* channels at FreeNode are fine without.

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

Re: [Development] Changes to Freenode's IRC

[André Pönitz]

On Wed, May 19, 2021 at 02:37:26PM +, Andy Nichols wrote:
> Hello,
> 
> Rather than just move to another IRC server, we should really take
> this as an opportunity to move to another chat service as the official
> Qt Project chat. 
>
> IRC has a terrible user experience and is not at all accessible for
> people who haven't been using it for decades like many of us. It does
> us a huge disservice when trying to attracting new contributors to
> point to our IRC.

I seriously doubt that the problem of not getting new contributors
has a lot to do with IRC's "user experience".

> There are lots of better options out there now
> (which I see some of you on already), so lets move on already.

Which of these options you have in mind 

* do require no registration

   -- and --  

* are not _obviously_ driven by commercial interests?


Andre'

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

Re: [Development] User-defined literals for QString (and QByteArray)

[André Pönitz]

> Ville Voutilainen 
> On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development
>  wrote:
> > 
> > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto:
> > > This seems like a bug though? From an API point of view, I’d expect this
> > > simple assignment to JustWorkTM, without requiring syntactic sugar all
> > > over the place. Shouldn’t we fix this, so we don’t need (or leave
> > > optional) an explicit _qs suffix?
> > 
> > Because of
> > 
> >void f(QString);
> >void f(QStringView);
> >f(u"foobar"); // ambiguous
> > 
> > combined with the overarching plan of adding QStringView overloads when
> > possible (that is, in functions where historically we weren't doing so)
> > and never breaking BC/SC.

> Right. Somethings gotta give, and if QString and QStringView are
> implicitly convertible from the same things,
> those calls are ambiguous, and there's nothing that can be done about
> that unless the overload set f decides which
> one it prefers.

> Compromising the implicit convertibility would allow us to make one of
> those functions preferable, but that would
> mean that all conversions to one of those types need to be explicit.
> At which point the syntax you want to work doesn't
> work. The ambiguity doesn't prevent it from working, though - but if
> we don't want that ambiguity, we need to make
> either of QString or QStringView not-implicitly-convertible from a literal.

> Like in this little playground: https://wandbox.org/permlink/mjAdAI56GCjBXhjJ

What if there weren't overloads of the actual functions on QString and
QStringView?

https://wandbox.org/permlink/rdIhbPRdGHuWWxFW

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

Re: [Development] Qt 6 co-installability with Qt 5

[André Pönitz]

On Tue, Feb 16, 2021 at 04:35:25PM +0200, Ville Voutilainen wrote:
> On Tue, 16 Feb 2021 at 15:35, Kai Köhne  wrote:
> > And again, this is not something limited to Qt. Last time I checked,
> > the executable to run Python 3 on Windows is python.exe, not
> > python3.exe. On Debian at least it's python3. This hasn't blocked
> > Python from being perceived as overall beginner friendly ...
> 
> Uh.. that seems like an apples-and-oranges comparison. On linux, it's
> expected and conventional that if you install both python 3 and python
> 2, both are available in the usual PATH, neither eclipses the other,
> and you can cd between python 2 and python 3 projects and run both,
> without switching environments or alternatives in between.
> 
> On windows, I don't know what's conventional. In many cases, a
> shortcut is used that launches a command prompt with the right
> environment, and using two versions in the same command prompt just
> isn't done.
> 
> > So, I would stick to qmake as canonical name, also in the
> > documentation. We can mention that it's sometimes called qmake6 on
> > Linux. But forcing everyone to change their habit and scripts just
> > for the sake of consistency with a fraction of the users that use a
> > global installation on Linux, and do not use update-alternatives, is
> > IMO not a good move.
> 
> update-alternatives is a long-term system-wide configuration change.
> Changing PATH is a shorter-term user-specific one. That's how I switch
> between compilers, and I wouldn't dream of using update-alternatives
> to switch between them. Especially not on multi-user systems, where
> it's none of my business to change the alternative used for a system
> compiler for other people. I *can't* do an update-alternatives on a
> build server, and I *shouldn't*. That doesn't mean that a build server
> installation couldn't have both qt 5 and qt 6 installed in a
> system-wide location.
> 
> Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
> If our approach requires it, our approach is broken.

[Responding to a more or less random mail in the thread here]

I agree that update-alternatives is Just Wrong for something that
should effectively be the user's decision (and not even a decision
for all of the user's projects but something that needs to be done
case-by-case).

On the other hand I don't quite understand all the fuzz about the
Correct Global Name. When I as a user am not happy with someone's
decision on how to name a binary or if a distribution acts funnily or if
I am too lazy to change my muscle memory I set up a shell alias to do
what I want. 

The only problem with that is people looking over my shoulder sometimes
wonder why 'n' brings up firefox or 'gh' starts Qt Creator...

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

Re: [Development] Qt6 repo

[André Pönitz]

On Wed, Jan 13, 2021 at 12:48:45PM -0800, Thiago Macieira wrote:
> On Wednesday, 13 January 2021 10:17:02 PST André Pönitz wrote:
> > I have a product that depends on qtbase, qtdeclarative and qttool, and
> > qtdeclarative and qttools refer to different and incompatible versions
> > of qtbase in their respective dependency.yaml files.
> > 
> > How do I build Qt?
> 
> There's no such thing.

You are telling me my day job doesn't exist?
 
> Any *product* is built with released versions of Qt, which means you
> must have exactly the same releases of each module. No other
> combination is supported.

I am not asking for *support*. I am asking how to find a recent working
combination of Qt modules that I need for porting some code base to
Qt 6. Don't tell me to use 6.0 nor to wait for some 6.x.

> For people developing Qt, once you've checked the Git repositories out, it 
> doesn't matter whether there's a .gitmodules or not to build.

Lacking a monolothic repo the superrepo is currently pretty much the only
safe way to find a working combination of reasonably recent states of
Qt modules. Sure, one can try HEAD of each module first, and it works
sometimes. In a few more cases commenting out a few unneeded bits helps
to make it work, but after the third attempt one wants a safe fall back.
So far the superrepo delivers that.

I am not a big fan of git submodules, nor does the effort spent on failed
integration attempts look appealing. But effectively the central
integration is the work that otherwise all users who need to keep up with
the bleeding edge had to do by themselves.

> For example, I always use the latest of the branch in question for
> every module, regardless of what's stored in the super module.

How much do you depend on modules outside qtbase? With qtbase only you
practically live in a world of a monolithic repo. Working HEAD is
expected there.



In any case, the point was that "building according to dependency.yaml"
doesn't give a "build". Different leave modules will have different
dependencies on qtbase, which cannot be used at the same time.

Andre'

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

Re: [Development] Qt6 repo

[André Pönitz]

On Wed, Jan 13, 2021 at 01:37:21PM +, Volker Hilsheimer wrote:
> [...]
> The workflow with such a setup would not be fundamentally different
> from today. You clone one thing (build system repo instead of
> qt5.git), you run a script and tell the script what you want to work
> on to get all the things you need. You build Qt more or less as
> before; the configure script lives in the build system repo rather
> than in some Qt super module clone. The file system structure will be
> a bit different.
> 
> 
> Advantage:
> 
> * no (inconsistently) duplicate information in .gitmodules vs
> dependency.yaml files

I have a product that depends on qtbase, qtdeclarative and qttool, and
qtdeclarative and qttools refer to different and incompatible versions
of qtbase in their respective dependency.yaml files.

How do I build Qt?

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

Re: [Development] QVariant comparison in Qt6

[André Pönitz]

On Fri, Sep 18, 2020 at 11:56:38AM -0700, Thiago Macieira wrote:
> On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > > We should use one of the types from [1]. Yes, it's C++20; we can
> > > make our internal API return an integer that is convertible to those types
> > > in the front-end API, under #if __has_include().
> > > 
> > > [1] https://en.cppreference.com/w/cpp/header/compare
> > 
> > Why do people keep pushing C++20 facilities when we decided that C++17 is 
> > our
> > standard version? How does the int say "I can't compare this"?
> > partial_ordering can do that, but what will the int do?
> 
> Because we should push our users to adopt new compiler versions.

What kind of political agenda is that?

Pushing for newer anything just means we are leaving people behind.

This might be justified in some cases if there's a real benefit outweighing
this loss, but pushing just for the sake of pushing?

> features in Qt only available when they upgrade is a good way to do that. 
> Want 
> to use old compilers? It costs more.

The cost is on *our side* because frustrated people leave the ecosystem.

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

Re: [Development] Is qsizetype *documented* to be ptrdiff_t?

[André Pönitz]

On Wed, Sep 02, 2020 at 09:15:37AM +0200, Mathias Hasselmann wrote:
> I'd rather say that cast is entirely ugly. Seems like a perfect example or
> code smell: Something is fundamentally wrong they way qsizetype is defined.

Funnily enough the same can be said for the casts that are now necessary
in a formerly consistent 'int'-based codebase using Qt containers.

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

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

[André Pönitz]

On Wed, Sep 02, 2020 at 09:37:49PM +0200, Giuseppe D'Angelo via Development 
wrote:
> 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 do not build *truly* performance sensitive code using Qt containers.

The reference counting is very convenient, but it comes with a price tag
for non-const item accesses for checking the reference count. 

In the (absolutley rare) cases of "performance trumps everything" *this*
is not acceptable.

The only backstabbing that happens in this area is the removal of Qt
container convenience functionality based on performance arguments that
are not applicable in almost all cases, or on a "does not exist in the
Standard Library so it can't be good" base.

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

Re: [Development] qsizetype and classes working with QStrings or QList

[André Pönitz]

On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
>C++ also has a solution for that problem: [1]
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

AAA is a non-solution from the ivory tower.

It's a pain for human reviewers and tools operating on less then a full
translation unit.

(Almost) real-world example:

for (auto i = foo.guess_stuff(); --i >= 0; )
  do_something(i);

Good? Bad? 

Andre'

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

Re: [Development] qsizetype and classes working with QStrings or QList

[André Pönitz]

On Mon, Aug 24, 2020 at 09:26:54AM +0200, Giuseppe D'Angelo via Development 
wrote:
> On 23/08/2020 16:06, Marcel Krems wrote:
> > If they keep using int there could be a lot of warnings like this one:
> > warning: implicit conversion loses integer precision: 'qsizetype' (aka
> > 'long long') to 'int' [-Wshorten-64-to-32]
> 
> I'm afraid that these warnings will be all over the place anyhow. Just how
> much code has been written against int-based APIs?

Depends on the nature of the application, but in a typical Qt application
where GUI plays a major role, I would expect 'int' all over the place,

As an example, Qt Creator code has 48715 hits for '\bint\b', 1191 '\bsize_t',
most of the latter in 3rd party or test code.

> why I wanted a configure time switch to choose the size of qsizetype).

This doesn't really help if Qt comes with your distribution or even with
the Qt installers.

> But anyhow: yes, as a consistency factor, as many APIs as possible should be
> ported to qsizetype.

For us it was consistent so far. It is getting a pain only now. 

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

Re: [Development] QProperty and library coding guide

[André Pönitz]

On Wed, Jul 22, 2020 at 10:24:21AM -0700, Thiago Macieira wrote:
> On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> > How often do we think people are actively taking advantage of Qt's BC
> > promise (and how often do we hold this promise, and how often is this
> > relevant as we do not promise to change behaviour while keeping BC)?
> 
> That is a good question. I don't want to minimise it, just to add.
> 
> Have at least one category of users that require it, that being the Linux 
> distributions.
> So long as we support them, we have to provide a way to have 
> BC. And if we do have such a way, how much does it hurt to extend it 
> everywhere?

How much of a *hard* requirement is that in practice?

If Qt would bump major versions once a year, and take that as a chance to
break BC, would that be a problem, if so, why?

Because distributions have a large set of packages that are not
rebuild at least once a year? Or because users have a few hundred
packages that they don't want to update otherwise?

> We've seen users of not-systemwide-Qt-OSes having BC issues too. Large 
> projects often have binary artifacts they'd rather not recompile every time. 

"Every time" would be something as or less frequent than the current minor
release cycles, i.e. twice per year, or less frequent.

> Those teams can be taught to recompile, but that's not their current 
> practice. 
> Breaking BC means subtle errors that are hard do detect and debug.

Right. But at the same time we accept behaviour changes which can lead to
similar subtle errors that are hard to detect and debug as well. 

I see no real conceptual difference here.


> Finally, there's the issue of binary-only components by third parties. If we 
> ever want to support such an ecosystem (we could call it "Qt Marketplace"), 
> we 
> must have as few binary-incompatible versions as possible. It's already 
> difficult to support, for desktops alone:
>  - Linux GCC 64-bit
>  - Apple Clang 64-bit [*]
>  - Windows MinGW / Clang 32-bit
>  - Windows MSVC 2019 / clang-cl 32-bit
>  - Windows MSVC 2019 / clang-cl 64-bit

I'll argue that a robust, binary-only distribution of independent, but 
interacting
components does not work in practice. If it would, the Windows ecosystem would
have invented that during the last 30 years or so. Instead we have rather
monolitic fat applications there, with components shared at most within a given
vendor's own product line, with really rare exceptions.

> Breaking BC frequently means replicating this table for every BC breakage 
> level.

Or have the input channel accept source code and build the binaries 
automatically.


In any case, I don't think either use case is an absolute reason for keeping BC.

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

Re: [Development] QProperty and library coding guide

[André Pönitz]

On Wed, Jul 22, 2020 at 10:27:14AM +, Lars Knoll wrote:
> > On 22 Jul 2020, at 11:38, Shawn Rutledge  wrote:
> > 
> > 
> >> On 2020 Jul 16, at 11:19, Ulf Hermann  wrote:
> >> 
> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> >> actually late to the game. If we want Qt to stay relevant, then it needs to
> >> offer the same kind of convenience and performance that other frameworks
> >> offer. This would be an argument for converting all existing properties, 
> >> and
> >> paying the price, just to make the binding API available.
> > 
> > Has someone done a survey of how bindings are implemented in other 
> > frameworks?
> > Maybe there is a cool trick out there that we are missing, which would 
> > enable
> > a big leap in efficiency.
> 
> I don’t know of anybody who has done this for C++ yet. I do believe the design
> we have with QProperty is pretty good from an API perspective as well as
> efficient.
> 
> The problem we’re having purely comes from the fact that we’re trying to 
> provide
> BC between versions and are hiding our data behind a d-pointer. If we'd give
> this up the whole problem would go away.

Then the elephant in the room is the question how valuable BC in generally is
for normal Qt users.

How often do we think people are actively taking advantage of Qt's BC promise
(and how often do we hold this promise, and how often is this relevant as
we do not promise to change behaviour while keeping BC)?

For me personally, source compatibility is much more valuable, and BC is a
"good enough" approximaton for that insofar that having to keep BC prevents
a lot of changes that would also break SC. 

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

Re: [Development] QProperty and library coding guide

[André Pönitz]

On Thu, Jul 16, 2020 at 11:08:40AM +, Edward Welbourne wrote:
> Giuseppe D'Angelo (16 July 2020 12:58) requested:
> > Could anyone please illustrate with some code snippets how to achieve
> > this, in practice, in a number of use cases? E.g. client code (non
> > pimpled QObject subclass), (Qt) library code (pimpled QObject
> > subclass), etc.; gadgets (does QProperty work there?); with and
> > without other Q_PROPERTY/QProperty already present, etc.
> 
> As noted in my last mail, documentation is still lagging. 

I think just a few typical code snippets would already help.

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

Re: [Development] Applications using -fno-rtti

[André Pönitz]

On Sun, Jun 21, 2020 at 11:22:58AM +, Lars Knoll wrote:
> We didn’t want it in earlier versions of Qt for mainly two reasons. Early
> implementations had quite an overhead on library size, and dynamic_cast didn’t
> work reliable between DLL boundaries on Windows. Both problems have gone away
> many years ago.

I would appreciate if someone on Windows could run a reality check on that
with a dynamic_cast between classes that don't have a key function, i.e.
where everything is inlined and/or templates.

> [...]
> We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s
> high time we adjust the wiki.

The fact that it works in some, even common, situations doesn't imply
it works safely everywhere.

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

Re: [Development] Switch the main "Qt Build System"

[André Pönitz]

On Tue, Jun 09, 2020 at 08:06:57AM +, Alexandru Croitor wrote:
> > On 9. Jun 2020, at 04:32, André Pönitz  wrote:
> > 
> > On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
> >> [...]
> >> The CMake ports are built in Coin with the most important configurations
> >> (Linux, Windows, macOS, Android, iOS, qemu Linux).
> > 
> > Is there a list of configurations that work/do not work?
> 
> I'm not sure what your definition of works is.

My definition of "works" in this context is "Doesn't get in my way,
i.e. compiles, and doesn't crash for the things I am using".

> Here you can see the configurations that are rested currently in Coin.
> 
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml (svg 
> is
> just an example)
>
> So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw 
> also
> work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64.
 
I don't see any build there that looks like it might be a namespaced build.
This has a high chance to not meet the "compiles" condition above for me.

> I'm waiting on some updates to switch iOS to simulator_and_device.
> 
> Android multi-ABI is currently not implemented, and we don't plan to do it for
> 6.0.

Isn't Android support part of qtbase?

> We don't have WebAssembly at the moment, but it was tested to work at some
> point.
> 
> Not shown here, we also have a Linux embedded arm qemu configuration in Coin 
> for
> qtbase, which will be expanded to other modules.
> 
> > Will it be possible to use bisect "all of Qt" with reasonable effort also 
> > for
> > changes in the time until the transition is complete and the result is 
> > stable?
> > E.g. will there be clear which state of which module compiles with which 
> > state
> > of other modules with no or only short non-compilable phases inbetween?
> 
> If i understand correctly, this touches upon 2 topics.
> 
> 1) if we remove .pro files, there will be 3 periods of build systems. Before
> 6.0, you'll have to configure and build with qmake, then a short period where
> you can build with qmake and somewhat with cmake (depends on how far in the 
> past
> you go and at what state the cmake port was in that time), and post-removal of
> .pro files, you'll only be able to build with cmake.
> 
> I don't think i can give you exact commit sets for that, so yes, it'll 
> probably
> be painful.

Given the amount of Qt5->6 code changes that would be an unfortunate situation.

Do you think it is really necessary to remove the .pro files at once? Wouldn't
just not using them for your CMake file generation already be enough for you
to proceed?

> 2) dependencies.yaml
> 
> Which module compiles against which other module seems like a separate concern
> that is not entirely related to the build system in all cases.
> 
> Figuring out combos of which module sha1s can be built together is already
> somewhat of an issue with the current qmake build system, so that part is out 
> of
> scope for the CMake port team.

It was not about module sha1, but figuring out the way modules are build given
a sha1. Effectively this would mean that at least in the early phases of a
bisection one has to find out what setup has to used to build a module, too.
 
> Are you suggesting we somehow annotate the CMake part of the question? Like 
> "we
> guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake 
> with
> SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly
> moving forward.

I think part of the issue would be avoided if the .pro file were not purged
until CMake is a full replacement.

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

Re: [Development] How bad QList really is

[André Pönitz]

On Wed, Apr 29, 2020 at 01:41:46AM +0200, Giuseppe D'Angelo via Development 
wrote:
> Il 28/04/20 21:45, Matthew Woehlke ha scritto:
> > > * QList gets adapted so that its internal array allocates 3 *
> > > sizeof(void*) per element, so that e.g. Q6StringList won't require a
> > > per-item allocation. This would then also avoid allocations for other
> > > datatypes, e.g. QStringView, QImage, maybe QVariant and QColor; but
> > > of course waste a ton of space for the ones which remain small (most
> > > of Qt implicitly shared datatypes).
> >
> > Uh... can't it allocate sizeof(T) if T meets some criteria? IOW, I
> > don't see the second case penalizing smaller types unless the
> > implementation is poorly done.
> 
> This way of working is the *key* of QList design.

It happens to be implemented that way.

Why this was done that way I don't *know*, but given that it is optimal
in 98.5% in my cases, I'd guess that it was simply considered "good enough".
Which it actually is.

It is surely not mandatory to have to achieve features like cheap erase at
the beginning etc for that.

*If* the workload changes in Qt 6 due to the increased QString size, there
could be a specialization for things with, say, 3 x sizeof(void *) for
objects of this size.

And only for those. The 1 x sizeof(void *) for normal cases can be kept.

This "we will have to waste a lot of space" argument is simply wrong.

> QList is alwys a vector of void* (so it's nice for Qt pimpled types).
> This allows to type erase the entire management of the vector (it's
> always a vector of void*), reducing the amount of template code that
> needs to be instantiated.

It is interesting to see that the "code size" argument shows up as super
important elsewhere, but doesn't play a role when it gets into the way of
killing QList.

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

Re: [Development] Views in APIs

[André Pönitz]

On Thu, May 14, 2020 at 11:46:29AM +0200, Marc Mutz via Development wrote:
> > Please stop with this crusade of yours to end all CoW, get rid of
> > QList, etc. It is misguided and harmful to the ecosystem at large.
> 
> You are entitled to your opinions just as I am. The difference is that I put
> time (much more than KDAB pays me for, esp. when it comes to my "crusade")
> where my mouth is.

The problem here is not what personal or company time you invest yourself.
You can spent as much of that as you wish or are allowed to.

The problem is the effort these activities cause for others, especially
for those that do not share your opinions, and are still forced to adapt
their code to your preferences.

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

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

[André Pönitz]

On Tue, May 12, 2020 at 02:09:21PM -0700, Thiago Macieira wrote:
> On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
> > What do you do? Adding a QStringView overload will make calls ambiguous,
> > removing the QString one will be an ABI break. We need an established
> > solution for these cases as they'll pop up during the Qt 6 lifetime.
> 
> Indeed.
> 
> And the API policy must be one such that it doesn't depend on what the method 
> does *today* and it doesn't create a mess. Functions change.
> 
> [Good regexp example snipped]
> 
> I want rules that determine what the API should be without looking at the 
> implementation of those two functions.

Same for me.

And I think this is an important point, even to the degree that a clear, uniform
API is more worth than a handful cycles.

Most of API changes that are currently discussed or even done "for performance
reasons" *do not matter in practice*.

If a real world Qt application has a performance problem, this is *not* solved
by changing QRegularExpression::pattern() from returning a QString to returning
QStringView.

There are very few cases in repeatedly used low level functions where it 
actually
*does* make sense, but there it's actually ok to have duplicated interface.

The "overload" problem would also be solvable, by not using overloads, but
differently named functions, e.g. by sth like  .midView() instead of .mid().

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

Re: [Development] How bad QList really is

[André Pönitz]

On Tue, Apr 28, 2020 at 12:25:32AM +0200, Jean-Michaël Celerier wrote:
>> As starters, there are 85 occurences of QList::takeFirst() in Qt
>> Creator source code. Replacing these with QVector replaces a O(1)
>> operation with an O(n) operation.
>
>Apologies if I'm wrong, but isn't QList::erase (and anything
>derivative) always O(N) ?

Not in 5.x

https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=blob;f=src/corelib/tools/qlist.cpp;h=5d5da20752aa3d21e06330094095702019f53c93;hb=refs/heads/5.15.0#l272

For offset == 0 the memmove is of length 0, only d->begin is bumped.

>With a lower cost than std::vector for things with sizeof > 8, sure,
>but still.

Even when inserting in the middle, where both QList and QVector insertion
is formally O(n), QList on large data only memmoves size/2 pointers,
QVector's size/2 operations can be arbitrarily expensive, depending on the
exact nature of the stored items.

>And, given that 98% of QList usage seems to fall into the "good" case
>of sizeof<= 8, wouldn't that make zero change when switching to QVector
>?

There would be no difference in those cases if the premise were right.
But it isn't.

If you have ideally movable items in the QVector case (i.e. item move
costs equal to one pointer move, and the move loop optimized the same
as the explicit memmove), and choose a random position in the container
to insert from a uniform distribution, the expected cost of item shuffling
due to the insertion is for QList only half the cost as for QVector.

This ratio decreases further, i.e. becomes even more in favour of
QList, when the items are not ideally movable.

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

Re: [Development] How bad QList really is

[André Pönitz]

On Mon, Apr 27, 2020 at 11:13:26AM -0400, Matthew Woehlke wrote:
> On 25/04/2020 10.49, André Pönitz wrote:
> > We all know the story that began with
> > 
> >  "We knew for a long time that QList is not a good default
> >  container, despite what the documentation claims. The problem
> >  boils down to the fact that for a lot of types T, QList is
> >  needlessly inefficient by allocating elements on the heap and
> >  storing pointers to them instead of storing the elements
> >  in-place, like e.g. QVector does. Sometimes, for large and
> >  complex types, that might be exactly what you want, but a
> >  conservative estimate would put that chance at less than 5%." [1]
> > 
> > 
> > I was curious how this "conservative" estimate of "less than 5%"
> > manifests in real QList object instances in a real world example.
> 
> (Remainder elided)
> 
> Thanks for the analysis! However, it seems the major take-away is that
> "when QList acts like QVector, all is well"?

No. The major take-away is that in the first reality check on the topic
98.5% of the cases QList behaves optimally, and in 1.4% the jury is still
out. 

Even if the jury comes back with a verdict that all the remaining cases
were better served by QVector (unlikely, see below) a shot-gun
replacement of QList would at best change 1 out of 70 instances, placing
the whole activity safely into micro-optimization land.

> It would be interesting to see a comparison that ignores all instances
> where QList is behaving like QVector.

This would indeed help us to understand how small the micro in this micro
optimization is, or whether we are actually looking at a pessimization.

As starters, there are 85 occurences of QList::takeFirst() in Qt Creator
source code. Replacing these with QVector replaces a O(1) operation
with an O(n) operation. This may or may not be a problem in practice,
in any case, all such uses would need to be audited. Similarly removeAt,
removeOne and removeAll have a chance to degrade in performance.

Andre'


PS:

> The other problem is that performance isn't the only story. Sometimes,
> reference stability is desired. AFAIK, the only containers in Qt¹ that
> provide this currently are QLinkedList and QMap.
> (¹ I speak of Qt6, specifically. In Qt5, QHash could be added to that list,
> but no more.)

Sure, but that's a different topic.

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

[Development] [SPAM] How bad QList really is

[André Pönitz]

Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  We all know the story that began with "We knew for a long
  time that QList is not a good default container, despite what the 
documentation
   claims. The problem boils down to the fact that for a lot of types T, 
QList
   is needlessly ineffi [...] 

Content analysis details:   (5.3 points, 4.6 required)

 pts rule name  description
 -- --
 0.8 BAYES_50   BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
 0.0 FREEMAIL_FROM  Sender email is commonly abused enduser mail
provider (apoenitz[at]t-online.de)
 0.0 SPF_HELO_NONE  SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2  RBL: Average reputation (+2)
[194.25.134.80 listed in wl.mailspike.net]
 0.0 URIBL_BLOCKED  ADMINISTRATOR NOTICE: The query to URIBL was
blocked.  See

http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
 for more information.
[URIs: marcmutz.wordpress.com]
 2.0 SPOOFED_FREEMAIL   No description available.
 2.5 TO_NO_BRKTS_PCNT   To: lacks brackets + percentage


--- Begin Message ---

We all know the story that began with

"We knew for a long time that QList is not a good default
container, despite what the documentation claims. The problem
boils down to the fact that for a lot of types T, QList is
needlessly inefficient by allocating elements on the heap and
storing pointers to them instead of storing the elements
in-place, like e.g. QVector does. Sometimes, for large and
complex types, that might be exactly what you want, but a
conservative estimate would put that chance at less than 5%." [1]


I was curious how this "conservative" estimate of "less than 5%" 
manifests in real QList object instances in a real world example.  

My random picks of real world examples usually end up with "Loading
the Qt Creator project in Qt Creator itself", and "statistics" is
something I make up myself, in this case it is looking at QList objects
at destruction time, and sorting them a bit according to size of
the items in the list, number of items still present at that time etc.

Besides being simple to do it's rather close to the typical use I see,
where containers are filled up, accessed/used a few times and destroyed
without much intermediate size changes.


Here is what I get:

* total QList objects created  :51.631.363   
  - destructors that only bump ref :38.015.673  73.6%
  - destructors that actually dealloc  :13.615.690  26.4% 


The  13.615.690  instances with actual deallocations ordered by the 
size of the item type:

size occurences

 4 1.656#  0.01 %   with internal padding
   
 8 13.424.228   # 98.59 %   objects with ideal size, 


 12 3\
 1674.979 |
 2460.560 |
 28   126 |
 3222.358 |
 40 2.054 |
 4818.786 |
 5671 >  # 1.40 %  with indirection
 64 3 |
 7246 |
 80 3.484 |
 96 1 | 
 1127.264 |
 128   52 | 
 1842 |
 2112  17/


>From the 8-byte objects we have
 
13.420.883  stored directly  #  99.975 %  of cases
 3.345  stored indirectly#   0.025 %

i.e. in 98.57% of all cases, QList objects behave optimally.

This high percentage differs from the artificial benchmark scenarios not
by accident. Almost all of these lists are lists of pointers, a natural
ingredient of tree-like structures, common in user interfaces.


The "padding problem" for types with less than ideal size has been touted
as major problem. Let's see how hard it hits me:

>From the 4-byte objects we have
 
   947  stored directly  #   57.2 %  of cases
   709  stored indirectly#   42.8 %

In the first case I use "conservatively estimated" 32 byte on the heap, for
data and any accounting, 4 more for the gap itself, the second has only
4 for the gap, summing up to a total of 29.312 bytes. 

>From the 8-byte objects we have
 
13.420.883  stored directly  #  99.975 %  of cases
 3.345  stored indirectly#   0.025 %

i.e. another 53.520 bytes due to the indirection. Total waste is 

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

[André Pönitz]

On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote:
> Am 24.04.2020 um 09:22 schrieb Lars Knoll:
> > > e "vector is a silly name from a mathematical standpoint" argument is 
> > > valid,
> > > but vector is an established term in C++ world. Sorry, that ship has 
> > > sailed.
> > > I am also in favor of proposal 2 or 3. I think deprecating either QList or
> > > QVector without any big advantage for the user will just make porting form
> > > Qt5 to Qt6 needlessly harder.
> > > 
> > > Even inside Qt we are struggling to keep up with deprecation warnings
> > > (Thanks to Friedemann for fixing these). I am pretty sure Creator does 
> > > have
> > > the same "problem". Extrapolating that from "just us" to the broader
> > > audience we are hopefully targetting, it looks like lots of
> > > users/applications will be hit by these warnings and it will mean (lots 
> > > of?)
> > > work for them.
> > I do agree that we shouldn’t deprecate neither name, as that would just make
> > moving from 5 to 6 harder. The unification of the classes should help 
> > simplify
> > things.
> > 
> > But we need to have a consistent message around which name is the preferred
> > one and used in Qt’s own API and documentation. Having a QList in one method
> > and a QVector in the next one would only be confusing to our users. So IMO
> > this thread should mainly be about deciding what the default name for this
> > container is in our documentation and API in Qt 6.
>
> Since you tell everyone since ages that QList should not be used (it's in the
> documentation since 5.6: 
> https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details

Sorry. There was never an *agreement* on the issue.

QList(<=5) was designed and implemented to be a convenient, easy-to-use
one-size-fits-all container for use cases in user facing application that was
hard to completely get wrong even for C++ newbies, including "unreasonable" use
cases like being able to access by index *and* to insert big objects in the
middle without completely killing performance.

It was never meant to be the best performing nor the smallest container for a
given fixed use case *by design*.

Consequently, it was very easy to find setups were there where better
alternatives. In fact, in almost all setups there was *some* other container
that was smaller or faster, it was "just" not always the same container.

From that some people draw the conclusion that QList was a bad thing and started
lobbying for its demise in blog posts, conference talks and here on the mailing
list. Over time this was successful, at some time in the documentation the
comment on the default choice was flipped and for Qt 6 the implementation was
shared with QVector.

For this discussion here now the interesting consequence is that by the new
sharing of the implementation with QVector all the implementation related
arguments against QList that have been made in the past are void, all those
arguments do *not* apply to QList(>=6), at least not unless you extend them to
QVector, see below.

When you now look at the 2010 blog post you'll notice that *none* of the
performance and size claims in there apply to QList(>=6).


So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually caused performance regressions in real world applications,
i.e. the performance argument made against QList wasn't quite as uniformly
applicable as initially presented.

Today the main line of reasoning given is that QVector is something like
std::vector and people knowing C++ would feel comfortable using it the same way.

And that would be a false friend.

QVector is refcounted, so it *also* trades cycles (e.g. for write access) for
convenience (return by value without further decoration? No problem!) This is
still exactly the same quality of compromise QList was accused of for a decade
now, all the arguments made against compromises in principle could be made
against QVector as well.

Replacing *now* all QList uses by QVector would be a lose-lose situation. People
aiming at the ability to use a std:: container of their choice will not be
content, as it's still not a std:: container, both in name and behaviour.
Everyone else will have to adapt their code or live with the uncomfortable
feeling about not using the most recent name.

It's still possible, and easy, to limit the damage to one of the factions,
and that's what I understand is what the proposals here were aiming at.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 04:45:02PM +0200, Giuseppe D'Angelo via Development 
wrote:
> On 4/23/20 1:20 PM, Edward Welbourne wrote:
> > So how much harm does it really cause, to keep both names; and use
> > whichever feels like the more natural description of the value one is
> > returning ?
> 
> I missing the bigger picture about this thread. What are we trying to assess
> / solve?

I am not sure what everyone else is trying to solve, but I know
what I am trying to solve.

I am trying to solve the problem that moving an application from
Qt 5 to 6 will require significant effort, arguably too much effort
already for, so we'll see a lot of applications reluctantly,
or possibly never, moving to Qt 6, effectively dropping out.

And I think that's a situation nobody here should be interested in.

Solving the QList issue by saying "nothing to be done" takes
away some part of the pressure, specifically one that has the
potential of touching a large part of a code base.
 
> If we went the other way around, i.e. QList is the "default" type, like
> proposed: doesn't the task stay fundamentally the same?

No, because there's a lot less code using QVector, and from that
quite a bit only introduced recently, i.e. in an context where
one can hope that the projects actually have active resources
to "fix" things.

> [...]

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 05:04:27PM +0200, Julius Bullinger wrote:
> On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:
> > == Naming of functions and types if QList = QVector ==
> > 
> > We have QStringList, QVariantList and friends, which are aliases /
> > subclasses of QList and so on.
> > 
> > Should they become QStringVector, QVariantVector; and the *List names
> > stay, aliases for the *Vector names, mirroring QList and QVector
> > themselves?
> 
> Another suggestion: Get rid if the aliases; use the fully-qualified types
> instead.

In case of QStringList that would be QStringList.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
> 
>I read the entire discussion, and I'd like to say this one more time:
>we don't have to fight the consequences. Better to eliminate a cause.
>There always will be a functionality to deprecate. There always will be
>controversial APIs, that, for example, contain a hard-coded type
>information in the name (e.g. "windowList()" instead of "windows()").
>Why not think about it instead? Today it QVector vs. QList, tomorrow
>something else...
> 
>We can at least shorten release cycle to one year.

One year for a major Qt release and then break API?

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?

How often do you think we can play this game until people look for
something they consider more stable?

>Provide clang-based tools to (semi-)automatically port users' code
>bases to a new version of Qt.
>
>These tools might either fix a code or at
>least add a comment in potentially problematic places where a user
>should correct the code. A developer who changes API should also
>implement a rule for these tools.

This magic tool comes up over and over again, still no-one "just did it".
Maybe because it's not *that* trivial after all, maybe because doing that
actual porting ends up in real work, which is  much less fun than just
deciding that something needs to be changed, maybe something else.

Really: All this talk "this is bad, should be done differently, and
then it is better" would be much easier to believe if they were accompanied
by patches that implements that change for all of Qt. Or all of KDE.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> >
> > That depends on the number of the functions affected, and how commonly those
> > are used. If we are talking about just a few virtual functions here and 
> > there
> > which are not expected to be overriden by a vast majority of applications
> > (such as the QIconEngine example), then changing the signatures is probably
> > acceptable. After all, Qt 6 will have a number of source compatibility 
> > breaks
> > (typically in less commonly used APIs) anyways, let's have no illusions 
> > here.
> > So on its own this should not be an argument for reprioritizing the tainted
> > QList name.
> >
> > For years we have been teaching people to stay away from QList and treat it 
> > as
> > a legacy thing in the API, and that it may change in a future major release.
> > Any newly introduced public APIs (in the graphics-related areas at least) 
> > for
> > the past 5-6 years are using QVector.  It is odd to turn this over just like
> > that.
> 
> I have to agree with Laszlo here. The message has been that QList due to its
> duality etc is problematic and may become deprecated, so we've put in work on
> changing it to QVector in our code bases [...]

Was that work more than s/QList/QVector/ ?

>and used QVector in newly written
> code. It's a bit annoying if QList is now to become the name to be used. I'll
> accept whatever is decided, but think it's a little unfortunate if we'd have 
> to
> change all that code back to QList again.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 12:17:38PM +0200, Daniel Engelke wrote:
>> You'd need also adapt some variable and function names,
>> comments and documentation are silently broken.
> 
>I don't really see it, unless you name all variables like qListMyList.
> 
>As for comments it's not like the logical meaning changes. Besides,
>QList will have QVectors implementation anyway,
> 
>making comments or variable names that focus on it being a list
>illogical anyhow. (Besides QList was never a list to begin with)
> 
>Either way you'll have the same issues with API that is using QVector.
> 
>That would need to be changed to QList to be consistent.

In other parts of the discussion the point was made that such a renaming
is trivial, and it stands to reason that there's quite a bit more code
using QList in the wild than QVector.

So overall eco-system-effort to convert to QVector is higher than staying
with QList.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
> >
> > Almost all the time I second your positions, but not this time ;)
> >
> > QList is historically a cause of ambiguity, and Qt6 is the chance to get 
> > rid of that.
> 
> Indeed. QList causes confusion for the uninitiated that are aware of
> the differences between std::vector and std::list [...]

And "vector" confuses the uninitiated who expect it to be an element
of a vector space, to point somewhere, to carry diseases, or to be
something like a single pointer ("interrupt vector").

I really wonder who thought that "vector" was a good name for a 
container of not necessarily scalar elements that can change its
dimension.

Maybe someone who was involved with the initial choice of that name
can share some insight?

Andre'

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 10:02:04AM +0200, André Pönitz wrote:
> On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann 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?
> 
> This would avoid *quite* a bit code churn for user code.
> 
> +1

To refine: +1 for staying with QList as the container of choice, and
making QVector an alias for that, but I would not deprecate QVector.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 10:52:07AM +0200, Daniel Engelke wrote:
>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.

A proper replacing is not done by replacing one type by another.

You'd need also adapt some variable and function names,
comments and documentation are silently broken.

There's also serialization to be considered, changes to log messages,
external tools operating on stringified type names, etc.

This is a significant amount of work for non-trivial applications,
replacing the type name scratches only the surface.

 
>It's even less work if auto has been used.

Not really. 'auto' saves at best the first mechanical bit concerning
the type itself.  Variables, comments etc. will not be done that way 
and will require manual interaction. It's very likely that this
work can not be done in a lot of cases, and application will simply
decide to stick to Qt 5.

I am *really* happy that this proposal came up.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 10:06:07AM +0200, Albert Astals Cid via Development 
wrote:
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> > 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?
> 
> As taught in Computer Science/Engineering courses:
>  * QList is not a list
>  * QVector is a vector

"vector" in this context is a misnomer. It does not "carry" something
from one place to another, it does not have a direction, it's (generally)
not an element of a vector space etc.

"list" is the better word already. To lists can be appended etc, operations
that do not apply to elemens of vector spaces. "array" as some ordered
arrangment would be in principle ok, to, but see below.

> Compating to std:: types:
>  * QList is not comparable to a std::list
>  * QVector is comparable to a std::vector
> 
> Personally i think it makes sense to keep the QVector name.

The problem is that this triggers tons of practically needless
renamings in tons of user code without actual gain.

And as QVector is longer than QList, this in turn will trigger 
reformatting due to exceeded line lenght limits. Etc.

Effectively only pain, no gain.

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

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

[André Pönitz]

On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann 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?

This would avoid *quite* a bit code churn for user code.

+1

Andre'

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

Re: [Development] WebSocket Module [CVE-2018-21035]

[André Pönitz]

On Fri, Mar 13, 2020 at 07:00:46PM +0100, enston...@gmail.com wrote:
>Hi,
> 
>I forwarded my message to the security team on Monday
>([1]secur...@qt-project.org).
>I didn't get any answer except this:
> Your mail to 'Security' with the subject
> 
> Fwd: Re: [Development] WebSocket Module [CVE-2018-21035]
> 
> Is being held until the list moderator can review it for approval.
> 
> The reason it is being held:
> 
> Post by non-member to a members-only list
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

I can confirm that your message titled

   Fwd: Re: [Development] WebSocket Module [CVE-2018-21035]

has reached the list.

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

Re: [Development] Make Qt6 JNI API safer to use

[André Pönitz]

On Fri, Mar 06, 2020 at 11:59:32AM +, Simon Hausmann wrote:
>Hi,
> 
>I think it would be great to have a result type in the Qt API and use
>that, instead of C++ exceptions. In theory we could use std::variant,
>but I think the API inconvenient for the use-case of a result. That
>wouldn't prevent us from using it in the implementation though.
> 
>Simon

The problem with the currently available and sometimes sold as "proper"
solutions in C++ is that they require a lot of boilerplate to be written,
so people (rightfully...) ignore or even actively refuse to use them.

As stated earlier, Rust's Result and question mark operator is a *really*
nice solution to that. It's almost no overhead to write and read compared
to the "no error checking" solution.

Now, if there were only a way to change something in C++ ... 

Andre'

___
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

[André Pönitz]

On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 22:11, André Pönitz  wrote:
> >
> > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > > > I, for one, definitely want to see whether I am emitting a signal or 
> > > > not.
> > >
> > > Right; the claims that you can ignore signal emits when looking at a
> > > piece of code or expect that they
> > > don't affect the current scope are exactly backwards.
> >
> > Christian is right and your conclusion is wrong.
> 
> My conclusion is fine. Your unsubstantiated claims don't make it wrong.
> 
> > See the already mentioned example of debugging in code that follows
> > the convention of using signals only for inside-out communication:
> 
> Buy a debugger that can skip code that you didn't write.

The point was that in a such a situation I, as user, would not even
try to step in when the call is marked with 'emit'. This 'emit' in
a line *is* valuable markup, that saves me time.

That's unrelated to what the debugger would or could do if I did step in,
I just don't need to follow that path.

[And apart from that: There's no need to *buy* such debugger, e.g. gdb's 
'skip' actually works]

> > Emitting the signal may cause all kind of activity on the outside,
> > but in first approximation one can assume it doesn't change state in
> > the current object. So when drilling down in this situation
> > "ignoring" emit is indeed natural.
> 
> Seems quite unnatural to me, considering that signal emissions
> reasonably often tend to result in further calls being made to the object.

I stated as pre-condition that this is about "code that follows the convention
of using signals only for inside-out communication".

> > This sounds a bit like the committee shot down the proposal to
> > not use 'emit' without even bothering to think about reasons why
> > there are users of this "nonsense", let alone tried to ask them.
> 
> The committee shot down the proposal because
> 1) there are work-arounds to the problem, and we already use those
> work-arounds for similar
> issues with boost::signal
> 2) trying to avoid clashes with lowercase non-function-like macros is
> rather difficult
> 3) the scope of the problem is narrow
> 4) no existing code is broken

Is that documented, perhaps with a bit more detail, somewhere?

Andre'
___
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

[André Pönitz]

On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > I, for one, definitely want to see whether I am emitting a signal or not.
> 
> Right; the claims that you can ignore signal emits when looking at a
> piece of code or expect that they
> don't affect the current scope are exactly backwards.

Christian is right and your conclusion is wrong.

See the already mentioned example of debugging in code that follows
the convention of using signals only for inside-out communication:

Emitting the signal may cause all kind of activity on the outside,
but in first approximation one can assume it doesn't change state in
the current object. So when drilling down in this situation
"ignoring" emit is indeed natural.

That's a different situation than, say, just reading code, where an
emit is a flag that assumptions on the calling code might not be
valid anymore.

> [...]
> Thanks, Christian - that's the first ever plausible explanation for
> marking a signal emission.

This sounds a bit like the committee shot down the proposal to
not use 'emit' without even bothering to think about reasons why
there are users of this "nonsense", let alone tried to ask them.

Andre'

PS: @Marc: Thank you for trying.
___
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

[André Pönitz]

On Fri, Feb 21, 2020 at 02:41:35PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:
> 
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability.  Can you please explain what that vital
> > > information is?
> > How can you tell if it's a signal being emitted or just a function
> > call without the emit syntax? With the emit syntax before the signal
> > emission, it's immediately obvious that it's a signal. Not all
> > signals follow the *Changed() naming convention, nor should they, so
> > it becomes even less obvious in those cases.
> 
> Why do I need to know that it's a signal being emitted?

The question is not why you need to know that, but why apparently
quite a few people feel that using an empty macro adds value.

My best guess is that different people have different reasons here.

I myself usually prefer shorter code to longer doing the same, so my
natural reaction would be to drop 'emit'. However, I am actually ok with
having it, and that's mainly because it signals the use of a convention
in the code I usually operate on: Signals are use to communicate to an
unknown outside, so one might spend a thought e.g. on how much work this
might trigger, whether threads play a role etc.

> How is that "vital information"?

It's not *vital*, and it's irrelevant to the compiler. It's there for
the human reader.

   int i = 2;

is practically the same as
  
   int fjwqDwerewnrUHBLswd = 2

for an compiler, still some people might prefer one of them.

Andre'

___
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

[André Pönitz]

On Fri, Feb 21, 2020 at 08:40:23AM +, Alex Blasche wrote:
> > -Original Message- From: Kai Köhne
> 
> > Another alternative is to actually use C++ attributes for this:
> > 
> >   [[qt::emit]] somethingChanged();
> 
> I think a fallback to 
> 
> somethingChanged() 
> 
> without any annotation is not what we want. We'd miss vital
> information and reduce readability. Having said that I hate Q_EMIT
> even more. It just is ugly as hell. Therefore, I am very glad about
> Kai's suggestion. Personally, I don't think we need an extra namespace
> after all what are the odds to have a clash here  but that's
> details. 

One could have a convention to add an emit_* inline function, i.e.

class Foo : public QObject
{
Q_OBJECT

...

void emit_somethingChanged();

signals:
void somethingChanged()
};


That would require only one character to change on the user side,
instead of 

...
emit somethingChanged()
...

it would be

...
emit_somethingChanged()
...

Also, the use of the emit_-prefixed version would be optional as
before, just using 'somethingChanged()' is possible for those
who prefer that style.

> Last but not least, I don't see why we'd want to disable all other
> keywords when only one of them has a clash.  If the current macro
> enforces this then we should differentiate more. Let's not be too
> hasty when there is no need.

I fully agree.

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

Re: [Development] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[André Pönitz]

On Wed, Feb 19, 2020 at 06:26:56PM +0200, Konstantin Ritt wrote:
>  Should we ever try to work around issues caused by broken CPUs?

Yes.

Because "CPU is broken" one way or the other is rather the common
case. Declining to work as best as reasonably feasible in this
situation might as well end up with an empty potential user base.

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

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote:
> Even when doing development (as opposed to the pointy-haired work), I
> benefit from having tools that help me to maintain a work-in-progress
> limit, that allow me to see what state the work someone else is doing
> is in (because I might depend on it or just be curios about it), or
> allow me to signal to customers waiting for the fix that they might
> want to have a look at a proposed change, even if they don't have an
> account on Gerrit.

*Customers*, *without an Account*, to *look* at changes on Gerrit?

Sometimes I really regret having dropped out of university before
finishing basic maths.

> The Qt Project defines “code review” as an explicit step that
> contributions have to go through.

Correct.

> Given that it takes a substantial amount of time to get things
> through review,

A review, even a *proper review* by *your standards*, does not have
to "take substantial amounts of time".

It's technically completely feasible (and I guess one could dig out
practically examples) where an issue goes from "Someone mentioned
a problem on IRC" to "Fix is integrated" in less then five minutes.

The undeniable fact that it actually *does* take a substantial amount
of time *in a lot of cases* is not the result of having "not enough
JIRA states" but actually that of a lot of causes, none of which that
I am aware are of of the sort that would benefit from changes to the
JIRA process.

> I think it would make the JIRA-model of how work happens a bit more
> useful if it would reflect the way that work actually happens.

That's an interesting puzzle to solve when "the way that work actually
happens" is actually "outside JIRA, for a reason"

And that happens to be rather normal when e.g.
  - the issue is not coming via JIRA, like normal reviews,
  - the issue is urgent so JIRA would be too slow to use,
  - the issue is small, so the overhead would be prohibitive
compared to the cost of the actual work.
  - the issue is big, so wind direction would change to often
before this is done.


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

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote:
> On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
> >> Stepping through the interim steps is not a requirement, so it is not that
> >> much difference to go from Reported->In Progress to Reported->In Review,
> >> really.
> >>
> >> So the list you have to select from has one more entry to choose from, is
> >> that such a big deal?
> 
> > This is not the problem.
> >
> > More states lead to bikeshedding what would be The Right State for a
> > task.
> 
> I very much doubt the distinction between In Progress and In Review is
> going to involve much bike-shedding.

*shrug*

Assuming that JIRA states are meant to be disjoint and that the names
actually bear some meaning, "In Review" would mean "Not in Progress".

Which already would be an interesting message to the reviewer. Like,
"whatever you do here, that's not considered 'Progress'".

Of course, nobody intents to bui^H^H^Hsend such message, and that's
easily solvable, by either dropping the connection between state names
and meaning, or by dopping the disjointness of states.

What do you prefer? 


> > Already now there are tasks that get prioritized, and assigned, and
> > re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened
> > several times. Watchers that e.g. wait for a "Done" there get notified
> > each time on such unprogressing transitions, and skipping these sums
> > up to quite a bit of unproductive time already now.
> 
> True enough; this would introduce one more transition, so one more
> e-mail per bug.  None the less, it's a transition that does mean
> something useful to those watching - especially those waiting for a fix
> - we are a significant step closer to a fix,

Is is?

First, being on review might still not mean getting closer to 'Done'.
Patches get rejected or delayed for real or imagined reasons, nobody
might actually review, a successful review might not be convincing
enough for CI to let it pass etc, etc.

Second, water-level reports on how close something is to being done
is practically never the reason why I watch tasks, I watch them 
because I may need to act once it is resolved. And only then.

> and there's a patch they might even be interested in applying
> locally.  And, as Lorn pointed out, issues don't have to go through
> every stage; it'd just be there for the benefit of those who find it
> useful.

And to the distraction to those that don't. That's why the 'Verified'
state was removed not that long ago.
 
> Yes, we could do that with a tag, although I'm not sure how well Jira's
> "scrum board" view would integrate with that.  In any case, adding such
> tags would generate mail, just as state transitions would, and
> cluttering Jira with a plethora of person-specific and team-specific
> tags

We have "Reported_by_X", "Y_thinks_this_is_a_P1", "up", "Earmarked_by_Z",
and a lot more. And it's completely fine to have them. The rule to
handle them is easy: "If you are not fully convinced it is meant for you
it /is/ not meant for you".

> might not be the clearest way to communicate with folk; in
> particular it'd mean there's no uniform way for teams to communicate
> this, making it harder to write tools that can be shared between teams
> with similar work-flows.

Can't comment here, as I don't know what kind of tools this refers to.

> > Looks like we are getting to the actual problem here. It's not
> > about development after all.
> 
> No "getting to" about it - my original mail was quite explicit about
> the point of the exercise being clarity of communication with my
> scrum master (whose beard is plaited - I would not call his hair
> pointy).

I am positive an "Eddy-calls-this-Done" label will be explicit enough
to communicate the fact that Eddy calls this "Done" within this
particular relation.

> We've had tasks where the actual coding was done in one sprint but
> the review and integration (and waiting for merges up from one branch
> to another) have happened in other sprints. Distinguishing those
> parts of the work would make sprint organisation easier.

Ok, more seriously: I think you want to communicate "I did what I can
do here, for this period of time". This is a valid, and noteworthy
state, but at the same time orthogonal to the existing JIRA states. It
would also apply to an "Won't do", or "Invalid", or whatever else state
you chose after working on the issue. This calls for some markup that 
is orthogonal to existing JIRA states, and a label provides that.

> The co-ordination of development, and communication to stake-holders
> of what's going on, are important parts of our process. To dismiss
> them out of hand as "not about development" strikes me as painfully
> limiting.  Jira is a tool as much for our customers (reporting bugs
> and getting feed-back on whether and when we're going to do anything
> about them) and our managers as for us. 

[ . o O ( BINGO! ) ...  ]

> The addition of an "In Review" state would 

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
> On 18/2/20 6:03 AM, Thiago Macieira wrote:
> > I'm with Alexandru here: all ideas to have more states in JIRA start with a
> > good intentions, but eventually people stop using them and just transition
> > through all stages in one go when they've finished the work. For example,
> > people realise they've never changed from Reported to Confirmed before they
> > actually submitted the fix and autotest to Gerrit. I often do that and the
> > task goes from Reported to Confirmed to In Progress in 5 seconds. With your
> > proposal, it would go through yet another state in that period.
> 
> Stepping through the interim steps is not a requirement, so it is not that
> much difference to go from Reported->In Progress to Reported->In Review,
> really.
> 
> So the list you have to select from has one more entry to choose from, is
> that such a big deal?

This is not the problem.

More states lead to bikeshedding what would be The Right State for a task.

Already now there are tasks that get prioritized, and assigned, and
re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened
several times. Watchers that e.g. wait for a "Done" there get notified
each time on such unprogressing transitions, and skipping these sums
up to quite a bit of unproductive time already now.

> > What's the harm in leaving the task in In Progress state while it's being
> > reviewed?
> 
> There is no harm, but being able to better distinguish the main development
> phase of a large task from the review stage would benefit the 'pointy hairs'
> [...]

Looks like we are getting to the actual problem here. It's not about
development after all.


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

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[André Pönitz]

On Mon, Feb 17, 2020 at 09:13:17AM +, Edward Welbourne wrote:
> When my team is planning sprints, our scrum master wants to know what
> tasks I'll be working on, and what counts as "Done" for each of them.
> Having a separate state for "In Review", distinct from "In Progress",
> would let us distinguish the relatively plannable, and intense, part of
> the work from the part that (often happens in a later sprint, and)
> takes up a smaller proportion of my time but may take longer.
> [...]
> Does anyone have any objection to this, or suggestions for a better way
> to handle the relevant work-flow transition ?

This situation can be handled by you adding an 'Eddy-calls-this-done'
label. There's precendence for that, and this can even be applied to 
arbitrary other states, without affecting anyone else.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Thu, Feb 13, 2020 at 10:01:02AM +, Maurice Kalinowski wrote:
> > From: Development  On Behalf Of
> > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan
> > Sandfeld Jensen  Cc: development@qt-project.org
> > Subject: Re: [Development] The future of smart pointers in Qt API
> > 
> > On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen
> > wrote:
> > > > Allowing _both_ I have not seen actively endorsed by anyone,
> > > > this only makes a messy incosnsistent API.
> > >
> > > I would allow both. It is the only way to remain source
> > > compatible, while making it possible for those that wish to, to
> > > follow the so-called Core guidelines for C++.
> > 
> > I'll rather have a uniform API than to have latest bells and
> > whistles in some random places. 
> 
> I'd like to challenge the categorization of "latest bells and
> whistles" on something which is in the standard for 9 years now.

"Being in the standard" does not really have the kind of positive
connotation for me that some people expect.

std::auto_ptr was in the standard for 12 years in 2010. In fact it was
the *only* "smart" pointer there. And I am rather happy Qt didn't jump
on *that* boat, even though it was highly en vogue with university
dropouts at the time.

> Also considering that Qt 6 is going to have at least the same lifetime
> as Qt 5, 8 years

Is it going to?

I'll owe you few beers and a Döner at Ecki's once Qt 6.7 is out.
But I am rather afraid that the "Let's have a major release each
year and give a damn about compatibility" faction will win before
that.

> this means that you propose to not adapt an item from
> the standard for 17 years?

No, I said that I prefer a uniform API. I propose not to sacrifice
that to partial modernization. 

Amder'

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Thu, Feb 13, 2020 at 09:42:23AM +, Karsten Heimrich wrote:
> -Original Message-
> >From: André Pönitz  Sent: Mittwoch, 12. Februar
> >2020 19:38 Uhr To: Vitaly Fanaskov  Cc:
> >Karsten Heimrich ; development@qt-project.org
> >Subject: Re: [Development] The future of smart pointers in Qt API
> >
> >On Wed, Feb 12, 2020 at 11:13:17AM +, Vitaly Fanaskov wrote:
> >> >> We should also move Qt smart pointers to Qt5Compat module. The
> >> >> destiny of QPointer is not well defined so far.
> >> >
> >> > This was not part of the research and should probably discussed
> >> > separately.
> >>
> >> I agree. But if we decide using standard smart pointers, why should
> >> we keep Qt smart pointers as a part of Qt6?
> >
> >https://www.qt.io/blog/2019/08/07/technical-vision-qt-6
> >
> > "Compatibility with older versions is extremely important and is a
> > major requirement when we develop Qt 6. There are billions of lines
> > of code written using our framework and any incompatible change we
> > do will thus have a cost for our users. Furthermore, the more work
> > the change to Qt 6 requires from our users the slower the adoption
> > will be, which leads to more cost on our side to maintain the last
> > version of Qt 5."
> >
> >Already now the jump from, say, 5.12 to Qt dev is way bigger than the
> >whole Qt 4 -> Qt 5 upgrade was, adding more to that does definitely
> >not help with Qt 6 adoption.
> 
> We probably could move it to Qt5Compat first, so that lifetime ends
> with Qt6.

I wouldn't even object to that.

Except, maybe, that in the age of limited resources spending there might
me more beneficial ways to spend them ;-}

> But as mentioned already, we did not even discuss anything
> there like...

Indeed.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

> On Mon, Feb 03, 2020 at 11:53:57PM +, Scott Bloom wrote:
> > From: Development [mailto:development-boun...@qt-project.org] On
> > Behalf Of André Pönitz
> > [...]
> > An actual "need" for a unique pointer is typically a sign that
> > things are created, passed around until they end up somwhere, for
> > a long time so that people get unsure about ownership or have
> > developed an irrational fear of naked pointers.  Fixed by not
> > having the 'factory' create the object and pass the object
> > around, but by passing the factory around (by 'reference') and
> > letting the receiver create the object.  Additional advantage:
> > creation can take input both from the factory setup (say, lambda
> > capture) and the receiver side, saving potentially a lot of
> > state. And it's of course fine to use unique pointers if that's
> > not the reason. E.g. to delete dynamic stuff in case of early
> > returns. I.e.  a kind of, surprise, "scoped" pointer.
> > 
> > That people coming from Java exhibit a high affinity to shared
> > pointers is not exactly news in this millenium. A bit more
> > amusing is that some proponents of "modern" C++ demand using
> > unique pointers, when actually more direct, less boiler-plate
> > requiring tools (lambdas...) were standardized at the same time.
> 
> To be fair, while I 100% agree  with the reasons given, you are not
> listing one of the (only???) reasons, that a smart pointer shared
> or unique, are truly > necessary.
>  
> When you are working with the possibility that the lifetime of
> the pointer, might not be exception safe.   

Sorry for not being explicit, I meant this case to be covered by

 "And it's of course fine to use unique pointer [...] in case
  of early returns."

So, sure, that's a valid use case. But effectively this also uses
only the "scoped" feature of unique_ptr to ensure proper destruction,
not the feature to pass ownership around.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen wrote:
> > Allowing _both_ I have not seen actively endorsed by anyone,
> > this only makes a messy incosnsistent API.
> 
> I would allow both. It is the only way to remain source
> compatible, while making it possible for those that wish to, to
> follow the so-called Core guidelines for C++.

I'll rather have a uniform API than to have latest bells and
whistles in some random places. It's like putting chromium
coating on the wheel covers of your trusty oxcart. Sure, one
can do that, but it's not exactly solving a problem.

As Volker already noticed, it's not the "odd" QObject ownership
model that cause problems in practice, if at all it's the few cases
where it is unclear whether it applies.

Having said that, there might be some middle ground. E.g. for
large subsystem like QtWebEngine that differ for valid technical
reasons from the core offering anyway, having mildly different
API style might be ok.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Wed, Feb 12, 2020 at 11:13:17AM +, Vitaly Fanaskov wrote:
> >> We should also move Qt smart pointers to Qt5Compat module. The
> >> destiny of QPointer is not well defined so far.
> >
> > This was not part of the research and should probably discussed
> > separately.
>
> I agree. But if we decide using standard smart pointers, why
> should we keep Qt smart pointers as a part of Qt6?

https://www.qt.io/blog/2019/08/07/technical-vision-qt-6

 "Compatibility with older versions is extremely important and is a
  major requirement when we develop Qt 6. There are billions of lines
  of code written using our framework and any incompatible change we
  do will thus have a cost for our users. Furthermore, the more work
  the change to Qt 6 requires from our users the slower the adoption
  will be, which leads to more cost on our side to maintain the last
  version of Qt 5."

Already now the jump from, say, 5.12 to Qt dev is way bigger than
the whole Qt 4 -> Qt 5 upgrade was, adding more to that does
definitely not help with Qt 6 adoption.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote:
> I want to summarize intermediate results of the discussion and return it 
> back to the track.
> 
> 
> Subject: using smart pointers in the API.
> Good idea. Better to use than not because of automatic lifetime 
> management,

*shrug*

You seem to repeat your initial statements.

QObject parents _do_ manage lifetime to start with.

> Subject: raw pointers for passing mandatory parameters vs. using 
> references.
> Allow both approaches, recommend using references (and/or smart 
> pointers) when acceptable.

> Not too many arguments collected here, just 
> try to make Qt API more modern.

Again only your statement.

The issue itself has been discussed over and over again.

Allowing _both_ I have not seen actively endorsed by anyone,
this only makes a messy incosnsistent API.

> There are a few irrelevant discussions. Start a new thread if you want 
> to continue discussing them, please.
> 
> Irrelevant subject: smart pointers vs. parent-child lifetime management 
> model.

Sure. Because it would void the 'lifetime management' line of reasoning.

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

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[André Pönitz]

On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
> 
> > -Original Message- From: Development
> >  On Behalf Of Thiago Macieira
> > 
> > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> > >
> > >  wrote:
> > > > The correct signal for an error situation is errorOccurred, like in
> > > > QLocalSocket and QProcess.
> > >
> > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" 
> > > getter
> > > to keep using "error()" signal as opposed to many other Qt modules
> > > "errorOccurred()" signals.
> > 
> > Which is the opposite of QProcess and violates the naming convention. 
> > Signals
> > are named after verbs in the past tense and properties & property getters 
> > are
> > simple nouns. So "error" is the getter, "errorOccurred" is the signal.
> 
> Either option solves the ambiguity. What's more important to our users - a
> consistent naming convention
> or an early warning/compile error when adopting Qt 6?

Consistent naming will be beneficial for a much longer time than any
short term incentive to adopt Qt 6.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 04, 2020 at 10:10:08PM +0200, Ville Voutilainen wrote:
> On Tue, 4 Feb 2020 at 21:31, André Pönitz  wrote:
> > Seriously, *double deletion*? In real, proper Qt-style code?
> 
> Yes, seriously, because allocated objects are stored in RAII handles

A "Qt style" "RAII handle" is a QObject parent at creation time.
There is no double deletion in this context, *only* when you start
to sprinkle in other ownership models, i.e. deviate from "Qt style".

> so as to avoid leaking them on break/return/throw (or heaven forbid, goto).
> Then you can pass the result of a .release()  into Qt's various object chains.
> Or if you think shared_ptr is what's needed, then you can't.
> 
> > The only problem is with people passing out when seeing different numbers 
> > of 'new'
> > and 'delete'. And it's only a *real* problem when do not they take "Relax, 
> > it's ok"
> > as an answer, and start to actively interfere. And that's when double 
> > deletion
> > comes into play.
> 
> Indeed. All libraries and frameworks are perfectly fine for everybody,
> as long as they know what they're doing.

Well, no. Some also suck in case one knows what one is doing. OTOH, at 
least roughly knowing what one's doing is probably necessary for any
kind of code.

> > > > If you understand Qt (and don’t assume that by understanding some basic 
> > > > C++
> > > > concepts you can use any framework), then you see that widgets are 
> > > > added to a
> > > > layout that is used, and are therefore managed objects.
> > > Managed by what? Also, it seems downright detrimental if understanding 
> > > basic C++
> > > concepts is useless with Qt.
> >
> > I don't think that's received as much of an insult as you meant it to be
> > by parts of your audience. Not requiring the verbosity of "basic C++" in
> > user code is surely a benefit of Qt for me, and if people are appalled by
> > not getting that with Qt, well, not my problem.
> 
> Yeah, well, "basic C++" isn't verbose.
> QVector and QList are slightly above basic C++, since they're templates.

Ok? Then what were you referring to when saying "it seems downright detrimental
if understanding basic C++ concepts is useless with Qt."? I thought it was
std::unique_ptr, but that's a template, i.e. no "basic C++" in your definition.

> Yet we don't suggest that users should manually iterate through their elements
> to clean those elements up when no longer needed, but for some reason when
> exactly that technique is suggested to be used in object trees, some of us 
> just
> balk, and start throwing tantrums.

Now you completely lost me. What iteration is suggested to be used to clean
elements in a _QObject_ tree? 

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 04, 2020 at 07:42:22AM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 23:55, André Pönitz ha scritto:
> > On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> > > Il 03/02/20 20:38, André Pönitz ha scritto:
> > > > Directly affected are for instance functions operating on full 
> > > > containers in
> > > > 
> > > > https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
> > > 
> > > Just to set the record straight, the main reason why qAlgorithm(begin, 
> > > end)
> > > as well as qAlgorithm(container) have been deprecated altogether, rather
> > > than simply have their implementation replaced with std::algorithm() 
> > > calls,
> > > was the fact it would've been source incompatible.
> > 
> > I think I've never needed qAlgorithm(begin, end), but used quite a bit of
> > qAlgorithm(container).
> > 
> > > For instance: qSort internally uses calls to qSwap and qLess.
> > 
> > So what?  It worked.  Now it doesn't anymore.
> 
> So changing qAlgorithm(container) implementation to call
> std::algorithm(container.begin(), container.end()) would have been a source
> incompatible change.

Which might have been in the acceptable range, i.e. on par with the other
incompatible changes within a major release. I don't think there are overly
many sensible pieces of code that implement std::swap() observably differently
than qSwap() for the same type.

> (Side note: throughout the entire Qt 5 lifetime qAlgorithm(container) still
> 100% works -- it's deprecated, not removed.)

['deprecated' means 'removed' in my universe... Which also might explain 
allergic
reactions towards 'deprecation without pre-existing alternatives' etc.]

> In other words, in the Qt4->5 time, the choice was between one of these:
> 
> A) Keep QtAlgorithms as-is between Qt 4 and Qt 5, leave them fully
> supported.
> 
> B) Keep QtAlgorithms API as fully supported, but change the implementation
> under the hood to use std::algorithms.
> 
> C) Deprecate QtAlgorithms API, leave them as-is for Qt 4 compatibility. Tell
> the users that they have Qt 5.x entire lifetime to migrate away.
> 
> D) Something else: e.g. add the convenience wrappers back in some other
> namespace (after the port to std::algorithms, so with different semantics)
> etc.; no one has proposed or done so far.

B. Or A.

> B) is a "hidden" source incompatible change (code would still compile but
> break at runtime).

*shrug*

It would not *generally* "break at runtime", it would "break at runtime _for 
some
very weird setups_". This happens practically, intentionally or not, with each 
Qt
minor, even patch releases, and is completely acceptable for a major releases.

> So we went for C).

> Was all of this done because "I don't need qAlgorithms' convenience so no
> one needs it"? Absolutely not!
> 
> Should we had gone for B) instead? I say no, QUIP-6 says no,

QUIPs are unreleated: QUIPs didn't exist at the time, and 4->5 was a major
release, which QUIP-6 is not about.

> are feel to say yes. (Side note: this *will* fuel arguments against using Qt
> facilities, namely, "Qt regularly breaks them".)

(I was quite happy with the level of breakage between 4 and 5, and I'd be
more than happy if 5 to 6 would have been about the same (non-)pain.)

> No: it would break existing code without the user changing their code at
> all.
> 
> Qt 4: qSort(foo) (uses qLess)
> Qt 5: qSort(foo) (uses std::less)

Formally "yes", but as already stated ...
 
> Users don't change their code; code compiles just as before; behavior and
> thus semantics of the call change, possibly breaking at runtime.

... that happens *all the time* even with minor releases, some intended,
some simply new bugs. Accepting this, but insisting that people might 
sensibly have different qLess and std::less implementations *and* rely
on that is an interesting stance to take.`

> > There is not upstream 'sort(Container)' that this has possibly diverged 
> > from.
> 
> Oh wai, in C++20 there is :-P

Indeed. Diverging from something that will only be invented in eight years
time is incredibly naughty ;-P

> More seriously: is this arguing for having qSort(container) still around
> with the Qt 4 implementation?

s/4/5/ ? Yes. And until it's in released std::, there too.

> > That 'porting away' basically consists of creating a layer of convenience
> > ex-Qt functions on top of Qt. Same implementation initially, deviating
> > now on a per-project base.
> 
> I, for one, would welcome centralization of these efforts. Anyone else?

I guess that ship has sailed.  "Centralizing" would currently mean to bring
it back to Qt. By now people have either forked qalgorithm or they do not
care about the issue. In both scenarios, a revived Qt implementation would
not be very attractive.

Andre'

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 04, 2020 at 06:49:50AM +0100, Giuseppe D'Angelo wrote:
> Il 04/02/20 00:49, André Pönitz ha scritto:
> > > I've asked "what's wrong with the C++ smart pointers" a dozen times and
> > > never received a satisfactory answer.
> > Did you? I am - to some degree truly - afraid I didn't notice.
> [snip]
> 
> I apologize, I should've asked more clearly: "what's wrong with the C++
> smart pointers that demands re-implementations of them in Qt"?

"Nothing."

> Your answer is on point regarding the usage of smart pointers in general (no
> matter who's providing the implementation); it's a starting point for a
> discussion relative to Daniel's proposal, I guess?

My take is that Daniel's proposal is sane - and actually the only one I've seen
in that ballpark, with a huge margin - *if* one accepts that there's an actual
problem to solve.

Andre'


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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 04, 2020 at 07:17:13PM +0200, Ville Voutilainen wrote:
> On Tue, 4 Feb 2020 at 18:48, Volker Hilsheimer  
> wrote:
> > >>> But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to
> > >>> behave imho saner in that edge case and actually delete the widgets that
> > >>> were added but never parented. (And I should really implement that to 
> > >>> show
> > >>> how it would work.)
> > >>
> > >>
> > >> That seems like a terrible idea. One of the layout’s jobs is to set up 
> > >> the
> > >> parent/child hierarchy so that you as a developer don’t have to.
> > >
> > > I don't see how that idea changes that.
> >
> >
> > Iif the layout deletes widgets that were created without parent, instead of
> > adding it to the correct parent, then that’s a change. You have to create
> > widgets with parents, and add them to the layout (which might then add it to
> > another parent, which at the very least introduces unnecessary overhead of
> > ChildAdded/Removed event processing).
> 
> Right; the layout shouldn't insta-kill parentless children without trying to
> reparent them first.
> 
> > >> Do we really want to make it harder for people to write UIs just because
> > >> the resulting code doesn’t satisfy a C++ idiom?
> > > It's not a question of satisfying idioms for the sake of satisfying 
> > > idioms,
> > > it's a question of avoiding bugs that we know based on decades of 
> > > experience
> > > to be difficult to avoid with raw pointers.
> > That’s my point: I do not believe that the decades of experience we have 
> > with
> > QObject’s parent/child model support the claim that it is inferior to using
> > smart-pointers. It’s not something people constantly struggle with.
> 
> I have a completely polar opposite experience, it's the main source of memory
> leaks and double deletes in Qt application code. 

> [...]

> Your experience suggests that this is not something people constantly
> struggle with, my experience suggests that it's the #1 top-priority bug in Qt,
> hands down, no competition.

*shrug*

I am with Volker here.

Seriously, *double deletion*? In real, proper Qt-style code?

The only problem is with people passing out when seeing different numbers of 
'new'
and 'delete'. And it's only a *real* problem when do not they take "Relax, it's 
ok"
as an answer, and start to actively interfere. And that's when double deletion
comes into play.

> > If you understand Qt (and don’t assume that by understanding some basic C++
> > concepts you can use any framework), then you see that widgets are added to 
> > a
> > layout that is used, and are therefore managed objects.
> 
> Managed by what? Also, it seems downright detrimental if understanding basic 
> C++
> concepts is useless with Qt.

I don't think that's received as much of an insult as you meant it to be
by parts of your audience. Not requiring the verbosity of "basic C++" in
user code is surely a benefit of Qt for me, and if people are appalled by
not getting that with Qt, well, not my problem.
   
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Tue, Feb 04, 2020 at 03:52:34PM +, Vitaly Fanaskov wrote:
> 
> I also don't think that this is something we should worry about when 
> discussing adding smart pointers.

I think I've still not understood what "adding smart pointers" means when you 
use
the term. Right now my impression is that you want to use them in new API only.
While that would not stomp on my toes directly, it sounds a bit like creating a
mess when it comes to API uniformity. And that is (was?) one of the few actual
advantages of Qt.

While I am unlikely to leave the "there's no problem to solve" camp anytime
soon here, for me Daniel's approach has the distinctive charm of maintaining
API uniformity *and* trying really hard to be minimally invasive. That's two
*huge* advantages in my book. 

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Mon, Feb 03, 2020 at 10:25:40PM +0100, Giuseppe D'Angelo via Development 
wrote:
> I've asked "what's wrong with the C++ smart pointers" a dozen times and
> never received a satisfactory answer.

Did you? I am - to some degree truly - afraid I didn't notice.

Answer would have been easy: They solve problems that should not occur
on a large scale in a sensible setup.

To start with: I was not much in favour of std::auto_ptr when it was
standardized. People started hyping it, best thing since sliced bread.
Sprinkle your code base with it or you are doomed.

Well. Fast forward twenty years. Case settled.

boost::shared_ptr, ..., std::unique_ptr: Same story, just not finished:

An actual "need" for a shared pointer is typically a sign that ownership
is not clear at all: "Here's a thing, it doesn't really belong anywhere,
so let's copy it around, last one switches off the light". Fixed by making
ownership clear. Also solves the problem of needing to copy some stuff
because it's not copied, just referenced. And sure, there *are* situation
where shared pointers are useful, and it's of course fine to use them
if there's such reason.

An actual "need" for a unique pointer is typically a sign that things
are created, passed around until they end up somwhere, for a long time
so that people get unsure about ownership or have developed an
irrational fear of naked pointers.  Fixed by not having the 'factory'
create the object and pass the object around, but by passing the factory
around (by 'reference') and letting the receiver create the object.
Additional advantage: creation can take input both from the factory
setup (say, lambda capture) and the receiver side, saving potentially a lot
of state. And it's of course fine to use unique pointers if that's not
the reason. E.g. to delete dynamic stuff in case of early returns. I.e.
a kind of, surprise, "scoped" pointer.

That people coming from Java exhibit a high affinity to shared pointers
is not exactly news in this millenium. A bit more amusing is that some
proponents of "modern" C++ demand using unique pointers, when actually
more direct, less boiler-plate requiring tools (lambdas...) were 
standardized at the same time.

Andre'

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 20:38, André Pönitz ha scritto:
> > Directly affected are for instance functions operating on full containers in
> > 
> >https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
> 
> Just to set the record straight, the main reason why qAlgorithm(begin, end)
> as well as qAlgorithm(container) have been deprecated altogether, rather
> than simply have their implementation replaced with std::algorithm() calls,
> was the fact it would've been source incompatible.

I think I've never needed qAlgorithm(begin, end), but used quite a bit of
qAlgorithm(container).

> For instance: qSort internally uses calls to qSwap and qLess.

So what?  It worked.  Now it doesn't anymore.

> An user overloading or specializing them would have had their algorithms
> broken by the mere replacement towards std::sort (which instead uses an
> ADL-found swap() + std::swap, and std::less).

And most user code breaks by a mere replacement of 0 by 1.

What kind of argument is that?

"Break existing code, since other code might potentially break
when uses replace some function by something else"?

> So, for the record, if you want to point the finger against the
> deprecation/removal of these algorithms, please point it against the
> decision of making the Qt 4 algorithms _diverge_ from upstream, then
> noticing that Qt cannot or shouldn't catch up with the significant
> improvements happening upstream, then realizing that a direct port isn't
> doable because of the diversion. I have already said that having different
> behavior from from upstream is a terrible idea in this very thread, and the
> algorithms example is an excellent one.

There is not upstream 'sort(Container)' that this has possibly diverged from.

> Now, we may disagree on the extent of the incompatibility -- in the end, who
> would override qSwap, specialize qLess, and so on? Can't we just bite the
> bullet and break those rare usages rather than forcing everyone to port
> away?

That 'porting away' basically consists of creating a layer of convenience
ex-Qt functions on top of Qt. Same implementation initially, deviating
now on a per-project base.
 
> As the one who did the porting work, then I get the privilege to say: no, we
> can't; this is a gratuitous and very hidden source-incompatible change, and
> the promise of Qt 4->5 was to keep them at a minimum. (And, I don't like
> them.) So, keep using the deprecated qAlgorithms if you want, throughout the
> entire Qt 5.x lifetime, with the same Qt 4.x semantics; they still work just
> like before. _Port_ to the std:: equivalents at your earliest convenience
> (no, you cannot do a mere s/qAlgorithm/std::algorithm/ in the general case;
> it's a full port).

You don't need what I need, so you kill it, and I am forced to re-create
it on my own time. Overall, this approach de-values Qt.

And now we are back to the fallacy thing "I don't need it, noone else does",
which was the actual point. No matter what the actual topic is, I consider
it a fundamental necessity of any sensible discussion that both sides are
allowed to use the same kind of arguments. So if "I don't need it, noone else
does" is considered a valid argument for one side, the other side has to
be allowed to use it as well. Alternatively, neither side should use it
(which actually would be my prefered setup, but that seems out of question)

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Sun, Feb 02, 2020 at 11:32:02PM +0100, Giuseppe D'Angelo wrote:
> On 02/02/2020 22:45, André Pönitz wrote:
> > > This is a logical fallacy; "I don't need it, noone else does".
> > But this is the argument the de-Qt-ers use when it comes to Qt convenience
> > they don't need.
> 
> Which Qt convenience in particular?

Directly affected are for instance functions operating on full containers in

  https://doc.qt.io/qt-5/qtalgorithms-obsolete.html 

Indirectly, standard containers have no direct equivalent of .contains(),
so advocating using std over Qt has a similar effect here.

> I seem to be advocating against duplication "for the sake of it", not when
> there's strong arguments (e.g.  convenience) for it.

This is appreciated.

Andre'


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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Sun, Feb 02, 2020 at 07:55:09PM +0100, Giuseppe D'Angelo via Development 
wrote:
> On 02/02/2020 17:38, Alberto Mardegan wrote:
> > On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote:
> > > Il 01/02/20 12:37, Alberto Mardegan ha scritto:
> > > > Do we need to have such a counterpart? In my work experience, when I'm
> > > > not allowed to use Qt and am restricted to the STL, all the times I had
> > > > to use std::unique_ptr was to get the same behaviour as a 
> > > > QScopedPointer.
> > > 
> > > So you never had to pass one to a function, return one from a function,
> > > create a vector of them? Color me *very* suspicious.
> > 
> > Believe it or not :-) I find std::shared_ptr easier to use when passing
> > pointers to and from functions. And I never needed to put them into an
> > array.
> 
> This is a logical fallacy; "I don't need it, noone else does".

But this is the argument the de-Qt-ers use when it comes to Qt convenience
they don't need.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Fri, Jan 31, 2020 at 03:27:29PM +, Vitaly Fanaskov wrote:
> Not abandoning, I think, but re-implementing properly. Raw pointers 
> cause some certain problems here and changing them to something more 
> smart would be nice. But it doesn't mean that we should get rid of 
> parent-child model entirely. The point is that we can make it more 
> explicit just by using smart pointers.

Can you maybe show some proof-of-concept pseudo-code how the typical
current user code looks like that you intent to improve, and how
it will look like afterwards?

> To make it clear, there is no decision made. We're just discussing.

Right.

And thank you for doing that.

I was already becoming afraid that we might be running out of
disputable items lately.

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

Re: [Development] The future of smart pointers in Qt API

[André Pönitz]

On Fri, Jan 31, 2020 at 10:07:52AM +, Vitaly Fanaskov wrote:
> Another thing to discuss is whether we should use raw pointers in the 
> API at all or not. There are a few options again:
> 
> 1) Yes
> 
> 2) No. Use “modern” approaches instead (pass mandatory dependencies by 
> either reference or const reference when using smart pointers makes no 
> sense, use something optional-like or tuples to return extra data from 
> functions, and so on)
> 
> 3) Mix 1 and 2.
> 
> There are pros and cons for all options. Share your opinion once again, 
> please.

1)

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

Re: [Development] QHash for Qt 6

[André Pönitz]

On Fri, Dec 20, 2019 at 02:47:06PM +0100, Giuseppe D'Angelo via Development 
wrote:
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies 
> > according to the library supplier.
> > And this, potentially much more eg. than std::vector.
> > And X-Platorm Qt users would expect performance consistency I guess.
> 
> Devil's advocate, again: this also applies, say, to std algorithms. Or
> operator new. Should we stop using them and roll our own?

Erm, yes, at least where it provides a benefit. 

E.g. the ones conveniently operating on whole containers instead of
iterator pair.

Qt had them, someone threw them out, and I doubt that Qt Creator
is the only "user" project that had to re-create them locally.

>  [...]
> And my point was that Qt shouldn't _really_ bother reinventing something
> already easily available elsewhere.

Correct. But these cases are very rare.

Specifically, "something that's already easily available elsewhere"
may not provide
- the same level of convenience (see algos + full containers)
- the best theoretical performance (std::unordered_map)
- consistent (with the rest of Qt) naming (std::*)

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

Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut

[André Pönitz]

On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development 
wrote:
> Il 04/12/19 12:56, Volker Hilsheimer ha scritto:
> > IIRC, then I added that in the early Qt 2 days, anticipating that with
> > Qt/Embedded we might see our widgets landing on touch screens “any moment
> > now”. The idea was to have a global setting that ensured that widgets and
> > other interactables (such as menu items, list items, checkbox markers etc) 
> > are
> > at least x,y pixels large.
> > 
> > Well, the world has moved on, and the value has never been consistely used 
> > in
> > styles or widgets anyway.
> 
> Ignoring for a moment the rest of the discussion: does such a value _make 
> sense_
> in the first place?
> 
> Qt-provided styles always tried to follow the OS native style, even in the
> sizing of the controls. Arbitrarily resizing controls has always been 
> possible,
> but generally doing that either violates the guidelines of the native style
> (e.g. making a push button 100px high) or breaks the widget altogether 
> (making a
> push button 5px high).
> 
> In this light, what's the idea of a global minimum size useful for? A native
> style should rightfully completely ignore it. A non-native style could have 
> it a
> as a tunable parameter, but then, actually, it could have _any_ amount of
> tunable parameters (e.g. have a minimum size for buttons, a minimum size for
> labels, etc.).
> 
> Does anyone have more insights?

I have no insight, but I can imagine scenarios where e.g. visually impaired
would like to increase minimum size of UI elements also for desktop applications
wihout necessarily applying some global scaling to all elements.
Not matching native style is certainly a minor issue in this context.

That's pure speculation though, and at least in the Qt Creator context
I am not aware that such a request has ever been made, and I doubt that
the current two(!) uses of QApplication::globalStrut() would be sufficient
to meet such need accidentaly.

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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote:
> On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote:
> > Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
> > _is_ there in general for some of the proposed porting strategies, but not
> > for the case of using a 32bit count(): We can assume that an existing
> > application using QContainers is fine with 32bit, otherwise it wouldn't
> > work right now. So continuing using 32bit interfaces does not introduce
> > bugs. Immediate truncation on the user code sode is also riskless, just
> > ugly.
> 
> I'm not talking about porting code.

> I'm talking about new code written in 2024. If we choose now to have 32-bit 
> count(), that will still be the case in 2024, possibly beyond, which means as 
> a result code written at that time needs to be careful not to use the 32-bit 
> methods.
>
> That's what I am referring to when I say a problem down the road.

And I am concerned about porting code, because that's what keeps me busy
nowadays.

2024 is four years ahead. That's quite some time in Qt's life. 2011's burning
platforms looked different in 2015, and 2015's paradigms (OpenG?L, JS?)
do not apply in 2019 anymore.

It's ok to keep in mind that there will be 2024 at some time, but it's nothing
worth sacrificing current usability for.

Unless the rest of Qt interface is adapted to use qsizetype, including places
where it's obvious overkill like, say, QComboBox::maxVisibleItems, user code
will from 6.0 always have to decide on what integer type to use. 

This is trivial for each instance, but since _a lot_ of code is affected,
this will sum up to a significant effort when writing and reading Qt code.

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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sun, Nov 24, 2019 at 12:31:32PM +0100, Konrad Rosenbaum wrote:
> I'd rather have the compiler tell me that I need to change my code than hide
> it from me. Warnings are there for a good reason.

["Some"...]

> The only way to do this with this proposal is to make count() deprecated from
> the start! So, why bother with duplicated API in the first place?

Because a lot consumers (and this includes most of Qt code itself) settled
on an int based interface for things they are interested to count or index.

So it's either getting _also_ an int interface directly, or direct 
narrowing on the user side. 

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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sun, Nov 24, 2019 at 11:30:29AM +0100, Giuseppe D'Angelo via Development 
wrote:
> Il 24/11/19 10:44, Uwe Rathmann ha scritto:
> > I fully agree with André - having 2 different APIs makes a lot of sense
> > to me. But instead of using count/size I would use something like
> > countU/sizeU. like you have QPen::widthF and QPen::width.
> 
> I disagree: it makes the API confusing. The F there stands for floating
> point, as opposed to integer (and historically you don't even know _which_
> floating point you get). What would the U stand for exactly?

Well, _some_ placeholder for a suffix. '32' might be explicit, but awkward.

My idea with using 'count' was that we currently have three functions
doing the same (size, count, length), and giving one more of them
a real meaning would be ok. But as I said before, you have a point
that the situation is there as well for indexOf() etc.

A suffix on all interesting function would allow more uniformity than
just having the one special case for getting the size.

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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sat, Nov 23, 2019 at 11:26:02PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 13:55:52 CET André Pönitz wrote:
> > Also, replacing size() by count() would be easy to do in e.g. Creator
> > (effectively a single global renaming of size() to count() and discarding
> > the changes to Qt itself).
> > 
> > Wrapping int() around requires more manual work.
> 
> I understand, but I think this is the type of change that will eventually 
> become a problem down the road. We think it can help with porting, but it may 
> later introduce subtle bugs by truncating sizes.

The cases that a user application _needs_ >2GB elements in a _Q_Container,
are extremely rare, for two reasons:

First: Such cases rare are in general. I think the only case in Qt Creator code
where 64bit indices into anything were needed, is the binary editor, and
there's effectively file positions.

Second: The only benefit of QContainer is ::fromRawData, in all other cases
the costs of implicit sharing are rather a problem then a benefit. So the
typical solution would be to use std::vector etc in that case anyway.

Practically, those occurances are singular arrangements within an application
that then also get special attendence by the developers. This is less of
a problem than mass-replacements.


Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
_is_ there in general for some of the proposed porting strategies, but not for
the case of using a 32bit count(): We can assume that an existing application
using QContainers is fine with 32bit, otherwise it wouldn't work right now.
So continuing using 32bit interfaces does not introduce bugs. Immediate
truncation on the user code sode is also riskless, just ugly.

Andre'


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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sat, Nov 23, 2019 at 12:48:12PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote:
> > So let's make this a real proposal: Should we have
> > 
> >qsizetype QContainer::size()
> >int QContainer::count() const
> 
> So you propose changing code like
> 
>   int n = vec.size();
> to
>   int n = vec.count();
> while we could just change it to:
>   int n = int(vec.size());
> 
> If we're going to make changes anyway, why not make the right change?

int n = vec.count();

is less ugly than

int n = int(vec.size());

It's less to type, less to read, one level of parantheses less.

Also, replacing size() by count() would be easy to do in e.g. Creator
(effectively a single global renaming of size() to count() and discarding the
changes to Qt itself).

Wrapping int() around requires more manual work.

Peppe has a point that the problem exists for other functions like indexOf(),
but e.g. in Creator code that's used far less frequently than size() (about an
order of magnitude less) so having to use int(indexOf(...)) is less of a pain
than the .size() case.

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

Re: [Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Fri, Nov 22, 2019 at 08:01:30PM +0100, Giuseppe D'Angelo via Development 
wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
> 
> Sorry, what do you mean by "conflicts"? I mean that there's countless code
> today that uses "int s = foo.size()" (or indexOf, or similar); such code
> will now trigger narrowing warnings.
> 
> > There's always QVector::size_type, QByteArray::size_type and
> > QString::size_type if you really need to be explicit and that's fine today.
> 
> The chance that non-generic code uses this is practically 0 and we know it.
> Yes, "auto" will work, but still has anyone actually did the exercise on a
> big codebase (Creator, KDE, ...) and checked how many warnings are we
> talking about?

My current assumption is that it will be an unrealistic effort to actually
fix the cause for the warning, so not enabling narrowing warnings flags is
the most likely cause of action at least for Qt Creator.


Now that you spell out the problem, it occurs to me that we might
even have the cake and eat it in this case:

Most (all?) containers have currently several functions to return their
size, e.g. QVector::{size,count,length}. We could one of them continue
to return an int.

So adapting a codebase would be just replacing the now qsizetype-returning
variant by an int-returning variant, which is rather easy and safe, compared
to fiddling with actual type changes.

So let's make this a real proposal: Should we have

   qsizetype QContainer::size()
   int QContainer::count() const

?

Andre'

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

Re: [Development] QTCS2019 Notes from the Qt 6 Changes / Migration session

[André Pönitz]

On Fri, Nov 22, 2019 at 03:01:25PM +0100, Uwe Rathmann wrote:
> On 11/22/19 11:01 AM, Friedemann Kleint wrote:
> 
> > https://wiki.qt.io/Qt_Contributors_Summit_2019_Qt_6_Changes_/_Migration
> 
> Maybe one aspect I would like to add: there is a lot of software, that has
> to be compilable with Qt 5 and Qt 6. Especially when your product is library
> you can't decide which version of Qt is going to be used in the application.
> 
> It would be good if this does not end up in a total mess of ifdefs.

Since Qt Creator intents to stay compilable "for a while" with probably
5.14 (extrapolating from the usual "latest LTS minus one minor", or in
this special situation possibly 5.15) and 6.0 I guess there will be some
noise if this starts requiring _a lot_ of #ifdefs.

Right now the situation is that Qt dev (a.k.a. Qt 6 in spe) "works"
with a Creator codebase that's not far from being 5.11 compatible.

This has required quite some work already to port away from "near death"
constructs (there are few helper functions toSet/toList, and there's a
handful of unavoidable #ifdefs due to the collapsing of QList and QVector, 
some changes around the Qt namespace, QDataStream, etc) but overall I am
fairly optmistic that the envisioned scenario that porting a codebase
piece-by-piece to 5.15 that's then 6.0 compatible is somewhat realistic.
 
> My experience from the past is, that it takes years until the majority of
> the applications has upgraded to the next major Qt version - and probably
> only few applications will seriously try out Qt x.0 versions.

That matches my experience from the past.

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

Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate

[André Pönitz]

On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
> On Thu, Nov 21, 2019 at 04:38:28PM +, Joerg Bornemann wrote:
> > There is the ongoing effort to replace the old outdated parser with a
> > clang, similar to what's been done in qdoc. The corresponding JIRA
> > issue is QTBUG-71835.
> > 
> a more radical and much simpler approach would be switching to gettext
> (actually, or at least in fundamental functionality) - that doesn't need a
> whole c++ parser to do a sensible job.
> 
> oh, wait, that topic ain't new ... ;)

I wasn't aware of a related discussion, and I actually think this could
be a way forward.

The most prominent difference is the (usually) per-class automatic context
which I always found too clever to be sensible, and that's effectively
also the only reason to need a C++ parser.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Mon, Nov 18, 2019 at 07:09:30PM +0100, Thiago Macieira wrote:
> On Monday, 18 November 2019 17:05:29 CET Lars Knoll wrote:
> > > On 18 Nov 2019, at 17:00, Kevin Kofler  wrote:
> > > 
> > > Thiago Macieira wrote:
> > > 
> > >> The codecs we want to remove are just big tables of mapping old, legacy
> > >> codecs to UTF-16. We can easily remove those.
> > >> 
> > >> After that, removal of QTextCodec itself is not a big gain.
> > > 
> > > 
> > > So let me ask once again: Is ICU not already a hard requirement for Qt on
> > > 
> > > *nix systems? So why can we not just rely on ICU's tables?
> > 
> > 
> > No, it’s not a hard requirement. And especially for low end embedded
> > systems, we also want to keep it that way.
> 
> But we should not keep the our codecs (aside from the UTF ones) because of 
> that.

Why not?

I see no reason why we can't keep the QTextCodec _interface_ in Qt Core,
together with some interface to register new codecs, provide UTF-* directly,
and let the "fancy" ones live on in a seperate module, plugging them in
at runtime.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Fri, Nov 15, 2019 at 05:47:04PM -0800, Thiago Macieira wrote:
> On Friday, 15 November 2019 16:23:24 PST André Pönitz wrote:
> > > The questions are:
> > > 1) do we want to prevent another library from accidentally unsetting it?
> > > 2) do we want child processes to use the same?
> > > 
> > > Note the answers for both questions must be the same, for the solution is
> > > the same. So either both yeses or both nos.
> > 
> > This "answers for both questions must be the same" requirement is arbitrary.
> > 
> > The fact that one known solution results in same answers to both is in
> > no way proof that no other solutions exist.
> 
> I don't see how to prevent another library doing setlocale(LC_ALL, "") from 
> not overriding Qt's default other than to make setlocale(LC_ALL, "") do what 
> we want. Since what it does is read the environment, the only solution is to 
> change the environment.

You haven't even explained why this prevention would be needed, what exact
bad would happen if you don't do that, and you cannot prevent the other library
from setting an explicit locale anyway.

With modifying the environment, you just catch the "" case, one out of many,
and I'll continue to argue that it's not Qt's business to try even that.

> > > Qt 6 will not have support for non-UTF-8 codecs, outside of Windows. You
> > > can either deal with binary data or with UTF-8 text, there's no middle
> > > ground.
> > Now that's an interesting twist.
> > 
> > The latest memo I did (not...) get was that codecs are to be moved into a
> > separate module. Which is actually ok, as it allows user code using codecs
> > to live on with minimal changes, and makes QtCore slimmer, kind of "no-loss
> > + win".
> 
> Sure. But that's no different than using ICU or writing your own code to 
> convert from binary to text. QString will not support it on its own.

> 
> > "Qt 6 will not have support for non-UTF-8 codecs, outside of Windows" is
> > definitely news to me. I've not seen this being discussed, neither here nor
> > within the part of the company that I usually talk to.
> 
> You just said yourself, above.

I did not say that.

> If QTextCodec moves to another library, we have  no codecs in QtCore.

Not having codecs in QtCore does not mean QtCore cannot use codecs.

One could have a setup where Qt Core just has the bare minimum, with stubs
for other codecs that are used when that QtCodecs lib is linked.

Actually that's what I had expected something like that to be the targeted
solution once I heard that text codecs move out of QtCore.

> > So when and where was this decision made, by whom, and why?
> > 
> > Did that person bother to check e.g. whether Qt Creator uses non-UTF-8
> > codecs in some cases and did that person come to the conclusion that any
> > such use is bad and deserves to die?
> 
> Probably not. Why does Qt Creator need other codecs?

My guess would be to handle code bases that are not (a subset) of UTF-8.
 
> > > you're arguing that here are broken applications that won't handle
> > > C.UTF-8 correctly, without giving as single example.
> > 
> > ... is of course not true:
> > 
> > 1. I did not claim there were "broken" applications that won't handle
> >C.UTF-8 "correctly", I claimed that there are applications that react
> >differently to C.UTF-8.
> 
> Different behaviour is *exactly* what we want. We want this:

Who is 'we'?

> $ LC_ALL=C.UTF-8 ls á
> ls: cannot access 'á': No such file or directory
> 
> not this:
> 
> $ LC_ALL=C ls á
> ls: cannot access ''$'\303\241': No such file or directory

If you do not touch the environment, the user gets what he asked for.

He will most likely want not to see ''$'\303\241, but if he explicitly asks
for it in the environment he sets up, it's not Qt's job to override this.

> I thought the argument would be that despite being what we wanted,

Who is 'we'?

> it would break certain scenarios. But I haven't seen any examples of breakage.
> 
> >  gcc produces different output under C and C.UTF-8:
> > 
> >  echo x | LC_CTYPE=C gcc -xc -
> >   :1:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
> > at end of input
> > 
> >  echo x | LC_CTYPE=C.UTF-8 gcc -xc -
> >   :1:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
> > at end of input
> > 
> >  As an additional twist, this different behaviour does not require fancy
> > input, input is plain ASCII in both cases.
> > 
> >  Output parsers expecting "'" e.g. to produce a set reco

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Thu, Nov 14, 2019 at 11:20:08PM -0800, Thiago Macieira wrote:
> On Thursday, 14 November 2019 13:27:23 PST André Pönitz wrote:
> > *Within* a Qt application consisting of Qt library, other libraries,
> > and actual user code it's mildly presumptous for one library to impose
> > random unnecessay restrictions on user code and other libraries.
>
> That boat sailed 20 years ago when we started calling setlocale() from
> QCoreapplication. We set the locale, period.

1. I was refering to putenv, not setlocale.

2. Even for setlocale, the point is not _whether_ it is called, but _how_.
   setlocale(..., 0) e.g. only queries, does not change anything.

   QCoreapplication currently calls setlocale(LC_ALL, "").

   This is fine. This accepts the user's choice of environment as authorative.

   It also works well in practice. I can run something like

   LC_PAPER=de_LU LC_TIME=en_US.UTF-8 LC_COLLATE=C qtcreator

   and it will not only "just work" for the application itself, but
   also be properly passed on to e.g. a terminal started from within.
   
   So no boat has sailed, let alone 20 years ago.

   The boat _will_ sail once there when you put a non-empty string there,
   overriding user's choice.


> The questions are:
> 1) do we want to prevent another library from accidentally unsetting it?
> 2) do we want child processes to use the same?
>
> Note the answers for both questions must be the same, for the solution is the
> same. So either both yeses or both nos.

This "answers for both questions must be the same" requirement is arbitrary.

The fact that one known solution results in same answers to both is in 
no way proof that no other solutions exist.

But it looks like there's no need to discuss _that_, as my answers are
"no" and "no". 

> > Making assumptions on the controlability of content of a input stream is
> > questionable. The proposed method of changing the environment for child
> > processes is no guarantee on what the child actually produces, and the
> > Qt application still has to be prepared to handle non-Utf-8 or otherwise
> > "broken" input.
>
> Qt 6 will not have support for non-UTF-8 codecs, outside of Windows. You can
> either deal with binary data or with UTF-8 text, there's no middle ground.

Now that's an interesting twist.

The latest memo I did (not...) get was that codecs are to be moved into a 
separate
module. Which is actually ok, as it allows user code using codecs to live
on with minimal changes, and makes QtCore slimmer, kind of "no-loss + win".

"Qt 6 will not have support for non-UTF-8 codecs, outside of Windows" is
definitely news to me. I've not seen this being discussed, neither here nor
within the part of the company that I usually talk to.

So when and where was this decision made, by whom, and why?

Did that person bother to check e.g. whether Qt Creator uses non-UTF-8
codecs in some cases and did that person come to the conclusion that any
such use is bad and deserves to die?

> > This discussion so far claimed the existance of a range of problems
> > without giving an actual example. Then it goes on to propose a shotgut
> > approach (LC_ALL, "ALL") to handle ... what? "Obscure locale settings"
> > like categories that are a bit more fine grained than LC_ALL?  Bear with
> > me when I do not have the impression that Qt will be the right context
> > to accept such "obligations".
>
> The same argument can be made for your statements:

Sure, one could do that.

But that would _my_ argument not make go away, nor compensate for the current 
lack
of answers to the questions I asked.

And ...

> you're arguing that here are broken applications that won't handle
> C.UTF-8 correctly, without giving as single example.

... is of course not true:

1. I did not claim there were "broken" applications that won't handle
   C.UTF-8 "correctly", I claimed that there are applications that react
   differently to C.UTF-8. 

2. I _did_ give two examples. I can repeat here:

   2.1) 
https://lists.qt-project.org/pipermail/development/2019-November/037815.html

 gcc produces different output under C and C.UTF-8:

 echo x | LC_CTYPE=C gcc -xc -
  :1:1: error: expected '=', ',', ';', 'asm' or '__attribute__' at 
end of input

 echo x | LC_CTYPE=C.UTF-8 gcc -xc -
  :1:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ at 
end of input

 As an additional twist, this different behaviour does not require fancy
 input, input is plain ASCII in both cases.

 Output parsers expecting "'" e.g. to produce a set recommendations how to 
quick-fix
 such problems in an IDE will break.


   2.2) 
https://lists.qt-project.org/pipermail/development/2019-November/037810.html

  

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Thu, Nov 14, 2019 at 12:10:24PM +0100, Mathias Hasselmann wrote:
> 
> Am 03.11.2019 um 06:35 schrieb André Pönitz:
> > I am all for not propagating Qt's UTF-8 choice to child processes at all.
> 
> "Write once, compile/run everywhere" mandates Qt enforcing a maximum level
> of homogenity within our Qt applications.

*Within* a Qt application consisting of Qt library, other libraries,
and actual user code it's mildly presumptous for one library to impose
random unnecessay restrictions on user code and other libraries.

I am running firefox in parallel, currently with 174 shared object
loaded. I don't think it will improve overall firefox user experience
if the authors of said 174 library decide to impose their views on what
is good code and what is bad code on the other 173 participants in
the game. 

And even if people agreed on using UTF-8 inside an application - and I
wouldn't disagree - this does not warrant changing the environment.


> That extends to the input and output streams of the child processes
> our applications deal with.

Making assumptions on the controlability of content of a input stream is
questionable. The proposed method of changing the environment for child
processes is no guarantee on what the child actually produces, and the
Qt application still has to be prepared to handle non-Utf-8 or otherwise
"broken" input.

So this is effectively snake oil.

> Not propagating Qt's UTF-8 choices seeems like a violation of that
> principle of maximum homogenity.

Which you just invented.

Apart from that we just broke "homogenity", as now child processes
started from a Qt application behave differently then when started
otherwise (see the gcc quotes example with different results on pure
7-bit input)

> Hiding the complexity of obscure locale settings truely
> belongs to the hearth of Qt's obligations in my opinion.

This discussion so far claimed the existance of a range of problems
without giving an actual example. Then it goes on to propose a shotgut
approach (LC_ALL, "ALL") to handle ... what? "Obscure locale settings"
like categories that are a bit more fine grained than LC_ALL?  Bear with
me when I do not have the impression that Qt will be the right context
to accept such "obligations".

Andre'


PS: Just seen: https://wiki.debian.org/Locale:

Warning!

Using LC_ALL is strongly discouraged as it overrides everything.
Please use it only when testing and never set it in a startup file. 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Two-digit dates: what century should we use ?

[André Pönitz]

On Wed, Nov 06, 2019 at 12:38:48PM +, Edward Welbourne wrote:
> want.  Sample options:
> * keep 1900-1999, discourage use of ShortFormat;
> * rolling window based on currentDate(), as I described earlier;
> * we update startYear's default with each major release of Qt.

First option seems to be the one least surprising.

> For the last, for example, we could make startYear=1940 in Qt6; by the
> time we get to a major release in the late '20s, we'd be ready to move
> that to startYear=1950.  I guess we can be confident of at least one
> major release per not much more than a decade, which suffices to ensure
> that dates throughout the supported life-time of that release do
> round-trip, while reaching well into the past.  That's assuming
> range=100: if we use a buffer zone, range=90 for example, we'd probably
> want Qt6 using startYear=1950 already (so '40s are invalid and '30s are
> the 2030s).
> 
> Any objections to this revised plan ?
> Anyone want to make the case for keeping 1900--1999 as default ?

You mentioned other systems that used that approach.

I would expect interacting with such systems is easiest, if the rules
are the same.

A shifting window would probably be unique to Qt, i.e. cause friction
in all cases.

> Or for my earlier dynamic floating-window proposal ?
> Or any other suggestions for the default ?
> If not, the update at major release - a.k.a. static floating-window -
> looks the sanest to me.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Mon, Nov 04, 2019 at 11:38:07AM -0800, Thiago Macieira wrote:
> On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> > A parser accepting the output of one might or might not be able to
> > handle the second.
> 
> A driver would set LC_ALL in the environment when it calls gcc.

Can we please take a step back and repeat for the slow thinker^H^H me
what the benefit of forcing a UTF-8 locale on unknown child processes
would be?

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Mon, Nov 04, 2019 at 10:55:03AM -0800, Thiago Macieira wrote:
> On Monday, 4 November 2019 10:29:16 PST André Pönitz wrote:
> > All but one do not let the UI user change the environment, i.e. the
> > environment is passed through the Qt UI process (so far). The one is
> > Qt Creator, but even there it is not possible to configure all child
> > processes, and would not be tolerable to tell users "When you create a
> > new run configuration remember to undo spurious environment changes done
> > by Qt".
> 
> It's highly unlikely you're running Qt Creator in a non-UTF-8 environment in 
> the first place.

*shrug*

   > locale | grep -q '=C$' && echo oops
   oops


> KDE has not supported such locales for 15 years.

I haven't tried to run KDE in earnest for about the same time. 

> If we were in 2004-2006 when this was recent and other Unix environments like 
> Solaris and HP-UXi where non-UTF-8 could be still in use I could understand 
> the skepticism.
> 
> > 
> > There _are_ setups that _are_ set in stone, that are not connected
> > to anything and that don't give anything on updates, or do not even
> > have the possibility to be "fixed" or changed in any way.
> 
> Why are you inserting Qt 6 into them, then?

Because data generation and data visualization are different tasks, that
can, and perhaps should, be done in different processes, and while data
visualization occasionally might need to react to user demand, data generation
might not.

> > Looks contrieved? [Check your hard disk before you answer.]
> 
> I'll do a full search on Clear Linux to see if there's any software that 
> checks the return value of setlocale().
> 
> > Potentially harmful behaviour should always be opt-in, not opt-out
> > (and never be non-configurable).
> 
> I don't disagree on the statement. I just disagree on whether it's harmful. 
> *Not* calling qputenv could be harmful too.

As mentioned in the second example, even "clean ASCII" 7 bit input produces
different results under "C.UTF-8" and "C":

 echo x | LC_ALL=C.UTF-8 gcc -xc -
 echo x | LC_ALL=C  gcc -xc -

Given that most parsers in the world are ad-hoc, chances are high that some
are based on looking for certain quotes, but not for others.

And even if someone knows that the immediate child processes are ok with
C.UTF-8, their children, grand children, ... might not.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Mon, Nov 04, 2019 at 09:40:00AM +, Edward Welbourne wrote:
> Indeed, what program would have problems in C.UTF-8 yet have a
> non-Unicode locale in which it works nicely ?

Other example:

echo x |  LC_ALL="C.UTF-8" gcc -xc -

and

echo x |  LC_ALL="C" gcc -xc -

produce different output.

A parser accepting the output of one might or might not be able to
handle the second.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Mon, Nov 04, 2019 at 09:40:00AM +, Edward Welbourne wrote:
> On Friday, 1 November 2019 12:29:19 PDT André Pönitz wrote:
> >> a) and b) are fine with me, "c) yes" sounds like a potential problem.
> >>
> >> Most of the child process I usually call are not Qt based,
> 
> That shouldn't matter.  Qt<6-based things and non-Qt things are all the
> same from the point of view of the contemplated change.
> 
> To what extent are these child programs started via a UI that lets the
> user set environment variables (as I assume all IDEs do for most of the
> commands they run) ?

All but one do not let the UI user change the environment, i.e. the
environment is passed through the Qt UI process (so far). The one is
Qt Creator, but even there it is not possible to configure all child
processes, and would not be tolerable to tell users "When you create a
new run configuration remember to undo spurious environment changes done
by Qt".

> Obviously, if some antique needs a special locale, that's no problem
> if it's started via a UI that lets one configure its environment,
> overriding what Qt might have set.

Even _if_ that UI would let the user configure the environment,
that's not an excuse.

> >> rather some random unrelated tools, in some cases even quite old
> >> random unrelated tools.
> 
> I read antiquity as tending to assume C locale, so unharmed by C.UTF-8,
> although some may be assuming an ISO Latin or similar legacy codec.
> All the same, so antique as to not grok Unicode at all is pretty old !
> You probably need to update it for security fixes, by now.

"Security reason, because it is old" must be Godwin's Law in 
"Always Online" times.


There _are_ setups that _are_ set in stone, that are not connected
to anything and that don't give anything on updates, or do not even
have the possibility to be "fixed" or changed in any way.

If Qt development does not want to care for these cases _even as
child processes_ that's fine in principle (even with me), but then
it would help to clearly communicate that fact to prevent accidents
in the selection of toolkits.


> Thiago Macieira (1 November 2019 22:49)
> > TBH, all the more reason for propagating the choice. Please remember
> > that on any modern Linux or macOS or FreeBSD, they are already running
> > with a UTF-8 locale. The most common scenario of our setting something
> > is when LC_ALL=C was set in the environment, which will cause us to
> > reset it to C.UTF-8.
> 
> Indeed, what program would have problems in C.UTF-8 yet have a
> non-Unicode locale in which it works nicely ?
> An example would help us to reason about this ...

The following works on all my setups (and, btw, with LC_ALL="C"
which I do _not_ use) and crashes with LC_ALL="C.UTF-8":

#include 
#include 
#include 

int main()
{   
if (strcmp((setlocale(LC_COLLATE, "")), "C") != 0)
abort();
}

Looks contrieved? [Check your hard disk before you answer.]

Shotgun-changing environment for child processes is _not_ harmless.

> >>>> ones, would not make the same choices. If we do not propagate, we
> >>>> could end up with a child process (often helpers) that make
> >>>> different choices as to what command-line arguments or pipes or
> >>>> contents in files mean.
> 
> >> If we propagate we'll expose the child processes to locales they
> >> might not expect, in circumstances where the user of the system
> >> possibly intentionally chose a non-UTF8-locale to make exactly those
> >> child processes happy.
> 
> > True, but that was done at the expense of running Qt in a largely
> > unsupported and untested scenario. Setting the locale to C means we
> > can't access any file with an 8bit file name; setting to Latin1 would
> > allow that, but produce mojibake in GUI.
> 
> >> Effectively, going for "c) yes" deprives the user of a certain level
> >> of freedom that is needed, "c) no" is less intrusive.
> >>
> >> "c) no" as default and a simple one-liner opt-in for applications
> >> that want to engage in "strict parenting" might be an option, too.
> 
> > How about making the resetting opt-out, instead of opt-in?
> > QT_NO_OVERRIDE_LC_CTYPE?
> 
> Possibly its value could be:
> * all, 1, yes, true, .* - it applies to all child processes [*]; or
> * a list of regexes for program names to which it applies, when started
>   as child processes.

The syntax doesn't really matter, but the direction "opt-out" is wrong.

Potentially harmful behaviour should always be opt-in, not opt-out
(and never be non-configurable).

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Sat, Nov 02, 2019 at 06:16:36PM +0100, Kevin Kofler wrote:
> A true runtime option actually belongs in an environment variable, not in a 
> method that has to be called by the compiled code. (In fact, that's what I 
> would have expected your proposed QT_NO_OVERRIDE_LC_CTYPE to be, but 
> apparently you were thinking of a preprocessor define.)
> 
> Whether to propagate the locale to child processes is really a decision that 
> can and should be left to the user at runtime rather than compiling it 
> either into the application (as in André's proposal) or even into Qt itself 
> (as in your proposal).

I am all for not propagating Qt's UTF-8 choice to child processes at all.

Having that as opt-in on some level was an attempt to appease people who
think that's a good idea.

A configure option for Qt itself does not help as it keeps the question open
what the default setup will be. And given the circumstances that would
be "propagation".

Compiled opt-in per-application at least shifts the blame from Qt to the
application vendor, compiled opt-in per-process environment leaves the blame
still with the application vendor, but actually provides the possibility
to do the right thing when it is known that the child actually _needs_ it.

On the other hand, in those circumstances, this can already be done now
by normal fiddling with the child process environment.

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Fri, Nov 01, 2019 at 02:49:36PM -0700, Thiago Macieira wrote:
> On Friday, 1 November 2019 12:29:19 PDT André Pönitz wrote:
> > > > My personal preference is:
> > > > a) C.UTF-8
> > > > b) override it to force UTF-8 on the same locale
> > > > c) yes
> > > 
> > > I agree with all three choices.
> > 
> > a) and b) are fine with me, "c) yes" sounds like a potential problem.
> > 
> > Most of the child process I usually call are not Qt based, rather some
> > random unrelated tools, in some cases even quite old random unrelated
> > tools.
> 
> TBH, all the more reason for propagating the choice. Please remember that on 
> any modern Linux or macOS or FreeBSD, they are already running with a UTF-8 
> locale.

With that argument we wouldn't even need to change the locale for the
actual Qt application.

I think we are currently discussing the rare case where the Qt application
is started with a non-UTF-8 locale, and the main question is whether this
was some kind of accident that the Qt application should correct for their
child processes or whether this was intentional.

As you said, any modern Linux or macOS or FreeBSD default to UTF-8, so
chances are high that any deviation from that is actually intentionally.

> The most common scenario of our setting something is when LC_ALL=C was 
> set in the environment, which will cause us to reset it to C.UTF-8.

I understand that, and even though I am not aware of an actual problem for
my personal uses I am a bit reluctant to expose unsuspecting processes
to a variable-lengths encoding they may not be aware of. At least there's
a potential for buffer overruns here.

Also, going from "C" to "C.UTF-8" might foil code checking for the 
string "C" explicitly in a child process.

> > > > ones, would not make the same choices. If we do not propagate, we could
> > > > end up with a child process (often helpers) that make different choices
> > > > as to what command-line arguments or pipes or contents in files mean.
> > 
> > If we propagate we'll expose the child processes to locales they might not
> > expect, in circumstances where the user of the system possibly intentionally
> > chose a non-UTF8-locale to make exactly those child processes happy.
> 
> True, but that was done at the expense of running Qt in a largely unsupported 
> and untested scenario. Setting the locale to C means we can't access any file 
> with an 8bit file name; setting to Latin1 would allow that, but produce 
> mojibake in GUI.

Setting to "C" also "works" in practice when blobs are just read and written
unmodified.

> > Effectively, going for "c) yes" deprives the user of a certain level of
> > freedom that is needed, "c) no" is less intrusive.
> > 
> > "c) no" as default and a simple one-liner opt-in for applications that
> > want to engage in "strict parenting" might be an option, too.
> 
> How about making the resetting opt-out, instead of opt-in? 
> QT_NO_OVERRIDE_LC_CTYPE?

I was more thinking of a runtime option. Like 

  QCoreApplication::setPropagateOurChoices(true)

Or do I miss something why this has to be a compile time choice?

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

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

[André Pönitz]

On Fri, Nov 01, 2019 at 09:21:48AM +, Lars Knoll wrote:
> > There are three questions to be decided:
> > a) What should Qt 6 assume the locale to be, if no locale is set?
> > b) In case a non-UTF-8 locale is set, what should we do?
> > c) Should we propagate our decision to child processes?
> > 
> > My personal preference is:
> > a) C.UTF-8
> > b) override it to force UTF-8 on the same locale
> > c) yes
> 
> I agree with all three choices.

a) and b) are fine with me, "c) yes" sounds like a potential problem.

Most of the child process I usually call are not Qt based, rather some random
unrelated tools, in some cases even quite old random unrelated tools.

> > ones, would not make the same choices. If we do not propagate, we could end 
> > up 
> > with a child process (often helpers) that make different choices as to what 
> > command-line arguments or pipes or contents in files mean.

If we propagate we'll expose the child processes to locales they might not
expect, in circumstances where the user of the system possibly intentionally
chose a non-UTF8-locale to make exactly those child processes happy.

Effectively, going for "c) yes" deprives the user of a certain level of
freedom that is needed, "c) no" is less intrusive.

"c) no" as default and a simple one-liner opt-in for applications that
want to engage in "strict parenting" might be an option, too.

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

Re: [Development] The age-old T* foo vs. T *foo

[André Pönitz]

On Fri, Oct 18, 2019 at 12:24:12AM +0300, Ville Voutilainen wrote:
> On Fri, 18 Oct 2019 at 00:16, André Pönitz  wrote:
> >
> > On Thu, Oct 17, 2019 at 09:04:36PM +0300, Ville Voutilainen wrote:
> > > Since we are about to do a major version upgrade, should be stop being
> > > a special snowflake in the C++ world and start attaching pointer-stars
> > > and reference-ampersands to the type instead of to the variable?
> >
> > No.
> 
> Why?

It's a huge effort for discussion and conversion effort
for practically no gain.

And it opens the gate for more such fruitless discussions
   snake_style vs camelStyle
   east const vs west const
   getter/setter naming convention
   Q prefix
   namespaces
   indentation
   ...

I also think that there are more than enough open issues
in JIRA that, when solved, would have more practical impact
than shifting around white space in the code base.

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

Re: [Development] The age-old T* foo vs. T *foo

[André Pönitz]

On Thu, Oct 17, 2019 at 09:04:36PM +0300, Ville Voutilainen wrote:
> Since we are about to do a major version upgrade, should be stop being
> a special snowflake in the C++ world and start attaching pointer-stars
> and reference-ampersands to the type instead of to the variable?

No.

And it's not "just our style".

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

Re: [Development] Nominating Vitaly Fanaskov as Approver

[André Pönitz]

On Sun, Oct 06, 2019 at 06:19:37PM +, Timur Pocheptsov wrote:
> AndrЁ: I'm probably missing something, but ... yeah, it's about Vitaly,
> who's this Kirill you're talking about?

It's the person whose dashboard was linked to support Vitaly's nomination.

Andre'

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

Re: [Development] Nominating Vitaly Fanaskov as Approver

[André Pönitz]

On Wed, Oct 02, 2019 at 11:22:33AM +, Shawn Rutledge wrote:
> Hi all,
> 
> I would like to nominate Vitaly Fanaskov as approver for the Qt Project.
> Vitaly joined the Qt Quick and Widgets team about a year ago.  He has been 
> fixing bugs in widgets and Qt Quick, making it easier to use and customize 
> color palettes in Qt Quick, working on the speech module, working on 
> KUserFeedback (which we will use for telemetry in Creator), teaching us how 
> to use some modern C++ features that some of us didn’t know about before, etc.
> I trust that he will follow Qt guidelines and will use the approver rights 
> responsibly.
> 
> Here is his list of changes:
> https://codereview.qt-project.org/q/owner: 
>  
> vitaly.fanaskov%2540qt.io
> 
> and reviews:
> https://codereview.qt-project.org/q/reviewer:vitaly.fanaskov%2540qt.io

Looks like Kirill did indeed a good job.

Andre'

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

Re: [Development] INTEGRITY

[André Pönitz]

On Thu, Sep 19, 2019 at 11:37:14PM +0200, Giuseppe D'Angelo wrote:
> Il 19/09/19 21:53, Kyle Edwards ha scritto:
> > As a generalization of this, perhaps Qt could introduce something like
> > a Q_CONSTEXPR macro, which does what we expect on platforms that
> > support it, and compiles to nothing on Integrity.
> 
> It's already in Qt, and used:
> 
> > https://code.woboq.org/qt5/qtbase/src/corelib/tools/qarraydata.h.html#_M/Q_ARRAY_LITERAL_IMPL
> 
> Revocation of Q_CONSTEXPR is not so simple, as it's a source incompatible
> change.

It's a fairly safe assumption that given a choice of a SiC change and completely
dropping a platform most users of that platform would prefer the SiC change.

> (It's one of the reasons why stdlib implementors are not allowed to
> plaster constexpr unless the Standard says so.) It might work in the case in
> question, for which I've already asked for help twice in a few months
> (again: I don't have any access to INTEGRITY). It will just not work for
> other cases where you do want a constant expression, bringing us back to
> square one.

The context was dropping support for INTEGRITY, not "other cases".

Andre'


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

Re: [Development] INTEGRITY

[André Pönitz]

On Thu, Sep 19, 2019 at 09:14:36PM +0200, Giuseppe D'Angelo via Development 
wrote:
> On 19/09/2019 21:01, André Pönitz wrote:
> > "Is it worth" is exactly the question that should drive this kind of 
> > discussion.
> > And it can be answered_after_  evaluating, or even guessing the "value" of 
> > the
> > available options.
> 
> It's not so easy: I, for once, don't have access to INTEGRITY to do any a
> priori evaluation of the technical feasibility of a solution.

Me neither. 
 
> I can test and evaluate the other platforms, though. My webgradient patch
> will improve the situation on *ALL* platforms because it removes (quoting):
> 
> > * the binary json representation from QtGui's resources (~4KB
> > compressed, ~50KB uncompressed)
> > * the overhead of reading from the JSON for each used web
> > gradient;
> > * the startup costs of registering the webgradients in the
> > resources;
> > * all the overhead of mutex locking when building such
> > gradients;
> > * all the runtime memory allocations to load, parse and cache
> > the web gradients (including the memory + CPU spike on first
> > load due to the uncompression of the JSON data, as well as a
> > couple of deep copies).
> 
> But it cannot go in in Qt 5 because INTEGRITY does not implement C++11's
> constexpr.

Having constexpr or not on certain functions could depend on the actual
compiler in some cases, providing the performance benefits for the 
compilers supporting it, and still keeping platforms with unsuitable
compilers alive.

> Is it worth it? YES.

That's a valid opinion.

However, right now this looks to me like that you could have your performance
benefits for webgradients without Qt as a whole dropping support for INTEGRITY.

Andre'

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

Re: [Development] INTEGRITY

[André Pönitz]

On Thu, Sep 19, 2019 at 11:18:26AM +0200, Mutz, Marc via Development wrote:
> But it helps nothing with all the places where we use QWaitCondition in Qt
> implementation and would like to replace it with std::condition_variable +
> std::mutex, because, as I explained in an earlier mail, QWaitCondition is a
> condition_variabe_any and thus has inherently and unavoidably more overhead
> than condition_variable + mutex. There is no justification to add #ifdefs
> for all the places that QWaitCondition is used unconditionally now, so
> either we don't get the order-of-magnitude improvement on our main platform,
> Windows, or we need to introduce a private QtPrivate::condition_variable as
> an inline wrapper around condition_variable + mutex or, for Integrity,
> QWaitCondition + QMutex, which we need to replace once more with
> std::condition_variable + mutex if Integrity is fixed. Is it worth it,

"Is it worth" is exactly the question that should drive this kind of discussion.
And it can be answered _after_ evaluating, or even guessing the "value" of the
available options.

But you entered the discussion _again_ with _your_ answer, stating _again_
that "we" "would like to replace it".

Can you please try to use a less overbearing approach? Like, presenting the
options, stating your personal opinion on their respective values, give people 
the
impression they have a chance to give their views, and when the dust has 
settled,
give the impression of making an educated guess on the result and "decide" 
_then_?

"Thank you."

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

Re: [Development] HEADS-UP: QStringLiteral

[André Pönitz]

On Thu, Aug 22, 2019 at 08:48:30PM +0200, André Pönitz wrote:
> On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> > I'm sorry if I sound blunt, but this is just nonsense. What you call
> > optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> > readable. As is just using "".
> 
> I am not sorry to sound blunt here, but calling
> 
>  a["b"] = "c"
> 
> "equally readable" to
> 
>  a[QStringLiteral("b")] = QStringLiteral("c")
> 
> requires a kind of proficiency that's rare to find in real life.

And to make it clear: I am not that proficient. To me the second version is
70% line noise and I in ordinary cases I happily pay cycles to have not to
write or read that.

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

Re: [Development] HEADS-UP: QStringLiteral

[André Pönitz]

On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> I'm sorry if I sound blunt, but this is just nonsense. What you call
> optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> readable. As is just using "".

I am not sorry to sound blunt here, but calling

 a["b"] = "c"

"equally readable" to

 a[QStringLiteral("b")] = QStringLiteral("c")

requires a kind of proficiency that's rare to find in real life.

I don't think it makes sense to move Qt into a direction that reduces
its potential audience to a handful people worldwide.


> Aye, it's more to _think_ and to _write_, but we don't care about those 
> metrics.

tr("Haeh?")

[And who is "we"?]

Andre'

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

Re: [Development] HEADS-UP: QStringLiteral

[André Pönitz]

On Wed, Aug 21, 2019 at 10:01:29AM +, Tor Arne Vestbø wrote:
> > 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! 

Indeed.

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

Same here.

Traditionally, "ease of use" and "consistent API" have been a core values of Qt,
even consciously bought at the cost of some bytes and some cycles.

Of course, this has meant that in certain parts of certain types of applications
Qt could not sensibly be used. Still, in most cases all, or almost all of the 
code
could be "plain Qt", benefiting for creation and maintenance from those values.
I do believe this was a sensible setup for Qt, and I do think there's room for
a general purpose framework living that compromise also in today's world.

During the last years (ok, let's say, starting around \epsilon A.J. - "After
Jasmin") this promise has been more or less silently broken, once by "leaf" 
modules
deviating, partially intentionally, from previous naming conventions, then for 
real
accidents that couldn't be corrected due to too-late discovery and compatibility
promises, and finally by attempts to provide "high performance" alternatives in
some places.

In the end we lost uniform, easy-to-use interfaces, and the performance gains 
are
only present in very isolated areas of the offering with long stretches 
in-between,
hidden by obscure and continuously changing do's and don'ts so that they are
effectively not visible in real-world GUI-centric applications.


With Qt 6 approaching, we could, at least in theory, revert steps on the 
"un-Qt-ish"
path, or opt for any of the alternatives ("modern C++ trumps all", "performance
trumps all", "random hogwash of whatever gets a +2 on Gerrit").

I surely have a preference here, but I'll be probably ok with anything that 
follows
*some* rules set, but I'd like to have a conscious decision on that.

If that does not happen, we will continue on the hogwash path.  For me that'd 
be the
least preferable option of all.

Andre'


PS:

> > test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1);
> > 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?

One option is to use QT_RESTRICTED_CAST_FROM_ASCII instead of 
QT_NO_CAST_FROM_ASCII
for your application.

Yes, that costs cycles. But one is still free to use The Right Decorations in 
the
handful places where one doesn't want to in an application.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Request a new branch for Qt Creator

[André Pönitz]

On Mon, Aug 05, 2019 at 11:48:54PM +, Stottlemyer, Brett (B.S.)
wrote:
> Before I address André's specific questions, let me add a little more
> context.
> 
> We have a few plugins for QtC that were developed with KDAB starting
> about 5 years ago with the development of Qt Remote Objects.  We've
> actually had several developers from The Qt Company reviewing the code
> outside of Gerrit, which has been difficult.  Moving to Qt's Gerrit
> was proposed by them (Simon Hausmann specifically).  We believe the
> code fills a hole in Qt, one that would require significant
> development effort to replicate independently.

Such context is always good.

> On 8/5/19, 1:39 PM, "André Pönitz"  wrote:
> Would it be possible to use a less overloaded name? After a bit of
> search I think I get now what it refers to, but it surely was not my
> first guess.
> 
> I'm open to changing the name of the plugin.  I'd rather discuss that
> as part of the review process though.  If we need a better name for
> the branch, is "acme-simulator" acceptable?

For me, 'ACME' probably will always trigger 'ACME Corporation' as in
https://en.wikipedia.org/wiki/Acme_Corporation, but ..

.. by now I think we can simply side step this issue of finding a name
for a branch, as I think we shouldn't have a branch to start with.

[I'll reorder your paragraphs a bit, but all your text is left]


> For how long? "Eternity"? Or is this a meant to be a feature
> branch that gets incorporated into the mainline at some time?
> 
> The hope/plan is to update the code from QtC 4.8 to master in the
> branch, and let more developers review.  Once approved, we'd like it
> to be part of QtC and not be maintained in a separate branch.

As Thiago already stated, such content should target 'master' branch.

There won't be any release from the 4.8 branch anymore, nor would in
the normal course of action any merges happen there, so effectively
any new content in 4.8 would just cause extra effort to merge down to
4.9/4.10/master, causing more work to handle all intermediate stages
than to directly jump to master.

Even if code is not directly compilable in master, interesting contents
often finds helping hands to update it once it is on gerrit.

> How is this planned to be maintained? Will you do that, and the
> mainline is not affected at all?
> 
> Because QtCreator does not maintain binary compatibility like the rest
> of Qt, maintenance is a burden, requiring changes for each new QtC
> version.  We'd like that to be taken over by The Qt Company,
> just as it is done for other plugins. 

Note that "being part of the Qt Creator" does not imply "being
maintained by the Qt Company". Being part of the Qt Creator sources
only means a high probability that the code remains updated and
compilable, and typically also working, as any changes to the core
will be more or less mechanically be applied everywhere. 

Other than that it's the usual bunch of options if you want a real
guarantee that it keeps working:
 (a) do it yourself,
 (b) find someone interested in the code doing it for you,
 (c) pay someone to be interested in the code doing it for you.

All those approaches are easier/cheaper if the code is in-tree,
as at least mechanical updates are applied "for free", but 
"drop and run" is, generally speaking, not an option.

> We expect it to be much less of a burden for the people making
> the changes and knowing why they were made.

That's indeed typically the case.

> Regards, Brett

Regards, Andre'
> 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Request a new branch for Qt Creator

[André Pönitz]

On Mon, Aug 05, 2019 at 10:35:37AM +, Stottlemyer, Brett (B.S.) wrote:
> Hi,

Hi Brett.
 
> I’d like to request  a new branch (“acme”) on QtCreator.
 
Would it be possible to use a less overloaded name? After a bit of search
I think I get now what it refers to, but it surely was not my first guess.

> The too short version: ACME is a simulation tool, allowing you to create a
> project that can run in QtCreator and quickly implement interfaces (e.g., 
> DBus,
> QtRemoteObjects, etc) to feed other components.  You can directly edit
> properties and/or send signals, or you can create custom logic and user
> interfaces in Qt/QML.

Out of curiosity:

How is this planned to be maintained? Will you do that, and the mainline is
not affected at all?

For how long? "Eternity"? Or is this a meant to be a feature branch that gets
incorporated into the mainline at some time?

Andre'

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