[Qt-interest] Clarification on "out of scope" closed bug

[Andre Somers]

Op Wo, 19 januari, 2011 1:38 pm, schreef Thiago Macieira:
> On Wednesday, 19 de January de 2011 07:55:58 Andre Somers wrote:
>> Auch!
>> How is that for being able to count on Qt as a stable platform?
>
> It's "we make mistakes"

Fair enough, we all make mistakes we live to regret. But at least, then
please *document* that, so that users don't find out later on that they
have worked against a piece of code that is considdered a dead end.

>> QGraphicsProxyWidget has been introduced in 4.4, released in the first
>> half of 2008. That is less than 3 years ago. And now, you tell your
>> users that what they have come to rely on is suddenly not supported
>> anymore? There is no "depricated" label to be found for that class.
>
> I didn't say it is not supported. I said you're better off not using it.
> It's
> horribly slow and will kill your graphics view performance. It's not
> something we can optimise further because it's a flawed design.

> The bug report the OP posted was just a symptom of that fact.
As I remember, the OP was not complaining about performance, but about
rendering issues. That's not the same, I'd say. How is closing a rendering
bug with an "out of scope" not "not supported" then? If bugs are not going
to be fixed, then in my book it is not supported. But perhaps my notions
of "supported" differ from those used by Qt, so please clarify.

> It's also being
> honest: the priority for fixing the issue the OP reported was so low that
> it's fair to say it won't get done. That way, if someone else
> has a fix, please go ahead for it.
Being honest after the fact is not much use. What I mean is: I think you
(not you personally, but Qt in general) should add warnings in the
documentation if classes are considdered end-of life, "mistakes" or for
some other reason won't receive bugfixes anymore or are for other reasons
better to stay away from in new code. Better yet: that should be announced
*ahead* of time, *before* such support actually stops. Qt decided to
release the code (and I remember showed it off even, I can still see the
cool demo's where a Grahics view item rotated to show it's backside to
reveal a widget-based form to edit something). That, IMHO, also means
supporting it.

The mistake reported by the OP is not a performance issue; he could have
known about those. It is a rendering issue. Was it documented that it
suffered rendering problems? The only warning I find, is one about
performance issues: not for "high performance scenarios".

>> What are the promises made by Sebastian Nyström at the 2010 DevDays that
>> investments in the desktop area would not go down worth, if this is what
>> happens in practice? [1] Can we rely on QML being supported three years
>> from now, or will we again need redo our components in the next great,
>> yet immature, Qt technology again to expect to work against supported
>> code?
>
> We're supporting desktops, sure. But we're not going to add features to a
> subsystem that is known to be broken.

This is not a feature request, it is a clear rendering bug! And if it's
"known" to be broken, perhaps it is time to share that knowledge to a
wider audience.

>> I really love working with Qt, but I really don't like the way users
>> with existing investments in Qt seem to be left in the cold because
>> their little corner is not the next hot thing any more.

I seem to recall we had this discussion before. Please notice that I
engage in them because I *care* about Qt, not out of malice or spite. I
really appreciate your public interaction here and on other channels, and
I know you're a nice guy (we've met briefly a few times).

Perhaps the question is, in summary: what other pieces or subsystems in Qt
are considdered mistakes, end of life, better avoided, things to migrate
away from or have some other questionable status that you would not want
to base real-life code on? What viable migrations paths are recomended for
those? I know of two: QHttp (documented obsolete, fine) and QDom* (based
on earlier comments by you, not documented). Any others?

André