Re: [Development] Coin mailing issue

[Simon Hausmann]

Yeah something bad happened and it started yesterday late afternoon.

I don’t know what’s causing it but since nobody reacted so far I have shut down 
coin. I hope that will help with the mass emailing. I’m unfortunately not in a 
position to investigate this issue right now (or this weekend).

Simon

> On 14. Jun 2019, at 21:21, Thiago Macieira  wrote:
> 
>> On Friday, 14 June 2019 12:07:08 PDT Samuel Gaist wrote:
>> Over the last couple of hours I have received more that an hundred of emails
>> about integration failure some of which don’t even contains patches I have
>> submitted, participated in or reviewed.
> 
> I've got over two thousand. All emails from Gerrit in the past 13 hours have 
> been summarily marked as read.
> 
> If you did any work on Friday that requires my attention, ping. ("requires my 
> attention" includes any new non-trivial changes to QtCore)
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Friday, 14 June 2019 15:11:42 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> That really sounds like a nice solution. I don't know if it uses
> private headers or not. If it does it might need to be updated in case
> a future revision breaks it, otherwise it should be quite
> straightforward. And make Qt a little bit slimmer too.

It does, but that should be duplicated inside the tool. It uses the QDBusUtil 
namespace for checking the validity of certain strings and for the printing of 
D-Bus messages that QVariant does not know how to convert. The latter should 
become API and therefore hardcoded in the tool.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Friday, 14 June 2019 15:19:50 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Fri, 14 Jun 2019 at 19:18, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> 
> [snip]
> 
> > The list of user-facing applications is much longer:
> > 
> > ls -1 `qmake -qt5 -query QT_INSTALL_BINS`
> 
> Sorry, that's the complete list of applications. We should still
> filter which ones should live in $libexecdir and which ones not.

I think they're all libexec except for:
 - qdbus
 - qdbusviewer
 - linguist
 - qmake
 - (possibly) qtdiag

The first three should promise backwards compatibility by design. The other 
two need to be suffixed.

I wonder if Assistant as a standalone application still makes sense. Is it 
used by the VS Add-in?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 14/06/2019 17.05, Ville Voutilainen wrote:
> On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke wrote:
>> On 13/06/2019 16.09, Ville Voutilainen wrote:
>>> The minor problem being that to not so small audiences,
>>> new Whoosh(something);
>>> just looks like a bug, and then you need to look three times to
>>> realize that something is a parent.
>>
>> Sure... but `something.createChild()` can help with that.
>>
>> OTOH, I just realized a problem with that... when the new child needs to
>> take its parent in the ctor for other reasons. I don't know if there is
>> an easy solution to that. (Of course, you can still pass the parent with
>> createChild, but then you've violated DRY.)
> 
> That seems like a fairly minor problem. We either just pass the
> parent in, or make createChild do the child construction with the
> parent as an argument if that's valid, or fall back to reparenting if
> not.

I don't think createChild can/should assume that a QObject* ctor
parameter means "parent", i.e. it should *always* explicitly reparent.

So I don't see a way that such classes can avoid writing:

  parent.createChild(parent, ...);

...which means we wrote 'parent' twice, vs.:

  new Whoosh(parent);

OTOH I don't think such classes are common. (I know my own code contains
a few, but I'm not sure there are any in Qt itself.)

>>> [...] the largeish application was leaking like a sieve and doing
>>> use-after-free in all too many places.
>>
>> QPointer is great for avoiding this :-). (Also, properly "owned"
>> signal/slot connections.)
> 
> I fail to see how QPointer helps with that,

Proper use of QPointer can certainly help with use-after-free.

> nor do I know what "properly owned" signal/slot connections are.

Connections which have both a sender and receiver owner, such that they
disappear when *either* is destroyed... and in particular, when the
receiver is the owner of any resources used in the slot. (Although, this
really only became relevant with Qt5 when you could use lambdas as slots.)

>>> On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote:
 My "concern", and possibly why everyone fixated on the unique_ptr stuff,
 is how wide-sweeping the necessary API changes will be. Modifying every
 method, everywhere, that reparents a QObject is a little intimidating.
 (Maybe you have some WIP that can put this into perspective?)
>>>
>>> Like https://codereview.qt-project.org/c/qt/qtbase/+/260618 ?
>>
>> Uh... yeah, I suppose. And... yeah. Yike. That's a scary (or at least
>> intimidating) amount of API churn. In particular, there are enough files
>> being touched to strongly discourage me even looking at the diffs...
> 
> I don't know what to do with that. You asked whether there's a WIP, 
> and after being pointed to such a WIP, you are applying a yardstick
> to it and then saying that you're discouraged from even looking at
> it, because it violates your arbitrary yardstick requirement.
I suggested that perhaps folks were intimidated by Daniel's proposal
because "modifying every method, everywhere, that reparents a QObject is
a little intimidating." As I'd overlooked the patch, I was just guessing
at how much churn there would be. Subsequently looking at the patch
confirmed my suspicion.

IOW:

Me: 
You: 
Me: Okay, sticking with my original conjecture.

I don't know what to do with your "arbitrary yardstick" comment. Large
code changes tend to be intimidating, and (in many cases) rightly so.

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

Re: [Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 14 Jun 2019 at 19:18, Lisandro Damián Nicanor Pérez Meyer
 wrote:

[snip]
> The list of user-facing applications is much longer:
>
> ls -1 `qmake -qt5 -query QT_INSTALL_BINS`

Sorry, that's the complete list of applications. We should still
filter which ones should live in $libexecdir and which ones not.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

Hi Matthew!

On Fri, 14 Jun 2019 at 18:36, Matthew Woehlke  wrote:
>
> On 14/06/2019 14.35, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Thu, 13 Jun 2019 at 17:02, Thiago Macieira wrote:
> >> That means you should NOT do that strong dependency. app5 should
> >> require qdbus >= Qt5, which means Qt 6's should suffice.>
> > Except you can't ship both version in the same binary-package,
>
> ...so? Pick one (and only one) to install.
>
> > so there is no way to express that relationship *with versioning*.
>
> Requires: qdbus >= 5.0  # satisfied by qdbus-6.3
>
> The whole point, as I understood it, was that the above is supposed to
> work. (If packagers aren't packaging qdbus separately, well, that's
> *their* problem.)

Correct, but that as long as the application is backwards compatible
and/or doesn't make use of external plugins (so far you shouldn't be
able to run a Qt4 plugin on a Qt5 designer). So far we have this
promise only with qdbus. The list of user-facing applications is much
longer:

ls -1 `qmake -qt5 -query QT_INSTALL_BINS`

> On 14/06/2019 15.05, Thiago Macieira wrote:
> > I was thinking that you'd split the package so that Qt 3, 4 and 5's
> > qdbus is never installed, but instead you always get the one from Qt
> > 6. That means Qt 6 is always installed in a system that needs qdbus,
> > regardless of whether any applications use it.
> That shouldn't be necessary. Just make "qdbus" a virtual package, and
> install the one for which you are willing to drag in Qt.
>
> i.e. qdbus5-5.13 → Provides: qdbus = 5.13
>
> (At this point, I'm talking about things *packagers* need to do. Qt can
> just ship /usr/bin/qdbus.)
>
> I'm not sure if package managers are smart enough to pick whichever
> concrete package satisfies a virtual dependency with the fewest
> dependencies of its own, but again, that's not *Qt's* problem.

And again, that's correct as long as we have the conditions I wrote
above. If they are don't met then yes, it becomes a Qt problem.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 14 Jun 2019 at 16:06, Thiago Macieira  wrote:
>
> On Friday, 14 June 2019 11:35:20 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > > That means you
> > > should NOT do that strong dependency. app5 should require qdbus >= Qt5,
> > > which means Qt 6's should suffice.
> >
> > Except you can't ship both version in the same binary-package, so
> > there is no way to express that relationship *with versioning*. The
> > package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
> > package might be considered, but only for applications that will not
> > change their backwards behavior *ever*.
>
> THAT's a good point.
>
> I was thinking that you'd split the package so that Qt 3, 4 and 5's qdbus is
> never installed, but instead you always get the one from Qt 6. That means Qt 6
> is always installed in a system that needs qdbus, regardless of whether any
> applications use it.

And now I get your point here. I think we never thought in this
because qdbus is the only tool we have a promise of backwards
compatibility.

> This is not always a good solution.

But at the same time the only place in which this can not be good
would be in Yocto, but in those cases you will certainly ship only one
Qt version.

> But we should consider splitting qdbus and qdbusviewer out of qtbase and
> giving them their separate, independent releases.

That really sounds like a nice solution. I don't know if it uses
private headers or not. If it does it might need to be updated in case
a future revision breaks it, otherwise it should be quite
straightforward. And make Qt a little bit slimmer too.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Matthew Woehlke]

On 14/06/2019 14.35, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thu, 13 Jun 2019 at 17:02, Thiago Macieira wrote:
>> That means you should NOT do that strong dependency. app5 should 
>> require qdbus >= Qt5, which means Qt 6's should suffice.>
> Except you can't ship both version in the same binary-package,

...so? Pick one (and only one) to install.

> so there is no way to express that relationship *with versioning*.

Requires: qdbus >= 5.0  # satisfied by qdbus-6.3

The whole point, as I understood it, was that the above is supposed to
work. (If packagers aren't packaging qdbus separately, well, that's
*their* problem.)

On 14/06/2019 15.05, Thiago Macieira wrote:
> I was thinking that you'd split the package so that Qt 3, 4 and 5's 
> qdbus is never installed, but instead you always get the one from Qt
> 6. That means Qt 6 is always installed in a system that needs qdbus,
> regardless of whether any applications use it.
That shouldn't be necessary. Just make "qdbus" a virtual package, and
install the one for which you are willing to drag in Qt.

i.e. qdbus5-5.13 → Provides: qdbus = 5.13

(At this point, I'm talking about things *packagers* need to do. Qt can
just ship /usr/bin/qdbus.)

I'm not sure if package managers are smart enough to pick whichever
concrete package satisfies a virtual dependency with the fewest
dependencies of its own, but again, that's not *Qt's* problem.

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

Re: [Development] unique_ptr and Qt, Take 2

[Ville Voutilainen]

On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke  wrote:
>
> On 13/06/2019 16.09, Ville Voutilainen wrote:
> > The minor problem being that to not so small audiences,
> > new Whoosh(something);
> > just looks like a bug, and then you need to look three times to
> > realize that something is a parent.
>
> Sure... but `something.createChild()` can help with that.
>
> OTOH, I just realized a problem with that... when the new child needs to
> take its parent in the ctor for other reasons. I don't know if there is
> an easy solution to that. (Of course, you can still pass the parent with
> createChild, but then you've violated DRY.)

That seems like a fairly minor problem. We either just pass the parent
in, or make createChild
do the child construction with the parent as an argument if that's
valid, or fall back to reparenting
if not.

> >> That's one of the things I love about Qt; object hierarchies give me
> >> working dynamic memory management without needing even smart pointers.
> >
> > That's the one thing that makes me queasy about using Qt in large
> > applications; I always need to worry about ownership relationships,
> > because I can't program with smart pointers.
> I guess your mileage varies. My experience has been the opposite.
>
> To be fair, I expect a lot of that is "instinctive"... that is, when you
> come from a background where not using smart pointers is scary, the Qt
> way is probably going to rub you the wrong way, even though it's nowhere
> near as dangerous as your experience causes you to believe. Conversely,

My experience with Qt matches my previous experience. Memory leaks are
easy to introduce, and avoiding them is not trivial.

> being comfortable with Qt and its minimal need for smart pointers likely
> produces an aversion to sprinkling them everywhere "because it's safer".

Interesting conjecture; there's no quotation marks in the actual
rationale for programming
with smart pointers without using raw pointers across a codebase, and
that reason is
that it's proven to work.

> > [...] the largeish application was leaking like a sieve and doing
> > use-after-free in all too many places.
>
> QPointer is great for avoiding this :-). (Also, properly "owned"
> signal/slot connections.)

I fail to see how QPointer helps with that, nor do I know what
"properly owned" signal/slot connections
are.

> > On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote:
> >> My "concern", and possibly why everyone fixated on the unique_ptr stuff,
> >> is how wide-sweeping the necessary API changes will be. Modifying every
> >> method, everywhere, that reparents a QObject is a little intimidating.
> >> (Maybe you have some WIP that can put this into perspective?)
> >
> > Like https://codereview.qt-project.org/c/qt/qtbase/+/260618 ?
>
> Uh... yeah, I suppose. And... yeah. Yike. That's a scary (or at least
> intimidating) amount of API churn. In particular, there are enough files
> being touched to strongly discourage me even looking at the diffs...

I don't know what to do with that. You asked whether there's a WIP,
and after being pointed to such a WIP,
you are applying a yardstick to it and then saying that you're
discouraged from even looking at it,
because it violates your arbitrary yardstick requirement. It shouldn't
come as a surprise to anyone that
adding smart pointer support to APIs that didn't have it before
requires churn, because smart pointers
don't just drop into raw pointer APIs - by design.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Kevin Kofler]

Thiago Macieira wrote:
> But as you said, this is a developer tool. And interestingly, if we move
> the developer tools out of $PATH, qtchooser becomes an interesting
> solution to bring them back in for those few people who want them. So I
> don't see anything wrong with qtchooser as a developer-of-Qt tool.

This is exactly how Fedora ships qtchooser: It is not installed or used by 
default (the default setup relies on suffixed binaries in /usr/bin and 
unsuffixed binaries in a version-specific directory), but you can enable it 
by installing the qtchooser package and prepending its directory to your 
$PATH.

Kevin Kofler

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

Re: [Development] Coin mailing issue

[Thiago Macieira]

On Friday, 14 June 2019 12:07:08 PDT Samuel Gaist wrote:
> Over the last couple of hours I have received more that an hundred of emails
> about integration failure some of which don’t even contains patches I have
> submitted, participated in or reviewed.

I've got over two thousand. All emails from Gerrit in the past 13 hours have 
been summarily marked as read.

If you did any work on Friday that requires my attention, ping. ("requires my 
attention" includes any new non-trivial changes to QtCore)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Coin mailing issue

[Иван Комиссаров]

Same here, also about merged ones

> 14 июня 2019 г., в 21:07, Samuel Gaist  написал(а):
> 
> Hi guys,
> 
> Does anybody know what is happening with coin ?
> 
> Over the last couple of hours I have received more that an hundred of emails 
> about integration failure some of which don’t even contains patches I have 
> submitted, participated in or reviewed.
> 
> Best regards
> 
> Samuel
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

[Development] Coin mailing issue

[Samuel Gaist]

Hi guys,

Does anybody know what is happening with coin ?

Over the last couple of hours I have received more that an hundred of emails 
about integration failure some of which don’t even contains patches I have 
submitted, participated in or reviewed.

Best regards

Samuel

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

Re: [Development] Proposing CMake as build tool for Qt 6

[Thiago Macieira]

On Friday, 14 June 2019 11:35:20 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > That means you
> > should NOT do that strong dependency. app5 should require qdbus >= Qt5,
> > which means Qt 6's should suffice.
> 
> Except you can't ship both version in the same binary-package, so
> there is no way to express that relationship *with versioning*. The
> package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
> package might be considered, but only for applications that will not
> change their backwards behavior *ever*.

THAT's a good point.

I was thinking that you'd split the package so that Qt 3, 4 and 5's qdbus is 
never installed, but instead you always get the one from Qt 6. That means Qt 6 
is always installed in a system that needs qdbus, regardless of whether any 
applications use it.

This is not always a good solution.

But we should consider splitting qdbus and qdbusviewer out of qtbase and 
giving them their separate, independent releases.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 13 Jun 2019 at 17:02, Thiago Macieira  wrote:
>
> On Thursday, 13 June 2019 05:02:01 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > > Giving our build tools different names depending on the version can create
> > > other problems for our users, especially those that use some hand rolled
> > > build systems (and we probably have lots of those as well).
> >
> > And the above is clearly a thing a Qt-internals' developer should definitely
> > look to, so a very valid concern. But let's take the other's too.
>
> I REALLY don't think there are a lot of hand-rolled buildsystems out there.
> And they must represent less than 0.1% of uses and complexity. We should
> consider giving them a solution. But by the same token, we should consider
> that Linux distributions must correspond to at least 10% of uses, which is
> 100x more.

That's my perception too, but I don't have data except maybe for some
partial data from linux distributions to back it up.

 it would be at very least amusing to have a guesstimate of
that, but I don't think that's feasible at all.

> > We can list qdbus and qdbusviewer as examples (perhaps not the best ones,
> > but will do for now). So let's say app4 is compiled against Qt4 (we still
> > have them around, sadly not every useful app was yet ported) and app5 is
> > compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where
> > developed using their own version's qdbus in mind.
> >
> > As a packager my duty is to ensure that app4 has a strong dependency against
> > Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
> > versions of qdbus will be installed.
>
> Those are really not good examples because qdbus is a regular tool that
> retains compatibility going forward, > like any other tool.

Actually they are the worsts examples. Those are the only tools that
it's maintainer (you Thiago) publicly expressed that they will keep
compatibility when I asked about that back when qtchooser was a new
thing. For the rest, at least in my memory (anyone please feel free to
prove me wrong) no compatibility was promised nor denied.

> That means you
> should NOT do that strong dependency. app5 should require qdbus >= Qt5, which
> means Qt 6's should suffice.

Except you can't ship both version in the same binary-package, so
there is no way to express that relationship *with versioning*. The
package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
package might be considered, but only for applications that will not
change their backwards behavior *ever*.

> The only other application that come close are Linguist and Assistant.

Ideally we should list all the applications and check whether they
really need to be in $libexec or directly accessible in $PATH, at very
least for the exercise of doing it.

> > ## Binaries that need to be accesible by developers using Qt
> >
> > These are moc, rcc, linguist, designer, uic, etc. Some of them really
> > need to be in
> > $libexecdir and ought to be found by way of the .cmake and .pc files
> > [1]. But then
> > there are the other tools that, once again, need to be readily accesible for
> > a developer user but in a much "normal" way. Let's say for example
> > linguist. Translators
> > are normally more in the "user" side of things than in the "developer" side.
> >
> > assistant might probably be in this situation too.
> >
> > [1]
> >  > ml> [2]
> >  > ml>
> >
> > And maybe lupdate is also an elegible example.
>
> The command-line tools used by the build system (moc, rcc, lupdate, etc.)
> should be in a lib / libexec dir and found by .cmake and .pc files.

As a start of the exercise I wrote above: should lupdate be in
$libexec? lupdate is normally used during string freeze. Granted, it
can be added as a non-automatic target of the build system, but it's
not strange at all to run it by hand. After all, is there any benefit
of running it during the build? Maybe there are some special cases,
but mostly it will regenerate a file that ought to be shipped with the
source code tarball, if shipped at all (I doubt proprietary apps/libs
would ship them).

Also, can we warrant that lupdate will *never* change it's default
output? Maybe we can for qt6, maybe it's a good time to change
something.

> For a
> foreign buildsystem, the only modification necessary is to change how it
> launches the binaries. Not very difficult and probably not the only
> modification necessary anyway to support Qt 6.

Agreed for stuff that can really live in $libexec.

> Linguist and Assistant are a different story: they should be found by the
> desktop menu. Both should retain compatibility with old files and, in case of
> Linguist, *generate* for older formats so the same tool can be used to
> translate for Qt 3, 4, 5 and 6.

Just as long as this can be achieved/supported as a P1 bug 

Re: [Development] From whence cometh Q_NAMESPACE?

[Matthew Woehlke]

On 11/06/2019 11.28, Matthew Woehlke wrote:
> A coworker just pointed out something interesting... the documentation
> of Q_NAMESPACE is in qobject.cpp, which causes it to be documented under
> the documentation for QObject. However, the *definition* comes from
> qobjectdefs.h, which is roughly QMetaObject, and indeed it seems like
> one should not need all of QObject to use Q_NAMESPACE. Q_ENUM and
> Q_ENUM_NS are in the same boat... In fact, so is Q_GADGET and everything
> that can be used with Q_GADGET.
> 
> Is this intended? Or would it make sense to move the documentation to
> QMetaObject?

Since code speaks louder than e-mail...

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

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