> yeah, 6.0 is a joke given that you intend to break binary
> compat in 6.1 - that's the wisdom of linking r&d's bonus payments to
> release dates even for major versions
Thank you for saying what no one else dared to say.
--
Best Re
you for informing us.
Funny, this is pretty much how I would phrased it as well.
--
Best Regards,
Bernhard Lindner
signature.asc
Description: This is a digitally signed message part
___
Development mailing list
Development@qt-project.org
https://l
> ... resulting in users complaining about "high priority bugs get ignored".
They're still complaining? Impressive. I have already passed the phase of
resignation and
just wonder why there is still a public bug tracker.
--
Best Regards
o qFatal (or at least qWarning).
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
5.15 gives me warnings about
deprecation of
operator < for QVariant.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
egards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
t; are exhaustive. And they're way too slow for a regular run.
I thought of something like a simple, manually maintained ABI version. Sure, on
the one
hand this wouldn't prevent uninentional BC breaks. On the other hand, BC
changes could be
done intentionally and managed in a safe
Hi!
> Breaking BC means subtle errors that are hard do detect and debug.
Couldn't those subtle errors be replaced by some clear and understandable
error? Like some explicit binary compatibility check?
--
Best Regards,
Bernhard
I agree completely with Jason.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
https://bugreports.qt.io/browse/QTBUG-77020
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
> * enable templated QObjects. There's a prototype from Olivier, so is that
> possible?
Yes, this is long overdue.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.o
better) replacement is an MCA in my
book. And it
heavily damages Qt's reputation.
The criteria that allows to deprecate a component without proper replacement
should be
EXTREMELY defensive.
--
Best Regards,
Bernhard Lindner
___
Development mailin
handle templates).
Any proposals for a Qt 6 story?
I hope my suspicion is wrong that Qt has spent so much on a few cash cows that
it is no
longer capable of any other major advances (but must even go backwards, see XML
thread).
--
Best Regards,
Bernhard Lindner
_
new strategic goals if the limits or goals are unknown?
Actions out of frustration are never a good idea. And pushing into a
(technical) direction
that does not solve the underlying (strategical) problem is futile.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
definitely
> but to actively develop them further?
No answer to my question above?
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ut
to actively develop them further?
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
nsider it broken? I consider that class fundamental.
Using XML without using a schema validator is (or at least should be) a no-go.
So even if
the Qt XML component should be continued in some way, Qt should also not lack a
schema
validator.
--
Best Regards,
Bernhard L
h for a deprecation. This means (at least for
new code)
there is no significant difference (only a delay) between "no maintainer" and
"deprecated".
Thiagos criteria sounded ok but obviously they are not valid anymore.
Qt must to be in a very strong market position if such a s
he confusion is perfect. Especially notice issue 71784 above. That is what I
talked about
earlier when I said without clean documentation you can not do clean Qt6
planning.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
instead of ambiguous sentences like the one I cited?
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
> I don't think the "Done" nomenclature stuck though. In half the cases it
> just meant unmaintained rather than actually done.
That document should be revised. It obviously is very important. How can you
even do
strategical planing without such a fundamental
ng the states and their meaning? Is there a
component/state
table where we could lookup the specific states?
--
Best Regards,
Bernhard Lindner
signature.asc
Description: This is a digitally signed message part
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ing progress, such as the QList discussion. Those two
> modules
> are not in the way of anything else, so the decision can change.
>
> All it takes is someone stepping up to maintain either or both of them.
>
--
Best Regards,
Bernhard Lindner
the deprecations irrevocable?
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ou...
Then compare this thread/answer: https://stackoverflow.com/a/18549053/1421332
With this thread/answer: https://stackoverflow.com/a/421615/1421332
And, LOL, do not skip the comment below the first answer!
Nothing more to say.
--
Best Regards,
Bernhard Lindner
t;, still requiring a few changes
> though, e.g. std::unordered_map iterators are forward, QHash ones are
> bidirectional. If the SIC is acceptable, something to consider for Qt 6.
Are there any plans/discussions how to procede with that experim
> you end up where the STL is - so convoluted it's hardly worth making
> anything with it.
I agree. The horrid of STL was one of the reasons for me to use Qt. Everything
is
complicated to the maximum in STL. Qt is so much more intuitive, it is fast to
learn and
fun to use (except when hitting a
Actually the Qt update behavior annoys my as well.
I wish there would be two checkbox options in the maintenance tool:
"Install new bug fix versions automatically"
"Install new minor versions automatically"
This is reasonable, isn't it?
--
Best Regards
Bernhard
r forever.
--
Best Regards,
Bernhard Lindner
signature.asc
Description: This is a digitally signed message part
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
; somewhat arbitrary.
> 4) Default values of object properties being context dependent is not that
> unusual
>
>
> Cheers,
> Volker
>
--
Best Regards,
Bernhard Lindner
On 11 Feb 2019, at 22:47, Bernhard Lindner wrote:
> >
> > Hi!
> >
> > I just
Default default of true to
buttons with
QDialogButtonBox parents instead of QDialog parents?
4. Anyway, is it good style to change the default value (!) of a property
dynamically like
this?
Thanks in advance!
--
Best Regards,
Bernhard Lindner
signature.asc
Description:
Hi everybody!
Are there any plans for Qt6' API to use standard types like size_t (or special
replacements like qsizetype) for return values and parameters that have
platform dependent
width?
--
Best Regards,
Bernhard Lindner
___
Development ma
Hi!
> No. However, I am asking for proof.
Maybe I worked for the wrong companies all the time. But whenever we wanted to
have proof
that some tool or library actually meets our requirements, it never was
sufficient to
*ask* for proof. We needed to test it by *ourselfs* in a feasibility project.
Resisting to have anything and everything in black and white is hard and is not
popular
and surely not zeitgeist but sometimes the better way.
Please do not make me discuss about that as well, I prefer to wrangle with item
delegate
code ;)
--
Best regards,
Be
a recent example.
I didn't say "technical". Also I didn't say "number of e-mails".
Anyway I think engineering and politics should be separated. On any level.
Politics is
extremly harmful to engineering. CoCs are alw
I wish any one discussion about Qt software quality would have attracted so much
attention, passion and effort as this CoC topic.
--
Best Regards,
Bernhard Lindner
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
> You could choose to turn QDataStream into a black-box, but I think there
> should be a white-box alternative which has to be
> 1/ as efficient : binary format
> 2/ as easy to use : QDataStream is able to serialize any type with the help
> of qRegisterMetaTypeStreamOperators
> 3/ as generic : it s
37 matches
Mail list logo
