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

2021-03-24 Thread Thiago Macieira 
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 (was: Mixing Commercial and Open...)

2021-03-24 Thread Thiago Macieira 
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...)

2021-03-24 Thread Thiago Macieira 
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...)

2021-03-24 Thread Thiago Macieira 
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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (was: Mixing Commercial and Open...)

2021-03-22 Thread Roland Hughes 


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

2021-03-22 Thread Roland Hughes 


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 (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
[signature_1251317868]
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 | 
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/ 
> > 
> >
> > 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...)

2021-03-22 Thread Roland Hughes 


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

2021-03-22 Thread Roland Hughes 

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

2021-03-22 Thread Roland Hughes 


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

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=DwIGaQ=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA=gqkHidFt_OznI1nBLNO0BnY0UT1ILkTMEW_qQQbTmCk=8eAioAP_sVFxZBs09SfrVELmNNKGDfcu3_znNi5BQuE=EJGZhrEuvpS6kt2IyI31RZNxODe8TUxAk6KWuVInpiY=
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...)

2021-03-22 Thread Roland Hughes 

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

2021-03-22 Thread Roland Hughes 


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

2021-03-22 Thread Roland Hughes 


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

2021-03-22 Thread Roland Hughes 


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

2021-03-22 Thread Roland Hughes 


On 3/22/21 4:07 AM, Volker Hilsheimer wrote:

On 20 Mar 2021, at 14:22, Roland Hughes  wrote:

I grepped the archive this morning. Hopefully Andre's email still works. I had 
hoped he was still watching on here and would pipe up. Maybe he and his company 
abandoned Qt as well after the June 2020 exchange?

Here is a scrape of one of the messages in the thread from the archive.

Subject: [Interest] Set manipulation in Qt 6
In-Reply-To: <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
References: 
  <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
Message-ID: <20200621172617.GB11000@klara>

On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest wrote:

With my hat of the guy going around and deprecating toSet() and friends: the
rationale for these deprecations is the terrible code that those methods
encourage, and the

While I sympathize to some degree with the performance motivation behind this
kind of removal of convenience functionality this has to be put into perspective
of the price you charge:

We had to spent a significant amount of our time during the last year to
keep up with the deprecations within the last releases in the 5.x series.
This includes re-inventing parts of the abandoned qalgorithm as part of
our code base.

The toSet/toList changes alone involved touching 200+ locations in the code
base and I am not aware of even a single noticable performance improvement
as a result.

A back-of-the-envelope calculation with generous assumptions on user count and
usage frequency makes me believe that the accumulated win on saved computer
time does not even offset the amount of manual work that had to be spent
on these changes.

On top of that goes the more complex and consequently harder to read re-written
code, plus the chance of introduction of actual regressions in the code.

The latter is btw not just theoretical, I noticed only last Friday the hard
way that blindly replacing QLinkedList by std::list can transform previously
correct and working code into a crash. Having to thoroughly check each and
every such replacement only to get in the best case the same functionality
as before is an awful value proposition.

To summarize: If you despise wasting cycles for convenience that's fine.
Assuming that everyone else shares this preference is already odd. Making
other people pay for this is simply wrong.


(Which brings me to my second crusade, try stop encouraging the usage of Qt
containers, as their API is full of holes and doesn't play nice with
algorithms or ranges. But it's enough for this mail.)

If you want to use Qt without Qt that's fine. But please stop making other
people suffer from your choices.

Andre'


Andre being one of the Qt Creator developers is of course in a very special 
place. Not only because the Qt Creator team has decided that they want a single 
code base that builds against both Qt 5 and Qt 6. Doing so as Qt 6 was being 
developed of course resulted in more churn - but also in good feedback. Either 
way, it is perhaps not the most representative porting experience.

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.

Cheers,
Volker


Everybody else simply quit Qt when what they needed was nuked without 
warning.


Right now the only big name I know of continuing forward with Qt is John 
Deere, but I doubt they stick with it much longer. Will have to chat 
with my hunting buddy from high school again some time soon. He was over 
that stuff last time we chatted.


Btw, given the current state of QtCreator, I would point to it as a 
highly representative port.


--
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 Volker Hilsheimer 
> On 20 Mar 2021, at 14:22, Roland Hughes  wrote:
> 
> I grepped the archive this morning. Hopefully Andre's email still works. I 
> had hoped he was still watching on here and would pipe up. Maybe he and his 
> company abandoned Qt as well after the June 2020 exchange?
> 
> Here is a scrape of one of the messages in the thread from the archive.
> 
> Subject: [Interest] Set manipulation in Qt 6
> In-Reply-To: <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
> References: 
> 
>  <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
> Message-ID: <20200621172617.GB11000@klara>
> 
> On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest 
> wrote:
> > With my hat of the guy going around and deprecating toSet() and friends: the
> > rationale for these deprecations is the terrible code that those methods
> > encourage, and the
> 
> While I sympathize to some degree with the performance motivation behind this
> kind of removal of convenience functionality this has to be put into 
> perspective
> of the price you charge:
> 
> We had to spent a significant amount of our time during the last year to
> keep up with the deprecations within the last releases in the 5.x series.
> This includes re-inventing parts of the abandoned qalgorithm as part of
> our code base.
> 
> The toSet/toList changes alone involved touching 200+ locations in the code
> base and I am not aware of even a single noticable performance improvement
> as a result.
> 
> A back-of-the-envelope calculation with generous assumptions on user count and
> usage frequency makes me believe that the accumulated win on saved computer
> time does not even offset the amount of manual work that had to be spent
> on these changes.
> 
> On top of that goes the more complex and consequently harder to read 
> re-written
> code, plus the chance of introduction of actual regressions in the code.
> 
> The latter is btw not just theoretical, I noticed only last Friday the hard
> way that blindly replacing QLinkedList by std::list can transform previously
> correct and working code into a crash. Having to thoroughly check each and
> every such replacement only to get in the best case the same functionality
> as before is an awful value proposition.
> 
> To summarize: If you despise wasting cycles for convenience that's fine.
> Assuming that everyone else shares this preference is already odd. Making
> other people pay for this is simply wrong.
> 
> > (Which brings me to my second crusade, try stop encouraging the usage of Qt
> > containers, as their API is full of holes and doesn't play nice with
> > algorithms or ranges. But it's enough for this mail.)
> 
> If you want to use Qt without Qt that's fine. But please stop making other
> people suffer from your choices.
> 
> Andre'


Andre being one of the Qt Creator developers is of course in a very special 
place. Not only because the Qt Creator team has decided that they want a single 
code base that builds against both Qt 5 and Qt 6. Doing so as Qt 6 was being 
developed of course resulted in more churn - but also in good feedback. Either 
way, it is perhaps not the most representative porting experience.

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.

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-21 Thread coroberti 
On Mon, Mar 22, 2021 at 2:51 AM Jason H  wrote:
>
> >
> > > Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> > > Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> > > customers-leaving
> >
> > I wonder if the loss of confidence in the current Qt owners can ever 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.
>
> 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.

Jason, welcome to the club of re-writers.

Are you still using it for mobile platforms?

Kind regards,
Robert
___
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-21 Thread Jason H 
>
> > 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.

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.
___
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-21 Thread Bernhard Lindner 

> I don't know if it is current or not, but the KDE Manjaro has is really 
> nice. They don't stick you with the really bad KDE packages either, like 
> Calligra and KMail either. Apologies to our resident KMail fan.

KMail has several problems. THis is why I am using Evolution. But you don't 
need to switch
the distro. Simply install your favourite tools and remove the nasty ones. I 
have a script
for that purpose.

Alas the are KDE Tools with not real replacement. Like smb4k. I guess this is 
one of the
most frustrating tools I have ever used but there is no replacement when using 
KDE :(

-- 
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-21 Thread Bernhard Lindner 
Hi!

> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS + 
> Qt-6-rolling-out-incomplete + deleted-convenience-methods = 
> customers-leaving

I wonder if the loss of confidence in the current Qt owners can ever be 
compensated.

Even if TQC took back their critical decisions, 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.

-- 
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-21 Thread Roland Hughes 


On 3/21/21 12:11 PM, Thorsten Glaser wrote:

On Sun, 21 Mar 2021, Jason H wrote:


I anticipate that 5.15 will require a doubly long LTS period as a
result.

Unfortunately we learnt here that 5.15 will not have any LTS period
at all, at least not one that matters for the Open Source world.

This is, basically, the end of Qt (considering Qt 6 probably won’t
be entering Debian either, at least not with the current maintainers).

bye,
//mirabilos


You know, I made that prediction back in February. It was followed by a 
chortle


=

Subject: Re: [Interest] Qt 6 Ubuntu package

On 31/1/21 12:09 AM, Roland Hughes wrote:


If history repeats itself, and in the software industry it most
definitely does, requiring a login to obtain the OpenSource code
effectively ended OpenSource Qt.


really?
I guess maybe 'git clonehttp://code.qt.io/qt/qt5.git'
is a bit too much to ask for open source developers to type.

=

That chortle was followed by a Guffaw.

=

05.02.2021, 12:32, "Lorn Potter" :

On 31/1/21 12:09 AM, Roland Hughes wrote:

  If history repeats itself, and in the software industry it most
  definitely does, requiring a login to obtain the OpenSource code
  effectively ended OpenSource Qt.

really?
I guess maybe 'git clonehttp://code.qt.io/qt/qt5.git'
is a bit too much to ask for open source developers to type.

Or https://download.qt.io/archive/qt/.

=

I concur. Qt OpenSource is basically dead. That was the intent of all 
the moves. It's time for DVorak to pull out the keyboard and write an 
essay on Qt.


https://dvorak.org/whatever/

Without a maintainer it will either disappear from the Debian flock 
within a year or it will become like that Juffed editor that seems to be 
a zombie in all the repos. If you install it your Qt build environment 
and other Qt based applications break. Even with that, the thing usually 
won't open and edit something. Last updated in 2013 on SourceForge.


https://sourceforge.net/projects/juffed/

Still found in almost every Debian based repo. Been breaking things bad 
for years.


KDE will then be forced out of the Debian repos as well or just stay in 
whatever state it is with no distro actually supporting KDE desktop.


If you need slightly newer Qt, Manjaro has slightly newer Qt stuff. You 
just won't be able to build a Debian package or have your code run many 
places unless you are going to package the Qt libraries with your 
application.


As Jason said, nobody is targeting Qt 6.

The industrial control, set-top box, and medical device market that has 
already left have been telling me they aren't coming back. Why would 
they? Been too much pain over the past couple of years. Too many methods 
just disappearing without even asking the market if they are in use.


What was it? About 25 years? Not a bad run for software. Clipper only 
made it 12.


https://en.wikipedia.org/wiki/Clipper_(programming_language)

Everything the market is telling me now though is that Qt is headed off 
for the Commodore Amiga and WordsStar realm. Small group of really rabid 
fans.


For many the last straw was what Jason pointed out. Qt 6 was shoved out 
the door to chase license revenue no matter the condition of it.



--
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-21 Thread Thorsten Glaser 
On Sun, 21 Mar 2021, Jason H wrote:

> I anticipate that 5.15 will require a doubly long LTS period as a
> result.

Unfortunately we learnt here that 5.15 will not have any LTS period
at all, at least not one that matters for the Open Source world.

This is, basically, the end of Qt (considering Qt 6 probably won’t
be entering Debian either, at least not with the current maintainers).

bye,
//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-21 Thread Roland Hughes 


On 3/21/21 7:42 AM, Jason H wrote:

Sent: Friday, March 19, 2021 at 4:07 PM
From: "Roland Hughes" 
Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
Qt-6-rolling-out-incomplete + deleted-convenience-methods =
customers-leaving


I find myself agreeing with Roland here. The rollout of the core modules if KDE 
without the rest was a disaster and I was shocked, disappointed, and perplexed 
as to why anyone would do it.  So there is Qt6? No one I know is targeting it. 
Way to make all that work irrelevant, or at least less relevant than a Qt 5.16 
release would have been. (Binary/API promises aside)

I'm really dismayed and confused as anyone would repeat the rollout of KDE. Xfce and 
GNOME are crushing KDE, and I attribute that to the way they rolled it out. In this day 
to not have multimedia a part of that... Just wow... The older and stable modules I could 
understand, QtSQL? Sure. But it creates an idea of "it's not ready yet" so no 
one targets it.  I anticipate that 5.15 will require a doubly long LTS period as a result.



I don't know if it is current or not, but the KDE Manjaro has is really 
nice. They don't stick you with the really bad KDE packages either, like 
Calligra and KMail either. Apologies to our resident KMail fan.


https://distrowatch.com/table.php?distribution=manjaro

I don't use it to watch streaming video though. It even handles multiple 
monitors correctly. Something Xfce has never been able to do.


You are correct though. KDE on every other Linux distro absolutely 
sucks. I chewed through a lot of them before just sticking Ubuntu 20.04 
LTS on my primary desktop.


MX Linux is at the top of the DistroWatch charts lately.

https://distrowatch.com/table.php?distribution=mx

It's really really nice, _if_ you only have one monitor _or_ you have 
the monitors in the exact order Xfce wants them in.


Again, I don't use it for streaming video and it is not my primary desktop.

--
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-21 Thread Jason H 
> Sent: Friday, March 19, 2021 at 4:07 PM
> From: "Roland Hughes" 

> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS +
> Qt-6-rolling-out-incomplete + deleted-convenience-methods =
> customers-leaving
>

I find myself agreeing with Roland here. The rollout of the core modules if KDE 
without the rest was a disaster and I was shocked, disappointed, and perplexed 
as to why anyone would do it.  So there is Qt6? No one I know is targeting it. 
Way to make all that work irrelevant, or at least less relevant than a Qt 5.16 
release would have been. (Binary/API promises aside)

I'm really dismayed and confused as anyone would repeat the rollout of KDE. 
Xfce and GNOME are crushing KDE, and I attribute that to the way they rolled it 
out. In this day to not have multimedia a part of that... Just wow... The older 
and stable modules I could understand, QtSQL? Sure. But it creates an idea of 
"it's not ready yet" so no one targets it.  I anticipate that 5.15 will require 
a doubly long LTS period as a result.
___
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-20 Thread Roland Hughes 
I grepped the archive this morning. Hopefully Andre's email still works. 
I had hoped he was still watching on here and would pipe up. Maybe he 
and his company abandoned Qt as well after the June 2020 exchange?


Here is a scrape of one of the messages in the thread from the archive.

Subject: [Interest] Set manipulation in Qt 6
In-Reply-To: <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
References: 


 <2dbe5c20-648d-02bd-745d-4415449f1...@kdab.com>
Message-ID: <20200621172617.GB11000@klara>

On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest 
wrote:
> With my hat of the guy going around and deprecating toSet() and 
friends: the

> rationale for these deprecations is the terrible code that those methods
> encourage, and the

While I sympathize to some degree with the performance motivation behind 
this
kind of removal of convenience functionality this has to be put into 
perspective

of the price you charge:

We had to spent a significant amount of our time during the last year to
keep up with the deprecations within the last releases in the 5.x series.
This includes re-inventing parts of the abandoned qalgorithm as part of
our code base.

The toSet/toList changes alone involved touching 200+ locations in the code
base and I am not aware of even a single noticable performance improvement
as a result.

A back-of-the-envelope calculation with generous assumptions on user 
count and

usage frequency makes me believe that the accumulated win on saved computer
time does not even offset the amount of manual work that had to be spent
on these changes.

On top of that goes the more complex and consequently harder to read 
re-written

code, plus the chance of introduction of actual regressions in the code.

The latter is btw not just theoretical, I noticed only last Friday the hard
way that blindly replacing QLinkedList by std::list can transform previously
correct and working code into a crash. Having to thoroughly check each and
every such replacement only to get in the best case the same functionality
as before is an awful value proposition.

To summarize: If you despise wasting cycles for convenience that's fine.
Assuming that everyone else shares this preference is already odd. Making
other people pay for this is simply wrong.

> (Which brings me to my second crusade, try stop encouraging the usage 
of Qt

> containers, as their API is full of holes and doesn't play nice with
> algorithms or ranges. But it's enough for this mail.)

If you want to use Qt without Qt that's fine. But please stop making other
people suffer from your choices.

Andre'

--
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-19 Thread Roland Hughes 


On 3/19/21 9:08 AM, Volker Hilsheimer wrote:

Ok. API stability on the one hand, and keeping things maintainable and 
un-bloated over a long time on the other, is of course a tradeoff. Different 
industries will have different preferences, but the path we have chose for Qt 
over the last 25 years seems to not have been completely wrong, even for folks 
building safety critical systems.

That there are long threads on controversial topics is often a good thing. esp 
if they are followed by code contributions from the people that care. Many of 
the discussions we had last year about e.g. the APIs of container and string 
classes (most of those on the development list where the development OF Qt is 
discussed [1]) have definitely resulted in better decisions for Qt 6.0.

Volker

[1] https://lists.qt-project.org/listinfo/development


Well, over the past two years it became wrong because I (and others in 
here) have been watching a massive exodus. Companies that were firmly 
entrenched with Qt have now banned and most have completely removed it 
from their product lines. Cable set-top boxes and medical devices used 
to provide no end of high paying Qt jobs. Licensing combined with API 
changes have the major players banning and removing Qt. The few 
automotive people I have any communication with say they are also 
looking at full redevelopment with RDK. Unless something drastically 
changes, from where I'm sitting the only market Qt will have left at 
year's end is phones.


By-the-bye, customers aren't going to hang out in the development list, 
usually. The IT industry standard is to not delete things from an API 
until customers have been queried. It has to do with keeping customer's 
code maintainable.


At any rate, it has been a perfect storm.

Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS + 
Qt-6-rolling-out-incomplete + deleted-convenience-methods = 
customers-leaving


If you've already got to go through a full re-certification you might as 
well jump to a platform that promises not to do that to you in the 
future. There was no way the above math was going to lead to more 
licenses and support contracts being sold.


Maybe Konrad is seeing something different where he lives? It sounds 
like we travel in much the same industries. In America the stalwart 
industries of Qt use appear to be abandoning it wholesale.


--

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-19 Thread Volker Hilsheimer 


> On 19 Mar 2021, at 14:34, Roland Hughes  wrote:
> 
> 
> On 3/19/21 7:51 AM, Volker Hilsheimer wrote:
>>> On 19 Mar 2021, at 12:12, Roland Hughes  wrote:
>>> 
>>> 
>>> 
>>> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
 Il 18/03/21 12:41, Christian Gagneraud ha scritto:
 
> My main grief is that Qt doesn't seem to care about C++.
> What was their last contribution to the standard?
> 
 Apart from hiring the ex-chair of the WG21 Evolution Working Group?
 
 (Can we stop with the FUD please?)
 
>>> Can we stop the willy-nilly deletion of existing convenience methods 
>>> currently used in products in the field?
>>> -- 
>>> Roland Hughes, President
>> Hey Roland,
>> 
>> Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the 
>> API from bloating too much. We can add convenience wrappers and overloads 
>> when we see that they are really needed.
>> 
>> We might have gone a bit far in some cases, but the porting experiences I’ve 
>> read so far suggest that by and large it has been a rather decent experience.
>> 
>> Do you have any particular classes in mind?
>> 
>> Volker
>> 
> I'm sure the person who was complaining repeatedly to Giuseppe will pipe up 
> if they are still using Qt. That was a long thread in here last year. It lead 
> to other long threads.
> 
> You cannot remove existing functionality without surveying the user base to 
> find out if it is used. That person took a big hit with a lot of needless 
> retesting and coding because of a willy-nilly removal.
> 
> Once you ship it, you can't remove it, until __after__ it dies on the field. 
> Doesn't matter what "it" is. This is called product stability. I do not know 
> if it was an FDA regulated product that impacted. I do know that if it was 
> FDA regulated the odds of them being able to slip it through the "minor 
> enhancement" (don't remember the official name) testing and approval path 
> with that level of modification would be slim. That would mean lots of 
> additional expense for them and everyone else impacted by the removal.
> 
> This also lead to a lengthy discussion about API stability. You can also find 
> that in the archives for last year and probably in 2019 as well.
> 
> For the SAFETY world where human/animal life is at Risk, LTS is roughly 20 
> years (over 30 in some markets) and STS (Short Term Support) is 7-10 years.
> 
> Thinning out the API may have been a conscious decisions, but I never saw any 
> messages on this list about things you were thinking about killing. Granted I 
> get this in digest form and mostly skim the subjects for something of 
> interest to me. Judging from the shock and length of that previous discussion 
> nobody on here saw any such messages either. From a customer base perspective 
> these decisions were made in a vacuum and are helping to speed the complete 
> abandonment of Qt.


Ok. API stability on the one hand, and keeping things maintainable and 
un-bloated over a long time on the other, is of course a tradeoff. Different 
industries will have different preferences, but the path we have chose for Qt 
over the last 25 years seems to not have been completely wrong, even for folks 
building safety critical systems.

That there are long threads on controversial topics is often a good thing. esp 
if they are followed by code contributions from the people that care. Many of 
the discussions we had last year about e.g. the APIs of container and string 
classes (most of those on the development list where the development OF Qt is 
discussed [1]) have definitely resulted in better decisions for Qt 6.0.

Volker

[1] https://lists.qt-project.org/listinfo/development

___
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-19 Thread Roland Hughes 


On 3/19/21 7:51 AM, Volker Hilsheimer wrote:

On 19 Mar 2021, at 12:12, Roland Hughes  wrote:



On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:

Il 18/03/21 12:41, Christian Gagneraud ha scritto:


My main grief is that Qt doesn't seem to care about C++.
What was their last contribution to the standard?


Apart from hiring the ex-chair of the WG21 Evolution Working Group?

(Can we stop with the FUD please?)


Can we stop the willy-nilly deletion of existing convenience methods currently 
used in products in the field?
--
Roland Hughes, President

Hey Roland,

Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the 
API from bloating too much. We can add convenience wrappers and overloads when 
we see that they are really needed.

We might have gone a bit far in some cases, but the porting experiences I’ve 
read so far suggest that by and large it has been a rather decent experience.

Do you have any particular classes in mind?

Volker

I'm sure the person who was complaining repeatedly to Giuseppe will pipe 
up if they are still using Qt. That was a long thread in here last year. 
It lead to other long threads.


You cannot remove existing functionality without surveying the user base 
to find out if it is used. That person took a big hit with a lot of 
needless retesting and coding because of a willy-nilly removal.


Once you ship it, you can't remove it, until __after__ it dies on the 
field. Doesn't matter what "it" is. This is called product stability. I 
do not know if it was an FDA regulated product that impacted. I do know 
that if it was FDA regulated the odds of them being able to slip it 
through the "minor enhancement" (don't remember the official name) 
testing and approval path with that level of modification would be slim. 
That would mean lots of additional expense for them and everyone else 
impacted by the removal.


This also lead to a lengthy discussion about API stability. You can also 
find that in the archives for last year and probably in 2019 as well.


For the SAFETY world where human/animal life is at Risk, LTS is roughly 
20 years (over 30 in some markets) and STS (Short Term Support) is 7-10 
years.


Thinning out the API may have been a conscious decisions, but I never 
saw any messages on this list about things you were thinking about 
killing. Granted I get this in digest form and mostly skim the subjects 
for something of interest to me. Judging from the shock and length of 
that previous discussion nobody on here saw any such messages either. 
From a customer base perspective these decisions were made in a vacuum 
and are helping to speed the complete abandonment of Qt.


In all fairness though, the licensing FUD already had it being kicked 
out the door in many places. When that is combined with a painful 
upgrade path the decision to re-platform is pretty easy. You are going 
to have to do the same amount of validation work anyway.


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

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

2021-03-19 Thread Volker Hilsheimer 
> On 19 Mar 2021, at 12:12, Roland Hughes  wrote:
> 
> 
> 
> On 3/19/21 6:00 AM, Giuseppe D'Angelo wrote:
>> Il 18/03/21 12:41, Christian Gagneraud ha scritto:
>> 
>>> My main grief is that Qt doesn't seem to care about C++.
>>> What was their last contribution to the standard?
>>> 
>> Apart from hiring the ex-chair of the WG21 Evolution Working Group?
>> 
>> (Can we stop with the FUD please?)
>> 
> Can we stop the willy-nilly deletion of existing convenience methods 
> currently used in products in the field?
> -- 
> Roland Hughes, President

Hey Roland,

Giving Qt 6 a leaner API was a conscious decision in many cases to avoid the 
API from bloating too much. We can add convenience wrappers and overloads when 
we see that they are really needed.

We might have gone a bit far in some cases, but the porting experiences I’ve 
read so far suggest that by and large it has been a rather decent experience.

Do you have any particular classes in mind?

Volker



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