Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 05:59:24 PST Marco Bubke wrote:
> > I guess GTK maintainers suffer, specially with the last changes they
> > announced some time ago about breaking API/ABI (sorry, I don't remember
> > exactly which one) in some minor releases. Incindentally the first thing
> > we Qt maintainers though about those changes is how lucky we are to have
> > such a string-minded upstream that guarantess ABI during the life of a
> > major version.
> 
> So GTK maintainers can do it. There are much more applications on my Linux
> Desktop so it is possible. And like Linus Torvalds has said,  it is
> questionable to provide a package for every application on Earth. Flatpack
> is a much more reasonable choise for the developer and the user.

First of all, GTK maintainers haven't started doing their weird dance of ABI 
breakage. We don't know if they'll actually go through with it and, if they 
do, for how long they'll keep doing it. It's very likely that distributions 
(aside from GTK-centric Fedora) will not keep the unstable versions updated, 
so they'll get less testing. I find it highly likely the GTK developers abandon 
this weird dance before or during GTK 5 because of the mess they created.

I don't agree on the philosophy of the flatpaks and similar because they're 
based on a shifting foundation. Oh, it's ok to have a random app here and 
there that I barely ever use not follow the system L&F -- for example, the 
Intel Parallel Studio installer (a Qt 5.6 application). But the everyday 
applications must be native.

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 07:00:17 PST Marc Mutz wrote:
> On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote:
> > That said, sometimes rebuilding even if there was no dependency on the
> > private  API could result in improvements. For example, every time we add
> > overloads there's a chance that the new method is faster and will get
> > selected.
> 
> Its even worse: if Qt fixes a bug in an inline function, no application will
> benefit unless recompiled, either. So for any Qt user, and esp. distros,
> not recompiling all users of Qt when Qt changes runs the risk of not
> getting some of the bug fixes, leading to users seeing those bugs together
> with Qt versions in which they're officially fixed.

True, but there are two important factors in this:

1) those bugfixes and overload additions are not so common

2) application rebuilding can happen at a leisure pace, when resources are 
available or when the application would have been updated anyway

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 06:13:44 PST Marco Bubke wrote:
> So you say it it does not work because of themeing support? Isn't Qt
> Controls 2 not anymore providing them too. And is there no technical
> solutions for that? Like propagating the values to the Flatpack themeing
> engine. This could be improve the interoperability between different
> desktop libraries too. The implementation which is based on GTK or Qt is
> suboptimal anyway. It shows visually why Linux Desktop was never widely
> adopted. I mean the lack of cooperation and the hesitancy to try to
> understand the context of the other. I use Linux all the day, but honestly
> many things are broken, especially where Unix wasn't copied.

So you're saying we need to develop another GUI toolkit for Linux desktops so 
that we can share some common things between the existing toolkits?

This comes to mind: https://xkcd.com/927/

Theming and styling is a complex operation. It's not just "propagating 
values". Reading config files will at best get you the right font, correct icon 
set, and somewhat correct colours. But gradients, shapes, complex dialogs will 
not work.

And I don't see anyone volunteering for a major overhaul of QtWidget's styling 
system. I don't even think a volunteer would be *accepted* by the Qt Project. 
So, no, there is no solution. Qt applications in a flatpak or similar will not 
look or feel native, therefore it is not an acceptable solution for an 
application of regular use.

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

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

[Development] CI suffering from an unknown problem

[Tony Sarajärvi]

Hi

There's something off in the CI currently and we're investigating.

-Tony



Tony Sarajärvi
CI Tech Lead

The Qt Company
Elektroniikkatie 10
90590, Oulu
Finland tony.saraja...@qt.io
+358 50 4821416
http://qt.io

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]

[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]




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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Kevin Kofler]

Marco Bubke wrote:

> On November 22, 2016 02:10:50 Thiago Macieira wrote:
>> GTK 2 and GTK 3 do keep their ABI just fine.
> 
> To my understanding GTK 3 gives no guarantees at all.

That is not true. GTK+ 3 is backwards ABI-compatible with previous versions 
all the way down to 3.0.

There are some private APIs whose ABI is not guaranteed, such as styling 
(where custom theme engines do not work anymore at all, you have to use CSS 
instead of C/C++ code now), but Qt also has such private APIs (and in fact 
Qt styling is also private, though I hope Qt will never break all existing 
styles the way GTK+ did!).

This will change with GTK+ 4 and their new way is going to be a nightmare, 
but I will draw a "Not My Problem" card and leave the Fedora GTK+ and GNOME 
packagers to deal with that. ;-)

Kevin Kofler

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 22, 2016 00:47:26 Thiago Macieira  wrote:

> On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote:
>> I strongly agree with Andre'. And is a BC break in the time of flat pack
>> that bad? As an user I really looking forward to flat pack,  so I can
>> update my heavily used Applications and being not dependent on
>> distribution. This package could be much better optimize with LTO and
>> profile guided optimization. Maybe sharing everything is not that smart
>> anymore.
>
> FlatPaks don't work for Qt.
>
> Reasons:
>
> /usr/lib64/qt5/plugins/styles/breeze.so
> /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so
>
> If you include Qt in your flatpak or equivalent, then your Qt application 
> will 
> not load the system plugins and will thus not have native look and feel in a 
> Plasma desktop or in LXQt.

So you say it it does not work because of themeing support? Isn't Qt Controls 2 
not anymore providing them too. And is there no technical solutions for that? 
Like propagating the values to the Flatpack themeing engine. This could be 
improve the interoperability between different desktop libraries too. The 
implementation which is based on GTK or Qt is suboptimal anyway. It shows 
visually why Linux Desktop was never widely adopted. I mean the lack of 
cooperation and the hesitancy to try to understand the context of the other. I 
use Linux all the day, but honestly many things are broken, especially where 
Unix wasn't copied.


> If you don't include Qt or if the included Qt loads plugins, then BC is 
> required.
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 22, 2016 01:30:47 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
> [snip] 
>> And how many applications are Qt only and use no standard lib anyway? Are
>> there any numbers?
>
> Good question, I wonder if there is a way to dig that.
>
>> Yes, sometimes they are inlined but sometimes they are
>> not. Is it really a so big burden for you? 
>
> Yes, as I described in a previous mail. Thiago got a nice word there: 
> bottleneck. It's a heck of a bottle neck.
>
>> And what are you doing about
>> GTK? To my knowledge their BC is quite limit.
>
> I guess GTK maintainers suffer, specially with the last changes they 
> announced 
> some time ago about breaking API/ABI (sorry, I don't remember exactly which 
> one) in some minor releases. Incindentally the first thing we Qt maintainers 
> though about those changes is how lucky we are to have such a string-minded 
> upstream that guarantess ABI during the life of a major version.

So GTK maintainers can do it. There are much more applications on my Linux 
Desktop so it is possible. And like Linus Torvalds has said,  it is 
questionable to provide a package for every application on Earth. Flatpack is a 
much more reasonable choise for the developer and the user. 


> -- 
> Bebe a bordo (pero con moderación)
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marc Mutz]

On Tuesday 22 November 2016 02:07:08 Thiago Macieira wrote:
> That said, sometimes rebuilding even if there was no dependency on the
> private  API could result in improvements. For example, every time we add
> overloads there's a chance that the new method is faster and will get
> selected.

Its even worse: if Qt fixes a bug in an inline function, no application will 
benefit unless recompiled, either. So for any Qt user, and esp. distros, not 
recompiling all users of Qt when Qt changes runs the risk of not getting some 
of the bug fixes, leading to users seeing those bugs together with Qt versions 
in which they're officially fixed.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 22, 2016 02:10:50 Thiago Macieira  wrote:

> On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor 
> Pérez Meyer wrote:
>> I guess GTK maintainers suffer, specially with the last changes they
>> announced some time ago about breaking API/ABI (sorry, I don't remember
>> exactly which one) in some minor releases. Incindentally the first thing we
>> Qt maintainers though about those changes is how lucky we are to have such
>> a string-minded upstream that guarantess ABI during the life of a major
>> version.
>
> GTK 2 and GTK 3 do keep their ABI just fine.

To my understanding GTK 3 gives no guarantees at all.

>
> Lisandro is talking about the GTK 4 plans. See 
> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Kevin Kofler]

André Pönitz wrote:
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

The problem is that Qt is a very widely used library, and that it is also
used by many libraries used by other libraries used by other libraries, all
of which also use Qt directly (e.g. KF5-*). The "all of which also use Qt
directly" part is how this differs from something like libpng which is
usually only used through higher-level APIs. Most applications do not link
directly to libpng. (In fact, we do this:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n562
to avoid Qt applications needlessly linking directly to libpng etc. We
cannot do this with Qt because its APIs are used both directly and
transitively.)

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
> 
> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.

It is not *an* application. It is *many* libraries and applications.

> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

Well yes, testing is what our users do daily. What we need to take care of
is to not have broken dependencies (or worse, symbol lookup failures at
runtime because the ABI was changed without a soname bump). Otherwise, the
application will not run at all.

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

In Fedora, the issues this would cause are twofold:

1. In Rawhide, we would have to rebuild all packages using Qt, which are
   dozens, each time such a thing happens. But, due to the transitive
   dependency issue I mentioned at the beginning, they would have to be
   rebuilt in reverse dependency order. So we would first have to compute
   that. Our tools do not do it for us. The mass rebuilds Fedora release
   engineering does for some releases are always done in alphabetical order.
   That will not work if so many libraries have broken dependencies.

2. In Fedora, Qt is often updated to a newer version in a release, as an
   official update. And even when not, the newer version is typically
   offered in a Copr repository (a Fedora "PPA"). That would not be
   reasonably doable anymore if the new version were not binary-compatible.
   As in Debian's case, the packages (ab)using private APIs are already
   enough of an issue for us as it stands. But at least we have a list of
   those, and their interdependencies are limited, whereas rebuilding ALL
   packages using Qt would be orders of magnitude larger and not suitable
   for an update nor (realistically) even a Copr at all.

Major versions of Qt (i.e., 3, 4, 5, …) are the right place to change the
ABI, because there, we just make both versions coexist, and the transition
becomes relatively smooth. But also breaking binary compatibility in the
minor releases would not really scale.

> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.

But if our users were to be stuck at, say, Qt 5.8 because 5.9 would be
binary-incompatible, they would be losing much more features.

> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

You can always think about it, but if you do so, you will quickly find that
it is not practical at all.


Marco Bubke wrote:
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution. This package could be much better optimize with LTO and
> profile guided optimization. Ma

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Kevin Kofler]

Marc Mutz wrote:
> People make mistakes. The difference is that, in the STL, by way of a
> larger target audience, mistakes tend to be fewer than in Qt (looked at
> qtimageformats, lately?)

That is not a fair comparison. The STL has nothing comparable to 
qtimageformats. Image decoding and encoding is necessarily a low-level byte 
crunching task, and performance-critical, even. And thus, things such as 
buffer overflows can happen. The STL just leaves you in the cold if you need 
to do any kind of image processing.

> If Qt consistently did a better job at implementing such things, the world
> might be different. But looking at the Qt containers, and the Qt image
> format plugins, I'd much rather use an external library (STL,
> lib{jpeg,png,tiff,...) that everyone else also uses, than to reinvent the
> wheel and create bugs exclusive to Qt.

Several of the decoders already use such external libraries. (The
qt5-qtimageformats distribution package I use is linked to libjasper.so.1, 
libmng.so.2, libtiff.so.5 and libwebp.so.6.) It might make sense to port the 
others to those libraries. But using an external library does not 
necessarily fix all problems. Those libraries can have security 
vulnerabilities (buffer overflows, integer overflows etc.) too. And 
sometimes, the library you chose is not or poorly maintained. And finally, 
there can also be bugs in the way the library is called in your code. Still, 
it is usually a better approach than hardcoding the format directly in Qt.

Now, if you are suggesting that all the applications should just use the 
low-level libraries directly, that is not a reasonable suggestion. Those 
libraries typically have very low-level C APIs. And most importantly, you 
need to use a different library for every single format! That is what 
higher-level abstractions such as qtimageformats are for.

Kevin Kofler

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 17:07:08 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > > I remember in the MeeGo days when building MeeGo with OBS spent an hour
> > > on
> > > a very beefy machine compiling Qt, with most of the resources in the OBS
> > > farm unused because nothing else could be built yet. With Qt 5 and our
> > > split packages, this lessens because only qtbase is the bottleneck.
> > 
> > As long as qtbase's private headers do not change. I guess in that case
> > one
> > who knows exactly what would affect will just rebuild the necessary parts,
> > the rest of us need to get all the stuff rebuilt (17 submodules? maybe
> > they
> > are more right now).
> 
> My point is that there are packages that depend only on qtbase libraries, so
> they can start rebuilding as soon as qtbase is done, while the system is
> building qtsvg and qtserialport in another node in the farm. And this
> scenario was the "rebuild world" case, regardless of whether there were ABI
> breakages or not.
> 
> You're right that if you're rebuilding only what needs to be rebuilt, then
> an update to qtbase should trigger only rebuilding of packages that
> depended on the private API. With the ELF version marker, that should be
> easy to detect now.

Just for the record, every time that qtbase's private symbols change we end up 
requiring a rebuild of almost all the submodules. We might be able to do 
better with some more hacks, but as we normally require this when we are 
pushing a new upstream release there is currently not much of a point.

> That said, sometimes rebuilding even if there was no dependency on the
> private API could result in improvements. For example, every time we add
> overloads there's a chance that the new method is faster and will get
> selected.

Fair point.

[snip]
> And ELF symbol versioning. That allows both libraries to be loaded into
> memory and not interfere with each other, so long as you don't pass data
> from one to the other.

Indeed, that would really be great.

-- 
Simulations are not data. In God we trust, all the others must supply data.
 Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments,
 http://www.spectrum.ieee.org/nov04/4004

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:23:54 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> Now I have a question: how will the Qt community take that a distro changes
> the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes
> happen?

We prefer to work with downstreams and have those changes in Qt itself. Not 
because we don't trust Debian, Fedora and OpenSUSE maintainers to do the right 
thing, but precisely because it's multiple teams. Why should each team 
redevelop the solution?

And don't forget tiny distros and self-built distros (Yocto comes to mind!) 
whose teams are not aware of those changes.

Note that we can do ABI versioning if we wanted to:

libQt5Core.so.5
 ↑↑
 ❘⌞→ ABI (binary) version
 ⌞→ API (source) version

The ELF symbol version would need to be adapted too. Right now, it marks 
everything as "Qt_5".

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:30:28 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> I guess GTK maintainers suffer, specially with the last changes they
> announced some time ago about breaking API/ABI (sorry, I don't remember
> exactly which one) in some minor releases. Incindentally the first thing we
> Qt maintainers though about those changes is how lucky we are to have such
> a string-minded upstream that guarantess ABI during the life of a major
> version.

GTK 2 and GTK 3 do keep their ABI just fine.

Lisandro is talking about the GTK 4 plans. See 
https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> > I remember in the MeeGo days when building MeeGo with OBS spent an hour on
> > a very beefy machine compiling Qt, with most of the resources in the OBS
> > farm unused because nothing else could be built yet. With Qt 5 and our
> > split packages, this lessens because only qtbase is the bottleneck.
> 
> As long as qtbase's private headers do not change. I guess in that case one
> who knows exactly what would affect will just rebuild the necessary parts,
> the rest of us need to get all the stuff rebuilt (17 submodules? maybe they
> are more right now).

My point is that there are packages that depend only on qtbase libraries, so 
they can start rebuilding as soon as qtbase is done, while the system is 
building qtsvg and qtserialport in another node in the farm. And this scenario 
was the "rebuild world" case, regardless of whether there were ABI breakages 
or not.

You're right that if you're rebuilding only what needs to be rebuilt, then an 
update to qtbase should trigger only rebuilding of packages that depended on 
the private API. With the ELF version marker, that should be easy to detect 
now.

That said, sometimes rebuilding even if there was no dependency on the private 
API could result in improvements. For example, every time we add overloads 
there's a chance that the new method is faster and will get selected.

> > I can't think of anything that would be worth the major headache that
> > breaking BC more often than once every 4 years would cause. And note I'm
> > not talking about breaking SC.
> 
> And if this can be coupled with an upstream-made SONAME like 5 to 5abi1...
> well, I guess once in 4 years is not that much.

And ELF symbol versioning. That allows both libraries to be loaded into memory 
and not interfere with each other, so long as you don't pass data from one to 
the other.

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 21:21:08 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
[snip]
> A transition like that would definitely take like a month, in which no other
> transition will probably be able to happen because Qt is *so* widely used.

Maybe worth mentioning: in order to improve the speed of a transition no Qt-
based apps/libs will be able to be upsdated during the process *except* when 
they fix bugs in order to achieve the transition. That includes the whole KDE 
stack, apart from Qt-only things.

-- 
Un viejo proverbio de El.Machi dice que la memoria es como
las papas fritas... ¡nunca sobran!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 15:57:06 ART Thiago Macieira wrote:
> On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote:
> > I also said that packagers (i.e. people like you) *are* affected, but I
> > claimed the way they are affected is not fundamentally different from
> > what happens if the packages in question uses any other library that
> > doesn't guarantee BC, or - in case they have similar BC promises like Qt
> > - what happens when there are jumps in major versions.
> 
> Fundamentally, no. But the important difference is the bottleneck.
> 
> I remember in the MeeGo days when building MeeGo with OBS spent an hour on a
> very beefy machine compiling Qt, with most of the resources in the OBS farm
> unused because nothing else could be built yet. With Qt 5 and our split
> packages, this lessens because only qtbase is the bottleneck.

As long as qtbase's private headers do not change. I guess in that case one 
who knows exactly what would affect will just rebuild the necessary parts, the 
rest of us need to get all the stuff rebuilt (17 submodules? maybe they are 
more right now).
 
[snip]
> I can't think of anything that would be worth the major headache that
> breaking BC more often than once every 4 years would cause. And note I'm
> not talking about breaking SC.

And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... 
well, I guess once in 4 years is not that much.

-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 23:18:08 ART Marco Bubke wrote:
[snip] 
> And how many applications are Qt only and use no standard lib anyway? Are
> there any numbers?

Good question, I wonder if there is a way to dig that.

> Yes, sometimes they are inlined but sometimes they are
> not. Is it really a so big burden for you? 

Yes, as I described in a previous mail. Thiago got a nice word there: 
bottleneck. It's a heck of a bottle neck.

> And what are you doing about
> GTK? To my knowledge their BC is quite limit.

I guess GTK maintainers suffer, specially with the last changes they announced 
some time ago about breaking API/ABI (sorry, I don't remember exactly which 
one) in some minor releases. Incindentally the first thing we Qt maintainers 
though about those changes is how lucky we are to have such a string-minded 
upstream that guarantess ABI during the life of a major version.

-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 15:42:12 ART Thiago Macieira wrote:
> On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián
> Nicanor
> Pérez Meyer wrote:
> > > So how often do you had a BC break in stdlibc++?
> > 
> > Last time was with gcc5.
> 
> In other words, once in 11 years.
> 
> > And quite messy in some concerns too because they did not increase the
> > SONAME
> > as they should, so the only thing we had is to track which apps/libs got
> > rebuilt. Normally we can track this with a proper SONAME change.
> 
> Because GCC developers, like the proponents of inline namespaces, forget
> that libraries use their libraries and thus expose their ABI differences in
> their ABI. GCC devs invented the "abi_tag" attribute so they could mark
> methods according to a deveoper-defined tag, and propagate that tag. They
> provide both sets of ABIs in libstdc++.
> 
> But unless developers of downstream libraries take the precautions to
> provide them both in their own libraries, this causes a BC breakage. THAT
> was the issue.

Point taken. If the 3rd party exposed API does not changes that much and the 
necessary guards are in place then it should not hurt that frequently.

Now I have a question: how will the Qt community take that a distro changes 
the SONAME of a lib from, let's say, 5 to 5abi1 when that kind of changes 
happen?

-- 
Only wimps use tape backup: real men just upload their important stuff on
ftp, and let the rest of the world mirror it ;)
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On martes, 22 de noviembre de 2016 01:06:00 ART André Pönitz wrote:
> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> > [snip]
> > 
> > > - people using Qt in applications distributed by packaging
> > > 
> > >   systems (read "Linux distributions"). They are not affected
> > >   by BC breakages.
> > 
> > Users might not notice if we maintainers have to deal with this nightmare.
> 
> That's what I said.
> 
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.
> 
> > If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
> > lib break ABI we need to get Qt rebuilt and *everything* building
> > against it.
> 
> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden

Because it's not just a few applications nor a few archs nor a day or two of 
rebuilding stuff nor Qt alone.

Let's take for example the work we Debian maintainers need to do on every 
minor Qt update due to private symbols.

As you all should know Qt ships private headers which should only be used by 
Qt itself. But there are people out there that need to use those private 
headers in order to be able to, for example, provide a native theme.

Of course Qt will not bump SONAME and that's fine by definition, because they 
are private headers. But we maintainers need to deal with it somehow.

One way to achieve it will mean rebuilding the whole set of apps using Qt, but 
that's definitely too much. Using something we call "symbols files" we where 
able to first hack a way to determine which apps uses private symbols (and 
then thanks to Thiago providing us with tagged symbols we improved it quite a 
lot). So we get down to something like this:



Of course that only shows 2 out of the 11 archs we have.

It will seem a pretty easy list, most of it being Qt submodules. That alone on 
the best case scenario takes us 3 to 5 days.

Last time we did it it got tangled with an openssl transition as both of them 
needed to rebuild the same package: calibre. It took us more than a week to 
solve the issue, but hey, it's what packagers do :-) (sadly not for a living 
;-) )

Now if you break BC at, let's say, libqt5core5 we would need to rename it to 
something like libqt5core5abi1 and rebuild the whole stack of stuff using Qt. 
The list of the example above would probably crawl to level 7 with quite some 
more packages on each level.

A transition like that would definitely take like a month, in which no other 
transition will probably be able to happen because Qt is *so* widely used.

> while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
> 
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

No.
 
> > That's the worth nightmare we distro maintainers can dream
> > on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

As I described above: by stopping half a distribution to be updated by too 
much time.

> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.

We know and do understand this. But the side effects that it ships are not 
negligible too. We would suffer a lot from them.

-- 
Un viejo proverbio de El.Machi dice que la memoria es como
las papas fritas... ¡nunca sobran!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On terça-feira, 22 de novembro de 2016 01:06:00 PST André Pönitz wrote:
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

Fundamentally, no. But the important difference is the bottleneck.

I remember in the MeeGo days when building MeeGo with OBS spent an hour on a 
very beefy machine compiling Qt, with most of the resources in the OBS farm 
unused because nothing else could be built yet. With Qt 5 and our split 
packages, this lessens because only qtbase is the bottleneck.

> I understand that.
> 
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.

Again, a matter of scale. And note you said "rebuilding an application", not 
"rebuilding all KF5 and other domain libraries, then the application".

In addition, the ability to upgrade just Qt and then retest already-built 
libraries and applications allows us and distros to detect regressions and 
other issues. There's no need to rebuild everything in order to see what 
happens.

> > That's the worth nightmare we distro maintainers can dream
> > on. And yes, we would need to adjust Qt's SONAME on each change.
> 
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?

End users who don't develop, sure. 

If they develop something, then their self-built libraries will break and need 
to be rebuilt. I've since stopped building KDE from sources, but that used to 
be a problem with libraries that broke ABI. ICU and Boost come to mind: after 
a system upgrade, many applications would fail to load (to the point of not 
having a desktop at all) because the older versions of the system packages for 
those libs got removed in the system upgrade until I rebuilt the world. 
Granted, this can be fixed by not removing those packages during system 
upgrade.

> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I can't think of anything that would be worth the major headache that breaking 
BC more often than once every 4 years would cause. And note I'm not talking 
about breaking SC.

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 23:18:08 PST Marco Bubke wrote:
> I strongly agree with Andre'. And is a BC break in the time of flat pack
> that bad? As an user I really looking forward to flat pack,  so I can
> update my heavily used Applications and being not dependent on
> distribution. This package could be much better optimize with LTO and
> profile guided optimization. Maybe sharing everything is not that smart
> anymore.

FlatPaks don't work for Qt.

Reasons:

/usr/lib64/qt5/plugins/styles/breeze.so
/usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so

If you include Qt in your flatpak or equivalent, then your Qt application will 
not load the system plugins and will thus not have native look and feel in a 
Plasma desktop or in LXQt.

If you don't include Qt or if the included Qt loads plugins, then BC is 
required.

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Thiago Macieira]

On segunda-feira, 21 de novembro de 2016 19:36:43 PST Lisandro Damián Nicanor 
Pérez Meyer wrote:
> > So how often do you had a BC break in stdlibc++?
> 
> Last time was with gcc5.

In other words, once in 11 years.

> And quite messy in some concerns too because they did not increase the
> SONAME
> as they should, so the only thing we had is to track which apps/libs got
> rebuilt. Normally we can track this with a proper SONAME change.

Because GCC developers, like the proponents of inline namespaces, forget that 
libraries use their libraries and thus expose their ABI differences in their 
ABI. GCC devs invented the "abi_tag" attribute so they could mark methods 
according to a deveoper-defined tag, and propagate that tag. They provide both 
sets of ABIs in libstdc++.

But unless developers of downstream libraries take the precautions to provide 
them both in their own libraries, this causes a BC breakage. THAT was the 
issue.

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

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

On November 21, 2016 23:57:07 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
>> [snip]
>> > - people using Qt in applications distributed by packaging
>> >   systems (read "Linux distributions"). They are not affected
>> >   by BC breakages.
>> 
>> Users might not notice if we maintainers have to deal with this nightmare.
>
> That's what I said.
>
> I also said that packagers (i.e. people like you) *are* affected, but I
> claimed the way they are affected is not fundamentally different from
> what happens if the packages in question uses any other library that
> doesn't guarantee BC, or - in case they have similar BC promises like Qt
> - what happens when there are jumps in major versions.

And how many applications are Qt only and use no standard lib anyway? Are there 
any numbers? Yes, sometimes they are inlined but sometimes they are not. Is it 
really a so big burden for you? And what are you doing about GTK? To my 
knowledge their BC is quite limit. 

>> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
>> lib break ABI we need to get Qt rebuilt and *everything* building
>> against it.
>
> I understand that.
>
> What I do not understand is how rebuilding an application can be
> considered a significant burden while running a full test cycle (Qt
> doesn't guarantee behavioural compatibility between versions, any
> versions for that matter) is not.
>
> I fear that the answer is something along the lines of "we
> might run a smoke test, but no more", isn't it?

You can capture behavior changes by unit and integration tests but there is 
always the possibility that you break something because the complexity is not 
reasonable testable. It's always a tradeoff. 

>> That's the worth nightmare we distro maintainers can dream
>> on. And yes, we would need to adjust Qt's SONAME on each change.
>
> That's maybe one per year. With a typical distro running, say, two
> bigger updates per year replacing most packages anyway, that would
> ill-affect a distro user... how?
>
> I am not here trying to make your life harder. I do understand that you
> would be on the receiving end in case Qt BC guarantees are lowered. I
> believe I understand the effort packagers invest, and the benefit this
> has for the Qt ecosystem. But the BC guarantee comes at quite some
> price like the inability to fix certain mistakes that slipped into some
> x.0 release, or to use certain features that only became usable a some
> x.5 time, and this price is payed both by developers and end users.
>
> This is not a zero-sum game, there's room for total improvement, and
> since BC is not the only thing packagers care for a loss of BC could
> possibly get compensated by something dev can influence. At the very
> least I see no reason to forbid thinking about it.

I strongly agree with Andre'. And is a BC break in the time of flat pack that 
bad? As an user I really looking forward to flat pack,  so I can update my 
heavily used Applications and being not dependent on distribution. This package 
could be much better optimize with LTO and profile guided optimization. Maybe 
sharing everything is not that smart anymore. 

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[André Pönitz]

On Mon, Nov 21, 2016 at 03:49:49PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> [snip]
> > - people using Qt in applications distributed by packaging
> >   systems (read "Linux distributions"). They are not affected
> >   by BC breakages.
> 
> Users might not notice if we maintainers have to deal with this nightmare.

That's what I said.

I also said that packagers (i.e. people like you) *are* affected, but I
claimed the way they are affected is not fundamentally different from
what happens if the packages in question uses any other library that
doesn't guarantee BC, or - in case they have similar BC promises like Qt
- what happens when there are jumps in major versions.

> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt
> lib break ABI we need to get Qt rebuilt and *everything* building
> against it.

I understand that.

What I do not understand is how rebuilding an application can be
considered a significant burden while running a full test cycle (Qt
doesn't guarantee behavioural compatibility between versions, any
versions for that matter) is not.

I fear that the answer is something along the lines of "we
might run a smoke test, but no more", isn't it?

> That's the worth nightmare we distro maintainers can dream
> on. And yes, we would need to adjust Qt's SONAME on each change.

That's maybe one per year. With a typical distro running, say, two
bigger updates per year replacing most packages anyway, that would
ill-affect a distro user... how?

I am not here trying to make your life harder. I do understand that you
would be on the receiving end in case Qt BC guarantees are lowered. I
believe I understand the effort packagers invest, and the benefit this
has for the Qt ecosystem. But the BC guarantee comes at quite some
price like the inability to fix certain mistakes that slipped into some
x.0 release, or to use certain features that only became usable a some
x.5 time, and this price is payed both by developers and end users.

This is not a zero-sum game, there's room for total improvement, and
since BC is not the only thing packagers care for a loss of BC could
possibly get compensated by something dev can influence. At the very
least I see no reason to forbid thinking about it.

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 19:36:43 ART Lisandro Damián Nicanor Pérez 
Meyer wrote:
> On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote:
> > So how often do you had a BC break in stdlibc++?
> 
> Last time was with gcc5. We've got a nice big [transition] within Debian due
> to it. It was related to C++11 stuff, and we've got away precisely because
> Qt doesn't expose it.

Forgot to mention: begginging of 2016 if I remember correctly.

-- 
La ciencia sin la religión es renga, la religión sin la ciencia es ciega.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 20:47:31 ART Marco Bubke wrote:
> So how often do you had a BC break in stdlibc++?

Last time was with gcc5. We've got a nice big [transition] within Debian due 
to it. It was related to C++11 stuff, and we've got away precisely because Qt 
doesn't expose it.

And quite messy in some concerns too because they did not increase the SONAME 
as they should, so the only thing we had is to track which apps/libs got 
rebuilt. Normally we can track this with a proper SONAME change.

[transition] the required work to get stuff rebuilt against a lib changing 
SONAME (or breaking ABI without changing it) in the whole Debian archive and 
let the affected packages migrate to testing in the same go.

-- 
The generation of random numbers is too important to be left to chance.
  http://www.devtopics.com/best-programming-jokes/

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 20:02:54 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote:
>> Giuseppe D'Angelo:
>> >> I would also like to point out that, despite we have a repository, we
>> >> still don't have a tool for properly discussing the actual content of
>> >> QUIPs.
>> >>
>> >> * Gerrit does not work because comments cannot be threaded, they
>> >>   don't stick to multiple reviews, and they can be ignored
>> >> * Email does not work (it may work for the overall direction, but not
>> >>   for the in depth discussion) because a single message may cover
>> >>   multiple discussion points, disrupting the threading, and
>> >>   discussion points can get ignored (*)
>> 
>> All of which plays into my desire to introduce you all to Critic [0]
>
> Guys,
>
> the idea of QUIPs was to *fix* a problem, namely the current inability
> to pinpoint results of mailing list discussion. This *is* a problem for
> the Project, as lazy consensus on the mailing list is *the* official
> decision making process in the Qt Governance model, but it works in
> practice rather accidentally, if at all.
>
> Discussions are observed to deteriorate, develop into completely
> unrelated discussions, and even if something appears like consensus or
> the discussion dies, it typically turns out that different people think
> differently about what the consensus actually was, and the discussion
> re-starts half a year later.
>
> You both nicely demonstrate that this problem exist, thank you for that,
> but beyond that this particular sub-discussion misses the point.
> QUIPs were not meant to require new or different tooling, and I still
> believe such will be needed.
>
> The rough idea is that a topic is presented as usual on the mailing
> list, and when someone, usually the original proponent, gets the feeling
> that the usual rounds of bike-shedding, trolling and name-calling is
> over, and the occasional sensible arguments all have been heard, writes
> up what appears like a potential consensus and puts that on Gerrit,
> where some review process commences.
>
> The only difference to a normal review process I'd like to see would be
> a *much* higher bar for approval, to ensure that QUIPs are really close
> to consensus and to ensure some consistency within the set of QUIPs.
>
> None of this requires new tools, certainly not the bootstrapping of
> the first QUIP. There's also nothing changing processes, so everybody
> will be free to continue to present his views on his favourite tools
> in the future, but for now I'd really like to get this here done.
>
> IMNSHO it boils down to the question: Does anybody have any fundamental
> problem with main idea of having documents summarizing the lazy consensus
> of certain mailing list discussions? If not I'd call that a lazy
> consensus and would ask to proceed with reviewing the final wording
> on Gerrit.
>

I think it's modeled after Python PEP and RFCs? Do we have a first QUIP who is 
describing the process? 

I think we should copy a successful model like 
https://www.python.org/dev/peps/pep-0001/ and don't try to be smarter.

And yes, I don't think document a random email conversation is the answer. 

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Alejandro Exojo]

On Saturday 19 November 2016 21:08:00 Kevin Kofler wrote:
> I am glad that I am not alone with that feeling.
> 
> And by the way, with my distribution packager hat on, I have to frown upon
> the idea of dragging in yet another dependency just to enforce the C++
> language inventor's personal, not uncontroversial stylistic preferences.

Have you seen the size of the GSL? I think I skimmed in one go through all the 
source code when it was published, and I did it while commuting, on a mobile 
phone. Maybe it's a tad larger now, but according to Mark's comment, stuff 
like owner could even be bundled/reimplemented.

I'm almost always on the side that would not like Qt to change at all if it's 
to make it similar to the standard library API, but I've always had in the 
mental to-do list some patch to Qt that would annotate when ownership of 
QObjects is transferred ("I guess the QNetworkReply returned by QNAM::post has 
a parent, because the docs don't say it should be deleted... Or should be?").

I though that qdoc would be the tool for this (like we have \threadsafe) but 
stuff like owner<> and not_null<> are IMHO vastly superior. And at least they 
chose reasonable names for these. :)

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marco Bubke]

So how often do you had a BC break in stdlibc++? 


On November 21, 2016 19:50:23 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
> [snip]
>> - people using Qt in applications distributed by packaging
>>   systems (read "Linux distributions"). They are not affected
>>   by BC breakages.
>
> Users might not notice if we maintainers have to deal with this nightmare.
>
> If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib 
> break 
> ABI we need to get Qt rebuilt and *everything* building against it. That's 
> the 
> worth nightmare we distro maintainers can dream on. And yes, we would need to 
> adjust Qt's SONAME on each change.
>
> -- 
> Yo quiero conocer el pensamiento de Dios, el resto son detalles.
>  Albert Einstein
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Pönitz]

On Mon, Nov 21, 2016 at 03:29:01PM +0300, Konstantin Tokarev wrote:
> 
> 
> 21.11.2016, 15:26, "Giuseppe D'Angelo" :
> > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
> >  wrote:
> >>>  Any idea to how to actually make this work?
> >>  how about taking the existing processes seriously and exercising social
> >>  pressure on those who think they are above them?
> >
> > May I just say that prefer a tool that mandates a workflow over using
> > political and social pressures, which in the long term hurt the
> > project?
> 
> Well, tools cannot help with social issues, and ignoring review comments is
> more like the latter.

Well, right, and wrong, kind of ;-)

I think tools can help to *prevent* social issues. As example, I think it
easier for people to accept a -1 from the Sanity Bot than to accept
exactly the same comment from a human reviewer, specifically when it
comes to arbitrary choices like prefering American over British spelling
in comments. With the bot I usually just swallow and "fix" the issue,
no matter how insane it appears to me.

Sounds irrational? It is. It is human. 

Andre'

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Pönitz]

On Mon, Nov 21, 2016 at 11:06:52AM +, Edward Welbourne wrote:
> Giuseppe D'Angelo:
> >> I would also like to point out that, despite we have a repository, we
> >> still don't have a tool for properly discussing the actual content of
> >> QUIPs.
> >>
> >> * Gerrit does not work because comments cannot be threaded, they
> >>   don't stick to multiple reviews, and they can be ignored
> >> * Email does not work (it may work for the overall direction, but not
> >>   for the in depth discussion) because a single message may cover
> >>   multiple discussion points, disrupting the threading, and
> >>   discussion points can get ignored (*)
> 
> All of which plays into my desire to introduce you all to Critic [0]

Guys,

the idea of QUIPs was to *fix* a problem, namely the current inability
to pinpoint results of mailing list discussion. This *is* a problem for
the Project, as lazy consensus on the mailing list is *the* official
decision making process in the Qt Governance model, but it works in
practice rather accidentally, if at all.

Discussions are observed to deteriorate, develop into completely
unrelated discussions, and even if something appears like consensus or
the discussion dies, it typically turns out that different people think
differently about what the consensus actually was, and the discussion
re-starts half a year later.

You both nicely demonstrate that this problem exist, thank you for that,
but beyond that this particular sub-discussion misses the point.
QUIPs were not meant to require new or different tooling, and I still
believe such will be needed.

The rough idea is that a topic is presented as usual on the mailing
list, and when someone, usually the original proponent, gets the feeling
that the usual rounds of bike-shedding, trolling and name-calling is
over, and the occasional sensible arguments all have been heard, writes
up what appears like a potential consensus and puts that on Gerrit,
where some review process commences.

The only difference to a normal review process I'd like to see would be
a *much* higher bar for approval, to ensure that QUIPs are really close
to consensus and to ensure some consistency within the set of QUIPs.

None of this requires new tools, certainly not the bootstrapping of
the first QUIP. There's also nothing changing processes, so everybody
will be free to continue to present his views on his favourite tools
in the future, but for now I'd really like to get this here done.

IMNSHO it boils down to the question: Does anybody have any fundamental
problem with main idea of having documents summarizing the lazy consensus
of certain mailing list discussions? If not I'd call that a lazy
consensus and would ask to proceed with reviewing the final wording
on Gerrit.

Andre' 

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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Lisandro Damián Nicanor Pérez Meyer]

On domingo, 20 de noviembre de 2016 12:53:11 ART André Pönitz wrote:
[snip]
> - people using Qt in applications distributed by packaging
>   systems (read "Linux distributions"). They are not affected
>   by BC breakages.

Users might not notice if we maintainers have to deal with this nightmare.

If Qt exposes a non-Qt lib trough it's API then whenever that non-Qt lib break 
ABI we need to get Qt rebuilt and *everything* building against it. That's the 
worth nightmare we distro maintainers can dream on. And yes, we would need to 
adjust Qt's SONAME on each change.

-- 
Yo quiero conocer el pensamiento de Dios, el resto son detalles.
 Albert Einstein

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review

[Nikolaus Waxweiler]

> Here is a proof of concept: https://codereview.qt-project.org/#/c/177325/

Oh nice, didn't expect something so soon. Will have a look.

> Note, we need a FreeType API for getting to the module-name from the face, or 
> a direct getter of the stem-darkening on the face. 

Ah, hm. I only know of a way from within the FT source. Will get back to
you.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] HEADS-UP: Branching from '5.8' to '5.8.0' started

[Jani Heikkinen]

Hi,
We have started branching from '5.8' to '5.8.0'. Please start using '5.8.0' for 
new changes targeted to Qt 5.8.0 release. There should be enough time to 
finalize ongoing changes in '5.8'; final downmerge will happen Monday 28th 
November.

br,
Jani



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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 14:29:10 Shawn Rutledge  wrote:

>
>> On 21 Nov 2016, at 12:06, Edward Welbourne  wrote:
>> 
>> Giuseppe D'Angelo:
 I would also like to point out that, despite we have a repository, we
 still don't have a tool for properly discussing the actual content of
 QUIPs.
 
 * Gerrit does not work because comments cannot be threaded, they
  don't stick to multiple reviews, and they can be ignored
>> 
>> [0] https://github.com/jensl/critic
>> 
>> I would dearly love to replace Gerrit with it - I realise that's hoping
>> for too much - but, for a new repository on which Gerrit isn't adequate,
>> maybe we could consider it …
>
> Maybe it’s worth a try.  But someone has to install it on a server so that we 
> can try it, right?  Is that easy enough?

Yes, some server for evaluation would be nice. 

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Shawn Rutledge]

> On 21 Nov 2016, at 12:06, Edward Welbourne  wrote:
> 
> Giuseppe D'Angelo:
>>> I would also like to point out that, despite we have a repository, we
>>> still don't have a tool for properly discussing the actual content of
>>> QUIPs.
>>> 
>>> * Gerrit does not work because comments cannot be threaded, they
>>>  don't stick to multiple reviews, and they can be ignored
> 
> [0] https://github.com/jensl/critic
> 
> I would dearly love to replace Gerrit with it - I realise that's hoping
> for too much - but, for a new repository on which Gerrit isn't adequate,
> maybe we could consider it …

Maybe it’s worth a try.  But someone has to install it on a server so that we 
can try it, right?  Is that easy enough?

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 13:51:10 Oswald Buddenhagen  
wrote:

> On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
>> On November 21, 2016 12:58:59 Oswald Buddenhagen  
>> wrote:
>> > how about taking the existing processes seriously and exercising social
>> > pressure on those who think they are above them?
>> 
>> Sorry, not everybody likes to use social pressure (mobbing).
>>
> the thing is that there there is no tooling which is absolutely
> foolproof. people will always come up with creative ways to
> circumvent it, and the only way to deal with that is showing them that
> doing so is not acceptable. it's a bit of a stretch to call that
> mobbing, and i gladly laugh it off when it happens.

But you see that a tool who makes it easy to snippet on some argument is maybe 
more suboptimal than other. It's not about using the perfect tool but using one 
which is better. Ones that sets 'loud'  people at a disadvantage. And it's not 
only the tool,  it's the culture too. A culture which is appreciating new 
arguments and not loves to repeat arguments again and again, especially to hide 
some private agenda. If an argumentation is more about individual agendas and 
less about the common good it is doomed.  Especially if people try to sell the 
first as last. The tool should help to make that transparent but it is only one 
building stone. 

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
> On November 21, 2016 12:58:59 Oswald Buddenhagen  
> wrote:
> > how about taking the existing processes seriously and exercising social
> > pressure on those who think they are above them?
> 
> Sorry, not everybody likes to use social pressure (mobbing).
>
the thing is that there there is no tooling which is absolutely
foolproof. people will always come up with creative ways to
circumvent it, and the only way to deal with that is showing them that
doing so is not acceptable. it's a bit of a stretch to call that
mobbing, and i gladly laugh it off when it happens.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Font rendering on X11/Wayland: New FreeType API to toggle LCD filters and stem darkening on a per-font basis, would love a review

[Allan Sandfeld Jensen]

Here is a proof of concept: https://codereview.qt-project.org/#/c/177325/

Note, we need a FreeType API for getting to the module-name from the face, or 
a direct getter of the stem-darkening on the face. 

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 12:58:59 Oswald Buddenhagen  
wrote:

> On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote:
>> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen 
>>  wrote:
>> > the repository has been created.
>> 
>> I would also like to point out that, despite we have a repository, we
>> still don't have a tool for properly discussing the actual content of
>> QUIPs.
>> 
>> * Gerrit does not work because comments cannot be threaded,
>>
> when you use inline comments, the locality is good enough to
> make threading generally unnecessary.
>
>> they don't stick to multiple reviews,
>>
> this is true, but becomes a real problem only if the change owner
> doesn't bother handling all comments before pushing new changesets.
>
>> and they can be ignored
>>
> that's correct, and having real issue tracking would be advantageous
> (which gerrit upstream knows very well).
> otoh, it's the responsibility of the reviewers and the submitter (a role
> we have intentionally restricted in this repo, mind you) to verify that
> all comments have been (actually) acted upon.
>
>> Any idea to how to actually make this work?
>> 
> how about taking the existing processes seriously and exercising social
> pressure on those who think they are above them?

Sorry, not everybody likes to use social pressure (mobbing). And could it be 
that the outcome of the argumentation is be quite different of what we would 
describe as good in the long run. My impression is generally that many smart 
people don't like too spend their time for that games. But people who thinks 
that their arguments are smarter think that they deserve to be chosen. 

Or let our describe it that way,  the rationality of people is quite limited 
and you need a good framework to get a better outcome. You can easily derail 
cooperation with a dysfunctional framework. Is shown in many experiments and 
believe me, we are not different. Actually people who working in IT have more 
trouble because they often describe the world  not as contingent but as based 
on a all-time, universal fundament (truth). So it's hard to compromise because 
that would be deviate from truth. If the discussion is based on experience it 
is actually quite positive to compromise because all arguments together give a 
bigger picture, based on much more experience. 

So the truth based world description leds to few 'specialists' discuss that 
matter but the latter is a cooperation of all people with experience about that 
matter. Neither is guaranteed to succeed but if you get the last in a 
cooperative mode you have a good chance. 

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Konstantin Tokarev]

21.11.2016, 15:26, "Giuseppe D'Angelo" :
> On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
>  wrote:
>>>  Any idea to how to actually make this work?
>>  how about taking the existing processes seriously and exercising social
>>  pressure on those who think they are above them?
>
> May I just say that prefer a tool that mandates a workflow over using
> political and social pressures, which in the long term hurt the
> project?

Well, tools cannot help with social issues, and ignoring review comments is
more like the latter.

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Giuseppe D'Angelo]

On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
 wrote:
>> Any idea to how to actually make this work?
>>
> how about taking the existing processes seriously and exercising social
> pressure on those who think they are above them?

May I just say that prefer a tool that mandates a workflow over using
political and social pressures, which in the long term hurt  the
project?

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote:
> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen 
>  wrote:
> > the repository has been created.
> 
> I would also like to point out that, despite we have a repository, we
> still don't have a tool for properly discussing the actual content of
> QUIPs.
> 
> * Gerrit does not work because comments cannot be threaded,
>
when you use inline comments, the locality is good enough to
make threading generally unnecessary.

> they don't stick to multiple reviews,
>
this is true, but becomes a real problem only if the change owner
doesn't bother handling all comments before pushing new changesets.

> and they can be ignored
>
that's correct, and having real issue tracking would be advantageous
(which gerrit upstream knows very well).
otoh, it's the responsibility of the reviewers and the submitter (a role
we have intentionally restricted in this repo, mind you) to verify that
all comments have been (actually) acted upon.

> Any idea to how to actually make this work?
> 
how about taking the existing processes seriously and exercising social
pressure on those who think they are above them?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

Giuseppe D'Angelo:
>> I would also like to point out that, despite we have a repository, we
>> still don't have a tool for properly discussing the actual content of
>> QUIPs.
>>
>> * Gerrit does not work because comments cannot be threaded, they
>>   don't stick to multiple reviews, and they can be ignored
>> * Email does not work (it may work for the overall direction, but not
>>   for the in depth discussion) because a single message may cover
>>   multiple discussion points, disrupting the threading, and
>>   discussion points can get ignored (*)

All of which plays into my desire to introduce you all to Critic [0], a
code-review tool my former colleague Jens wrote at Opera.  It knows how
to carry comments forward from one patch set to another, even through
rebases (within limits), it knows the range of lines a comment relates
to, it distinguishes issues (which must be resolved) from comments
(which can be discussed).  Discussions on a particular issue are linear
- i.e. forking off side-threads to separately discuss different parts of
a comment or follow-up would need to be implemented.  It handles whole
branches, making it possible to review a set of related changes
together; the reviewer can chose whether to review all changes to a file
together or each commit's changes separately; it helps keep track of
what you have reviewed so that you can tell when you're done.

[0] https://github.com/jensl/critic

I would dearly love to replace Gerrit with it - I realise that's hoping
for too much - but, for a new repository on which Gerrit isn't adequate,
maybe we could consider it ...

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marc Mutz]

On Sunday 20 November 2016 20:29:01 Giuseppe D'Angelo wrote:
> On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira
> 
>  wrote:
> > Can you remember the list of C++11 features we're allowed to use? We had
> > a discussion on the mailing list.
> 
> Going back to this particular point: so should this list go into the
> QUIPs repository, or in qtbase? (The idea of putting it in qtbase was
> to re-use the same branching scheme, so for a given branch you can
> know which features you are allowed to use).

IMHO, we need a QUIP that says where in each Qt module such a file should be 
located, what its format is, what the process is to update it, whether it 
should be machine-readable (read: run from configure checks), etc.

Neither the wiki, nor the QUIP itself is the place to put the actual lists.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marc Mutz]

On Monday 21 November 2016 09:37:38 Philippe wrote:
> > And you think Qt provides what MS added to std::vector here, in QVector?
> 
> Of course not. I just point the danger of dependencies on the usage of STL
> APIs, especially corner APIs.
> 
> I understand the #1 target of Qt is to behave the same on all platforms
> (as much as possible...). This is what users expects, at least.

These fixes mostly sound like they were enabled by - finally - implementing 
missing core C++11 features. We know we can't rely on MS to provide all C++11 
features atm, so we know not to rely on std::vector using 
std::move_if_noexcept, e.g., too. The aliasing thing, though, sounds like a 
genuine bug, and GCC's nth_element was buggy for some time, too.

OTOH, QList does not at all behave the same on different platforms, 
either, in a much more fundamental way than any std::vector behaviour differs 
between platforms these days.

People make mistakes. The difference is that, in the STL, by way of a larger 
target audience, mistakes tend to be fewer than in Qt (looked at 
qtimageformats, lately?), and more easily fixed, because of largely no BC 
support, so it seems a bit skewed to throw one such STL bug on the table as an 
argument not to use the STL.

If Qt consistently did a better job at implementing such things, the world 
might be different. But looking at the Qt containers, and the Qt image format 
plugins, I'd much rather use an external library (STL, lib{jpeg,png,tiff,...) 
that everyone else also uses, than to reinvent the wheel and create bugs 
exclusive to Qt.

Thanks,
Marc

> Philippe
> 
> On Mon, 21 Nov 2016 09:04:59 +0100
> 
> Marc Mutz  wrote:
> > On Sunday 20 November 2016 23:20:11 Philippe wrote:
> > > On Sun, 20 Nov 2016 19:49:09 +0100
> > > 
> > > Marc Mutz  wrote:
> > > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL,
> > > > but failed to take advantage of the STL containers,
> > > 
> > > ...good that STL containers were not used... Look at _this month_
> > > Visual Studio 2017 announcement:
> > > 
> > > 
> > > std::vector has been overhauled for correctness and performance:
> > > aliasing during insertion/emplacement is now correctly handled as
> > > required by the Standard, the strong exception guarantee is now
> > > provided when required by the Standard via move_if_noexcept() and
> > > other logic, and
> > > insertion/emplacement perform fewer element operations.
> > > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> > > 
> > > 
> > > Being the "standard library" does not mean "bug free and equal on all
> > > platforms". Dependencies with other libraries must be careful checked.
> > 
> > And you think Qt provides what MS added to std::vector here, in QVector?
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Philippe]

> And you think Qt provides what MS added to std::vector here, in QVector?

Of course not. I just point the danger of dependencies on the usage of STL APIs,
especially corner APIs.

I understand the #1 target of Qt is to behave the same on all platforms
(as much as possible...). This is what users expects, at least.

Philippe

On Mon, 21 Nov 2016 09:04:59 +0100
Marc Mutz  wrote:

> On Sunday 20 November 2016 23:20:11 Philippe wrote:
> > On Sun, 20 Nov 2016 19:49:09 +0100
> > 
> > Marc Mutz  wrote:
> > > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but
> > > failed to take advantage of the STL containers,
> > 
> > ...good that STL containers were not used... Look at _this month_ Visual
> > Studio 2017 announcement:
> > 
> > 
> > std::vector has been overhauled for correctness and performance: aliasing
> > during insertion/emplacement is now correctly handled as required by the
> > Standard, the strong exception guarantee is now provided when required by
> > the Standard via move_if_noexcept() and other logic, and
> > insertion/emplacement perform fewer element operations.
> > (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> > 
> > 
> > Being the "standard library" does not mean "bug free and equal on all
> > platforms". Dependencies with other libraries must be careful checked.
> 
> And you think Qt provides what MS added to std::vector here, in QVector?
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marc Mutz]

On Sunday 20 November 2016 23:20:11 Philippe wrote:
> On Sun, 20 Nov 2016 19:49:09 +0100
> 
> Marc Mutz  wrote:
> > I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but
> > failed to take advantage of the STL containers,
> 
> ...good that STL containers were not used... Look at _this month_ Visual
> Studio 2017 announcement:
> 
> 
> std::vector has been overhauled for correctness and performance: aliasing
> during insertion/emplacement is now correctly handled as required by the
> Standard, the strong exception guarantee is now provided when required by
> the Standard via move_if_noexcept() and other logic, and
> insertion/emplacement perform fewer element operations.
> (https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes)
> 
> 
> Being the "standard library" does not mean "bug free and equal on all
> platforms". Dependencies with other libraries must be careful checked.

And you think Qt provides what MS added to std::vector here, in QVector?

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development