On søndag 2. juni 2019 11:50:35 CEST Volker Hilsheimer wrote:
> > On 1 Jun 2019, at 16:12, Alberto Mardegan
> > wrote:
> > On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
> >
> >> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
> >> three years maintenance. We are not
On Wed, Jun 5, 2019 at 9:44 PM André Pönitz wrote:
> On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote:
> > 2. Delete all uses of the deprecated API from Qt itself
>
> ... and that *before* the deprecation happens.
>
> Lately the deprecations left Qt in a state that was
On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote:
> = The meaning of deprecation
>
> I think of deprecation as a means to tell users that the designers of the
> deprecated API think that there is some deep flaw in the API that makes it
> harder to use correctly or easier
On Wednesday, 5 June 2019 06:31:25 PDT Olivier Goffart wrote:
> That's where inline namespaces could help. (You'd change the name of the
> inline namespace as well so you could link to two libraries that use
> different version of Qt, and it would work. (as long as each of these
> library don't
On 05.06.19 07:24, Thiago Macieira wrote:
On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
$ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME
SONAME libQt5Core.so.5
Note the two numbers in the SONAME. They mean two
On Wed, Jun 5, 2019 at 12:57 AM Kevin Kofler wrote:
> IMHO, major versions with source compatibility need to actually
> live
> much LONGER, not shorter. At least 20-30 years, with the time at least
> doubling with every new major release. Or just stop doing compatibility
> breaks entirely.
>
On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME
> SONAME libQt5Core.so.5
Note the two numbers in the SONAME. They mean two different thing. Right now,
they are equal but
Konstantin Shegunov wrote:
> What about shortening the major version release time, instead of changing
> the whole model?
IMHO, major versions with source compatibility need to actually live
much LONGER, not shorter. At least 20-30 years, with the time at least
doubling with every new major
What about shortening the major version release time, instead of changing
the whole model?
Say we keep the current model, but instead of doing a major release once in
6-7 years, we fix that to 3 years with two LTS releases - one 1.5 years in,
and then the last minor version before the major
Hi!
On Tue, 4 Jun 2019 at 13:46, Mutz, Marc via Development
wrote:
>
> Hi,
>
> This is not meant to be a summary of the thread so far, but the
> definition of a possible solution space:
>
> = The meaning of deprecation
>
> I think of deprecation as a means to tell users that the designers of
>
Hi,
This is not meant to be a summary of the thread so far, but the
definition of a possible solution space:
= The meaning of deprecation
I think of deprecation as a means to tell users that the designers of
the deprecated API think that there is some deep flaw in the API that
makes it
Il 03/06/19 23:04, Kevin Kofler ha scritto:
Giuseppe D'Angelo via Development wrote:
Also, please name me 3 GUI frameworks that have not broken APIs for 30
years.
Also also, please name me 3 libraries that have not broken APIs for the
30 years.
There is at least one (almost): Win32 has now
Giuseppe D'Angelo via Development wrote:
> Also, please name me 3 GUI frameworks that have not broken APIs for 30
> years.
>
> Also also, please name me 3 libraries that have not broken APIs for the
> 30 years.
There is at least one (almost): Win32 has now existed for 26 years without
an ABI
On Monday, 3 June 2019 06:26:36 PDT Giuseppe D'Angelo via Development wrote:
> > QList::prepend has O(1) amortized and O(n) worst case time complexity.
> > QVector::prepend has O(mn) (always!) time complexity.
> >
> > If you are dealing with a large class or struct, e.g. 800 bytes, then the
> >
On Monday, 3 June 2019 04:34:27 PDT Kevin Kofler wrote:
> Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete" x86
> instructions from their CPUs! x86 has kept backwards compatibility with
> every single instruction for more than 30 years.
And yet, we can look at this
On Monday, 3 June 2019 01:50:26 PDT Giuseppe D'Angelo via Development wrote:
> At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus
> a couple of pointers or so, to bring it to 64 bytes (~ a cacheline).
The minimum size for a QString is 3 pointers, which would be 12 bytes on
> On 3 Jun 2019, at 13:34, Kevin Kofler wrote:
>>> I'd rather get fewer (or even no) new features than losing existing ones.
>>
>> How is this even an argument? Qt will need to evolve and acquire
>> features to remain competitive. Again, development bandwidth is finite:
>> either the overall
Il 03/06/19 13:34, Kevin Kofler ha scritto:
Giuseppe D'Angelo via Development wrote:
Il 03/06/19 00:08, Kevin Kofler ha scritto:
What you call "obsolete functionality" is functionality that existing
code relies on and rightfully expects to remain there.
Rightfully? By what right exactly?
On 6/3/19 1:34 PM, Kevin Kofler wrote:
So I disagree with the assertion that Qt needs more features to
remain competitive.
Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that
does not make use of the graphics hardware, is begging for being replaced.
Quick Controls 1 was
> APIs in libraries are meant to be used. I consider it an entirely reasonable
> expectation by developers using the APIs that they will not be removed under
> them because the library developers consider them "obsolete". Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete"
Giuseppe D'Angelo via Development wrote:
> Il 03/06/19 00:08, Kevin Kofler ha scritto:
>> What you call "obsolete functionality" is functionality that existing
>> code relies on and rightfully expects to remain there.
>
> Rightfully? By what right exactly?
APIs in libraries are meant to be
On Sat, 1 Jun 2019 14:36:12 +0200
André Pönitz wrote:
> On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry
> > poorly designed architecture or APIs around with us throughout the Qt
> > 6 series, and as long as
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote:
How is this even an argument? Qt will need to evolve and acquire
features to remain competitive.
The probably most important module - Qt/Widgets - sits on a graphic
stack, that had been identified as not being competitive many
Going back to the beginning of the thread.
> On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> It seems to me that many emails in the earlier deprecation thread were from
> users concerned by the problem of removal of functionality. This is not an
> old story.
> On 3 Jun 2019, at 08:00, Thiago Macieira wrote:
>
> On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote:
>> Well, something has to give. Either
>> a) Qt can never remove superseded APIs and classes (which is what
>> you suggested previously) and will eventually collapse under its own
>>
Il 03/06/19 00:08, Kevin Kofler ha scritto:
Ballast (obsolete functionality, for various degree of "obsolete") has
to be dropped from time to time, causing API breaks. The question in
this thread is how to manage those API breaks to be as painless as
possible.
What you call "obsolete
On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote:
> Well, something has to give. Either
> a) Qt can never remove superseded APIs and classes (which is what
> you suggested previously) and will eventually collapse under its own
> weight, or
> b) Distributors have to deal with the fact
On Sunday, 2 June 2019 16:39:24 PDT Kevin Kofler wrote:
> PS: Imagine the outcry and havoc if Intel decided to tell you, e.g.: "Sorry,
> x87 floating-point is obsolete and hard for us to maintain, we will drop it
> from our next generation of CPUs and force everybody to port their software
> to
On Sunday, 2 June 2019 15:29:11 PDT Manuel Bergler wrote:
> > Repeat after me: inline namespaces are not a tool to retain ABI.
>
> Of course they are. That's the reason they were introduced [0]: To
> allow symbol versioning as part of the language without having to
> write linker scripts, thus
Am Mo., 3. Juni 2019 um 02:21 Uhr schrieb Konstantin Shegunov
:
>
> On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote:
>>
>> Why should software be different?
>
>
> It shouldn't, as already pointed out. That's why well behaved libraries try
> to keep compatibility in some reasonable margins.
>
On Mon, Jun 3, 2019 at 2:10 AM Manuel Bergler wrote:
> Why should software be different?
It shouldn't, as already pointed out. That's why well behaved libraries try
to keep compatibility in some reasonable margins.
To throw one more stone here - are you willing to backport patches from
latter
Am Mo., 3. Juni 2019 um 01:35 Uhr schrieb Kevin Kofler :
>
> Manuel Bergler wrote:
> > And this is where we come full circle :) Yes, FOSS needs to port, so
> > we should make porting as easy as possible. In particular, there
> > shouldn't be too many breaking changes all at once as that would make
Kevin Kofler wrote:
> But we do have the expectation that the CPU will still run our 10-year-old
> code without having to recompile it. Modern CPUs are backwards-compatible
> with restrictions (e.g., you cannot use 16-bit code from a 64-bit OS, at
> least not without dangerous hacks) all the way
Manuel Bergler wrote:
> And this is where we come full circle :) Yes, FOSS needs to port, so
> we should make porting as easy as possible. In particular, there
> shouldn't be too many breaking changes all at once as that would make
> porting a multi-month project. Instead, spread out the breaking
Am Mo., 3. Juni 2019 um 01:20 Uhr schrieb Konstantin Tokarev
:
> 03.06.2019, 02:10, "Manuel Bergler" :
> > Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler
> > :
> >
> >> What you call "obsolete functionality" is functionality that existing code
> >> relies on and rightfully expects to
Manuel Bergler wrote:
> I fully disagree with the sentiment in that blog post. If you don't
> want to port, fine, but then also use whatever version of Qt you were
> using before and don't try to use the latest and greatest.
But that is a luxury we simply do not have in the Free Software world
03.06.2019, 02:10, "Manuel Bergler" :
> Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler
> :
>
>> What you call "obsolete functionality" is functionality that existing code
>> relies on and rightfully expects to remain there.
>>
>> I'd rather get fewer (or even no) new features than
Am Mo., 3. Juni 2019 um 00:09 Uhr schrieb Kevin Kofler :
> What you call "obsolete functionality" is functionality that existing code
> relies on and rightfully expects to remain there.
>
> I'd rather get fewer (or even no) new features than losing existing ones.
>
> See also Boudewijn Rempt's
Am So., 2. Juni 2019 um 18:56 Uhr schrieb Lisandro Damián Nicanor
Pérez Meyer :
>
> Hi! With my Debian maintainer hat on:
>
> On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote:
> >
> > Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler
> > :
> >>
> >> Volker Hilsheimer wrote:
> [snip]
> >>
Am So., 2. Juni 2019 um 19:18 Uhr schrieb Thiago Macieira
:
>
> On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote:
> > First of all, Qt itself
> > could make use of inline namespaces to ship several version of the same
> > classes in the same binary while keeping source compatibility.
>
>
Manuel Bergler wrote:
> I myself don't mind the 2 weeks it took so far to upgrade from Qt 5.9 to
> Qt 5.12 in our project, that's just the cost of progress...
I guess one of the reasons that you are feeling more migration pain than the
FOSS projects is because you skip all the non-LTS branches,
Lisandro Damián Nicanor Pérez Meyer wrote:
> Boost is **exactly** the best example of why Qt should not go the same
> route. It's totally problematic to have more than two stacks around,
> and we **will** have Qt5 and Qt6 for a long time.
In fact, Fedora even still ships Qt 3 and Qt 4 and they
On Sun, 2 Jun 2019 at 13:59, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote:
> [snip]
> > >
> > I have no problem with breaking ABI more often but allowing it in every
> > minor
> > releases probably goes to far. Perhaps every second LTS
Il 31/05/19 15:24, Volker Hilsheimer ha scritto:
Hey Guiseppe,
That is my understanding as well. Yes, 5.15 will be an LTS, and assumed to be
the last feature release in Qt 5.
Thanks for confirming my reading.
I guess that the idea is that the port to Qt 6 can then happen in multiple
On Sunday, 2 June 2019 01:20:51 PDT Manuel Bergler wrote:
> First of all, Qt itself
> could make use of inline namespaces to ship several version of the same
> classes in the same binary while keeping source compatibility.
Repeat after me: inline namespaces are not a tool to retain ABI.
They
On Sunday, 2 June 2019 07:30:11 PDT Jean-Michaël Celerier wrote:
> - boost has the exact same ABI stability issue (e.g. no ABI / API stability
> guarantees at all) and yet distros seem to manage all the C++ software
> which uses it without much problems.
Please send your distro packager some
Hi!
On Sun, 2 Jun 2019 at 11:31, Jean-Michaël Celerier
wrote:
>
> > If existing package of application cannot be rebuilt from source with
> > updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will
On Sun, 2 Jun 2019 at 10:10, Allan Sandfeld Jensen wrote:
[snip]
> >
> I have no problem with breaking ABI more often but allowing it in every minor
> releases probably goes to far. Perhaps every second LTS (every 3 years), might
> be better.
That would work as long as related applications (moc,
Hi! With my Debian maintainer hat on:
On Sun, 2 Jun 2019 at 05:21, Manuel Bergler wrote:
>
> Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler
> :
>>
>> Volker Hilsheimer wrote:
[snip]
>> Your proposal to break ABI at every 6.x minor release would be an absolute
>> nightmare for
On 6/2/19, 12:02 PM, "Stottlemyer, Brett (B.S.)" wrote:
This discussion reminds me of Python 2 vs. Python 3, and I think there are
some important lessons to consider from Python.
FYI, I know Qt has been through version updates as well, and Qt 4 -> Qt 5 was
not that long ago. For me, QML
On 6/1/19, 9:10 AM, "Development on behalf of Philippe"
wrote:
I second a recent quote from Lars Knoll :
> Qt has always had a somewhat different philosophy. Make C++ easy to use,
> no need to use Java. The fact is that 95% of the source code our users
>write will not be
> - People nowadays will just use the flatpak / appimage / snap / whatever
I can see how that works for single-binary GUI applications.
Do you know any example for a complex Qt-based multi-binary (preferably
command line usage) application that does that well?
02.06.2019, 17:30, "Jean-Michaël Celerier" :
>> If existing package of application cannot be rebuilt from source with
>>updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will be somehow patched by
Il 02/06/19 16:07, Konstantin Tokarev ha scritto:
That's why I suggested using inline namespaces. Then even if an
application no longer compiles with the new version of Qt it can still
link against it.
If existing package of application cannot be rebuilt from source with updated
Qt version,
> If existing package of application cannot be rebuilt from source with
updated
Qt version, it's a sure no-go for distibution. Either Qt update will be
blocked, or
application will be thrown away (or application will be somehow patched by
other
people, without you even knowing about that)
-
02.06.2019, 17:03, "Manuel Bergler" :
> Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
> :
>> 02.06.2019, 16:34, "Manuel Bergler" :
>> > Due to Hyrum's law [0], even with stricter guarantees there will
>> > always be someone for which migration is a non-trivial amount of work.
Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
:
>
>
>
> 02.06.2019, 16:34, "Manuel Bergler" :
> > Due to Hyrum's law [0], even with stricter guarantees there will
> > always be someone for which migration is a non-trivial amount of work.
> > The only way to avoid that is to change
02.06.2019, 16:34, "Manuel Bergler" :
> Due to Hyrum's law [0], even with stricter guarantees there will
> always be someone for which migration is a non-trivial amount of work.
> The only way to avoid that is to change nothing, ever. I personally
> also don't understand why people would expect
> Manuel Bergler wrote:
> > Right now, even though the API and ABI are stable, I have never seen an
> > update to a new minor version of Qt5 that did not require source changes
> > due to changed behavior,
>
> Well, that depends pretty much on the individual project (how large it is
> and what
Il 01/06/19 23:34, Kevin Kofler ha scritto:
Volker Hilsheimer wrote:
The overall goal here is to make sure that we don’t have to carry poorly
designed architecture or APIs around with us throughout the Qt 6 series,
and as long as we care about binary and source compatibility within a
major
On Sonntag, 2. Juni 2019 10:20:51 CEST Manuel Bergler wrote:
> Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
>
> kevin.kof...@chello.at>:
> > Volker Hilsheimer wrote:
> > > The overall goal here is to make sure that we don’t have to carry poorly
> > > designed architecture or APIs
> On 1 Jun 2019, at 16:12, Alberto Mardegan wrote:
>
> On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
>> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
>> three years maintenance. We are not expecting lots of people to jump
>> on Qt 6.0 anyway (because .0, and not an LTS
Il 01/06/19 23:17, Kevin Kofler ha scritto:
Indeed. One case in point: All this confabulation about move constructors
etc. misses the point that the gain of moving compared to shallow copying
with CoW is typically irrelevant for those 95% of non-performance-critical
code. But using explicit move
Manuel Bergler wrote:
> Right now, even though the API and ABI are stable, I have never seen an
> update to a new minor version of Qt5 that did not require source changes
> due to changed behavior,
Well, that depends pretty much on the individual project (how large it is
and what parts of Qt it
Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
kevin.kof...@chello.at>:
> Volker Hilsheimer wrote:
> > The overall goal here is to make sure that we don’t have to carry poorly
> > designed architecture or APIs around with us throughout the Qt 6 series,
> > and as long as we care about
Volker Hilsheimer wrote:
> The overall goal here is to make sure that we don’t have to carry poorly
> designed architecture or APIs around with us throughout the Qt 6 series,
> and as long as we care about binary and source compatibility within a
> major series, doing what we can for Qt 6.0 (and
Philippe wrote:
> On Sat, 1 Jun 2019 14:36:12 +0200
> André Pönitz wrote:
>
>> So it might make even sense to step back further and start with
>> asking "What should Qt be?" before trying to find out on whether
>> a specific API is poorly designed or not, as that decision depends
>> on the
On 5/31/19 4:24 PM, Volker Hilsheimer wrote:
> Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with
> three years maintenance. We are not expecting lots of people to jump
> on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when
> an API was marked as deprecated makes
On Sat, 1 Jun 2019 14:36:12 +0200
André Pönitz wrote:
> So it might make even sense to step back further and start with
> asking "What should Qt be?" before trying to find out on whether
> a specific API is poorly designed or not, as that decision depends
> on the purpose.
I second a recent
On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote:
> The overall goal here is to make sure that we don’t have to carry
> poorly designed architecture or APIs around with us throughout the Qt
> 6 series, and as long as we care about binary and source compatibility
> within a major
On Fri, May 31, 2019 at 02:50:45PM +0200, Giuseppe D'Angelo via Development
wrote:
> I guess that the idea is that the port to Qt 6 can then happen in multiple
> steps:
>
> 1) port to Qt 5.latest;
> 2) (enable and) fix all deprecation warnings;
> 3) port to Qt 6.
> If this is still the plan, I
Hey Guiseppe,
> On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> It seems to me that many emails in the earlier deprecation thread were from
> users concerned by the problem of removal of functionality. This is not an
> old story.
>
> However, apart from the
Hi,
It seems to me that many emails in the earlier deprecation thread were
from users concerned by the problem of removal of functionality. This is
not an old story.
However, apart from the specifics of why deprecating a certain class /
what to replace it with / etc., there's a bigger thing
73 matches
Mail list logo
