On Wednesday, 24 March 2021 09:58:50 PDT André Pönitz wrote:
> > The exact opposite is the correct thing:
> > - deprecation messages while compiling the source code are correct
> > - messages to the mailing list are not sufficient
>
> Sorry, this assumes that "user" people constantly compile
On Wednesday, 24 March 2021 09:05:50 PDT Giuseppe D'Angelo via Interest wrote:
> >> * I've got a square peg (a QList) and a round hole (an function I made
> >> that takes a QSet), so I need conversions to call it.
> >
> > And what, exactly, is the solution here? Probably "ranges", but those
> >
On Wednesday, 24 March 2021 07:57:57 PDT Matthew Woehlke wrote:
> "Just ignore it" may not be an option; sometimes there are *policies*
> that preclude this.
If your policy is that you will port away from everything that got deprecated,
then do so.
If your policy is that you shall have no
On Wednesday, 24 March 2021 07:33:35 PDT Jason H wrote:
> The elephant in the room is that Qt5 QList an QVector can have majorly
> different impacts on memory. A QList is more tolerant of memory
> fragmentation than QVector as you need o reallocate a
> contiguous chunk of memory successfully.
On Wed, Mar 24, 2021 at 12:17:02PM +0100, Giuseppe D'Angelo via Interest wrote:
> [...]
> The other reason was more profound and related to the deprecation of these
> APIs, meaning that in the huge majority of usages found was a form of
> algorithmic abuse. Should we offer APIs which facilitate
On Tue, Mar 23, 2021 at 05:09:51PM -0700, Thiago Macieira wrote:
> On Monday, 22 March 2021 14:55:04 PDT Roland Hughes wrote:
> > A deprecation message at compile time is __not__ a warning to the
> > installed base. This is especially true for things that were built with
> > earlier versions of Qt
> >
> >> * I've got a square peg (a QList) and a round hole (an function I made
> >> that takes a QSet), so I need conversions to call it.
> > And what, exactly, is the solution here? Probably "ranges", but those
> > aren't available yet.
>
> Not an easy answer, but maybe start not to have
Hi,
On 24/03/2021 15:57, Matthew Woehlke wrote:
...we might not be having this conversation.
Sure. I don't get called to make *that* decision, though. So I also had
to live through that.
I've proposed helpers and cleanups for 5.15/6.0 and those didn't land
due lack of time or API/ABI
On 24/03/2021 09.46, Giuseppe D'Angelo wrote:
And anyways these methods are still fully supported within Qt 5.
Tell that to all the people that compile with -Werror. Or just want
their code to compile without being full of warning spam.
"Just ignore it" may not be an option; sometimes there
>
> Probably. There's only so much space for the message in them. I'm trying
> to point out that the specific motivation here isn't even remotely
> _technical_ (e.g. is this hard to implement correctly; as you've shown,
> it's super easy), but a _design_ one (is this API *good*?).
>
> And anyways
>
> Oh, another problem I've run into is that the replacements for a lot of these
> deprecated methods aren't even available until the same version that
> deprecated them. That makes it a PITA to write warning-free code when we
> have to support older versions of Qt.
>
[Maurice Kalinowski]
I
On 24/03/2021 13:49, Matthew Woehlke wrote:
Let's take e.g. QList::toSet as an example. The deprecation message says
to use `QSet(list.begin(), list.end())` instead. How, then, is the
correct implementation*not*:
QSet QList::toSet() { return QSet{begin(), end()}; }
That is the correct
> Sent: Wednesday, March 24, 2021 at 8:49 AM
> From: "Matthew Woehlke"
> To: "Giuseppe D'Angelo" , interest@qt-project.org
> Subject: Re: [Interest] The willy-nilly deletion of convenience methods (was:
> Mixing Commercial and Open...)
>
> On 24/03/2021 07.17, Giuseppe D'Angelo via Interest
On 24/03/2021 07.17, Giuseppe D'Angelo via Interest wrote:
On 22/03/2021 17:19, Thiago Macieira wrote:
I thought we'd fixed that and reverted them. Or didn't we add
toContainer?
Peppe, what was our final conclusion here?
There was no conclusion reached, unfortunately, and didn't manage to
On Wed, 24 Mar 2021 at 12:17, Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:
> On 22/03/2021 17:19, Thiago Macieira wrote:
> > I thought we'd fixed that and reverted them. Or didn't we add
> toContainer?
> >
> > Peppe, what was our final conclusion here?
>
> There was no
On 22/03/2021 17:19, Thiago Macieira wrote:
I thought we'd fixed that and reverted them. Or didn't we add toContainer?
Peppe, what was our final conclusion here?
There was no conclusion reached, unfortunately, and didn't manage to
provide a replacement in time. I was (and still am) afraid at
On Monday, 22 March 2021 14:55:04 PDT Roland Hughes wrote:
> A deprecation message at compile time is __not__ a warning to the
> installed base. This is especially true for things that were built with
> earlier versions of Qt and are now just being recompiled with a much
> later version.
>
> A
On 3/22/21 4:03 PM, interest-requ...@qt-project.org wrote:
has any framework crossed your way that implements CoW?
Honestly, I haven't dug that deep.
Been using CopperSpice on RedDiamond editor. Veered off to try porting
Gede to CopperSpice so I could finally look at the new strings. Back
On 3/22/21 4:03 PM, Thiago Macieira wrote:
No removals have happened without warning. Please stop the FUD. (who am I
kidding? you're not going to stop)
All removals were announced by way of deprecation messages,
A deprecation message at compile time is __not__ a warning to the
installed
+1 over her on Qml being my favorite UI framework, did crazy think with it
we did render 3D into Qml scene before Qt 3D was there, rendering an
engine into texture into our own declarative engine rendering exposed nodes.
Multiple QQmlEngine for pipeline flow rendering pass (fast
Hi Roland,
has any framework crossed your way that implements CoW?
--
Best Regards,
Bernhard Lindner
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
> Sent: Monday, March 22, 2021 at 5:18 PM
> From: "Roland Hughes"
> To: "Jean-Michaël Celerier" , "Jason H"
>
> Cc: "interest"
> Subject: Re: [Interest] The willy-nilly deletion of convenience, methods
> (was: Mixing Commercial and Open...)
>
>
> On 3/22/21 10:39 AM, Jean-Michaël Celerier
On Monday, 22 March 2021 02:37:08 PDT Benjamin TERRIER wrote:
> but the removal of toList(), toSet() & co. is already a pain, and we
> basically needed to add helper functions to keep our code readable.
I thought we'd fixed that and reverted them. Or didn't we add toContainer?
Peppe, what was
On Monday, 22 March 2021 02:23:01 PDT Roland Hughes wrote:
> Everybody else simply quit Qt when what they needed was nuked without
> warning.
No removals have happened without warning. Please stop the FUD. (who am I
kidding? you're not going to stop)
All removals were announced by way of
On 3/22/21 10:39 AM, Jean-Michaël Celerier wrote:
> A debian package would go along way to introduce people to Qt there
in the hobbyist sector, but it's a compile-it-for-yourself situation
??
http://archive.raspbian.org/raspbian/pool/main/q/qtbase-opensource-src/
There are plenty of C++ developers.
They don't work for the slave wages JavaScript hackers do, but there are
plenty of C++ developers. More graduate college every year. I've never
seen a paid C++ Internship that didn't see dozens of candidates.
On 3/22/21 9:39 AM, Vlad Stelmahovsky wrote:
On 3/22/21 9:22 AM, Jason H wrote:
Roland, what did those companies move to?
That's what myself and Konrad have been comparing notes on. "The market"
hasn't settled on "one thing."
The set-top boxes all went to RDK along with Opera browser.
The "Explore this computer"/Kiosk market seems
+1
Qt for me still is the best cross-platform solution for mobile app
development enabling me to build great (and performant) apps from one
source.
from time to time looking at Flutter but still feel better using QML for
UI and C++ for the rest.
cannot say much about Qt6 yet because I'm
> A debian package would go along way to introduce people to Qt there in
the hobbyist sector, but it's a compile-it-for-yourself situation
?? http://archive.raspbian.org/raspbian/pool/main/q/qtbase-opensource-src/
kind regards,
jm
On Mon, Mar 22, 2021 at 3:23 PM Jason H wrote:
> >
> > Even
+1 for idea that mobile support has not been the priority in QtCo's mind that I
need it to be.
+1 for idea that filing bug reports and voting for them did not result in my
concerns being addressed. UX with QML across mobile and desktop platforms could
be better but many issues simply sit
The problem with companies, moving away from Qt, laying only partially with
weird licensing rules, which constantly changes (and this is annoying,
agreed)
The problem mostly with lack of C++ developers.
On Mon, Mar 22, 2021 at 1:47 PM Roland Hughes
wrote:
> On 3/22/21 7:25 AM, Vlad Stelmahovsky
On Montag, 22. März 2021 15:22:37 CET Jason H wrote:
> > Even Jason's company, you remember Jason right? QML's biggest, and
> > possibly __only__, fan. Even his company dumped Qt. The medical device
> > clients I've worked for have also dumped Qt.
> >
> > It isn't the FUD that is obsolete, just
>
> Even Jason's company, you remember Jason right? QML's biggest, and
> possibly __only__, fan. Even his company dumped Qt. The medical device
> clients I've worked for have also dumped Qt.
>
> It isn't the FUD that is obsolete, just the management of Qt.
I'm apparently Qt's biggest fan boy?
On 3/22/21 7:25 AM, Vlad Stelmahovsky wrote:
oops.
suddenly all the FUD becomes obsoleted
On Mon, Mar 22, 2021 at 11:49 AM Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:
On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:
> On 3/22/21 4:07 AM, Bernhard Lindner wrote:
oops.
suddenly all the FUD becomes obsoleted
On Mon, Mar 22, 2021 at 11:49 AM Allan Sandfeld Jensen
wrote:
> On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:
> > On 3/22/21 4:07 AM, Bernhard Lindner wrote:
> > >> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
>
On 3/22/21 5:19 AM, Vad Rulezz wrote:
Hello Roland, Qt devs!
On 3/22/21 12:38 PM, Roland Hughes wrote:
Even if TQC took back their critical decisions, I can't imagine that
people would ever
trust them again. This could cause fatal damage to Qt in the long
run if they don't sell
it to
On 2021-03-22 11:48, Allan Sandfeld Jensen wrote:
On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:
On 3/22/21 4:07 AM, Bernhard Lindner wrote:
Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
Qt-6-rolling-out-incomplete + deleted-convenience-methods =
On Montag, 22. März 2021 10:38:09 CET Roland Hughes wrote:
> On 3/22/21 4:07 AM, Bernhard Lindner wrote:
> >> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> >> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> >> customers-leaving
> >
> > I wonder if the loss
On 3/22/21 4:07 AM, Jason H wrote:
Is there anything we can do to maybe block the release of new Qt versions, so
that the BSD poison pill clause is triggered? Then we can start over from a BSD
license, and maybe get other custodians of the code base?
Qt is currently catering to automotive
but the removal of toList(), toSet() & co. is already a pain,
and we basically needed to add helper functions to keep our code readable.
Yes. These are good examples of "small convenient methods" that make (made) Qt
containers stand apart (in the positive way)
Philippe
On Mon, 22 Mar 2021
On 3/22/21 4:07 AM, Bernhard Lindner wrote:
Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
Qt-6-rolling-out-incomplete + deleted-convenience-methods =
customers-leaving
I wonder if the loss of confidence in the current Qt owners can ever be
compensated.
Even if TQC
On Mon, 22 Mar 2021 at 10:07, Volker Hilsheimer
wrote:
>
> Roland, if you have specific 1st hand porting experience to share and
> constructive contributions to make about which APIs we should bring back
> because, then please do so.
>
>
>
Just to add my experience.
A big part of the Qt
On 3/22/21 4:07 AM, Volker Hilsheimer wrote:
On 20 Mar 2021, at 14:22, Roland Hughes wrote:
I grepped the archive this morning. Hopefully Andre's email still works. I had
hoped he was still watching on here and would pipe up. Maybe he and his company
abandoned Qt as well after the June 2020
> On 20 Mar 2021, at 14:22, Roland Hughes wrote:
>
> I grepped the archive this morning. Hopefully Andre's email still works. I
> had hoped he was still watching on here and would pipe up. Maybe he and his
> company abandoned Qt as well after the June 2020 exchange?
>
> Here is a scrape of
On Mon, Mar 22, 2021 at 2:51 AM Jason H wrote:
>
> >
> > > Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> > > Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> > > customers-leaving
> >
> > I wonder if the loss of confidence in the current Qt owners can ever
>
> > Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> > Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> > customers-leaving
>
> I wonder if the loss of confidence in the current Qt owners can ever be
> compensated.
>
> Even if TQC took back their critical
> I don't know if it is current or not, but the KDE Manjaro has is really
> nice. They don't stick you with the really bad KDE packages either, like
> Calligra and KMail either. Apologies to our resident KMail fan.
KMail has several problems. THis is why I am using Evolution. But you don't
Hi!
> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> customers-leaving
I wonder if the loss of confidence in the current Qt owners can ever be
compensated.
Even if TQC took back their critical decisions,
On 3/21/21 12:11 PM, Thorsten Glaser wrote:
On Sun, 21 Mar 2021, Jason H wrote:
I anticipate that 5.15 will require a doubly long LTS period as a
result.
Unfortunately we learnt here that 5.15 will not have any LTS period
at all, at least not one that matters for the Open Source world.
This
On Sun, 21 Mar 2021, Jason H wrote:
> I anticipate that 5.15 will require a doubly long LTS period as a
> result.
Unfortunately we learnt here that 5.15 will not have any LTS period
at all, at least not one that matters for the Open Source world.
This is, basically, the end of Qt (considering
On 3/21/21 7:42 AM, Jason H wrote:
Sent: Friday, March 19, 2021 at 4:07 PM
From: "Roland Hughes"
Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
Qt-6-rolling-out-incomplete + deleted-convenience-methods =
customers-leaving
I find myself agreeing with Roland here. The
> Sent: Friday, March 19, 2021 at 4:07 PM
> From: "Roland Hughes"
> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> customers-leaving
>
I find myself agreeing with Roland here. The rollout of the core modules
I grepped the archive this morning. Hopefully Andre's email still works.
I had hoped he was still watching on here and would pipe up. Maybe he
and his company abandoned Qt as well after the June 2020 exchange?
Here is a scrape of one of the messages in the thread from the archive.
Subject:
On 3/19/21 9:08 AM, Volker Hilsheimer wrote:
Ok. API stability on the one hand, and keeping things maintainable and
un-bloated over a long time on the other, is of course a tradeoff. Different
industries will have different preferences, but the path we have chose for Qt
over the last 25
> On 19 Mar 2021, at 14:34, Roland Hughes wrote:
>
>
> On 3/19/21 7:51 AM, Volker Hilsheimer wrote:
>>> On 19 Mar 2021, at 12:12, Roland Hughes wrote:
>>>
>>>
>>>
>>> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
Il 18/03/21 12:41, Christian Gagneraud ha scritto:
> My main
On 3/19/21 7:51 AM, Volker Hilsheimer wrote:
On 19 Mar 2021, at 12:12, Roland Hughes wrote:
On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
Il 18/03/21 12:41, Christian Gagneraud ha scritto:
My main grief is that Qt doesn't seem to care about C++.
What was their last contribution to the
56 matches
Mail list logo
