subject:"\[Interest\] The willy\-nilly deletion of convenience, methods"

On Wednesday, 24 March 2021 17:21:31 PDT Scott Bloom wrote:
> Hard failure here.  Because Qt decided to change the list of supported
> compilers and OSes in the Qt 5 timeframe, (another major problem with the
> Qt universe), I know of many companies stuck at 5.12.  BTW, that includes
> Intel on two projects I know of 

That was not new policy.

We started Qt 4 supporting HP-UX, IRIX, AIX, Solaris, in addition to the free 
Unix (the BSDs and Linux), macOS (then called Mac OS X) and Windows. During 
Qt 4's lifetime, we dropped IRIX, then HP-UX on PA-RISC, then HP-UX on 
Itanium. By the time 5.0 came around, Solaris went the way of the dodo. Qt 4.0 
also supported the non-Unicode Windows (95, 98, Me), but that codebase was 
removed in 4.4 or 4.5 too.

Qt used to support Tru64 on Alpha at some point in time before 4.0. I don't 
know exactly when because the code was gone by the time I arrived in Oslo 
(Volker might remember).

So this policy had existed since at least 2004.

It sucks when it's your turn to be left out of support. My first Mac Mini, 
from 2011, which I used to test Qt on (and used for nothing else), was happily 
chugging along with Apple updates until Mojave (I think). At that point, Apple 
decided that they needed a 2013 Mac Mini or later for updates.

> I have customers who REQUIRE (as in I don’t have a choice) using CentOS 6. 
> We tried and failed to back port 5.15 to it.

Qt 5.15 was released on 2020-05-20. RHEL 6.0 was released 2010-11-10. That's a 
nine and a half year old system by then. That's when most library versions 
were frozen. The current Qt release at the time was 4.7.1.

I really admire you for trying (and I hope you were being well-compensated). 
But I do not envy your position and I do not want to share in your pain.

> And yes, we know 6.0 has been end of life'd, is insecure, has problems etc
> etc.. You tell them, well just enter the modern world, stop developing
> billion dollar systems by choosing an OS to start with and not allowing
> major OS changes until the version the team is working on is finished.

Wikipedia says RHEL 6 ELS will be supported through 2024. Red Hat must be 
making a good chunk of money from customers like yours to still support kernel 
2.6.32.

> And while you are at it, convince the intel internal rtl lint team to do the
> same.

We're not using CentOS 6. We're using SUSE Linux Enterprise 11. That's a whole 
3 years newer! At least it's kernel 3.0!

Any discussions we may or may not have had with them, I can't say.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

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 their application
> against Qt dev branch to notice. That is obviously not the case. And once it
> is already merged or even released it's practically to late.

If you meant that "too late to reverse the deprecation", then yes. It could 
eventually be reversed, if the need was great (we did un-deprecate QPointer, 
after all), but the vast majority of deprecations are there for good. If you 
want to know about deprecations early enough to have a say in whether they 
should be deprecated or not in the first place, you need to participate in 
development.

If you meant "too late to port", then I disagree and this is what I meant. 
When finally making progress, you get the warnings before you have to modify 
your code. The point is that people can make progress updating the Qt and 
other components in their applications without having to worry about replacing 
deprecated APIs. This is the time to deal with the inevitable 
incompatibilities that will arise. Once that is done and you have a working 
application (even if not certified or released), you go and fix the warnings.

> I am /not/ saying it is wrong to _also_ put deprecation warnings into the
> code, but most deprecations I've seen lately would have deserved a somewhat
> broader discussion than (exaggerated...) two people agreeing on a random
> change on gerrit. Asking actual users would be a good start from my
> perspective.

The usual reaction is defensive: "I'm using this, so it must be good and 
you'll pry it from my cold dead hands!" That's why I said that polling users 
is usually not a good solution, even if it were statistically representative.

Polling source code, on the other hand, could be. "Oh, crap, just about every 
other application we checked uses this thing!" That may not change the actual 
decision on deprecation, but it may advise us on how long the replacement API 
must have been available for, how long we must keep compatibility for (see 
QLocale::country()), whether we need to educate developers (see the whole 
"derive from QThread" discussion).

When was the last time we had as part of the Qt release procedure rebuild all 
of KDE and figure out what we had broken? I remember this for 4.4, maybe 4.5.

> Also, even the "code only" way deprecation process is unsatisfactory at
> times: We've had cases where there no hints what the "better" way would be.
> In some cases, alternatives appeared only at the time where the previous
> functions was deprecated/removed, in some cases the suggested replacement
> was ugly and/or error prone, in some cases there was simply no alternative
> at all.

I agree. And I think we've learned from this. The feedback from the Qt Creator 
development team on exactly this issue is what led to the creation of the 
QT_DEPRECATED_VERSION_xxx macros. We even adopted as a policy that a 
replacement needed to be available for one LTS release before the warning 
could be emitted by default, but then the whole discussion on LTS happened 
too. And it doesn't help that 5.15 required a lot of deprecation *because* of 
6.0's development revealed it. At least I hope that those compatibility 
methods are still there in 6.0.

For the aforementioned QLocale::country() deprecation, I adopted a simple 
policy that its replacement must have been available for 2 years (4 releases) 
before the warning starts being emitted.

> > At that point, the decision has already been made. I am not discussing how
> > to make the decision on deprecation. That's not a vote either: we don't
> > remove things because we think no one uses them, with very few exceptions
> > (like QLinkedList). We remove things because they are badly named, have
> > flawed API or design, result in improper code, make progress impossible
> > otherwise, etc.
> A lot of that is highly subjective, and already the reasons you mentioned
> are broad enough that one can practically find a suitable excuse to
> deprecate anything.

That may be, but I sure hope it it isn't. I am specifically excluding the 
"willy-nilly deprecation" that was suggested, that we do things on a whim 
because we're evil and/or think no one is using something. That is NOT how we 
work.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Scott Bloom

-Original Message-
From: Interest  On Behalf Of Thiago Macieira
Sent: Wednesday, March 24, 2021 15:44
To: interest@qt-project.org
Subject: Re: [Interest] The willy-nilly deletion of convenience,, methods

On Wednesday, 24 March 2021 04:48:08 PDT Roland Hughes wrote:
> On 3/24/21 6:00 AM, interest-requ...@qt-project.org 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
> 
> No, it's not. It only seems correct if you live in a world where 
> nothing lasts six months.
> 
> Out in the real product world you create some product using Qt 3.x or 
> 4.2. That product goes to production where it remains for 7-15+ years.

I stand by what I said and I live in the real world. You clearly live in a 
different, also real world. I don't doubt any of the claims you make are true. 
I do doubt that they are the majority or even significant. The majority of the 
uses I am familiar with last much shorter than 7 years. At the very least, 
there are opportunities in those 7 years to do incremental progress or keep up 
with the latest.

Qt's horizon is about 7 years.

Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0. 
Once you're in the 5.x series, port to 5.15 and fix the warnings. Once you're 
clean in a working build, port to Qt 6.
==

Hard failure here.  Because Qt decided to change the list of supported 
compilers and OSes in the Qt 5 timeframe, (another major problem with the Qt 
universe), I know of many companies stuck at 5.12.  BTW, that includes Intel on 
two projects I know of 😊

I have customers who REQUIRE (as in I don’t have a choice) using CentOS 6.  We 
tried and failed to back port 5.15 to it.

So we are effectively stuck at 5.12 until our customer allows us to drop 
CentOS/RHEL 6.0

And yes, we know 6.0 has been end of life'd, is insecure, has problems etc 
etc.. You tell them, well just enter the modern world, stop developing billion 
dollar systems by choosing an OS to start with and not allowing major OS 
changes until the version the team is working on is finished.

And while you are at it, convince the intel internal rtl lint team to do the 
same.

Scott

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

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
> > aren't available yet.
> 
> Not an easy answer, but maybe start not to have functions take/return
> specific containers.

No, there is no answer. You have to choose a container.

Unless you want to go the route of everything-in-the-library-is-inline, which 
makes your compilation times (and your Qt Creator completions, see other 
thread) take 10x longer. That goes against Qt library coding policy, therefore 
is not an option.

So we have to choose one container. That's why we use QList for everything 
sequential, non-associative: it's (now!) usually more than good enough for 
almost all uses.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

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 warnings, then turn the deprecation 
warnings off for a particular version. Just define 
QT_DEPRECATED_WARNINGS_SINCE to version 5.13 or earlier. We provided this 
macro so you could port incrementally.

> ...And, again, even that would be less of an issue if it didn't require
> different code to support 5.14 and 5.15.

It doesn't.

The toSet() API was deprecated in 5.14. What changed between 5.14 and 5.15 was 
that you can disable the warning. In 5.14, it was:

Q_DECL_DEPRECATED_X("Use QSet(list.begin(), list.end()) instead.")
QSet toSet() const;

In 5.15, it is:

QT_DEPRECATED_VERSION_X_5_14("Use QSet(list.begin(), list.end()) 
instead.")
QSet toSet() const;

The 5.14 use was wrong (it should have used QT_DEPRECATED_X, which can be 
disabled centrally). In 5.15, you can disable the warning by setting 
QT_DEPRECATED_WARNINGS_SINCE to a value earlier than 5.14.

> Because history. If you want those, do them the "right" way. Meanwhile,
> don't "break" existing code.
> 
> Again, I think a lot of the reason folks are making such a big stink is
> because we had:
> 
>5.14: toSet() is fully supported, no alternative is available
>5.15: toSet() is deprecated, use ...
>6.0: there is no toSet()

Let's assume you're off by 1 here because your history is inaccurate. What did 
happen was:

  5.13: toSet is fully supported, no alternative is available
  5.14: toSet is deprecated, warning can't be disabled
  5.15: toSet is deprecated, warning can be disabled
  6.0: toSet is not available

The warning in 5.14 was wrong. That's why it was changed in 5.15 to something 
you can disable.

> If things had *instead* looked like:
> 
>5.9: toSet() is fully supported, "better" alternative is available
>5.12: toSet() is deprecated, "better" alternative is available
>5.15: same as 5.12
> 
> ...we might not be having this conversation.

There are other APIs that are like that. Some much earlier than 5.9.

There are also some APIs that did get deprecated in 5.15 and we still carried 
them over to 6.0. Explicitly because there had been no previous release with 
an alternative, so we decided we needed to provide at least one or two more 
releases where the deprecated API was available.

It didn't happen in this case. The deprecated API only got 2 releases of grace 
period.

We've noticed this before and this thread only reinforces so: deprecation 
warnings can't be given unless there has been an alternative for at least a 
couple of releases. So, right now, we have:

  Qt 6.1: no QLocale::territory()
  Qt 6.2: QLocale::territory() is available, no deprecation warnings
  Qt 6.6: QLocale::country() starts producing deprecation warning

And I don't think we'll be able to remove QLocale::country() for 7.0 either.

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

> In any case, I'm not convinced that removing API is the solution to this
> problem. It seems more like something for clazy to complain about.

I can sympathise. And this particular case is definitely a sore thumb.

But that's not the vast majority of deprecations and changes done. I think 
we've done a good job for the majority. We screwed up on a few, this one 
included and even primarily.

Peppe, how about we bring these back still in 6.1 or 6.2, with a warning 
enabled by default that you can disable with a macro?

#define Q_ENABLE_INEFFICIENT_CONTAINER_CONVERSIONS

> 
> > * I need to keep the list, process it in order, but avoid processing
> > duplicate elements; 99% of the time the list is a handful of elements;
> > let me do
> > 
> >> QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
> >> process(elem); } }
> 
> And what, exactly, is the solution here?

QDuplicateTracker (not public API, but we can entertain that if there's need).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

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. Where as Qt6 QList would allow
> LargeClass objects to be scattered. This is no longer the case in Qt6.
> You'll be forcing everything into contiguous memory. Which also has impacts
> on performance for systems with virtual memory. Please tell me I'm wrong
> about this?

You're not. That's correct: the contiguous memory of Qt 6 should have better 
performance.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

On Wednesday, 24 March 2021 04:48:08 PDT Roland Hughes wrote:
> On 3/24/21 6:00 AM, interest-requ...@qt-project.org 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
> 
> No, it's not. It only seems correct if you live in a world where nothing
> lasts six months.
> 
> Out in the real product world you create some product using Qt 3.x or
> 4.2. That product goes to production where it remains for 7-15+ years.

I stand by what I said and I live in the real world. You clearly live in a 
different, also real world. I don't doubt any of the claims you make are true. 
I do doubt that they are the majority or even significant. The majority of the 
uses I am familiar with last much shorter than 7 years. At the very least, 
there are opportunities in those 7 years to do incremental progress or keep up 
with the latest.

Qt's horizon is about 7 years.

Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0. 
Once you're in the 5.x series, port to 5.15 and fix the warnings. Once you're 
clean in a working build, port to Qt 6.

You've got all warnings you needed to make progress in each of those steps.

You may not like some of those changes. Then I suggest that you should have 
complained when Qt 5.15 became available with those warnings. And do note 
about half of the warnings were introduced before 5.15, so where were those 
people when those releases were made and the warnings added?

> Now the product needs to be redeveloped/enhanced because the benefits
> now outweigh the costs of spin-up. 

That's why you need to do it incrementally and you shouldn't wait to do it. 
Keep up to date in those 15 years, even if you don't actually release a new 
product with those updated versions.

> The very first time you find out everything that got nuked is today.

Like I said, I can't help if feedback wasn't given at the time that there was 
time to accept such feedback. You may say that going away for 15 years and 
then complaining is acceptable in some industries. It clearly isn't in this.

You may not like that statement. It's true nonetheless.

> Given the current state of Qt and the willy-nilly nuking of things, both
> of these companies are going to have to go with CopperSpice or some
> other competitor. Qt 6 isn't usable and Qt 5 has no LTS unless they want
> to support the ex-wife in a manner she would like to become accustomed to.

We are not nuking things willy-nilly. You may not like what we removed, you 
may not like the process, but it was documented, over a period of time, all 
the removals were for a reason. 

So stop the FUD. 

Want to have a reasonable conversation over things that were removed but are 
still useful? Count me in. We can figure out how to address those issues.

Otherwise, invent a time machine and provide us with feedback one year ago.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

On Tuesday, 23 March 2021 09:02:04 PDT Matthew Woehlke wrote:
> On 23/03/2021 11.44, Volker Hilsheimer wrote:
> > I wished I had seen the level of energy y’all are putting right now
> > into this email thread over the last two years when we discussed
> > where to go with Qt 6, and when the work actually happened.
> 
> IIRC, I complained plenty about QList at the time. I wouldn't be
> surprised if I complained about QHash also.

And lo and behold, QList and QHash are completely rewritten for Qt 6, because 
of the major complaints that existed against them, especially against QList.

Most people using the new QList won't notice a difference at all.

The one thing that will catch people with the new QHash is the lack of 
stability of references. That is unfortunately a silent change.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/24/21 1:45 PM, André Pönitz wrote:

On Wed, Mar 24, 2021 at 10:10:55AM -0400, Andy wrote:

Do you think everyone can take a moment and realize that this mailing list
has dozens of people on it.

1328 as of now.

Incidentally - even this was surely not the point you wanted to make -
this also means that this mailing list has a decent reach to find out
whether some feature is used or not *before* it gets removed.

Andre'


I sent him a private message telling him how to get this list in digest 
mode. The only time it interrupts my day is when someone direct messages 
me or we have another one of those days where people respond with one 
word/line to a message containing a 4000+ line compiler output 
***without nuking the now needless output.*** There is a size limit on 
the server. Once the gathered messages hit that certain size it sends 
out another email.


With a list there is always going to be subjects some care passionately 
about and others couldn't give a rat's behind about. They will also not 
understand why people don't give a rat's behind about what they 
themselves care passionately about.


The willy-nilly deletion of convenience methods, however, was not FUD as 
far too many attempted to paint it. We have stumbled across inconvenient 
bodies in the woods. Vital family members were taken out and shot.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread André Pönitz

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 bad coding
> practices?

Sure. And instead of having "the API facilitating bad coding"

gimmeList().toSet()

"we" now have the super-safe to use API 

QSet(gimmeList().begin(), gimmeList().end());

Do I need to check gerrit where such I've seen such replacement attempt last 
time?

Do I need to check gerrit where such replacement was actually integrated?

My firm stance here is that as long as "downstream" projects effectively
have to come up with wrappers around Qt, replacing removed functionality,
the removal was *WRONG*.

Andre'

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-24 Thread André Pönitz

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 and are now just being recompiled with a much
> > later version.
> > 
> > A message in interest saying "Hey! We are about to nuke this, is anyone
> > actually using it?"
> 
> 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 their application
against Qt dev branch to notice. That is obviously not the case. And once it
is already merged or even released it's practically to late.

I am /not/ saying it is wrong to _also_ put deprecation warnings into the
code, but most deprecations I've seen lately would have deserved a somewhat
broader discussion than (exaggerated...) two people agreeing on a random
change on gerrit. Asking actual users would be a good start from my
perspective.

Also, even the "code only" way deprecation process is unsatisfactory at
times: We've had cases where there no hints what the "better" way would be.
In some cases, alternatives appeared only at the time where the previous
functions was deprecated/removed, in some cases the suggested replacement
was ugly and/or error prone, in some cases there was simply no alternative
at all.

> The sample of developers in this mailing list is far too small. Any reply we 
> got from here would not be significative.

...

> Warnings posted here would not reach  the majority of the audience either.

Warnings put in the code do not reach anyone not involved with Qt development
_in time_.

> But creating warnings when you compile your code is a good way to let people 
> know that they have to take action at some time. No function can be removed 
> until the next major version, so you have until then to figure out.

[But removing whole modules is ok...]

> At that point, the decision has already been made. I am not discussing how to 
> make the decision on deprecation. That's not a vote either: we don't remove 
> things because we think no one uses them, with very few exceptions (like 
> QLinkedList). We remove things because they are badly named, have flawed API 
> or design, result in improper code, make progress impossible otherwise, etc.

A lot of that is highly subjective, and already the reasons you mentioned
are broad enough that one can practically find a suitable excuse to
deprecate anything. 

Some of the contested deprecations were based on arguments along the lines
"it does not exist in plain C++, so it is a flaw in Qt to have it", some
where accepted on "makes user code nicer" - when the only solution for
user code to make it compile at all was to introduce(!) preprocessor use
around the affected code.

If these ara acceptable arguments in favour of deprecations one does not
even have to have any "rules".

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

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Jason H


> >
> >> * 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 functions take/return
> specific containers.

mumblemumbleabstractiteratormubmlemumble.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Giuseppe D'Angelo via Interest


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 constraints. What else can one do?




We're not talking about adding many, many variations
upon this theme, just*not*  removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common*  use cases.

Can I hear some use cases then please? Because from the experience of
usages within Qt, it was a nail/hammer problem, call it an education
problem ("I know containers; I don't know algorithms; let me use
containers to solve an algorithmic problem"), of which we're entirely
responsible (Qt docs teach a lot about containers, but not about
algorithmic design.)

An example I know offhand:

https://github.com/Kitware/qtextensions/blob/0ff5b486f08435c8cdfbc9f05d2f104f63b16aed/util/qtUiState.cpp#L268

Yes, in fairness, using a set to de-duplicate is arguably an algorithm
problem. OTOH, I'm not sure I really want to trade hashed lookup for
generating a collection of an unbounded number of duplicates. Also, yes,
most programmers probably don't know offhand how to de-duplicate a
collection using algorithms. (I'd also want to see performance numbers
that the latter approach is actually more efficient, because offhand I'm
not*at all*  convinced it is, and wouldn't be surprised if it's*worse*).


You could, however, package that algorithm and hide the implementation. 
Maybe provide the bounded and unbounded versions so the caller can 
choose depending on some information they have. Maybe provide a version 
using monotonic PMR if the caller knows that the number of elements is 
going to be relatively small most of the time.


For your particular implementation, to give you another "interesting" 
datapoint, none of the code you're using is even particularly optimized 
(as it COULD be) within Qt itself. QSet::operator+=(QSet) doesn't splice 
from the argument if it's an unshared rvalue (whops!). Even the goodwill 
of using containers as algorithms gets sabotaged by the poor implementation.


(An incredibly better solution would already to be unordered_set and its 
ranged insert. But then 1) if you didn't package it now you have to 
change all over the place instead of once, and 2) obviously you don't 
have unordered_set::toList(), WHOPS!).





The reality is that using containers to solve algorithm problems (e.g.
"I'm using a map because I need the values to be sorted") is extremely
common.



Then we're spectacularly failing at educating users, to be honest.



* I need to keep the list, process it in order, but avoid processing
duplicate elements; 99% of the time the list is a handful of elements;
let me do


QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
process(elem); } }

And what, exactly, is the solution here?


KDToolBox::DuplicateTracker, courtesy of Marc.




* 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 functions take/return 
specific containers.



Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Matthew Woehlke


On 24/03/2021 09.45, Volker Hilsheimer wrote:

On 24 Mar 2021, at 13:20, Roland Hughes wrote:
death of OpenSource LTS


Get the patches you need from the dev branch.


Wait, so is TQtC *asking* the community to fork Qt? Because that's how 
this reads: 'TQtC has killed open source LTS; we (TQtC) won't provide 
any such thing, but we hope someone else will step up to do so'.



I started a new one were we can focus on substantial and
constructive conversation about what needs to be brought back to make
Qt 6 better and porting easier.

Step 1: make a Qt 6 that is usable.

Yeah, I know, "working on it". The problem is more that you forgot Step 
0: don't kill Qt 5 until Step 1 is complete.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-24 Thread Volker Hilsheimer

> On 24 Mar 2021, at 15:06, eric.fedosej...@gmail.com wrote:
> 
> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Wednesday, March 24, 2021 4:06 AM
> 
>> For feedback regarding the licensing changes made that context (including 
>> 5.15), I’d suggest you go back to the respective email thread if you just 
>> want to vent, or call your sales rep in The Qt Company.
> 
> Translation: open source users should just shut up and go away. Bold move, 
> let's see how it works out for you.

I think it would work quite wonderfully if the licensing discussion would 
happen in the thread with “license” in the subject, while the discussion about 
perhaps overzealous deletion of methods would happen in the thread that has 
“deletion of methods” in the subject.

Cheers,
Volker

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Matthew Woehlke

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 are *policies*
that preclude this.

...And, again, even that would be less of an issue if it didn't require
different code to support 5.14 and 5.15.

Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that).

All the contrary, this is one big crux of the problem: toX() for a
completely arbitrary closed set of X is bad API. Why QSet::toList and
not toVector? Why QList::toSet and not, say, MULTI sets?

Because history. If you want those, do them the "right" way. Meanwhile,
don't "break" existing code.

Again, I think a lot of the reason folks are making such a big stink is
because we had:

5.14: toSet() is fully supported, no alternative is available
5.15: toSet() is deprecated, use ...
6.0: there is no toSet()

If things had *instead* looked like:

5.9: toSet() is fully supported, "better" alternative is available
5.12: toSet() is deprecated, "better" alternative is available
5.15: same as 5.12

...we might not be having this conversation.

We're not talking about adding many, many variations
upon this theme, just*not* removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common* use cases.

Can I hear some use cases then please? Because from the experience of
usages within Qt, it was a nail/hammer problem, call it an education
problem ("I know containers; I don't know algorithms; let me use
containers to solve an algorithmic problem"), of which we're entirely
responsible (Qt docs teach a lot about containers, but not about
algorithmic design.)

An example I know offhand:

https://github.com/Kitware/qtextensions/blob/0ff5b486f08435c8cdfbc9f05d2f104f63b16aed/util/qtUiState.cpp#L268

Yes, in fairness, using a set to de-duplicate is arguably an algorithm
problem. OTOH, I'm not sure I really want to trade hashed lookup for
generating a collection of an unbounded number of duplicates. Also, yes,
most programmers probably don't know offhand how to de-duplicate a
collection using algorithms. (I'd also want to see performance numbers
that the latter approach is actually more efficient, because offhand I'm
not *at all* convinced it is, and wouldn't be surprised if it's *worse*).

The reality is that using containers to solve algorithm problems (e.g.
"I'm using a map because I need the values to be sorted") is extremely
common.

Ranges will fix some, but not all, of this.

Miscellanea examples from Qt itself,

* I need to remove duplicates from my list, let me do:

list = list.toSet().toList();

Right. Although note that the above example is doing a multi-merge with
de-duplication, so the "use a set as an intermediary" approach has a
better chance of being more efficient, since each merge will never
result in duplicates existing in the collection in the first place. I
agree that the above example is probably not optimal.

In any case, I'm not convinced that removing API is the solution to this
problem. It seems more like something for clazy to complain about.

* I need to keep the list, process it in order, but avoid processing
duplicate elements; 99% of the time the list is a handful of elements;
let me do

QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
process(elem); } }

And what, exactly, is the solution here?

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

--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Jason H


>
> 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 these methods are still fully supported within Qt 5.

I want to "code less, create more". And manually writing these over and over
for every project I use Qt in is not coding less. They should be part of
the library.

> This is calling for a more generic toX() API. Which isn't easy to
> provide within the quality constraints of QtCore. If it were, don't you
> think Yours Truly would already have provided it? Do I sound *that* evil
> that I enjoy crippling for the sake of it? :-(

I'd rather an ANPI where you have to call toX() a minimal number of times.
See below.

> Miscellanea examples from Qt itself,
>
> * I need to remove duplicates from my list, let me do:
>
> > list = list.toSet().toList();

This should just be toSet() and generic iteration after that. No need
to convert it to a list if you can iterate over QSets the same as QLists.

> * I need to keep the list, process it in order, but avoid processing
> duplicate elements; 99% of the time the list is a handful of elements;
> let me do
>
> > QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); 
> > process(elem); } }
> * 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.

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. Where as Qt6 QList would allow LargeClass objects to be 
scattered.
This is no longer the case in Qt6. You'll be forcing everything into contiguous 
memory.
Which also has impacts on performance for systems with virtual memory.
Please tell me I'm wrong about this?

I wanted a generic iterator.  Typdefing QList to QVector does not solve that.
But even so, how do I generically iterate over QVector/QSet?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Andy

Do you think everyone can take a moment and realize that this mailing list
has dozens of people on it.

Every email we receive takes some non-zero amount of time to deal with.

Please consider this before clicking "send".

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 

On Wed, Mar 24, 2021 at 10:05 AM Christian Gagneraud 
wrote:

> On Thu, 25 Mar 2021 at 02:44, Roland Hughes 
> wrote:
> > On 3/24/21 8:21 AM, Christian Gagneraud wrote:
> > > On Thu, 25 Mar 2021 at 01:22, Roland Hughes <
> rol...@logikalsolutions.com> wrote:
> > Apparently Martians fart sulfur
>
> Apparently Roland talks sulfur
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Maurice Kalinowski

> 
> 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 assume you mean "removed them".

Those are the tough ones, agreed. And we know that those are situations, which 
are the most complicated. However, the problem usually around these are that we 
know that architecturally those will not withstand for a longer period without 
serious limitations. Afterall, Qt 5 served for 8 years, Qt 4 for less. For Qt 6 
we aim to have it available even longer, for reasons mentioned in this very 
thread actually.

We are recognizing this also on some other modules currently in the works for 
6.2. For instance some parts in Bluetooth will need such an effort. 
Unfortunately, those do not happen just for the sake of "modernization", but 
rather because there are flaws in the design which do not scale anymore.

As said, those are the worst and everyone (TQtC, but also all contributors) 
tries to keep these at a minimum. However, there is a chance that you are hit 
by those. Stating early "going to be deprecated" covers the notification aspect 
only then.

BR,
Maurice

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-24 Thread eric.fedosejevs

From: Interest  On Behalf Of Volker Hilsheimer
Sent: Wednesday, March 24, 2021 4:06 AM

>For feedback regarding the licensing changes made that context (including 
>5.15), I’d suggest you go back to the respective email thread if you just want 
>to vent, or call your sales rep in The Qt Company.

Translation: open source users should just shut up and go away. Bold move, 
let's see how it works out for you.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/24/21 8:45 AM, Volker Hilsheimer wrote:

The research done by e.g. DORA around continuous deployment, including in 
safety critical environments, tells a different story than your anecdotes.

https://www.devops-research.com/research.html
You cannot continuously deploy to a medical device that has to go 
through clinical trial. They have to go through clinical trials because 
*even one crash kills*



  To be honest, many of those bugs are really hard to fix without breaking 
anything else, so often we decide that a known, well-documented bug is 
preferable to a bunch of new, unknown bugs that a fix might introduce.


You knowingly create 30 year old security issues and you diss your customers 
who have worked around theirs.

:P

Knowingly? That’s a bit much, even from you, Roland.
Well, you are the one who said "so often we decied that a known, 
well-documented bug is preferable" which means you are knowingly leaving 
a bug in the product that could become a security/stability 
vulnerability (if it wasn't to start with.) As to the number of years, 
that is just the march of time.

You forgot customer abandonment

Talk to your sales rep.


OpenSource users never want to hear from a sales rep.



Qt 6 being useless
QML needing to be ripped out.

Don’t use it.

I don’t consider this substance. Go back to the original thread if you want to 
spread FUD, Roland.

It's not FUD when LTS was shot out of the saddle and Qt 6 is unusable.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Christian Gagneraud

On Thu, 25 Mar 2021 at 02:44, Roland Hughes  wrote:
> On 3/24/21 8:21 AM, Christian Gagneraud wrote:
> > On Thu, 25 Mar 2021 at 01:22, Roland Hughes  
> > wrote:
> Apparently Martians fart sulfur

Apparently Roland talks sulfur
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Christian Gagneraud

On Thu, 25 Mar 2021 at 02:36, Ulf Hermann  wrote:
>
> On 3/24/21 2:21 PM, Christian Gagneraud wrote:
> > On Thu, 25 Mar 2021 at 01:22, Roland Hughes  
> > wrote:
> >> You forgot customer abandonment
> >>
> >> death of OpenSource LTS
> >>
> >> Qt 6 being useless
> >>
> >> QML needing to be ripped out.
> >
> > Is there life on Mars?
>
> I'm from Mars.

Hi, nice to meet you, i'm from July.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Giuseppe D'Angelo via Interest


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 implementation, but the deprecation functions aren't 
about "how this ought to be implemented into Qt".




What was so hard about that? If that's wrong, then so AFAICT is the
deprecation message.


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 these methods are still fully supported within Qt 5.




Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that). 


All the contrary, this is one big crux of the problem: toX() for a 
completely arbitrary closed set of X is bad API. Why QSet::toList and 
not toVector? Why QList::toSet and not, say, MULTI sets? If you want 
stability of references and can't use Q6Set but want std::unordered_set, 
why there isn't a function for that? And so on.


This is calling for a more generic toX() API. Which isn't easy to 
provide within the quality constraints of QtCore. If it were, don't you 
think Yours Truly would already have provided it? Do I sound *that* evil 
that I enjoy crippling for the sake of it? :-(




We're not talking about adding many, many variations

upon this theme, just*not*  removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common*  use cases.


Can I hear some use cases then please? Because from the experience of 
usages within Qt, it was a nail/hammer problem, call it an education 
problem ("I know containers; I don't know algorithms; let me use 
containers to solve an algorithmic problem"), of which we're entirely 
responsible (Qt docs teach a lot about containers, but not about 
algorithmic design.)



Miscellanea examples from Qt itself,

* I need to remove duplicates from my list, let me do:


list = list.toSet().toList();


* I need to keep the list, process it in order, but avoid processing 
duplicate elements; 99% of the time the list is a handful of elements; 
let me do



QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); 
process(elem); } }
* 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 so on.

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Volker Hilsheimer

> On 24 Mar 2021, at 13:20, Roland Hughes  wrote:
>>> Who said anything about "ever?"  Or even "last year."  Have you never built 
>>> anything that is actually finished, and stays finished, and relevant, and 
>>> functional for 10, 20, 30 years?  Granted, if I get 10 years of use out of 
>>> anything built in this century, I do consider it a minor victory.  So maybe 
>>> that's my answer.
>>> 
>> There are evidently (form what has been written here, and from my personal 
>> experience of working in and with financial, medical, and telko) industries 
>> that prefer 30 year old security issues in their devices over establishing a 
>> process that allows them to continuously update their software stack. In 
>> which case, yes I personally do think they are missing the point of 
>> “software”, and I’m happy that our way of developing Qt is not constrained 
>> by those industries.
> Those would be your customers. 30 year old security issues tend to be easily 
> plugged or otherwise defended against. There is no defense against the 
> relentless stream of new security vulnerabilities, bugs, and crashes brought 
> about by continuous integration and deployment.


The research done by e.g. DORA around continuous deployment, including in 
safety critical environments, tells a different story than your anecdotes.

https://www.devops-research.com/research.html


>>  To be honest, many of those bugs are really hard to fix without breaking 
>> anything else, so often we decide that a known, well-documented bug is 
>> preferable to a bunch of new, unknown bugs that a fix might introduce.
>> 
> You knowingly create 30 year old security issues and you diss your customers 
> who have worked around theirs.
> 
> :P


Knowingly? That’s a bit much, even from you, Roland.


>> FWIW, so far the substance of this discussion seems to boil down to
>> 
>> * the old QList implementation being gone
>> * toContainer convenience methods removed
>> * references to QHash entries no longer stable when the hash is mutated
>> 
> You forgot customer abandonment

Talk to your sales rep.

> death of OpenSource LTS

Get the patches you need from the dev branch.

> Qt 6 being useless
> QML needing to be ripped out.

Don’t use it.

I don’t consider this substance. Go back to the original thread if you want to 
spread FUD, Roland.

I started a new one were we can focus on substantial and constructive 
conversation about what needs to be brought back to make Qt 6 better and 
porting easier.


Volker





___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/24/21 8:21 AM, Christian Gagneraud wrote:

On Thu, 25 Mar 2021 at 01:22, Roland Hughes  wrote:

You forgot customer abandonment

death of OpenSource LTS

Qt 6 being useless

QML needing to be ripped out.

Is there life on Mars?


Apparently Martians fart sulfur

https://futurism.com/scientists-nasa-found-evidence-ancient-life-mars

https://www.nasa.gov/press-release/nasa-finds-ancient-organic-material-mysterious-methane-on-mars

https://www.cnn.com/2019/10/15/us/nasa-life-on-mars-intl-hnk-scli/index.html


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Ulf Hermann


On 3/24/21 2:21 PM, Christian Gagneraud wrote:

On Thu, 25 Mar 2021 at 01:22, Roland Hughes  wrote:

You forgot customer abandonment

death of OpenSource LTS

Qt 6 being useless

QML needing to be ripped out.


Is there life on Mars?


I'm from Mars.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Jason H



> 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 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
> > provide a replacement in time. I was (and still am) afraid at simply
> > reintroducing .to() functions.
> >
> > One reason is purely API quality: implementing them "correctly" in
> > C++14/17 without ranges/concepts is not exactly funny (just look at the
> > ranges::to proposal for how many corner cases are there to consider),
> > and there's indeed already ranges-v3::to as the ready-made solution (so
> > why spending time redoing it).
>
> Huh?
>
> 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()}; }

+1024

I also think that this is also made a problem because of lack of a general
collection interface. QVector, QList, QSet, I don't want to care what is passed
into my function. I just want to take multiple of some thing. Let my API user
determine what the best storage mechanism is.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

2021-03-24 Thread Christian Gagneraud

On Thu, 25 Mar 2021 at 01:22, Roland Hughes  wrote:
> You forgot customer abandonment
>
> death of OpenSource LTS
>
> Qt 6 being useless
>
> QML needing to be ripped out.

Is there life on Mars?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Matthew Woehlke


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 
provide a replacement in time. I was (and still am) afraid at simply 
reintroducing .to() functions.


One reason is purely API quality: implementing them "correctly" in 
C++14/17 without ranges/concepts is not exactly funny (just look at the 
ranges::to proposal for how many corner cases are there to consider), 
and there's indeed already ranges-v3::to as the ready-made solution (so 
why spending time redoing it).


Huh?

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()}; }

What was so hard about that? If that's wrong, then so AFAICT is the 
deprecation message.


Yes, it does not generalize to every possible container type, but I 
don't know that anyone is asking for that (and I agree we shouldn't try 
to support that). We're not talking about adding many, many variations 
upon this theme, just *not* removing the ones that already existed. The 
ones that do exist, exist because they are more convenient to use, and 
because they cover *the most common* use cases.


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.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods

On 3/24/21 6:00 AM, Volker Hilsheimer wrote:

Who said anything about "ever?" Or even "last year." Have you never built
anything that is actually finished, and stays finished, and relevant, and functional for 10, 20, 30
years? Granted, if I get 10 years of use out of anything built in this century, I do consider it a
minor victory. So maybe that's my answer.

There are evidently (form what has been written here, and from my personal
experience of working in and with financial, medical, and telko) industries
that prefer 30 year old security issues in their devices over establishing a
process that allows them to continuously update their software stack. In which
case, yes I personally do think they are missing the point of “software”, and
I’m happy that our way of developing Qt is not constrained by those industries.

Those would be your customers. 30 year old security issues tend to be
easily plugged or otherwise defended against. There is no defense
against the relentless stream of new security vulnerabilities, bugs, and
crashes brought about by continuous integration and deployment.

The Wild Wild West coding style really does kill people. A blue screen
of death on your heart surgery robot mid-surgery generally results in a
real death.

Yes it’s great if stuff that some of the stuff I built 30 years ago still works
(at least I assume it does; I’d have to find a working floppy drive, and a DOS
emulator with Turbo Pascal). But then I don’t expect it to look and feel great
on the latest macOS version.

I don't have to. The Parts Order Routing System at Navistar has been
making sure trucks have the parts and maintenance items they need to
keep bringing food to your store, supplies to your construction sites
and service vehicles for when your power lines go down. It is also
keeping the fire engines and pump trucks in many/most places running,
not to mention keeping the Blue Bird buses safe and operational hauling
your kids to school.

The trading floor system at the Chicago Stock Exchange I first worked on
in the late 1980s ran to 2005/6 when they got rid of the trading floor
to become an all electric stock exchange.

To be honest, many of those bugs are really hard to fix without breaking
anything else, so often we decide that a known, well-documented bug is
preferable to a bunch of new, unknown bugs that a fix might introduce.

You knowingly create 30 year old security issues and you diss your
customers who have worked around theirs.

I'd go on to explain that not everyone who uses Qt, lives and breathes Qt,
finds it endlessly fascinating, nor has time to conform to your strict and
relentless release schedule to evaluate every nuance of massive API changes,
etc, etc.

Apropos generalising. Are we still talking about the first release in 7 years
where APIs were changed?

FWIW, so far the substance of this discussion seems to boil down to

* the old QList implementation being gone
* toContainer convenience methods removed
* references to QHash entries no longer stable when the hash is mutated

You forgot customer abandonment

death of OpenSource LTS

Qt 6 being useless

QML needing to be ripped out.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Benjamin TERRIER

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 conclusion reached, unfortunately, and didn't manage to
> provide a replacement in time. I was (and still am) afraid at simply
> reintroducing .to() functions.
>
> One reason is purely API quality: implementing them "correctly" in
> C++14/17 without ranges/concepts is not exactly funny (just look at the
> ranges::to proposal for how many corner cases are there to consider),
> and there's indeed already ranges-v3::to as the ready-made solution (so
> why spending time redoing it).
> Given a half-cooked solution wouldn't be acceptable into QtCore, we'd
> need to put it somewhere else where we could be more flexible in terms
> of minor API breaks if we think we did a mistake, and we didn't find the
> right place. (KDToolBox comes to mind, eventually).
>
> 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 bad coding
> practices?
>
>
To be fair, most of the times I have encountered them, it was related to
some kind of algorithmic abuse.
The issue is that, once the abuse has lived for many years in the code
base, fixing it is not a priority.

In the end, even if the base issue is algorithmic abuse, the pain the
developers feel comes from Qt removing the API.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/24/21 6:00 AM, interest-requ...@qt-project.org 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


No, it's not. It only seems correct if you live in a world where nothing 
lasts six months.


Out in the real product world you create some product using Qt 3.x or 
4.2. That product goes to production where it remains for 7-15+ years.


Now the product needs to be redeveloped/enhanced because the benefits 
now outweigh the costs of spin-up. It hits start of new life when Qt 5 
LTS is flushed down the toidy and Qt 6 is an Easter Seals child.


The very first time you find out everything that got nuked is today.

This isn't mythical.

HCL was again late last year shopping around the Qt 3 & OS/2 medical 
device contract. The client is actually thinking of biting the upgrade 
bullet. Don't know who the client is. HCL was shopping around illegal 
alien wages as usual. It will be 8-12 months before they get up to my 
billing rates.


Several months ago I had a phone call and several emails with the 
founder of a company that is doing quite well with a product that is a 
shining symbol in the world indicating some people in the world make too 
damned much money. As of our last conversation they had yet to pull the 
trigger on a new Qt resource for the rewrite. Their product is also 
using Qt 3.


Given the current state of Qt and the willy-nilly nuking of things, both 
of these companies are going to have to go with CopperSpice or some 
other competitor. Qt 6 isn't usable and Qt 5 has no LTS unless they want 
to support the ex-wife in a manner she would like to become accustomed to.


https://youtu.be/8mLQ_fyiWIs


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/24/21 6:00 AM, Bernhard Lindner wrote:

The Wolfe oven needed a stacked widget, not a state machine. Project craters 
like these
aren't helping the reputation of Qt.

Can you explain that? I have seen software going down the drain because people 
didn't use
state machines. I have seen software using state machines without urgend need. 
But I have
never seen a software that failed*due to*  using state machines (at least not 
when fully
understood).


It was the wrong tool for the job is why it failed. But, Digia had 
recently added the state machine and was selling training in it, 
therefore, that must have been the hammer to hit all nails with.


The developer tried to run the __ENTIRE__ display with a state machine. 
This was a multi-oven high end thing with hundreds of configurations 
that had very little to do with cooking yet impacted cooking.


There were modes for every religious holiday where only limited 
work/activities are allowed. There were safety alarms that could be 
configured to pop up say, when an oven had cooled down enough to touch 
the inside. The various oven timers could be configured to display 
over-top of whatever screen was up, including the configuration screens.


Anyone who even glanced at the wire frame would instantly realize this 
was a stacked widget under/above/beside a reserve bar.


Yes, the tiny subset of the actual cooking process:

start timer fire

pre-heat

alarm for food insertion

auto-start timer and food temp monitor

alarm completion reduce to warming

open door oven off

monitor for safety until cool


That can definitely be a state machine and it also isn't running a 
screen, just signalling out.


I haven't found any significant UI that can really be a state machine. 
Yes, a simple menu ala COBOL green screen days, but touch screens 
subject to human whim, nah. You always end up with


On Thursdays, when it rains and Fred is at the keyboard - do this

logic.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-24 Thread Giuseppe D'Angelo via Interest


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 simply 
reintroducing .to() functions.


One reason is purely API quality: implementing them "correctly" in 
C++14/17 without ranges/concepts is not exactly funny (just look at the 
ranges::to proposal for how many corner cases are there to consider), 
and there's indeed already ranges-v3::to as the ready-made solution (so 
why spending time redoing it).
Given a half-cooked solution wouldn't be acceptable into QtCore, we'd 
need to put it somewhere else where we could be more flexible in terms 
of minor API breaks if we think we did a mistake, and we didn't find the 
right place. (KDToolBox comes to mind, eventually).


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 bad coding 
practices?


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-24 Thread Benjamin TERRIER

On Wed, 24 Mar 2021 at 10:40, Konrad Rosenbaum  wrote:

>
> It is possible to use software with an anti-tivo license in critical
> systems, it just requires you to use your brain before deploying it in
> your device. Question is whether you wouldn't want to use something else
> anyway, because you need hard, certified real time capabilities.
>
>
Also the anti-tivo clauses of the GPLv3/LGPLv3 are only about "User
Products":

  A "User Product" is either (1) a "consumer product", which means any
> tangible personal property which is normally used for personal, family,
> or household purposes, or (2) anything designed or sold for incorporation
> into a dwelling.


So most industry products are left untouched by the anti-tivo clauses.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-24 Thread Volker Hilsheimer

> On 24 Mar 2021, at 08:43, Max Paperno  wrote:
> On 3/23/2021 11:44 AM, Volker Hilsheimer wrote:
> ...
>> I personally wonder why people that never want to change what they built 
>> last year want to develop software development. Isn’t that what makes 
>> building stuff out of bits and ideas so much more interesting  than building 
>> stuff out of sticks and stones?
> 
> Wow. Really?  First of all, sheesh, generalize much?

Yes, isn’t that what this thread is for?

“Qt never fixes any bugs”
“QML is horrible, we need to rip it out”
“None of the people that have worked on Qt for the last 25 years can be part of 
this"
“Every change is harmful"

:P

> Who said anything about "ever?"  Or even "last year."  Have you never built 
> anything that is actually finished, and stays finished, and relevant, and 
> functional for 10, 20, 30 years?  Granted, if I get 10 years of use out of 
> anything built in this century, I do consider it a minor victory.  So maybe 
> that's my answer.

There are evidently (form what has been written here, and from my personal 
experience of working in and with financial, medical, and telko) industries 
that prefer 30 year old security issues in their devices over establishing a 
process that allows them to continuously update their software stack. In which 
case, yes I personally do think they are missing the point of “software”, and 
I’m happy that our way of developing Qt is not constrained by those industries.

Yes it’s great if stuff that some of the stuff I built 30 years ago still works 
(at least I assume it does; I’d have to find a working floppy drive, and a DOS 
emulator with Turbo Pascal). But then I don’t expect it to look and feel great 
on the latest macOS version.

I am pretty certain that - as long as you don’t upgrade any part of your 
software stack including the OS - then the Qt application you build today will 
run just as fine in 30 years as it does today.

> Clearly Qt devs don't find fixing 5000+ outstanding P2+ bugs all that 
> interesting either.

According to JIRA, we (the entire community of contributors) addressed 240 
issues reported to us by customers through our support team in the last 90 
days. And a whole bunch more that were reported by Open Source users.

Yes there are plenty more to go around. Yes, some of them are pretty old. To be 
honest, many of those bugs are really hard to fix without breaking anything 
else, so often we decide that a known, well-documented bug is preferable to a 
bunch of new, unknown bugs that a fix might introduce.

> And I personally find building things out of "sticks and stones" immensely 
> interesting and satisfying (assuming it works in the end :). There's no undo 
> or backups, just your skill in the moment. Not to mention very practical, as 
> all those bits and ideas would have nowhere to go otherwise. Comparing 
> physical building to digital creation (which I also enjoy a lot) is only 
> relevant in the most basic sense of "building" in that both require some 
> plan/vision and tools/skills to execute it (and in the end hopefully you get 
> something useful or enjoyable). Otherwise, not even close.

Same here. Just digging a hole in the garden can be very satisfying after a day 
of writing (code, or emails) :P

> I'd go on to explain that not everyone who uses Qt, lives and breathes Qt, 
> finds it endlessly fascinating, nor has time to conform to your strict and 
> relentless release schedule to evaluate every nuance of massive API changes, 
> etc, etc.

Apropos generalising. Are we still talking about the first release in 7 years 
where APIs were changed?

FWIW, so far the substance of this discussion seems to boil down to

* the old QList implementation being gone
* toContainer convenience methods removed
* references to QHash entries no longer stable when the hash is mutated

> You rushed Qt6 out the door, contrary to what even some of your core 
> contributors suggested, with the premise that "now we'll get some feedback."  
> Well there you go, you're getting it now. For many/most I think Qt is a tool, 
> like a very fancy hammer. If Estwing decided to remove the claw from their 
> "new streamlined" framing hammers, then made the clawed hammers cost $1000, I 
> bet they'd get about the same reaction as you're getting now.

Maurice gave the rationale on why Qt 6 was released with a subset of core 
modules. For the technical side of things, we are getting feedback, it’s 
useful, and it’s mostly encouraging.

For feedback regarding the licensing changes made that context (including 
5.15), I’d suggest you go back to the respective email thread if you just want 
to vent, or call your sales rep in The Qt Company.

Cheers,
Volker

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-24 Thread Max Paperno



On 3/23/2021 11:44 AM, Volker Hilsheimer wrote:
...


I personally wonder why people that never want to change what they built last 
year want to develop software development. Isn’t that what makes building stuff 
out of bits and ideas so much more interesting  than building stuff out of 
sticks and stones?


Wow. Really?  First of all, sheesh, generalize much? Who said anything 
about "ever?"  Or even "last year."  Have you never built anything that 
is actually finished, and stays finished, and relevant, and functional 
for 10, 20, 30 years?  Granted, if I get 10 years of use out of anything 
built in this century, I do consider it a minor victory.  So maybe 
that's my answer.


Clearly Qt devs don't find fixing 5000+ outstanding P2+ bugs all that 
interesting either.


And I personally find building things out of "sticks and stones" 
immensely interesting and satisfying (assuming it works in the end :). 
There's no undo or backups, just your skill in the moment. Not to 
mention very practical, as all those bits and ideas would have nowhere 
to go otherwise. Comparing physical building to digital creation (which 
I also enjoy a lot) is only relevant in the most basic sense of 
"building" in that both require some plan/vision and tools/skills to 
execute it (and in the end hopefully you get something useful or 
enjoyable). Otherwise, not even close.


I'd go on to explain that not everyone who uses Qt, lives and breathes 
Qt, finds it endlessly fascinating, nor has time to conform to your 
strict and relentless release schedule to evaluate every nuance of 
massive API changes, etc, etc. You rushed Qt6 out the door, contrary to 
what even some of your core contributors suggested, with the premise 
that "now we'll get some feedback."  Well there you go, you're getting 
it now. For many/most I think Qt is a tool, like a very fancy hammer. 
If Estwing decided to remove the claw from their "new streamlined" 
framing hammers, then made the clawed hammers cost $1000, I bet they'd 
get about the same reaction as you're getting now.


"All the planning charts and demolition orders have been on display at 
your local planning department in Alpha Centauri for 50 of your Earth 
years, so you've had plenty of time to lodge any formal complaint and 
it's far too late to start making a fuss about it now." -Douglas Adams


But I think I'm wasting my time.

-Max


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-23 Thread Thiago Macieira

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 message in interest saying "Hey! We are about to nuke this, is anyone
> actually using it?"

The exact opposite is the correct thing:
 - deprecation messages while compiling the source code are correct
 - messages to the mailing list are not sufficient

The sample of developers in this mailing list is far too small. Any reply we 
got from here would not be significative. Warnings posted here would not reach 
the majority of the audience either.

But creating warnings when you compile your code is a good way to let people 
know that they have to take action at some time. No function can be removed 
until the next major version, so you have until then to figure out.

At that point, the decision has already been made. I am not discussing how to 
make the decision on deprecation. That's not a vote either: we don't remove 
things because we think no one uses them, with very few exceptions (like 
QLinkedList). We remove things because they are badly named, have flawed API 
or design, result in improper code, make progress impossible otherwise, etc.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods

2021-03-23 Thread Thiago Macieira

On Monday, 22 March 2021 14:29:14 PDT Thorsten Glaser wrote:
> On Mon, 22 Mar 2021, Thiago Macieira wrote:
> > accomplish the same goal. As shown by the example of the KWallet CLI,
> > there
> > may be a much better and much simpler solution once the need is
> > understood.
> 
> I wouldn’t call shouting “API abuse!” at me a “much better” solution.
> I’m a user here, neither a KDE nor Qt developer, not even really a C++
> developer (I *do* C).

The much better solution was to understand that you didn't have to abuse the 
API, and instead you can simply pass 0.

You hadn't understood the API that you were using, possibly because it wasn't 
properly documented and, as you said you're not a C++ developer, you couldn't 
read the source code for the target function. So you didn't know how to do 
what you wanted and you didn't even know you were abusing the API. But that 
doesn't make what I said any less valid: once we understood what you needed to 
do, we could help you find a better solution.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Bernhard Lindner


> I don't know about other parts of the world, but in the U.S.A. the FDA 
> is very adamant. Only the binary set that they have tested gets installed.

Pretty much the same in Germany. Also for other safety related (non-medical) 
industries.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Bernhard Lindner

> Raise your hands.
> 
> How many of you have reported bugs that have sat open for over a year?

A year? LOL. 1 year is the age of the newest unresolved issue I have. Most of 
them are
many years old, including multiple issues dated 2012.

> Raise your hands.
> 
> How many of you have bugs reported against earlier versions of Qt that sat 
> open until
> they were closed as being against an unsupported version?

Actually this did not happen to me as far as I can remember. LOL! Probably 
because most of
my unresolved issue are rotting in the issue tracker as "Reported" and are 
ignored
forever.

> How many of you have had to scrap products or features because bugs you 
> reported were
> blockers and they were just rotting in the bug database? How many of those 
> bugs are
> still rotting?

Not scraped anything. But rewritten a lot. Hunted long known bugs. Reinvented 
the wheel
and wrote horrible work arounds.

> The only thing that is going to work for the big ticket companies is a 100% 
> commercial
> product that happens to release its older stuff as OpenSource and sometimes 
> accepts
> software developed by others for free. Nobody wants to hear that, but that is 
> the only
> model that works. With that model comes fixing all bugs inside 90 days. None 
> of this
> hoping someone in the OpenSource community fixes it for free.

You are right. But that has nothing to do with "Open Source" in the first 
place. I have
seen larger companies that insisted in "Open Source" for critical components - 
still with
the full, the reliably commercial support you are talking about. I think you 
are mixing
"Open Source" and "Community driven" here.

> That QML stuff really has to be ripped out and put into its own commercial 
> package so
> the rest of the world doesn't have to pay the heavy price. 

+1

> The Wolfe oven needed a stacked widget, not a state machine. Project craters 
> like these
> aren't helping the reputation of Qt.

Can you explain that? I have seen software going down the drain because people 
didn't use
state machines. I have seen software using state machines without urgend need. 
But I have
never seen a software that failed *due to* using state machines (at least not 
when fully
understood).

> Roughly half of my bugs reported via the forum are fixed within a couple of 
> days.

Seriously? Wow. What kind of bugs? What impact?

> Phones only care about what is shipping next week.
> As I said before, those are diametrically opposed markets.

I agree?

> Just my 0.0002 cents.

How do to change that? LOL, SCNR

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Maurice Kalinowski



> -Original Message-
> From: Sérgio Martins 
> Sent: Dienstag, 23. März 2021 20:40
> To: Maurice Kalinowski 
> Cc: Matthew Woehlke ; Volker Hilsheimer
> ; Qt Interest 
> Subject: Re: [Interest] The willy-nilly deletion of convenience, methods
> 
> On Tue, Mar 23, 2021 at 6:23 PM Maurice Kalinowski
>  wrote:
> >
> > >
> > > Not all deprecations are bad. However, I still maintain that *some*
> > > of the Qt
> > > 6 changes are problematic. Also, TBH, I think the real issue is less
> > > that Qt 6 made changes, and more that Qt 5 support got pulled well
> > > before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5.
> > >
> > > I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff
> > > that was immediately removed in Qt 5.0, although I may be wrong about
> that.
> > >
> > [Maurice Kalinowski]
> > There was, plenty of them, more than from Qt 5 to Qt 6.
> > And even more so, we had not the time to do deprecation warnings, like
> you can enable now when building against 5.15.
> > Hence, the migration should be (and according to user discussions is) much
> easier for this major release.
> >
> > Another aspect I would like to reiterate is why not all modules are 
> > available
> with the initial 6.0 release.
> >
> > For Qt 5.0 we tried to get everything over in one big go. The problem was
> that many of the features and behavior changes did not get fully executed
> through the leaf modules. That led to the situation that we couldn't do many
> modernizations afterwards again due to binary compatibility promises in the
> Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used
> modules.
> > From there get verification by users, that the changes have been in the
> right direction and broaden the module support then. As that allows to focus
> on bringing over modernization to those leaf modules, but also have
> dedicated time to modernize these as well.
> >
> > From what we've seen on reviews on blogs/articles/tweets/... this
> approach works. Admittedly, with not everyone being able to migrate as of
> now. But I strongly believe that with 6.2 we will have a much better Qt
> compared to taking the same approach as with Qt 4->5, even at 5.2 times.
> 
> That's not a fair comparison.

And I don't think it is fair to now merge a separate discussion into this. 
Generally, this thread contains way too many topics at once to be able to keep 
a streamlined discussion.


> After Qt 5.0 was released in 2012 we still saw several Qt 4 bugfix releases 
> (up
> until 2015).
> With the situation now, we're in a limbo, there's no 6.2 and there's no Qt5
> open-source bugfix releases.
> 

I can see this concern from your side, totally. But as mentioned above, I 
commented on the part whether removals have happened between Qt 4 and 5. And 
they did, in worse fashion.

Maurice
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Sérgio Martins

On Tue, Mar 23, 2021 at 6:23 PM Maurice Kalinowski
 wrote:
>
> >
> > Not all deprecations are bad. However, I still maintain that *some* of the 
> > Qt
> > 6 changes are problematic. Also, TBH, I think the real issue is less that 
> > Qt 6
> > made changes, and more that Qt 5 support got pulled well before Qt 6 is
> > viable for most folks. That didn't happen with Qt 4 → 5.
> >
> > I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was
> > immediately removed in Qt 5.0, although I may be wrong about that.
> >
> [Maurice Kalinowski]
> There was, plenty of them, more than from Qt 5 to Qt 6.
> And even more so, we had not the time to do deprecation warnings, like you 
> can enable now when building against 5.15.
> Hence, the migration should be (and according to user discussions is) much 
> easier for this major release.
>
> Another aspect I would like to reiterate is why not all modules are available 
> with the initial 6.0 release.
>
> For Qt 5.0 we tried to get everything over in one big go. The problem was 
> that many of the features and behavior changes did not get fully executed 
> through the leaf modules. That led to the situation that we couldn't do many 
> modernizations afterwards again due to binary compatibility promises in the 
> Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used 
> modules.
> From there get verification by users, that the changes have been in the right 
> direction and broaden the module support then. As that allows to focus on 
> bringing over modernization to those leaf modules, but also have dedicated 
> time to modernize these as well.
>
> From what we've seen on reviews on blogs/articles/tweets/... this approach 
> works. Admittedly, with not everyone being able to migrate as of now. But I 
> strongly believe that with 6.2 we will have a much better Qt compared to 
> taking the same approach as with Qt 4->5, even at 5.2 times.

That's not a fair comparison.
After Qt 5.0 was released in 2012 we still saw several Qt 4 bugfix
releases (up until 2015).
With the situation now, we're in a limbo, there's no 6.2 and there's
no Qt5 open-source bugfix releases.

Very unfortunate timing.
What's sad, is that this probably wasn't done by incompetence, but
intentionally: Cripple the open-source version to make the commercial
offering look better.
Prioritizing short term profits over long term.

And it's ironic, the commercial offering wouldn't be so good if it
wasn't for the open source version (and vice-versa). Each made the
other grow.


Regards,
Sérgio
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Maurice Kalinowski

> 
> Not all deprecations are bad. However, I still maintain that *some* of the Qt
> 6 changes are problematic. Also, TBH, I think the real issue is less that Qt 6
> made changes, and more that Qt 5 support got pulled well before Qt 6 is
> viable for most folks. That didn't happen with Qt 4 → 5.
> 
> I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was
> immediately removed in Qt 5.0, although I may be wrong about that.
> 
[Maurice Kalinowski] 
There was, plenty of them, more than from Qt 5 to Qt 6.
And even more so, we had not the time to do deprecation warnings, like you can 
enable now when building against 5.15.
Hence, the migration should be (and according to user discussions is) much 
easier for this major release.

Another aspect I would like to reiterate is why not all modules are available 
with the initial 6.0 release.

For Qt 5.0 we tried to get everything over in one big go. The problem was that 
many of the features and behavior changes did not get fully executed through 
the leaf modules. That led to the situation that we couldn't do many 
modernizations afterwards again due to binary compatibility promises in the Qt 
5 series. Thus, the approach was/is to have 6.0 with the set of most used 
modules.
From there get verification by users, that the changes have been in the right 
direction and broaden the module support then. As that allows to focus on 
bringing over modernization to those leaf modules, but also have dedicated time 
to modernize these as well.

From what we've seen on reviews on blogs/articles/tweets/... this approach 
works. Admittedly, with not everyone being able to migrate as of now. But I 
strongly believe that with 6.2 we will have a much better Qt compared to taking 
the same approach as with Qt 4->5, even at 5.2 times.

BR,
Maurice

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods



On 3/23/2021 11:47 AM, Jason H wrote:


QML is a binding environment, and a handy one at that. It is not just GUI.
I have Websocket servers that interact with non-visual classes with bindings
provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2
are pretty bad, but I think things are getting better.
You think it is great. My world knows it to be useless trash ruining the 
product. Your world is completely different than mine. I've had to sweep 
up behind people who thought they could use QML and JavaScript for 
medical device work. More specifically, like 90% of the device.

It is irreparable at this point. Whatever Qt becomes, it cannot have any
current or former Digia people involved. Deep pocket customers won't
come back. The Digia crew is 0 for 2.

It's reparable. Such things can be fixed with a stroke of a pen, like
when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is
running Qt as an open source project into the ground.
I wasn't talking about the license. The *reputation* of Qt is not 
fixable at this point. If 100% of the bugs were fixed tomorrow and the 
license was done correctly, a huge chunk of the market is __still__ not 
coming back all because of wretched management and worthless decisions.

I liked QML as a way to get those JS devs into Qt.


Cheap and putting out low quality systems. That's a market where no 
matter how much you pay you can't buy good.




I believe that if we could pull that off, Qt can still have a bright
future.

We can't.

The thing has to fork and split.

I really hate fragmentation. I'd rather convince Digia that their
licensing decisions are ultimately hurting the community and sales.


But the embedded market wants QML in its own hermetically sealed 
environment with all contaminants removed from the C++ code.


Removal of QML and an intelligent license is why CopperSpice now has a 
lot of former Qt customers.



I like Jason. He's a nice guy, but he wants to use Qt on phones and to
have QML. He's not alone. That's how this got so busted in the first
place. That write-once-run-anywhere myth surrounding Java back in the day.

As someone who has done it, it's not myth*
*for parts that Qt supports, but not nearly enough is supported on mobile.

Yeah. "Hello World!" works! :)



The OpenSource community was blind, deaf, and dumb when they railed
against Tivo locking down their devices and came up with all of these
poisoned pills in OpenSource licenses mandating users be able to modify
the software.

In medical devices, that's illegal.

In industrial control systems where SAFETY is mandated, that's illegal.

Not exactly. To use it comply with the license and you would have to
provide configuration management and source to generate the same binary.


You misinterpret what I mean by illegal. Understandable since we've been 
talking software license.


If I'm an employee of St. Nowhere Hospital and I pull down the latest 
OpenSSL (or whatever) OpenSource Linux library because I think it is 
needed and install it on an FDA tested and approved medical device the 
*act* of doing that is a crime. The device doesn't even have to be used, 
just remain in the hospital or other medical facility where it *could* 
be used.


I don't know about other parts of the world, but in the U.S.A. the FDA 
is very adamant. Only the binary set that they have tested gets installed.


Now, if the device gets used you are looking at a minimum of attempted 
manslaughter.  If there is an "adverse outcome" and where you live has a 
really good prosecutor, you could be facing murder one.


I don't remember what the regulations/legal liability is for industrial 
control where SAFETY in mandated but it isn't far off. If you tweak the 
firmware on something like the safety sensors that drop the steel safety 
nets in a paper mill, guys can literally get cut in half in a fraction 
of a second. The nets and sensors are there to stop that.


Any new/different OpenSource license __MUST__ remove the Tivo poison 
pill at least for the regulated environments where physically changing 
the software is illegal.


Hey, you want to hose up your own Tivo, have at it. You just won't get 
to watch TV. You hose up the surgical robot they are going to use for my 
mom's open heart surgery I'll throw the lever in that chamber myself and 
sleep good that night. Your "rights" just needlessly took an innocent 
life. I can forgive a drunk driver easier than I can forgive you.





No, I don't for a moment think QML is on that list :-).

+1000


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread dbeancoltd--- via Interest

Shut up you fucking cunts
Dennis Bean
Director
Dennis B Building Contractors Ltd62 Athol SquareLondonE14 0NPTel: 0207 538 
1437Fax: 0207 538 4957
dbeanco...@aol.com

On Tuesday, March 23, 2021, 04:48:10 PM GMT, Jason H  wrote: 

 > Now, the "commercial license" simply could be the Boot2Qt stuff with all
> of Qt being 100% OpenSource. This would provide additional incentive to
> rip QML out so it isn't bastardizing the rest of the product and QML
> could then be its own commercial thing, just for phones. I have lost
> track of other little things that Digia might have spun up for
> additional cash.

QML is a binding environment, and a handy one at that. It is not just GUI.
I have Websocket servers that interact with non-visual classes with bindings
provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2
are pretty bad, but I think things are getting better.

> > I'm not actually convinced that paying Qt customers aren't getting the
> > support they paid for; that information is generally not going to be
> > publicly available.
>
> Pull down a couple years worth of the interest archives and unzip them
> into a directory. Let grep search for bug or customer.

As a multiple-time commercial customer the bug/issue support has been great,
but the meta-narrative (previously Mobile in nature) was very lacking.
Lars/Digia is going to to do what they want, and Open Governance is a joke.

> https://lists.qt-project.org/pipermail/interest/
>
> The complete information will never be publicly available but many
> paying customers have come here to bitch about bugs open for over a year.

Not just a year, try 3. I usually was able to come up with a work-around
so that I was not blocked for 3 years though. The more critical stuff did
get fixed timely.

> > What *is* broken is the alimony licensing model and all the
> > fear-mongering around the licensing terms.
> +12
> > *Proper* commercial support for open source products lets you try
> > before you buy with no punishment afterward, no penalties if you want
> > to drop support later, or drop it and pick it up again. You pay, you
> > get support, *period*.
> +24
> >
> > For that matter, it seems like Qt's commercial model is working just
> > fine *for them*, at least at the moment. Ironically, the arguments you
> > are making probably are *why* it's working. The problem is that
> > they're busy killing the community and doing severe, possibly
> > irreparable damage to Qt's reputation.
> It is irreparable at this point. Whatever Qt becomes, it cannot have any
> current or former Digia people involved. Deep pocket customers won't
> come back. The Digia crew is 0 for 2.

It's reparable. Such things can be fixed with a stroke of a pen, like
when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is
running Qt as an open source project into the ground. They (IMO) don't see
opensource as a way cultivate an ecosystem that pumps the sales pipeline.
And they won't question it until the big customers dry up, look to the
community and realize they turned everyone off from it and they already
went to HTML5, where HTML/JS people are cheap and plentiful. Meanwhile
their C++ tooklit gets them a steady decline:
https://www.tiobe.com/tiobe-index/cplusplus/ that peaked 20 years ago.

I liked QML as a way to get those JS devs into Qt. They are familiar
with JS bindings, be them React, Angular, Knockout, Vue, etc.
PySide seems to be well-informed because that's the only language
(Python) that is steadily increasing.

They do seem to know HTML5 is a threat (they have whitepapers on it)
but have yet to really take it on meaningfully.

> >> It's highly doubtful that any company could pull in the staff to
> >> maintain all of the markets and eliminate all of the bugs, but that
> >> would have to be the starting point for such a venture.
> >
> > Right, which is why we *need* a community, or a consortium, or
> > something of that nature. We need everyone that cares about what Qt
> > *could* be, without Digia's efforts to break it, to pool their resources.
> >
> > I believe that if we could pull that off, Qt can still have a bright
> > future.
>
> We can't.
>
> The thing has to fork and split.

I really hate fragmentation. I'd rather convince Digia that their
licensing decisions are ultimately hurting the community and sales.

> I like Jason. He's a nice guy, but he wants to use Qt on phones and to
> have QML. He's not alone. That's how this got so busted in the first
> place. That write-once-run-anywhere myth surrounding Java back in the day.

As someone who has done it, it's not myth*
*for parts that Qt supports, but not nearly enough is supported on mobile.

> The OpenSource community was blind, deaf, and dumb when they railed
> against Tivo locking down their devices and came up with all of these
> poisoned pills in OpenSource licenses mandating users be able to modify
> the software.
>
> In medical devices, that's illegal.
>
> In industrial control syste

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Jason H

> Now, the "commercial license" simply could be the Boot2Qt stuff with all
> of Qt being 100% OpenSource. This would provide additional incentive to
> rip QML out so it isn't bastardizing the rest of the product and QML
> could then be its own commercial thing, just for phones. I have lost
> track of other little things that Digia might have spun up for
> additional cash.

QML is a binding environment, and a handy one at that. It is not just GUI.
I have Websocket servers that interact with non-visual classes with bindings
provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2
are pretty bad, but I think things are getting better.


> > I'm not actually convinced that paying Qt customers aren't getting the
> > support they paid for; that information is generally not going to be
> > publicly available.
>
> Pull down a couple years worth of the interest archives and unzip them
> into a directory. Let grep search for bug or customer.

As a multiple-time commercial customer the bug/issue support has been great,
but the meta-narrative (previously Mobile in nature) was very lacking.
Lars/Digia is going to to do what they want, and Open Governance is a joke.

> https://lists.qt-project.org/pipermail/interest/
>
> The complete information will never be publicly available but many
> paying customers have come here to bitch about bugs open for over a year.

Not just a year, try 3. I usually was able to come up with a work-around
so that I was not blocked for 3 years though. The more critical stuff did
get fixed timely.

> > What *is* broken is the alimony licensing model and all the
> > fear-mongering around the licensing terms.
> +12
> > *Proper* commercial support for open source products lets you try
> > before you buy with no punishment afterward, no penalties if you want
> > to drop support later, or drop it and pick it up again. You pay, you
> > get support, *period*.
> +24
> >
> > For that matter, it seems like Qt's commercial model is working just
> > fine *for them*, at least at the moment. Ironically, the arguments you
> > are making probably are *why* it's working. The problem is that
> > they're busy killing the community and doing severe, possibly
> > irreparable damage to Qt's reputation.
> It is irreparable at this point. Whatever Qt becomes, it cannot have any
> current or former Digia people involved. Deep pocket customers won't
> come back. The Digia crew is 0 for 2.

It's reparable. Such things can be fixed with a stroke of a pen, like
when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is
running Qt as an open source project into the ground. They (IMO) don't see
opensource as a way cultivate an ecosystem that pumps the sales pipeline.
And they won't question it until the big customers dry up, look to the
community and realize they turned everyone off from it and they already
went to HTML5, where HTML/JS people are cheap and plentiful. Meanwhile
their C++ tooklit gets them a steady decline:
https://www.tiobe.com/tiobe-index/cplusplus/ that peaked 20 years ago.

I liked QML as a way to get those JS devs into Qt. They are familiar
with JS bindings, be them React, Angular, Knockout, Vue, etc.
PySide seems to be well-informed because that's the only language
(Python) that is steadily increasing.

They do seem to know HTML5 is a threat (they have whitepapers on it)
but have yet to really take it on meaningfully.

> >> It's highly doubtful that any company could pull in the staff to
> >> maintain all of the markets and eliminate all of the bugs, but that
> >> would have to be the starting point for such a venture.
> >
> > Right, which is why we *need* a community, or a consortium, or
> > something of that nature. We need everyone that cares about what Qt
> > *could* be, without Digia's efforts to break it, to pool their resources.
> >
> > I believe that if we could pull that off, Qt can still have a bright
> > future.
>
> We can't.
>
> The thing has to fork and split.

I really hate fragmentation. I'd rather convince Digia that their
licensing decisions are ultimately hurting the community and sales.

> I like Jason. He's a nice guy, but he wants to use Qt on phones and to
> have QML. He's not alone. That's how this got so busted in the first
> place. That write-once-run-anywhere myth surrounding Java back in the day.

As someone who has done it, it's not myth*
*for parts that Qt supports, but not nearly enough is supported on mobile.

> The OpenSource community was blind, deaf, and dumb when they railed
> against Tivo locking down their devices and came up with all of these
> poisoned pills in OpenSource licenses mandating users be able to modify
> the software.
>
> In medical devices, that's illegal.
>
> In industrial control systems where SAFETY is mandated, that's illegal.

Not exactly. To use it comply with the license and you would have to
provide configuration management and source to generate the same binary.
However it would be a huge risk on their part to us

Re: [Interest] The willy-nilly deletion of convenience, methods


On 23/03/2021 11.44, Volker Hilsheimer wrote:

I wished I had seen the level of energy y’all are putting right now
into this email thread over the last two years when we discussed
where to go with Qt 6, and when the work actually happened.
IIRC, I complained plenty about QList at the time. I wouldn't be 
surprised if I complained about QHash also.


One of the reasons I don't try to contribute more than I do is because, 
when I *have* contributed patches, it hasn't accomplished anything.



So far, all I've seen is "C++ also deprecates stuff". You haven't
shown that the deprecations are actually *harmful* to the C++
community. >

Personally, I’m siding with those folks in the committee that
believe that not changing things (ref ABI discussion) is more harmful
than if we’d be able to fix now and again what is objectively
broken.


Likewise.

I've even said before that it might be beneficial if C++ could more 
aggressively deprecate bad stuff, even mentioning Qt as an example to 
follow.


Not all deprecations are bad. However, I still maintain that *some* of 
the Qt 6 changes are problematic. Also, TBH, I think the real issue is 
less that Qt 6 made changes, and more that Qt 5 support got pulled well 
before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5.


I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that 
was immediately removed in Qt 5.0, although I may be wrong about that.


I personally wonder why people that never want to change what they 
built last year want to develop software development. Isn’t that

what makes building stuff out of bits and ideas so much more
interesting than building stuff out of sticks and stones?


Is this really so surprising? People want to spend their time making 
*their* software better, not chasing an ever-shifting foundation on 
which their software is *built*.


Time spent adapting to library changes, especially changes seen as 
unnecessary or actively harmful, is time *not* spent developing new and 
exciting features, or even squashing existing bugs.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience,, methods



On 3/23/2021 8:24 AM, interest-requ...@qt-project.org wrote:

Having read this entire conversation I find it interesting that we as 
developers are complaining about features being deprecated and removed in Qt 
but yet where is the anger when C++ spec removes features?

  


https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation
Don't know of anybody that actually used any of that. volatile was 
"iffy" the day they added it to the language standard. The definition 
seemed to change compiler to compiler. Good riddance.


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed

Couldn't reach, but I only allow https anymore.


http://www.cplusplus2017.info/removed-features-from-c17/

Ditto

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed

  

Ditto

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Volker Hilsheimer

> On 23 Mar 2021, at 15:49, Matthew Woehlke  wrote:
> 
> On 23/03/2021 10.36, Benjamen Meyer via Interest wrote:
>> On 3/23/21 10:09 AM, Matthew Woehlke wrote:
>>> Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any
>>> change, not just on a mailing list, but in person. Anyone can, in theory
>>> (in practice, depending on where you live, there may be a non-trivial
>>> membership fee required) *vote* against a change. We, as the committee,
>>> generally try to be considerate of the community when making changes,
>>> and there is quite a lot of emphasis on not breaking existing code, even
>>> as far back as C++98.
>> How many C++ devs are on those?
> 
> Hundreds, which is probably more than the number of people making decisions 
> for Qt.
> 
>> Likely only those whose companies are paying them to be, and a few
>> that got there via academics (I've personally known and worked with
>> one person; outside of the folks I've seen here on the Qt lists.)
> 
> Even so, that's a lower bar than "you must be an employee of TQtC" (and even 
> that is probably not sufficient). The bar also happens to be much lower right 
> now due to COVID, since there are no in-person meetings happening.

I wished I had seen the level of energy y’all are putting right now into this 
email thread over the last two years when we discussed where to go with Qt 6, 
and when the work actually happened. Code and header reviews are all done in 
public, and it’s usually the same small handful of people that put an effort 
into those. And I’m extremely grateful to those people who do, and there were 
tons of occasion during the Qt 6 development where someone outside The Qt 
Company criticised a change, perhaps even -2’ed it, and made things better by 
putting their git (or at least gerrit) credentials next to their opinion.

Of course, The Qt Company paying several dozens of software engineers to work 
full-time on the various parts of Qt (the framework, the tools, the CI system) 
has a big momentum, and yes we have colleagues that can approve changes 
quickly. But the deprecations that seem to cause the most controversy right now 
- like removing toContainer helpers - were not implemented by a TQtC employee, 
and neither is the maintainer of the Qt Core module on TQtC payroll.

As the one who killed QDesktopWidget and a bunch of other, previously 
deprecated APIs for Qt 6 - I personally prefer to not have my code compile 
anymore if it wouldn't work as it needs to anyway. That’s better than code that 
builds, but doesn’t work, or doesn’t scale, or prevents long-term improvements. 
Yes, that’s to some degree my personal opinion, but it’s evidently also the 
general principle of The Qt Project (even if not written down in some quip or 
manifest) and it’s also the opinion of the folks in the Qt Project that +2’ed 
my changes.

Maybe ideally nobody would have to change anything ever, and we only get to use 
new things that work perfectly with the old stuff all the time. But knowing 
about what it costs to build software this way, we have decided that this is 
not how we are building Qt. This is not exactly a surprise, after 25 years and 
6 major Qt releases, all of which have removed old APIs.

> In any case, you've made an unsubstantiated allegation that the committee 
> does not care about C++ users.

And you have made the unsubstantiated claim that people outside of The Qt 
Company have no influence on the direction The Qt Project is (technically) 
taking - yes, the licensing shenanigans excluded.

> Please provide evidence to back that up. So far, all I've seen is "C++ also 
> deprecates stuff". You haven't shown that the deprecations are actually 
> *harmful* to the C++ community on anything like the scale to which Qt's 
> recent changes have been harmful.

Personally, I’m siding with those folks in the committee that believe that not 
changing things (ref ABI discussion) is more harmful than if we’d be able to 
fix now and again what is objectively broken.

> Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, 
> however, have caused major pain. Now you are apparently claiming that C++ is 
> "just as bad", but I have yet to see that claim substantiated.

I personally wonder why people that never want to change what they built last 
year want to develop software development. Isn’t that what makes building stuff 
out of bits and ideas so much more interesting  than building stuff out of 
sticks and stones?

Volker

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods


On 3/23/2021 8:57 AM, Matthew Woehlke wrote:

On 23/03/2021 06.59, Roland Hughes wrote:
30 years is __nothing__ for production systems. It is ordinary for a 
well developed system to run 10+ years without any modifications.


On that note, how many people are aware there's a computer that has 
been running non-stop for almost 45 years? :-D
Oh. Another DEC-ky Techie. Shouldn't say that too loud. One minor 
it, if that is the Irish Railway system. It's actually a cluster. Once 
every so many years they take one of the nodes down for hardware and 
other maintenance but the cluster operates the rail system 24x7x365 and 
change. If memory serves, up for 10 years before the first node got 
maintenance.


You kids and your uptime measured in hours...

+12


The Qt OpenSource model simply does not work. It cannot really be 
made to work.


You can't pursue licensing from lone wolfs and shoestring startups 
and expect well run legitimate companies to have any respect for you. 
It's not going to happen.


The only thing that is going to work for the big ticket companies is 
a 100% commercial product that happens to release its older stuff as 
OpenSource and sometimes accepts software developed by others for 
free. Nobody wants to hear that, but that is the only model that 
works. With that model comes fixing all bugs inside 90 days. None of 
this hoping someone in the OpenSource community fixes it for free.


Here, however, I'm going to have to disagree. I fail to see why the 
open source version can't be the latest and greatest, so long as the 
paid support *does* actually provide support, as you're saying.


(Dislaimer: This is my employer's business model. It seems to be 
working quite well for us.)


*If* one is going to have a commercial license with full support, that 
_has_ to be the tip of the tip. You have to actually get something for 
the additional fee rather than Digia executives getting a new 'Cedes and 
you the shaft which kind of feels like the business model now.


Now, the "commercial license" simply could be the Boot2Qt stuff with all 
of Qt being 100% OpenSource. This would provide additional incentive to 
rip QML out so it isn't bastardizing the rest of the product and QML 
could then be its own commercial thing, just for phones. I have lost 
track of other little things that Digia might have spun up for 
additional cash.




What I think it broken is the commercial licensing model. Either pay 
for support (and *get* support), or don't pay, and get whatever the 
community gives you. 


Okay, that's the point of disagreement. Kind of what I suspected.

The problem with that is one has to __START__ with all of the known bugs 
fixed, not just deleted. Ripping QML out into its own universe will go a 
long way to emptying the bug database *provided QML and JavaScript are 
ripped out root and stem not just deleted leaving support in the class 
and header code.*


I'm not actually convinced that paying Qt customers aren't getting the 
support they paid for; that information is generally not going to be 
publicly available. 


Pull down a couple years worth of the interest archives and unzip them 
into a directory. Let grep search for bug or customer.


https://lists.qt-project.org/pipermail/interest/

The complete information will never be publicly available but many 
paying customers have come here to bitch about bugs open for over a year.


Hey! "That guy again" needs to chime in here. Unless his company has 
also abandoned Qt as so many have.



What *is* broken is the alimony licensing model and all the 
fear-mongering around the licensing terms. 

+12
*Proper* commercial support for open source products lets you try 
before you buy with no punishment afterward, no penalties if you want 
to drop support later, or drop it and pick it up again. You pay, you 
get support, *period*.

+24


For that matter, it seems like Qt's commercial model is working just 
fine *for them*, at least at the moment. Ironically, the arguments you 
are making probably are *why* it's working. The problem is that 
they're busy killing the community and doing severe, possibly 
irreparable damage to Qt's reputation.
It is irreparable at this point. Whatever Qt becomes, it cannot have any 
current or former Digia people involved. Deep pocket customers won't 
come back. The Digia crew is 0 for 2.


It's highly doubtful that any company could pull in the staff to 
maintain all of the markets and eliminate all of the bugs, but that 
would have to be the starting point for such a venture.


Right, which is why we *need* a community, or a consortium, or 
something of that nature. We need everyone that cares about what Qt 
*could* be, without Digia's efforts to break it, to pool their resources.


I believe that if we could pull that off, Qt can still have a bright 
future.


We can't.

The thing has to fork and split.

I like Jason. He's a nice guy, but he wants to use Qt on phones and to 
have QML. He's not alone. That's

Re: [Interest] The willy-nilly deletion of convenience, methods


On 23/03/2021 10.36, Benjamen Meyer via Interest wrote:

On 3/23/21 10:09 AM, Matthew Woehlke wrote:

Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any
change, not just on a mailing list, but in person. Anyone can, in theory
(in practice, depending on where you live, there may be a non-trivial
membership fee required) *vote* against a change. We, as the committee,
generally try to be considerate of the community when making changes,
and there is quite a lot of emphasis on not breaking existing code, even
as far back as C++98.


How many C++ devs are on those?


Hundreds, which is probably more than the number of people making 
decisions for Qt.



Likely only those whose companies are paying them to be, and a few
that got there via academics (I've personally known and worked with
one person; outside of the folks I've seen here on the Qt lists.)


Even so, that's a lower bar than "you must be an employee of TQtC" (and 
even that is probably not sufficient). The bar also happens to be much 
lower right now due to COVID, since there are no in-person meetings 
happening.


In any case, you've made an unsubstantiated allegation that the 
committee does not care about C++ users. Please provide evidence to back 
that up. So far, all I've seen is "C++ also deprecates stuff". You 
haven't shown that the deprecations are actually *harmful* to the C++ 
community on anything like the scale to which Qt's recent changes have 
been harmful.


Deprecations, even in Qt, aren't always bad. Some recent Qt 
deprecations, however, have caused major pain. Now you are apparently 
claiming that C++ is "just as bad", but I have yet to see that claim 
substantiated.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Benjamen Meyer via Interest

On 3/23/21 10:09 AM, Matthew Woehlke wrote:
> On 23/03/2021 09.16, Michael Jackson wrote:
>> Having read this entire conversation I find it interesting that we as
>> developers are complaining about features being deprecated and
>> removed in Qt but yet where is the anger when C++ spec removes
>> features?
> Oh, it's there.
> 
> However, C++ is *far* more conservative than Qt about what it removes,
> and most of the removals are genuinely unuseful. (Seriously,
> *trigraphs*? Are *you* using trigraphs? Or auto_ptr?)
> 
> If you're seriously going to advance this argument, you need to point
> out one or more *specific* changes that you believe are harmful. Even
> then, chances are your compiler will continue to support that stuff for
> another 10 years.

The change of `auto` from a scope function to a variable type is
certainly harmful, especially since there was no version in between
where it wasn't defined at all; it was just changed. Granted the
argument was "no one uses it", but if you're porting an old application
that _did_ use it you'll get all kinds of junk quickly. And yes, there
was a type when I was learning about the various scoping aspects of
variables that I did learn about and use it; and I'm sure there is
legacy code out there that uses it.

Honestly, there hasn't been much added to C++ since C++98 that was
useful. std::string is one exception, as is standardizing on using Boost
- but you don't need to make Boost part of the C++ standards to achieve
that.

> Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any
> change, not just on a mailing list, but in person. Anyone can, in theory
> (in practice, depending on where you live, there may be a non-trivial
> membership fee required) *vote* against a change. We, as the committee,
> generally try to be considerate of the community when making changes,
> and there is quite a lot of emphasis on not breaking existing code, even
> as far back as C++98.
> 

How many C++ devs are on those? Likely only those whose companies are
paying them to be, and a few that got there via academics (I've
personally known and worked with one person; outside of the folks I've
seen here on the Qt lists.)

In all honesty, it comes down to those who are paying to vote - which is
certainly not the vast majority of C++ devs.

-- 
Ben Meyer
Software Engineer
(703)901-2797
bm_witn...@yahoo.com
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods


On 23/03/2021 09.16, Michael Jackson wrote:

Having read this entire conversation I find it interesting that we as
developers are complaining about features being deprecated and
removed in Qt but yet where is the anger when C++ spec removes
features?

Oh, it's there.

However, C++ is *far* more conservative than Qt about what it removes, 
and most of the removals are genuinely unuseful. (Seriously, 
*trigraphs*? Are *you* using trigraphs? Or auto_ptr?)


If you're seriously going to advance this argument, you need to point 
out one or more *specific* changes that you believe are harmful. Even 
then, chances are your compiler will continue to support that stuff for 
another 10 years.


Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any 
change, not just on a mailing list, but in person. Anyone can, in theory 
(in practice, depending on where you live, there may be a non-trivial 
membership fee required) *vote* against a change. We, as the committee, 
generally try to be considerate of the community when making changes, 
and there is quite a lot of emphasis on not breaking existing code, even 
as far back as C++98.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods


On 23/03/2021 06.59, Roland Hughes wrote:
30 years is __nothing__ for production systems. It is ordinary for a 
well developed system to run 10+ years without any modifications.


On that note, how many people are aware there's a computer that has been 
running non-stop for almost 45 years? :-D


You kids and your uptime measured in hours...


The phone world [...] [is] actually how this downward spiral started,
with the introduction of QML and forcing people to re-write,
re-write, re-write.


That does, indeed, seem to have been the turning point.

The Qt OpenSource model simply does not work. It cannot really be made 
to work.


You can't pursue licensing from lone wolfs and shoestring startups and 
expect well run legitimate companies to have any respect for you. It's 
not going to happen.


The only thing that is going to work for the big ticket companies is a 
100% commercial product that happens to release its older stuff as 
OpenSource and sometimes accepts software developed by others for free. 
Nobody wants to hear that, but that is the only model that works. With 
that model comes fixing all bugs inside 90 days. None of this hoping 
someone in the OpenSource community fixes it for free.


Here, however, I'm going to have to disagree. I fail to see why the open 
source version can't be the latest and greatest, so long as the paid 
support *does* actually provide support, as you're saying.


(Dislaimer: This is my employer's business model. It seems to be working 
quite well for us.)


What I think it broken is the commercial licensing model. Either pay for 
support (and *get* support), or don't pay, and get whatever the 
community gives you. I'm not actually convinced that paying Qt customers 
aren't getting the support they paid for; that information is generally 
not going to be publicly available. What *is* broken is the alimony 
licensing model and all the fear-mongering around the licensing terms. 
*Proper* commercial support for open source products lets you try before 
you buy with no punishment afterward, no penalties if you want to drop 
support later, or drop it and pick it up again. You pay, you get 
support, *period*.


For that matter, it seems like Qt's commercial model is working just 
fine *for them*, at least at the moment. Ironically, the arguments you 
are making probably are *why* it's working. The problem is that they're 
busy killing the community and doing severe, possibly irreparable damage 
to Qt's reputation.


It's highly doubtful that any company could pull in the staff to 
maintain all of the markets and eliminate all of the bugs, but that 
would have to be the starting point for such a venture.


Right, which is why we *need* a community, or a consortium, or something 
of that nature. We need everyone that cares about what Qt *could* be, 
without Digia's efforts to break it, to pool their resources.


I believe that if we could pull that off, Qt can still have a bright future.

Because they don't have bugs that have been rotting for over a decade, 
CopperSpice went to a support and consulting contract only model. It 
seems to be working.


I haven't much looked into CS, but that sounds plausible. Again, that's 
basically how my own employer works. It's a perfectly functional 
business model for organizations with the commitment and ethos to pull 
it off.


I'm also not sure how much I *want* to look into CS. The CoW stuff 
scares me, and I think they've gone too far in throwing out the good 
parts of Qt with the bad. There are quite a few changes in Qt5 that are 
good (the new OpenGL framework for one, not to mention all the C++11 
related changes). Ditching MOC is IMO questionable, especially when the 
overhead of MOC is so negligible these days.


No, I don't for a moment think QML is on that list :-). I looked at it 
once, briefly, and didn't see the point, and you're probably right about 
how it adds too much complexity for whatever dubious value proposition 
it might have. (For that matter, I'd like to see all the style sheet 
crud ripped out of Widgets as well.)


Medical devices, industrial controls, even desktop apps want a long 
stable platform.


Phones only care about what is shipping next week.


Yup, and this is the same reason why I loathe and want nothing to do 
with web development. Learning a new "platform" every month is a waste 
of time.


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods


On 22/03/2021 23.18, Jason H wrote:

Qt needs to go back to LGPL, or risk getting abandoned/replaced. Seems like 
some of the long time users here on this list have come to a similar conclusion.


I've said this before, and I'll say it again: Qt needs to go the way of 
OpenOffice.org.


That is, we need some folks to step up and decide that we're through 
with TQtC and we're going to continue Qt on our own, very possibly from 
5.15, as pure LGPL.


It probably isn't possible for contributors to retract rights already 
given to TQtC, but stop giving them new rights. Stop contributing under 
a CLA.


It would help tremendously if KDE was on board; wherever they go, the 
community will probably follow. Right now I'm worried that they're 
headed toward oblivion, which would make me really sad, because I do 
*not* care for Gnome. (That's not to say I think Gnome developers or 
users are terrible people, I just *personally* don't care for it.)


(I'd love to take CMake from 6.x, but I'm not exactly neutral in that 
respect, particularly as I've never used qmake. I'm not sure how much 
else from 6.x would be worth keeping. *Maybe* some of the move toward 
QVector. *Not* the total removal of QList, or the changes to QHash.)


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Michael Jackson

Having read this entire conversation I find it interesting that we as 
developers are complaining about features being deprecated and removed in Qt 
but yet where is the anger when C++ spec removes features? 

 

https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed

 

http://www.cplusplus2017.info/removed-features-from-c17/

 

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed

 

I have also been caught when trying to upgrade some legacy codes that were 
written well over 15 years ago by compiling with a “modern” C++ Compiler. We 
complain when the API gets bloated and slow then we complain when it gets 
trimmed down to be fast again. Pick something. 

 

I’m not disagreeing with the license issue. I’m not disagreeing with the “Qt6 
is a mess”. Just pointing out that even C++ undergoes changes where features 
that people may have used get’s removed.

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

From: Interest  on behalf of Roland Hughes 

Date: Tuesday, March 23, 2021 at 7:02 AM
To: , 
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods

 

 

On 3/23/21 2:31 AM, interest-requ...@qt-project.org wrote:

On 3/22/2021 7:32 PM, Turtle Creek Software wrote:
Re: willy-nilly

I can relate to anyone who is unhappy about deprecated functions.  It is 
never fun when existing code breaks.  We want to be inventing new stuff, 
not going back and fixing old code just to stay in the same place.  The 
C++ language has been decent about advancing, but still keeping ancient 
code stable.  Windows bends over backwards to stay backwards compatible. 
I think it's a basic courtesy that all platforms owe to developers.  
Programming is hard. Doing things once should be enough.
Amen brother, +100.
 
Life's too short for that BS, and computers are supposed to make our 
lives easier in the first place.
 
20 years in the life of a language or API or library is nothing (I'm 
over 50, which gives me some perspective). Assuming anyone actually uses 
it for more than a weather app or media browser. Something like that 
needs to last for as long as anyone uses it, and if it's time for it to 
die or be replaced then let it go in peace instead of gutting it and 
pretending it's still the same animal.  And yes I do think Windows has 
done us a great service in this regard... just talk to any non-fanboy 
MacOS developer who is older than 30.  And on *nix of course everyone 
still uses utilities written before they were born.  Stability, baby.
 
Dear QtC: Just call Qt6 a new library and make it all clean and sexy and 
commercial, or whatever.  But at least do right by everyone who's put 
their time into earlier versions, including by using them, and finish it 
up in style instead of scandal & annoyance. Not only would all the users 
appreciate it, but it just may make you seem more reliable going 
forward.  For me personally 5.12.x is the last Qt branch I will trust 
(until maybe someday all the 5.15 fixes are OS).
+1000

Amen! Can I get a witness?

Welcome to the north of 50 club, not far from the north of 60 club.

The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up 
mentality. Real products have to have 30+ years of stability, not be gutted 
every few years.

For those too young to understand, this is where AGILE and Iterative 
Development fail spectacularly. You are constantly putting out things that 
aren't going to last. By definition unstable.

30 years is __nothing__ for production systems. It is ordinary for a well 
developed system to run 10+ years without any modifications. Yeah, you really 
do need both doc and comments in the code because even if you wrote it, ten 
years later you are a different person.

You can't chase the phone market __and__ serve actual business.

These are diametrically opposed goals.

When a company puts a surgical robot in the field it has to be maintainable for 
at least 20 years. They can't afford a gut & rewrite. Yes, over the course of a 
20+ year life a robot will "get taught new tricks" but those will be additional 
tricks. Even something as "simple" as a patient monitor will have to have minor 
software upgrades due to new FDA/HIPPA regulations.

Here's the 8000 pound Elephant in the room.

Cross platform isn't needed. Ain't nobody going to put Android or Windows 
behind a touch screen on a medical device. That's always going to be a Yocto 
Linux build. The dev host is always going to be a YABU or some other Linux 
distro. Cross platform has very little meaning in the embedded medical, 
industrial controls, test equipment world.

Cross platform had meaning in the desktop world. It's become a limited meaning 
though. Yeah, it's nice that I

Re: [Interest] The willy-nilly deletion of convenience, methods



On 3/23/21 2:31 AM, interest-requ...@qt-project.org wrote:

On 3/22/2021 7:32 PM, Turtle Creek Software wrote:

Re: willy-nilly



I can relate to anyone who is unhappy about deprecated functions.  It is
never fun when existing code breaks.  We want to be inventing new stuff,
not going back and fixing old code just to stay in the same place.  The
C++ language has been decent about advancing, but still keeping ancient
code stable.  Windows bends over backwards to stay backwards compatible.
I think it's a basic courtesy that all platforms owe to developers.
Programming is hard. Doing things once should be enough.

Amen brother, +100.

Life's too short for that BS, and computers are supposed to make our
lives easier in the first place.

20 years in the life of a language or API or library is nothing (I'm
over 50, which gives me some perspective). Assuming anyone actually uses
it for more than a weather app or media browser. Something like that
needs to last for as long as anyone uses it, and if it's time for it to
die or be replaced then let it go in peace instead of gutting it and
pretending it's still the same animal.  And yes I do think Windows has
done us a great service in this regard... just talk to any non-fanboy
MacOS developer who is older than 30.  And on *nix of course everyone
still uses utilities written before they were born.  Stability, baby.

Dear QtC: Just call Qt6 a new library and make it all clean and sexy and
commercial, or whatever.  But at least do right by everyone who's put
their time into earlier versions, including by using them, and finish it
up in style instead of scandal & annoyance. Not only would all the users
appreciate it, but it just may make you seem more reliable going
forward.  For me personally 5.12.x is the last Qt branch I will trust
(until maybe someday all the 5.15 fixes are OS).


+1000

Amen! Can I get a witness?

Welcome to the north of 50 club, not far from the north of 60 club.

The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up 
mentality. Real products have to have 30+ years of stability, not be 
gutted every few years.


For those too young to understand, this is where AGILE and Iterative 
Development fail spectacularly. You are constantly putting out things 
that aren't going to last. By definition unstable.


30 years is __nothing__ for production systems. It is ordinary for a 
well developed system to run 10+ years without any modifications. Yeah, 
you really do need both doc and comments in the code because even if you 
wrote it, ten years later you are a different person.


You can't chase the phone market __and__ serve actual business.

These are diametrically opposed goals.

When a company puts a surgical robot in the field it has to be 
maintainable for at least 20 years. They can't afford a gut & rewrite. 
Yes, over the course of a 20+ year life a robot will "get taught new 
tricks" but those will be additional tricks. Even something as "simple" 
as a patient monitor will have to have minor software upgrades due to 
new FDA/HIPPA regulations.


Here's the 8000 pound Elephant in the room.

Cross platform isn't needed. Ain't nobody going to put Android or 
Windows behind a touch screen on a medical device. That's always going 
to be a Yocto Linux build. The dev host is always going to be a YABU or 
some other Linux distro. Cross platform has very little meaning in the 
embedded medical, industrial controls, test equipment world.


Cross platform had meaning in the desktop world. It's become a limited 
meaning though. Yeah, it's nice that I can run text editor A on Windows, 
Linux, and that obscure platform. The sad reality is they rarely run the 
same. Just try KATE on Windows. So, yes. A browser, an editor, a music 
player, in short, tiny "consumer apps" have some need for cross 
platform. The real business apps just don't do it. A front end for a 
medical records system simply isn't going to run on Mac or Linux unless 
they went with a browser interface.


The phone world is just an alternate reality. That's actually how this 
downward spiral started, with the introduction of QML and forcing people 
to re-write, re-write, re-write.


People poke fun at COBOL, but the reason it still today has more lines 
of code in production than any other language is the fact COBOL doesn't 
delete anything until the hardware and OS it was added to support can 
only be found in a museum. The compiler vendors also send out technical 
bulletins to their customers when considering changes. If it is not 
forced on them by a language standards committee they query the customer 
base before doing it. This isn't a deprecation warning someone stumbles 
into when they try to compile something old. It's actual communication.


All of this is too late of course.

For roughly the past two years there has been zero management of Qt in 
general. That's why I only see medical device projects still using Qt 
4.8 OpenSource or a token few that are trying

Re: [Interest] The willy-nilly deletion of convenience methods

2021-03-22 Thread Jason H

Surprisingly, I had a good experience with Wt, (webtoolkit.eu) the "web version 
of Qt" (uses boost). Maybe chromium plus Wt is the way to go? It's commercial, 
but not as bad as Qt licensing. (GPL2 or commercial)

If you don't constantly fracture the code base of humanity every couple years 
with some new toolkit how would the companies make any money? We're basically 
only ever putting rectangles and text on the screen. Yet we've had win32API, 
MFC,  WPF, Java, spring,  cocoa, windows forms, html, I've lost count. Qt 
seemed to be the stand out, but invented QtQuick.

One thing I muse about is geriatric computing, and got old people start 
relevant in a constantly changing UI landscape. Never I did think about the 
programmers churning away and needlessly updating style sheets, to make the 
retirement community less comfortable with using websites and apps.

Anyway I feel like things have gotten kind of off topic. Qt needs to go back to 
LGPL, or risk getting abandoned/replaced. Seems like some of the long time 
users here on this list have come to a similar conclusion. Oh and better 
support on mobile. Good luck with that. Hahahaha. Too interested in tweaking 
QHash performance in a GUI library than your use case using a mobile feature 
that's been around for 5 years but still isn't implemented in Qt.

Also, after reviewing the Qt company management, it's just Digia management, 
which might explain a lot.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods

2021-03-22 Thread Max Paperno



On 3/22/2021 7:32 PM, Turtle Creek Software wrote:

Re: willy-nilly


I can relate to anyone who is unhappy about deprecated functions.  It is 
never fun when existing code breaks.  We want to be inventing new stuff, 
not going back and fixing old code just to stay in the same place.  The 
C++ language has been decent about advancing, but still keeping ancient 
code stable.  Windows bends over backwards to stay backwards compatible. 
I think it's a basic courtesy that all platforms owe to developers.  
Programming is hard. Doing things once should be enough.


Amen brother, +100.

Life's too short for that BS, and computers are supposed to make our 
lives easier in the first place.


20 years in the life of a language or API or library is nothing (I'm 
over 50, which gives me some perspective). Assuming anyone actually uses 
it for more than a weather app or media browser. Something like that 
needs to last for as long as anyone uses it, and if it's time for it to 
die or be replaced then let it go in peace instead of gutting it and 
pretending it's still the same animal.  And yes I do think Windows has 
done us a great service in this regard... just talk to any non-fanboy 
MacOS developer who is older than 30.  And on *nix of course everyone 
still uses utilities written before they were born.  Stability, baby.


Dear QtC: Just call Qt6 a new library and make it all clean and sexy and 
commercial, or whatever.  But at least do right by everyone who's put 
their time into earlier versions, including by using them, and finish it 
up in style instead of scandal & annoyance. Not only would all the users 
appreciate it, but it just may make you seem more reliable going 
forward.  For me personally 5.12.x is the last Qt branch I will trust 
(until maybe someday all the 5.15 fixes are OS).


Cheers,
-Max

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, , methods (was: Mixing Commercial and Open...)



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 
the editor now as I ran into the 16 minute QList thing.


https://www.logikalsolutions.com/wordpress/information-technology/qlist/

So far that is the only place I can notice any significant difference 
between Qt CoW and obeying C++ standards. It might not even be directly 
that. They may just have some abhorrent bug I stumbled into. The test 
cases are on the blog and I filled the issue.


I'm batting about 50/50 with filing issues and having them fixed. A much 
improved batting average.


When I get "done" with RedDiamond I will use my "free" time to look for 
"what's next" at least for myself and my clients. I secretly hope at 
least one of them will make a good decision about "what's next" before I 
have to dig through a lot of trash.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)



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 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 message in interest saying "Hey! We are about to nuke this, is anyone 
actually using it?"


That's a warning. People who have stuff built with 4.x or very early 5.x 
can then make an informed decision. That is __not__ FUD, that is reality.


Deprecated is not same as having gone away. Just how many major releases 
as asprintf() been deprecated for?


https://doc.qt.io/qt-5/qstring.html#asprintf

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.


That duth sound a bit more like something was shot and left in the woods.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods

2021-03-22 Thread Thorsten Glaser

On Mon, 22 Mar 2021, Thiago Macieira wrote:

> accomplish the same goal. As shown by the example of the KWallet CLI, there 
> may be a much better and much simpler solution once the need is understood.

I wouldn’t call shouting “API abuse!” at me a “much better” solution.
I’m a user here, neither a KDE nor Qt developer, not even really a C++
developer (I *do* C).

Irritated,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Jérôme Godbout

+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 rendering into 
main GUI thread) other engine into another thread render with more precision 
into the background but declare into a declarative way of Qml. Was mostly a 
reality, only 1 thing ever stop us from releasing this at large, the Qml 
singleton bug from qmldir, this issue was never fixed btw). We could put 
rendering progress bar upside the 3D object as they get sharper and better 
smoothed and more precise into our CAD software, was very nice to see with the 
3D scene still completely fluid and user interactable while the heavy work was 
done and could be easily scripted by the high level application dev.

+1 on waiting for 6.2 before any switch can even be possible, will see when it 
get there, before it would be just plain huge waste of time.

But I see less and less Qt contract coming our way, client are scare of Qt 
license right now, everybody feel like this is a nuclear waste of some kind 
that they better to stay away as of now. I cannot really blame them, when the 
question always end up check with your lawyer, they don’t they just stroke the 
option out or if the answer the price toll depends will depend… they stroke 
that option out too!

I did my share of mobile and desktop development for 
Windows/Linux/MacOS/iOS/Android and Qt always was my fun ride to write a commun 
source code. But I touch it less and less and that make me sad, I do more and 
more Xamarin/.Net Standard 2/Unity/Blazor combo code those days.  This with 
embedded IoT device can go a long way and the cost is predictable… Client like 
predictable, they like that too much but they always do…


Jérôme Godbout, B. Ing.

Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
C: (581) 777-0050
godbo...@dimonoff.com<mailto:godbo...@dimonoff.com>
[signature_1251317868]<https://www.dimonoff.com/>
dimonoff.com<https://www.dimonoff.com/>
1015 Avenue Wilfrid-Pelletier,
Québec, QC G1W 0C4, 4e étage


From: Interest  on behalf of ekke 

Date: Monday, March 22, 2021 at 11:48 AM
To: interest@qt-project.org 
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods (was: 
Mixing Commercial and Open...)
+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 waiting for 6.2 to get all the 
modules I need - will start refactoring all the depricated parts next 
weeks/months step by step beside my daily work

Am 22.03.21 um 16:22 schrieb Nelson, Michael:

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



Still, cross-platform support is nevertheless strong and QML is indeed a great 
language for UI, so I'm still a paying customer, for now. Keeping an eye on 
Flutter, though. 😊



Best regards,





MICHAEL NELSON | Sr. Software Engineer

T  703-406-2800, 341

michael.nel...@otthydromet.com<mailto:michael.nel...@otthydromet.com> | 
www.otthydromet.com<http://www.otthydromet.com>





--

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
Qt Mobile: Android, iOS, W10 (former projects: BlackBerry 10)

Qt Champion
BlackBerry Elite Developer

max-josefs-platz 30, D-83022 rosenheim, germany

twitter: @ekkescorner
LinkedIn: http://linkedin.com/in/ekkehard/
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Bernhard Lindner

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

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Jason H

> 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 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/ 
> > <http://archive.raspbian.org/raspbian/pool/main/q/qtbase-opensource-src/>
> >
> > kind regards,
> > jm
> >
> >
> I __believe__ what Jason was talking about was a package for cross 
> compilation so that 12 year old kids could plug in a serial/usb cable 
> and assign a target for deploy. So people didn't have to endure stuff 
> like this:
> 
> https://www.logikalsolutions.com/wordpress/information-technology/how-far-weve-come-pt-18/
> 
> and this
> 
> https://www.logikalsolutions.com/wordpress/raspberry-pi/raspberry-qt-part-8/

Pretty much.. or a 40 year old kid.  I searched all over and found one guy 
publishing builds on GitHub.. That's what I use.  Also, linuxdeployqt isn't 
official Qt, so I just always installed QtCreator (also packaged) and re built 
when moving an app to a new pi...
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Thiago Macieira

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 our final conclusion here?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Thiago Macieira

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 deprecation messages, most of which also 
include the new API that replaces. We've tried to deprecate the API as early 
as possible; in the worst case, 5.15 should produce the warning so you know 
the problem and can port away before making the jump to Qt 6, while the 
application is still otherwise working. 

The ones that have no replacement are so because the API in question is flawed 
for some reason or another.  If there are legitimate use-cases for the API 
that was removed, say so. And please state what problem was trying to be 
solved, not simply how you were using the API. Often, the solution is not a 
1:1 match to the removed and flawed functionality, but something that can help 
accomplish the same goal. As shown by the example of the KWallet CLI, there 
may be a much better and much simpler solution once the need is understood.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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



kind regards,
jm


I __believe__ what Jason was talking about was a package for cross 
compilation so that 12 year old kids could plug in a serial/usb cable 
and assign a target for deploy. So people didn't have to endure stuff 
like this:


https://www.logikalsolutions.com/wordpress/information-technology/how-far-weve-come-pt-18/

and this

https://www.logikalsolutions.com/wordpress/raspberry-pi/raspberry-qt-part-8/


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

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:
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 
mailto:rol...@logikalsolutions.com>> wrote:

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:
> >> 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, 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 someone more
responsible.
>
> Dude,
>
> Comcast, TimeWarner, and all of those other set-top box
vendors formed
> an OpenSource project to create RDK so they could kick Qt
to the curb.
>
That happened 5 years ago. Comcast was only using QtWebKit
from Qt anyway.

Hmmm..

Just this year is when they flushed Qt. That's what the people
working there tell me.

The reality Vlad is that companies are dumping Qt wholesale.

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.

-- 

Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com  

http://www.infiniteexposure.net  
http://www.johnsmith-book.com  
http://www.logikalblog.com  
http://www.interestingauthors.com/blog  

--
Best regards,
Vlad

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)



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 to have all dumped Qt for 
Electron due to the licensing. The Intel one went that way at least.


A good number of Qt based things are now hanging out on the CopperSpice 
forums and asking for porting help. CopperSpice not quite there yet as 
far as a locked down API but good enough for a lot of things. You have 
to mentally shift design gears though because there is no CoW. One has 
to get used to using references and pointers again because those big 
objects will actually get copied.


A few have gone with that DOT-NOT-anywhere thing of Microsoft.

The medical device world is really kind of flailing around right now. 
Nobody is willing to pay for Qt given the new license and death of 
perpetual license. The ex-wife ransoming of the children didn't sit well 
either. NONE of them will pay royalties.



Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as a 
supported platform? 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.
That compile it yourself thing isn't smooth either. _Most_ of the 
on-line instructions only successfully build a tiny subset of Qt. Then 
you end up picking up host libraries for things like PostgreSQL. Been 
there. Done that. Got the hat, T-shirt, bumper sticker, and water bottle.

There is no grass roots support for Qt as a result.


KDE has __not__ helped that issue over the years. The continued 
abadonware (blogilo anyone?)


https://apps.kde.org/en/blogilo

KWord? now forcing that God-awful Calligra on everyone.

KMail. The continually updating and corrupting database.

Right now there is only one distro with a descent KDE implementation and 
that is Manjaro.


Adding insult to injury, the Juffed editor seems to be in every repo and 
if one installs it the thing trashes your Qt environment.



And with the licensing issues of late, they've ensured that there won't be. 
This means that they have to rely on and cater to the big spenders boys in the 
market.


You know. The medical device world has some pretty big spenders. When 
they can buy a one & done license and use it perpetually across multiple 
product lines with only a tiny support contract they usually bite the 
bullet. I've worked on devices where they paid around $600K for Qt. They 
honestly didn't even need to get a commercial license for what they were 
doing. They bought it just to remove a possible future issue.


There is no way in God's green earth they are going to pay royalties 
though. $600K is an awful lot for one dude writing a phone app. When you 
are going to create N different medical devices where unit sales will be 
50K to 3 million units for each device, $600K is not much. It's an 
overhead cost that ends up being amortized across millions of units. 
When the ex-wife wants $5/unit on top of a license fee that is the end 
of Qt in the medical device world.


So far I have not found two medical device projects that started 
__after__ the license FUD of killing off OpenSource LTS, etc. that have 
used the same libraries. Some are trying Electron (it's not actually in 
anything yet that I know of) others are kicking the tires on CopperSpice.


Other things people are kicking tires on right now:

U++  BSD license
https://www.ultimatepp.org/

OpenZinc LGPL
http://openzinc.com/Overview.html

Nana  Boost Software License
http://nanapro.org/en-us/

RDK  Unknown - license must apply for license but says there is no charge
https://rdkcentral.com/

Chromium Embedded Framework   BSD license
https://bitbucket.org/chromiumembedded/cef/src/master/

What __has__ changed in the medical device industry is all UI is now 
being designed client server on paper. Only the really good companies 
were doing that before. The rest were just making one big Qt 
application. Most new designs (and some old ones) are optically isolated 
via a publish-subscribe message queue.


UI <--> MessageQ <--> Devices

Zinc is still an application framework but it was mostly UI back in the 
day. I don't know if Wind River fixed the event loop so devices could be 
plugged in. What was unique about Zinc was the fact it was/is a wrapper 
library. Other than under DOS and raw OS/2 (sans PM) it provided a 
common wrapper subset for the OS level UI stuff. Zinc has both an 
OpenSource and commercial version. For years (and possibly still) Wind 
River systems used it as their default UI library after acquiring it. 
Now it seems to be spun back out on its own. Having a UI library in your 
commercial embedded OS was a big selling point back in the day.


I haven't heard any real feedback about U++. I spent about 10 minutes 
with U++ myself some time back.

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread ekke


+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 waiting for 6.2 to get all the 
modules I need - will start refactoring all the depricated parts next 
weeks/months step by step beside my daily work


Am 22.03.21 um 16:22 schrieb Nelson, Michael:

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

Still, cross-platform support is nevertheless strong and QML is indeed a great 
language for UI, so I'm still a paying customer, for now. Keeping an eye on 
Flutter, though. 😊

Best regards,


MICHAEL NELSON | Sr. Software Engineer
T  703-406-2800, 341
michael.nel...@otthydromet.com | www.otthydromet.com




--

ekke (ekkehard gentz)

independent software architect
international development native mobile business apps
Qt Mobile: Android, iOS, W10 (former projects: BlackBerry 10)

*Qt Champion
BlackBerry Elite Developer
*
max-josefs-platz 30, D-83022 rosenheim, germany

twitter: @ekkescorner
LinkedIn: http://linkedin.com/in/ekkehard/

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Jean-Michaël Celerier

> 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 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? Yes, I still think Qt (and yes, QML)
> is rockstar technology. My problems aren't with the API. It's that QtCorp
> has chipped away at the LGPL license from Nokia. And the stuff I wanted Qt
> to do, it didn't, even when under a commercial license.
>
> Qt completely delivered is promise in us getting something to market, but
> when it was finally feature complete,  that something had more native code
> in it than Qt, because we were using using Qt just for the UI. Taking that
> and writing a UI abstraction to native was not that hard.
>
> Qt *could have* made that port away so much harder, but because it's
> mobile support was so lacking, it was actually quite easy once we put our
> heads in it.
>
> I'm also at a new company and I've suggested Qt up for evaluation, to
> replace the patchwork of libraries they are currently using.  We will see
> how the talks go... I doubt we will be using Qt6, regardless. Roland, what
> did those companies move to?
>
> The problems I want fixed aren't technical. It's with the project's
> direction and management. "Open Governance" has not manifest the way I
> thought it would. Filling bugs and voting for them got my issues neglected.
> The constant relicensing to, of what was LGPL, to be under GPL 3. But these
> are issues that can be fixed with the stroke of a pen, or banging on a
> keyboard for a bit.
>
> Some other inexplicable decisions are why there isn't Qt for Raspberry Pi
> as a supported platform? 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. Qt continues to get beat by HTML5, but
> it shouldn't. Especially giving the WebGL plugin. But there just isn't that
> effort to enable that segment. There is no grass roots support for Qt as a
> result. And with the licensing issues of late, they've ensured that there
> won't be. This means that they have to rely on and cater to the big
> spenders boys in the market.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Nelson, Michael

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

Still, cross-platform support is nevertheless strong and QML is indeed a great 
language for UI, so I'm still a paying customer, for now. Keeping an eye on 
Flutter, though. 😊

Best regards,


MICHAEL NELSON | Sr. Software Engineer
T  703-406-2800, 341
michael.nel...@otthydromet.com | www.otthydromet.com



-Original Message-
From: Interest  On Behalf Of Jason H
Sent: Monday, March 22, 2021 10:23 AM
To: Roland Hughes 
Cc: interest 
Subject: Re: [Interest] The willy-nilly deletion of convenience, methods (was: 
Mixing Commercial and Open...)

>
> 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? Yes, I still think Qt (and yes, QML) is 
rockstar technology. My problems aren't with the API. It's that QtCorp has 
chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to do, 
it didn't, even when under a commercial license.

Qt completely delivered is promise in us getting something to market, but when 
it was finally feature complete,  that something had more native code in it 
than Qt, because we were using using Qt just for the UI. Taking that and 
writing a UI abstraction to native was not that hard.

Qt *could have* made that port away so much harder, but because it's mobile 
support was so lacking, it was actually quite easy once we put our heads in it.

I'm also at a new company and I've suggested Qt up for evaluation, to replace 
the patchwork of libraries they are currently using.  We will see how the talks 
go... I doubt we will be using Qt6, regardless. Roland, what did those 
companies move to?

The problems I want fixed aren't technical. It's with the project's direction 
and management. "Open Governance" has not manifest the way I thought it would. 
Filling bugs and voting for them got my issues neglected. The constant 
relicensing to, of what was LGPL, to be under GPL 3. But these are issues that 
can be fixed with the stroke of a pen, or banging on a keyboard for a bit.

Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as a 
supported platform? 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. 
Qt continues to get beat by HTML5, but it shouldn't. Especially giving the 
WebGL plugin. But there just isn't that effort to enable that segment. There is 
no grass roots support for Qt as a result. And with the licensing issues of 
late, they've ensured that there won't be. This means that they have to rely on 
and cater to the big spenders boys in the market.
___
Interest mailing list
Interest@qt-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.qt-2Dproject.org_listinfo_interest&d=DwIGaQ&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk&m=8eAioAP_sVFxZBs09SfrVELmNNKGDfcu3_znNi5BQuE&s=EJGZhrEuvpS6kt2IyI31RZNxODe8TUxAk6KWuVInpiY&e=
Please be advised that this email may contain confidential information. If you 
are not the intended recipient, please notify us by email by replying to the 
sender and delete this message. The sender disclaims that the content of this 
email constitutes an offer to enter into, or the acceptance of, any agreement; 
provided that the foregoing does not invalidate the binding effect of any 
digital or other electronic reproduction of a manual signature that is included 
in any attachment.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Vlad Stelmahovsky

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 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
>> +
>> > >> 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, 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 someone more responsible.
>> >
>> > Dude,
>> >
>> > Comcast, TimeWarner, and all of those other set-top box vendors formed
>> > an OpenSource project to create RDK so they could kick Qt to the curb.
>> >
>> That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.
>>
>>
> Hmmm..
>
> Just this year is when they flushed Qt. That's what the people working
> there tell me.
>
> The reality Vlad is that companies are dumping Qt wholesale.
>
> 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.
> --
>
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/blog
>
>

-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Frank Hemer

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 the management of Qt.
> 
> I'm apparently Qt's biggest fan boy? Yes, I still think Qt (and yes, QML) is
> rockstar technology. My problems aren't with the API. It's that QtCorp has
> chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to
> do, it didn't, even when under a commercial license.
> 
> Qt completely delivered is promise in us getting something to market, but
> when it was finally feature complete,  that something had more native code
> in it than Qt, because we were using using Qt just for the UI. Taking that
> and writing a UI abstraction to native was not that hard.
> 
> Qt *could have* made that port away so much harder, but because it's mobile
> support was so lacking, it was actually quite easy once we put our heads in
> it.
> 
> I'm also at a new company and I've suggested Qt up for evaluation, to
> replace the patchwork of libraries they are currently using.  We will see
> how the talks go... I doubt we will be using Qt6, regardless. Roland, what
> did those companies move to?
> 
> The problems I want fixed aren't technical. It's with the project's
> direction and management. "Open Governance" has not manifest the way I
> thought it would. Filling bugs and voting for them got my issues neglected.
> The constant relicensing to, of what was LGPL, to be under GPL 3. But these
> are issues that can be fixed with the stroke of a pen, or banging on a
> keyboard for a bit.
> 
> Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as
> a supported platform? 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. Qt continues to get beat by HTML5, but
> it shouldn't. Especially giving the WebGL plugin. But there just isn't that
> effort to enable that segment. There is no grass roots support for Qt as a
> result. And with the licensing issues of late, they've ensured that there
> won't be. This means that they have to rely on and cater to the big
> spenders boys in the market.

+1



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Jason H

>
> 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? Yes, I still think Qt (and yes, QML) is 
rockstar technology. My problems aren't with the API. It's that QtCorp has 
chipped away at the LGPL license from Nokia. And the stuff I wanted Qt to do, 
it didn't, even when under a commercial license.

Qt completely delivered is promise in us getting something to market, but when 
it was finally feature complete,  that something had more native code in it 
than Qt, because we were using using Qt just for the UI. Taking that and 
writing a UI abstraction to native was not that hard.

Qt *could have* made that port away so much harder, but because it's mobile 
support was so lacking, it was actually quite easy once we put our heads in it.

I'm also at a new company and I've suggested Qt up for evaluation, to replace 
the patchwork of libraries they are currently using.  We will see how the talks 
go... I doubt we will be using Qt6, regardless. Roland, what did those 
companies move to?

The problems I want fixed aren't technical. It's with the project's direction 
and management. "Open Governance" has not manifest the way I thought it would. 
Filling bugs and voting for them got my issues neglected. The constant 
relicensing to, of what was LGPL, to be under GPL 3. But these are issues that 
can be fixed with the stroke of a pen, or banging on a keyboard for a bit.

Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as a 
supported platform? 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. 
Qt continues to get beat by HTML5, but it shouldn't. Especially giving the 
WebGL plugin. But there just isn't that effort to enable that segment. There is 
no grass roots support for Qt as a result. And with the licensing issues of 
late, they've ensured that there won't be. This means that they have to rely on 
and cater to the big spenders boys in the market.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

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:
> >> 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, 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 someone more responsible.
>
> Dude,
>
> Comcast, TimeWarner, and all of those other set-top box vendors
formed
> an OpenSource project to create RDK so they could kick Qt to the
curb.
>
That happened 5 years ago. Comcast was only using QtWebKit from Qt
anyway.

Hmmm..

Just this year is when they flushed Qt. That's what the people working 
there tell me.

The reality Vlad is that companies are dumping Qt wholesale.

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.

--

Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Vlad Stelmahovsky

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 +
> > >> 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, 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 someone more responsible.
> >
> > Dude,
> >
> > Comcast, TimeWarner, and all of those other set-top box vendors formed
> > an OpenSource project to create RDK so they could kick Qt to the curb.
> >
> That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.
>
> 'Allan
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)



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 someone more responsible.


Dude,

Comcast, TimeWarner, and all of those other set-top box vendors 
formed an OpenSource project to create RDK so they could kick Qt to 
the curb.


They aren't coming back.

Opera moved to RDK.

Doubtful they would ever come back.


Although all of this sounds great, but is the RDK a real alternative 
to Qt on desktops?

Is there something like QtWidgets module? For X11?
If there is one, are there small examples for RDK features, so that 
one can compare RDK and Qt side-by-side?



Vad


Until the recent spate of VOIP recruiters barely able to communicate 
calling me about the Comcast gigs, I didn't know anything about RDK. 
They do have a Web site.


https://rdkcentral.com/

Once I get done writing RedDiamond in CopperSpice I will take a gander 
at RDK. No promises and no timelines. Feel free to explore on your own.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Henry Skoglund


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 =
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, 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 someone more responsible.

Dude,

Comcast, TimeWarner, and all of those other set-top box vendors formed
an OpenSource project to create RDK so they could kick Qt to the curb.


That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.

'Allan


It was in late 2013 if this announcement could be viewed as the launch:
https://press.opera.com/2013/12/13/opera-launches-the-industrys-first-commercial-grade-chromium-blink-engine-designed-for-rdk-set-top-boxes/

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Allan Sandfeld Jensen

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 of confidence in the current Qt owners can ever be
> > compensated.
> > 
> > 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 someone more responsible.
> 
> Dude,
> 
> Comcast, TimeWarner, and all of those other set-top box vendors formed
> an OpenSource project to create RDK so they could kick Qt to the curb.
> 
That happened 5 years ago. Comcast was only using QtWebKit from Qt anyway.

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)



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 companies, and those sales allow them to 
neglect other markets. I hope they circle back and get there market segments 
they have been neglecting.

My company abandoned commercial use of Qt as we were in a neglected market 
segment... Rewrote the app native on each platform. It was painful, but 
stuffiness routing the band-aid off quickly is the way to go.  I've been 
lurking hoping to hear good things about QT6 but it looks like The decision to 
go native was the right one.



Wow Jason! Didn't know your company was one of the seemingly endless 
stream dumping Qt. For several years Qt cared only about the mobile 
market at the expense of all other markets. That is why so many are so 
far gone.


As far as stopping new releases, I would assume if _all_ the OpenSource 
developers simply stop working on Qt that would do it.


Even if everything was switched over to someone else _today_ I don't 
think it matters for Qt. If John Deere is having trouble getting the 
usual suspects to provide extremely low wage Qt labor that means kids in 
third world countries aren't bothering to learn Qt anymore. John Deere 
has factories in lots of places around the world. They could easily move 
the development to one of them. My friend from high school who was over 
the creation of John Deere's first steering/navigation system used to 
have to go to Germany a lot.


Judging from the duration and the volume of these postings/phone 
calls/emails; they are pumping a dry well. They are even having trouble 
thieving them from the big three auto makers despite Deere paying higher 
pathetic billing rates. The difference hasn't gotten high enough for 
people to drive from Detroit to Ankeny Iowa and learn to say ain't.


Debian lost the Qt maintainers so the YABUs will be frozen in time with 
Qt. Eventually they will just have to rip it out. That will leave Qt 
only in RPM and ARCH/Pacman trees. Possibly Msys as well?


For whatever reason, the shops I go to for embedded systems all use 
Ubuntu for their Linux development host.


Guess that means we all have to focus on "What's next?" for each of our 
market segments. The era of Qt has ended.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Philippe

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 10:37:08 +0100
Benjamin TERRIER  wrote:

> 
> 
> 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 projects I have worked on, wouldn't qualify to be ported 
to Qt 6 right now because of missing modules.
Right now, I have only worked on migrating very small projects, so my 
experience is not representative,
but the removal of toList(), toSet() & co.  is already a pain, and we basically 
needed to add helper functions to keep our code readable.

My 2 cents

Benjamin

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)



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 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 someone more responsible.


Dude,

Comcast, TimeWarner, and all of those other set-top box vendors formed 
an OpenSource project to create RDK so they could kick Qt to the curb.


They aren't coming back.

Opera moved to RDK.

Doubtful they would ever come back.

When John Deere can no longer get illegal aliens to work for illegal 
alien wages with Qt (which it seems they are having desperate trouble 
right now) that will be the end in both the Ag and automotive 
industries. The major automakers tend to pay Qt developers even less 
than John Deere. Ordinarily those postings, phone calls, and emails only 
last about 3 days. It's been about 3 weeks now though it feels longer. 
They are desperate enough they've even started coming up on their rate. 
Still not a respectable rate (especially given the outlandish prices 
Deere has on their equipment) but they haven't raised the rate in a 
decade. It appears the usual culprits, Tata, InfoSys, Cognizant, Cap 
Gemini, et-al, are out of people to sneak in.


That will be the official death knell. When Deere flushes its installed 
base. There will be no coming back from that.


Ford has already proven they can successfully toss out infotainment 
architecture. They threw Microsoft out after MS helped them create a 
buggy horrible Sync and rewrote Sync with Qt. The people who did the 
port probably still work at Ford so it would be old hat for them.


The sad reality is everybody with a set-top box or willing to pull down 
Opera can see just how well RDK works. The greatest of the great 
unknowns can cheaply be removed for the decision makers by pointing that 
out.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Benjamin TERRIER

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 projects I have worked on, wouldn't qualify to be
ported to Qt 6 right now because of missing modules.
Right now, I have only worked on migrating very small projects, so my
experience is not representative,
but the removal of toList(), toSet() & co.  is already a pain, and we
basically needed to add helper functions to keep our code readable.

My 2 cents

Benjamin
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)