Re: [Development] Converting types in Qt
On Jul 15, 2014, at 7:36 PM, Olivier Goffart oliv...@woboq.com wrote:
On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix,
everything
is even more complex.
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build
time, but it's fine to change int foo() { return 42; } to int foo() {
return -1; } ?
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
breakages.
so Qt can know it and use it. For certain types we can do much better,
because we can automatically convert some types. For example:
QVectorchar - QLinkedListint
QVectorchar v; v.append(130);
QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
assert(l.first() == 130) ? Depends ?
QVariant(char(130)).toInt() already exists. You may argue that it is not
sensible but that's another issue.
I guess the example is more between QVectorT1 - QLinkedListT2 when there
exist a conversion from T1 to T2
A conversion may be arbitrary. For example, most of the
conversions
to QString. Should bool(false) - QString return False, 0,
false?
What about precision of, for example, double - QString ?
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
What's the mistake here? Wrong encoding? Bad performances?
wrong values unexpected results
When one use QVariant, it is because we want to enjoy dynamic typing and nice
conversions.
I don’t think we have a single place in Qt Creator where we want automatic
conversions when using QVariant. A search for QVariant(Map) returns 5400 hits.
In the map case, we usually expect the one retrieving the value for a key to
know the exact type of what was thrown in (that’s usually the same class, or
related classes), and then we use item models and QSettings which we use in the
same way.
Even if automatic conversion might be interesting (when, actually?), then the
point is:
There is no API in QVariant to support the common use case of getting the value
*without* automatic conversion.
We use common sense on a case by case basic.
Either there is no “common sense” common to me, or this rule has failed in the
past already ;)
bool - string ?
bytearray - int/long/double ?
keysequence - int ?
string - bool ?
string - bytearray ?
string - int ?
Br, Eike
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OTHER_FILES in Qt Creator 3.1.1
On Thu, May 29, 2014 at 10:51:15AM +0200, Richard Höhne wrote:
The problem is, that the other files are shown under the subfolder
lib.pri and not under the header- and cpp-files.
Is there a possibility to change it[?]
no.
wildcard matching in project files is considered bad practice and no
effort whatsover will be put in making it work better.
In the lib.pri I have following code:
defineTest(otherfiles) {
files = *.sql *json *lst * txt
return($$files)
}
and in the pro-File:
OTHER_FILES = $$otherFiles()
btw, this was a question for qt-creator@, not development@.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Milian Wolff as approver
+1 On Tue, Jul 15, 2014 at 08:08:39PM +, Gladhorn Frederik wrote: Hi all, it’s my pleasure to nominate Milian Wolff as approver. He’s a great guy, works for KDAB and has done interesting work on profiling, improves KDevelop amongst other things and has been active with all things web it seems. He’s started and is maintaining the qtwebchannel repository which is getting more and more attention lately. He’s great to work with and based in Berlin. I think he makes a great addition to the list of Qt approvers. His submissions: https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Tuesday 15 of July 2014 11:59:03 Olivier Goffart wrote: 1.3 Should we try to support a user's type conversions out of the box? Currently a user needs to manually register a conversion function so Qt can know it and use it. For certain types we can do much better, because we can automatically convert some types. For example: QVectorchar - QLinkedListint QListFoo - QVectorFoo QPointerFoo - QObject* QPointerFoo - void* QSharedDataPointerFoo - bool MyQObject* - QPointerMyQObject Currently we are not doing it for one reason which is behavior compatibility. What if a user already defined a conversion that we want to add? It could happen because the conversion was not available in a previous Qt version. The problem is that the new conversion function may behave in a different way, especially in edge cases and because of the lack of perfection mentioned in 1.2. We need to pick only one function. That could be the Qt version, but then we risk that an existing code will not work anymore. Are we willing to accept that? I believe that we should document the problem, and allow the conversions. I think we could try to automatically do conversion when we know how to do it. And if there is an user defined conversion, it overrides the automatic one. We could implement overriding, but we would not control which conversion is registered first / last. Moreover it would mean that a conversion could change at any point. I think it would be a bit too nondeterministic. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Tuesday 15 of July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix,
everything
is even more complex.
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build
time, but it's fine to change int foo() { return 42; } to int foo() {
return -1; } ?
Yes. Because there are two separate issues here. One is that the build time
sometimes doesn't exist, and you do not want to break an application that had
no opportunity to rebuild. Second is that I'm not talking about abstract foo
or bar function. I was explicit what would change, it would be Qt answer for
a simply question could you convert this value to this type. I guess in most
cases the question would be placed in a context: could you convert this value
to this type, because I know only how to handle the type and not any other.
In my opinion it is good to answer the question with yes.
so Qt can know it and use it. For certain types we can do much better,
because we can automatically convert some types. For example:
QVectorchar - QLinkedListint
QVectorchar v; v.append(130);
QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
assert(l.first() == 130) ? Depends ?
Invalid code = undefined output. You can simplify the example to:
QVectorchar v; v.append(130);
assert(v.first() == 130) ? Depends ?
The issue has nothing to do with a magic conversion. You can blame C++
standard, which doesn't specify if char is signed or not, or people that write
such code. I guess both options are valid :-)
A conversion may be arbitrary. For example, most of the
conversions
to QString. Should bool(false) - QString return False, 0,
false?
What about precision of, for example, double - QString ?
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
You are right, it is good to avoid it, but sometimes it is not possible
especially, if you do not control full stack.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart wrote:
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build
time, but it's fine to change int foo() { return 42; } to int foo() {
return -1; } ?
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
breakages.
Type safety is a safety net that catches errors very early in the
software production and deployment cycle, and one of the features
that makes a programming language usable for the development
of large applications at a reasonable pace.
Implicit type conversions kill type safety. This is widely recognized
as a bad thing. In case of C++ some are unavoidable due to the
C legacy, but e.g. for user-defined conversion operators we now got
explicit, _because_ people learned the hard way that implicit
conversions are causing more trouble than wanted.
[...]
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
What's the mistake here? Wrong encoding? Bad performances?
Wrong encodings under circumstances that are typically not present on
the developers or test machines. Here the lack of type safety postpones
a problem that would be immediately visible (and fixable) at compile time,
to the time after the application has been shipped.
In the best case this only causes a bug report that needs to be handled
normally, i.e. needs triaging/fixing/integration (and hopefully is not so
critical to require an immediate emergency release, but can be delivered
with the next regular one). Worst case this could mean that the application
is unusable in a larger part of the world. With or without someone reporting
the problem.
This is a kind of convenience I don't need, and I pretty much prefer
the inconvenience of having to spell out type conversions explicitly.
When one use QVariant, it is because we want to enjoy dynamic typing
and nice conversions.
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract anything else from the variant than exactly the thing
I put into it.
I _never_ (at least not intentionally) use QVariant as a kind of magic
converter bag where I put something in and get something
conveniently munged back.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract anything else from the variant than exactly the thing
I put into it.
So if I understand you and Eike correctly, what you want is some kind of
templatetypename T T qvariant_cast_safe(const QVariant v) {
Q_ASSERT(v.userType() == qMetaTypeIdT())
return *reinterpret_castconst T *(v.constData());
}
I _never_ (at least not intentionally) use QVariant as a kind of magic
converter bag where I put something in and get something
conveniently munged back.
When you play with qml or itemview, it's cool that there is a
QVariant::toString() that puts some string out in order to show to the user
what's in it.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote: [...] When one use QVariant, it is because we want to enjoy dynamic typing and nice conversions. I don’t think we have a single place in Qt Creator where we want automatic conversions when using QVariant. A search for QVariant(Map) returns 5400 hits. In the map case, we usually expect the one retrieving the value for a key to know the exact type of what was thrown in (that’s usually the same class, or related classes), and then we use item models and QSettings which we use in the same way. Even if automatic conversion might be interesting (when, actually?), then the point is: There is no API in QVariant to support the common use case of getting the value *without* automatic conversion. Nobody asked for it, It should be easy to implement something equal to this; Q_ASSUME(variant.userType() == qMetaTypeTargetType()); TargetType data = variant.valueTargetType(); I believe such new api make sense, we can add it. We use common sense on a case by case basic. Either there is no “common sense” common to me, or this rule has failed in the past already ;) bool - string ? bytearray - int/long/double ? keysequence - int ? string - bool ? string - bytearray ? string - int ? Br, Eike What is wrong with string - int or bytearray - int? -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Milian Wolff as approver
+1 On 7/15/14, 10:08 PM, Gladhorn Frederik frederik.gladh...@digia.com wrote: Hi all, it¹s my pleasure to nominate Milian Wolff as approver. He¹s a great guy, works for KDAB and has done interesting work on profiling, improves KDevelop amongst other things and has been active with all things web it seems. He¹s started and is maintaining the qtwebchannel repository which is getting more and more attention lately. He¹s great to work with and based in Berlin. I think he makes a great addition to the list of Qt approvers. His submissions: https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wo lff%2540kdab.com%253E%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian .wolff%2540kdab.com%253E%22,n,z Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 of July 2014 08:41:07 Poenitz Andre wrote:
Olivier Goffart wrote:
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() {
return
42; } to some int bar() { return 42; } that's easy to discover at build
time, but it's fine to change int foo() { return 42; } to int foo() {
return -1; } ?
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
breakages.
Type safety is a safety net that catches errors very early in the
software production and deployment cycle, and one of the features
that makes a programming language usable for the development
of large applications at a reasonable pace.
Implicit type conversions kill type safety. This is widely recognized
as a bad thing. In case of C++ some are unavoidable due to the
C legacy, but e.g. for user-defined conversion operators we now got
explicit, _because_ people learned the hard way that implicit
conversions are causing more trouble than wanted.
That is a controversial statement. There is many languages, that doesn't offer
strict type safety and they are fine. Let's no go into this discussion because
it would lead us nowhere.
[...]
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
What's the mistake here? Wrong encoding? Bad performances?
Wrong encodings under circumstances that are typically not present on
the developers or test machines. Here the lack of type safety postpones
a problem that would be immediately visible (and fixable) at compile time,
to the time after the application has been shipped.
In the best case this only causes a bug report that needs to be handled
normally, i.e. needs triaging/fixing/integration (and hopefully is not so
critical to require an immediate emergency release, but can be delivered
with the next regular one). Worst case this could mean that the application
is unusable in a larger part of the world. With or without someone reporting
the problem.
This is a kind of convenience I don't need, and I pretty much prefer
the inconvenience of having to spell out type conversions explicitly.
In this particular case I would blame QSettings API, which pretends that is
able to handle everything while it is not.
When one use QVariant, it is because we want to enjoy dynamic typing
and nice conversions.
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract anything else from the variant than exactly the thing
I put into it.
I _never_ (at least not intentionally) use QVariant as a kind of magic
converter bag where I put something in and get something
conveniently munged back.
Actually I agree, I believe that QVariant should be just a stupid container
which allows you to transfer a data in type agnostic way, from one place to
another. Well, during it lifetime it accumulated a bit of additional
functionality, but I see that the discussion is floating in wrong direction.
Let's not talk about implicit QVariant conversions, we have them and we can
not remove them. We can add, as Olivier suggested qvariant_type_safe_cast to
our API. Let's talk about QMetaType::convert and
QmetaType::hasRegisteredConverterFunction, instead are we allowed to change
their behavior by adding / modifying conversions ?
Jędrek
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart:
Poenitz Andre wrote:
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract anything else from the variant than exactly the thing
I put into it.
So if I understand you and Eike correctly, what you want is some kind of
templatetypename T T qvariant_cast_safe(const QVariant v) {
Q_ASSERT(v.userType() == qMetaTypeIdT())
return *reinterpret_castconst T *(v.constData());
}
This would alleviate the environment dependency of the problem,
i.e. presumably increase the probability that the issue is caught in
local testing. (Of course, a real compile-time check i.e. something
that would also catch errors in code paths that are not executed during
testing would be preferable, but that's not achievable in this setup)
I _never_ (at least not intentionally) use QVariant as a kind of magic
converter bag where I put something in and get something
conveniently munged back.
When you play with qml or itemview, it's cool that there is a
QVariant::toString() that puts some string out in order to show
to the user what's in it.
That's a one-way route for a specific purpose, pretty much like
qPrintable(). There's nothing wrong with a .toDisplay() (or similar)
function, but that's don't think this is the kind of type conversion
that triggered this thread.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote: Olivier Goffart wrote: It's always a dilemma. We have to look at how likely we are to break applications and I don't think adding a conversion is likely to cause breakages. Type safety is a safety net that catches errors very early in the software production and deployment cycle, and one of the features that makes a programming language usable for the development of large applications at a reasonable pace. I feel I need to clear up some misconceptions here: the kind of type safety offered by C++ is a possibility, but not a necessity for fast and safe development of large applications. I've done Smalltalk for quite some time - it does not have a static type system like C++ and development is still faster than in most C++ based environments - I'd even go as far as saying it is slightly faster to develop with Smalltalk than it is to develop with Qt (I still prefer Qt for its more modern API). The key is usually great documentation, good tooling, good APIs and fast turn-around from adding a few lines to seeing them in action (in the last point C++ can't even hope to compete with Smalltalk, the other three are quite good with Qt). Implicit type conversions kill type safety. This is widely recognized as a bad thing. In case of C++ some are unavoidable due to the C legacy, but e.g. for user-defined conversion operators we now got explicit, _because_ people learned the hard way that implicit conversions are causing more trouble than wanted. Let's not mix up too much here: type conversions are necessitated by the fact that C++ has static typing - otherwise you would not get much done with it - from the Smalltalk point of view C++ is not polymorphic. Implicit type conversions are necessitated by the fact that programmers (like me) are lazy bastards and don't like to read lines which are longer than a couple of words. The explicit keyword is just a way of telling the compiler that a constructor is NOT a type conversion - however, I'm not entirely sure whether it was such a brilliant idea to have two kinds of implicit user defined conversion (constructors and type operators). So, just get used to the idea of prefixing each constructor with an explicit and only consider removing it again afterwards. This is a kind of convenience I don't need, and I pretty much prefer the inconvenience of having to spell out type conversions explicitly. Reminds me of the early days of Java - almost every cast was explicit and you wrote endless lines of casts just to get a very simple resource. Thanks, but no thanks. In short: you need a certain amount of convenience to not hinder the programmer. Too much magic in the background and it is just as bad. The difficulty seems to be to define the ideal point between convenience and shooting yourself into the foot all the time. As long as QVariant mirrors the abilities of C++ (i.e. only using implicit conversions that are also available in plain C++, plus maybe a few very obvious ones, like toString) we are fine. More and we'll get weird bug reports, less and programmers will constantly bitch about it. BTW: you can already implicitly cast QByteArray-QString, so why not allow it through QVariant? Konrad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Jędrzej Nowacki wrote: Eike wrote: [...] We use common sense on a case by case basic. Either there is no “common sense” common to me, or this rule has failed in the past already ;) bool - string ? bytearray - int/long/double ? keysequence - int ? string - bool ? string - bytearray ? string - int ? What is wrong with string - int or bytearray - int? At the very least, _implicit_ conversions should not lose data, i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote: On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote: [...] When one use QVariant, it is because we want to enjoy dynamic typing and nice conversions. I don’t think we have a single place in Qt Creator where we want automatic conversions when using QVariant. A search for QVariant(Map) returns 5400 hits. In the map case, we usually expect the one retrieving the value for a key to know the exact type of what was thrown in (that’s usually the same class, or related classes), and then we use item models and QSettings which we use in the same way. Even if automatic conversion might be interesting (when, actually?), then the point is: There is no API in QVariant to support the common use case of getting the value *without* automatic conversion. Nobody asked for it, It should be easy to implement something equal to this; Q_ASSUME(variant.userType() == qMetaTypeTargetType()); TargetType data = variant.valueTargetType(); I believe such new api make sense, we can add it. We use common sense on a case by case basic. Either there is no “common sense” common to me, or this rule has failed in the past already ;) bool - string ? bytearray - int/long/double ? keysequence - int ? string - bool ? string - bytearray ? string - int ? Br, Eike What is wrong with string - int or bytearray - int? First of all I wondered what bytearray - int does at all. Convert the first byte in the byte array to an int, if bytearray.size() == 1 (which would be consistent with QStringList-QString)? bytearrays are not strings after all… Otherwise bytearray/string - int has similar problems as string - bool and string - bytearray: There is no canonical “right” way to do it, and it can fail depending on the actual *value*. Does QVariant::canConvert actually take that into account? Is there any other possibility to find out if it went wrong? Does it interpret 0xa1 ? Will 076 be interpreted as octal or decimal? Does it convert “ퟷ” (U+1D7F7) to 1 ? ;) All in all it creates more questions than it solves problems. There are no QKeySequence::toInt(), QString::toBool(), QString::toByteArray() functions btw, and QString/QByteArray::toInt(…) take arguments. I think one prerequisite for possible conversions (automatic or not) should be, that a corresponding ::to… function without any arguments in the corresponding type would survive an API review, and actually is added as well. Then one also has a place to look for documentation how the actual conversion is done. Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum kon...@silmor.de wrote: On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote: Olivier Goffart wrote: It's always a dilemma. We have to look at how likely we are to break applications and I don't think adding a conversion is likely to cause breakages. Type safety is a safety net that catches errors very early in the software production and deployment cycle, and one of the features that makes a programming language usable for the development of large applications at a reasonable pace. I feel I need to clear up some misconceptions here: the kind of type safety offered by C++ is a possibility, but not a necessity for fast and safe development of large applications. I've done Smalltalk for quite some time - it does not have a static type system like C++ and development is still faster than in most C++ based environments - I'd even go as far as saying it is slightly faster to develop with Smalltalk than it is to develop with Qt (I still prefer Qt for its more modern API). The key is usually great documentation, good tooling, good APIs and fast turn-around from adding a few lines to seeing them in action (in the last point C++ can't even hope to compete with Smalltalk, the other three are quite good with Qt). Implicit type conversions kill type safety. This is widely recognized as a bad thing. In case of C++ some are unavoidable due to the C legacy, but e.g. for user-defined conversion operators we now got explicit, _because_ people learned the hard way that implicit conversions are causing more trouble than wanted. Let's not mix up too much here: type conversions are necessitated by the fact that C++ has static typing - otherwise you would not get much done with it - from the Smalltalk point of view C++ is not polymorphic. Implicit type conversions are necessitated by the fact that programmers (like me) are lazy bastards and don't like to read lines which are longer than a couple of words. The explicit keyword is just a way of telling the compiler that a constructor is NOT a type conversion - however, I'm not entirely sure whether it was such a brilliant idea to have two kinds of implicit user defined conversion (constructors and type operators). So, just get used to the idea of prefixing each constructor with an explicit and only consider removing it again afterwards. This is a kind of convenience I don't need, and I pretty much prefer the inconvenience of having to spell out type conversions explicitly. Reminds me of the early days of Java - almost every cast was explicit and you wrote endless lines of casts just to get a very simple resource. Thanks, but no thanks. In short: you need a certain amount of convenience to not hinder the programmer. Too much magic in the background and it is just as bad. The difficulty seems to be to define the ideal point between convenience and shooting yourself into the foot all the time. As long as QVariant mirrors the abilities of C++ (i.e. only using implicit conversions that are also available in plain C++, plus maybe a few very obvious ones, like toString) we are fine. More and we'll get weird bug reports, less and programmers will constantly bitch about it. BTW: you can already implicitly cast QByteArray-QString, so why not allow it through QVariant? This can be considered an API fail, which is why you can explicitly turn off these type of conversions for your applications by defining QT_NO_CAST_TO_ASCII QT_NO_CAST_FROM_ASCII (which we e.g. do for Qt Creator). Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote: Jędrzej Nowacki wrote: Eike wrote: [...] We use common sense on a case by case basic. Either there is no “common sense” common to me, or this rule has failed in the past already ;) bool - string ? bytearray - int/long/double ? keysequence - int ? string - bool ? string - bytearray ? string - int ? What is wrong with string - int or bytearray - int? At the very least, _implicit_ conversions should not lose data, i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) André, QVariant conversions are not implicit, they are explicit. You have to use qvariant_castT, QVariant::valueT, or QVariant::to*. That's explicit. Conversions _to_ QVariant are sometimes implicit, but they are loss-less as it just wrap the type into the QVariant. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 of July 2014 12:51:36 Olivier Goffart wrote: On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote: Jędrzej Nowacki wrote: Eike wrote: [...] We use common sense on a case by case basic. Either there is no “common sense” common to me, or this rule has failed in the past already ;) bool - string ? bytearray - int/long/double ? keysequence - int ? string - bool ? string - bytearray ? string - int ? What is wrong with string - int or bytearray - int? At the very least, _implicit_ conversions should not lose data, i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) André, QVariant conversions are not implicit, they are explicit. You have to use qvariant_castT, QVariant::valueT, or QVariant::to*. That's explicit. Conversions _to_ QVariant are sometimes implicit, but they are loss-less as it just wrap the type into the QVariant. True conversions from QVariant are explicit, but some of Qt API hides that, for example QObject::setProperty which tries hard to implicitly convert data, Ok, so Andre is in favor of ideal conversions (point 1.2). Ideal round trip conversion is possible only if A and B represent the same concept using a different representation. So it would work for QLinkedListT = QVectorT, but not for int - long. In my opinion it is really limiting and kind of opposite to what we have now :-) We could potentially split all conversions into two groups ideal and best effort and disallow usage of the second group in certain cases. I'm not sure if it is worth the effort, and definitely It would break existing behavior as effectively it would remove some of the conversions (point 3) Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote: I don’t think we have a single place in Qt Creator where we want automatic conversions when using QVariant. A search for QVariant(Map) returns 5400 hits. In the map case, we usually expect the one retrieving the value for a key to know the exact type of what was thrown in (that’s usually the same class, or related classes), and then we use item models and QSettings which we use in the same way. From performance point of view it is good to avoid any conversions. I would say even more, if you know all types in your application there is no point in using QVariant. Sometimes it is not possible, and sometimes one just don't want be bothered. I made an extremely unfair experiment. I switched off all conversions in Qt and I recompiled QtCreator. To be honest I expected that it would crash at startup, but no (impressive!). I was able to use menu and open dialogs, nothing more. From the stderr I could deduct that a QVariant conversion was used in reading xml, qws files and in animations. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart wrote: Jędrzej Nowacki wrote: [...] What is wrong with string - int or bytearray - int? At the very least, _implicit_ conversions should not lose data, i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) André, QVariant conversions are not implicit, they are explicit. I am aware of that. I tried to answer the question of What is wrong with string - int or bytearray - int. We admittedly left the original context here (and in other parts of the discussion), but the question was posed in context that I read an example of an conversion that one would always consider convenient to have, and I started with At the very least, _implicit.. supposedly setting the context of the answer. Anyway. To summarize my position in the original context: QVariant is as it is. It is convenient at times, and it is already too convenient at times. Easy type conversion is a different use case than Type agnostic storage. QVariant does a bit of both, only the second one has ever been useful _to me_, I have been bitten by the first. As there are typically also more direct ways to convert types than to pass through QVariant, I consider the possibility to do type conversion through QVariant a mis-feature, and adding even more conversion abilities would be a step into the wrong direction _for me_. This is a personal opinion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Anyway. To summarize my position in the original context: QVariant is as it is. It is convenient at times, and it is already too convenient at times. Easy type conversion is a different use case than Type agnostic storage. QVariant does a bit of both, only the second one has ever been useful _to me_, I have been bitten by the first. As there are typically also more direct ways to convert types than to pass through QVariant, I consider the possibility to do type conversion through QVariant a mis-feature, and adding even more conversion abilities would be a step into the wrong direction _for me_. This is a personal opinion. I certainly can't recall any place in Creator where a conversion via QVariant was intended. I can though recall several instances where such a conversion was the source of bugs. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Make Qt WebEngine an add-on
Hi, As I have not received any objection to the plan we will now conclude and proceed with the proposed changes. Qt WebEngine will become an official Qt add-on module. :-) Cheers, - Zeno From: Zeno Albisser zeno.albis...@digia.commailto:zeno.albis...@digia.com Date: Fri, 27 Jun 2014 14:55:37 +0200 To: development@qt-project.orgmailto:development@qt-project.org Subject: [Development] Make Qt WebEngine an add-on Hi, We are currently developing Qt WebEngine as a qt-labs project. Now we would like Qt WebEngine to become an official Qt add-on module. I am therefore requesting to move the repository from: qt-labs/qtwebengine to qt/qtwebengine. This will also be a step in the direction of releasing Qt WebEngine as an add-on together with Qt 5.4 Best Regards, - Zeno -- Zeno Albisser Senior Software Engineer - Digia, Qt +47 406 03 455 Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Milian Wolff as approver
Definitely a +1 from me as well :) From: development-bounces+michael.bruning=digia@qt-project.org [development-bounces+michael.bruning=digia@qt-project.org] on behalf of Albisser Zeno [zeno.albis...@digia.com] Sent: Wednesday, July 16, 2014 11:49 To: Gladhorn Frederik; Qt Development Group Subject: Re: [Development] Nominating Milian Wolff as approver +1 On 7/15/14, 10:08 PM, Gladhorn Frederik frederik.gladh...@digia.com wrote: Hi all, it¹s my pleasure to nominate Milian Wolff as approver. He¹s a great guy, works for KDAB and has done interesting work on profiling, improves KDevelop amongst other things and has been active with all things web it seems. He¹s started and is maintaining the qtwebchannel repository which is getting more and more attention lately. He¹s great to work with and based in Berlin. I think he makes a great addition to the list of Qt approvers. His submissions: https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wo lff%2540kdab.com%253E%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian .wolff%2540kdab.com%253E%22,n,z Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Hi
In the qml designer we are using comparisons of variants quite extensive and
run in smaller problems like wrong conversions. E.g. color is broken because
the alpha value is not used in the comparison. We would like to extent existing
comparisons too because we get the variants from different sources, so the
value is equal but because the conversion is not working it is not the
same. Thomas Hartmann was running in more problems like that and if he is
back in two weeks you should ask him.
Best, Marco
From: development-bounces+marco.bubke=digia@qt-project.org
[development-bounces+marco.bubke=digia@qt-project.org] on behalf of Jędrzej
Nowacki [jedrzej.nowa...@digia.com]
Sent: Tuesday, July 15, 2014 8:55 AM
To: development@qt-project.org
Subject: [Development] Converting types in Qt
Hi,
I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, int to long, but also for more complex
ones like QByteArray to QString or CustomType to OtherCustomType. Type
conversion in Qt happens mostly without user interaction, for example in
QObject introspection or in QML, but it also can be used through public API:
- QVariant::convert - converts wrapped value to target type
- QVariant::canConvert - fast check if it may be possible to convert
wrapped type to a given target, which is, in my opinion, pretty useless,
unless the real conversion is really heavy
- QMetaType::registerConverter - allows to register a custom converter
function for a user defined type
- QMetaType::convert - perform conversion between two types
I would like to agree on some rules, regarding conversions, as the current
approach is chaotic:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix, everything is
even more complex.
1.1 Patch release or minor release only?
I would say that new conversions may appear only in minor releases,
obvious fixes to existing conversions may appear in patch releases, where by
obvious I mean crash fixes and cases in which the returned value is definitely
bogus.
1.2 Should conversion be perfect or based on a best effort?
Some of the conversion API returns a bool value which is a status
of conversion. What should it return if a conversion is not perfect, for
example int(-1) - uint or QVariantList{string, int, myobject} -
QStringList, should such a case be detected? How do we define the perfect
conversion? Sometimes only ideal, data lossless, conversions should be
allowed, for example QtTestLib is quite strict about it and it allows only
safe conversions. So, for example, int - long but not uint - int, but I
guess for normal use cases such strictness is not necessary.
I think we should base conversions on the best effort and set the
status to false only if a conversion failed completely, that is mainly if a
conversion is unknown or if underlying implementation detected a failure, like
QByteArray - float which uses QByteArray::toFloat(bool *ok)
1.3 Should we try to support a user's type conversions out of the box?
Currently a user needs to manually register a conversion function so
Qt can know it and use it. For certain types we can do much better, because we
can automatically convert some types. For example:
QVectorchar - QLinkedListint
QListFoo - QVectorFoo
QPointerFoo - QObject*
QPointerFoo - void*
QSharedDataPointerFoo - bool
MyQObject* - QPointerMyQObject
Currently we are not doing it for one reason which is behavior
compatibility. What if a user already defined a conversion that we want to add?
It could happen because the conversion was not available in a previous Qt
version. The problem is that the new conversion function may behave in a
different way, especially in edge cases and because of the lack of perfection
mentioned in 1.2. We need to pick only one function. That could be the Qt
version, but then we risk that an existing code will not work anymore. Are we
willing to accept that?
I believe that we should document the problem, and allow the
conversions.
1.4 Should a user be able to add Qt types conversion on his own?
Some conversions are missing, some we consider as not safe. A user,
assuming that he knows what he is doing, could register a conversion; for
example, QString - QChar, how bad is it? Currently, such usage is blocked,
because we are afraid that in the future we may add a conversion that
overrides it.
In my opinion it is not needed; it is a corner case, because we a)
should have the conversion and then it will appear in a future version b) the
conversion is
Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
On 7 July 2014 15:10, Koehne Kai kai.koe...@digia.com wrote: From: development-bounces+kai.koehne=digia@qt-project.org [...] 1) Developers who face regressions (not just testers) are now in an awkward position, and need to install an extra copy of Qt Creator (see below) Right, that's the main drawback. We could maybe have a 'Show all' section in the settings dialog or so that would show/hide such patch level releases though ... will bring this up with the Release Team. Thanks! [...] No. When running an installer (online or offline), Qt Creator is a compulsory component (although Qt itself is non-compulsory). I remember someone saying that Qt Creator is made compulsory because of interdependencies between the Maintenance Tool and Qt Creator. What are these dependencies? I'm willing to have a go at reducing this coupling, if I know where to look. I believe one of them is for the installer to register auto-detected kits. Instead of having the installer perform this registration, would it make sense for it to simply add a search path to a global Qt Creator config file, and let Qt Creator search for and register new copies of Qt at startup? Registration of Qt versions, kits, and toolchains is indeed the primary problem. We call Qt Creator's sdktool.exe in the installation/deinstallation scripts of the Qt versions the mingw toolchains . I'm not sure doing too much (file system) magic on Qt Creator startup though is the right thing to do, since it will slow down every launch. Perhaps Qt Creator could check to see if a path is already in its list of registered versions/kits/tools, before scanning the physical location? Alternatives that have been discussed in the past: 1. Move the sdktool.exe out of the Qt Creator package, into a separate one, and only make this one mandatory. That means though we'd need to ship separate Qt libraries for this tool only, effectively increasing the size of a 'default' installation. 2. Don't deregister/register toolchains and kits in the qt packages, but in separate virtual (i.e., hidden) packages that are only installed if both the resp. Qt version package and the Qt Creator package gets installed (AutoDependOn in IFW speak). This will only be a workaround though for new packages ... already released qt versions will still have a hard dependency on Qt Creator. 3. Accept the fact that, if people first install a Qt version / toolchain and _later on_ install Qt Creator, the toolchain Qt version won't show up. I think both 1. and 2. are be feasible ... 3. might end up in more bug reports / annoyed users than the current 'forced' installation, so I'm personally not keen to implement this. Agreed, #3 sounds like swapping one set of issues for another. #1 makes a lot of sense; sdktool could be considered an inseparable part of the MaintenanceTool. I'm less familiar with #2 as I haven't implemented package managers before; would this option increase the risk of repository corruption? (Example: https://bugreports.qt-project.org/browse/QTIFW-519) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
On 7 July 2014 16:09, Ziller Eike eike.zil...@digia.com wrote: On Jul 6, 2014, at 3:52 AM, Sze Howe Koh szehowe@gmail.com wrote: 2) In Qt Creator, the Qt version and kit are still listed as Qt 5.3.0, even though it has been upgraded to Qt 5.3.1. Since it is an auto-detected entry, the user cannot change the name. Hi, Since it is an auto-detected entry, the user cannot change the name.” is actually wrong (you _can_ change the name), and that is actually the reason why the bug Qt version and kit are still listed as “Qt 5.3.0”” exists ;) Oops, I stand corrected. Perhaps I was remembering auto-detected toolchains and debuggers -- those can't be renamed. I remember being stuck with Extracted from Kit Desktop Qt 5.1.1 MinGW 32bit in my system, when Qt 5.1.1 was long gone (replaced by Qt 5.2.1). Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] My availability
Hi Stephen, Thanks for all your contributions over the years. Up to anything interesting next? On 16 July 2014 14:25, Stephen Kelly stephen.ke...@kdab.com wrote: Hi, After 5 years, my time at KDAB is coming to an end, and I'm going to have less time for Qt development. I'll still be available for reviews. I'll be staying in Berlin, so you may still see me around sometimes. Thanks, -- Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
On 7 July 2014 19:11, Frederik Gladhorn frederik.gladh...@digia.com wrote: Mandag 7. juli 2014 10.02.55 skrev Ziller Eike: On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn frederik.gladh...@digia.com wrote: Mandag 7. juli 2014 07.10.00 skrev Koehne Kai: No. When running an installer (online or offline), Qt Creator is a compulsory component (although Qt itself is non-compulsory). I remember someone saying that Qt Creator is made compulsory because of interdependencies between the Maintenance Tool and Qt Creator. What are these dependencies? I'm willing to have a go at reducing this coupling, if I know where to look. I believe one of them is for the installer to register auto-detected kits. Instead of having the installer perform this registration, would it make sense for it to simply add a search path to a global Qt Creator config file, and let Qt Creator search for and register new copies of Qt at startup? Registration of Qt versions, kits, and toolchains is indeed the primary problem. We call Qt Creator's sdktool.exe in the installation/deinstallation scripts of the Qt versions the mingw toolchains . I'm not sure doing too much (file system) magic on Qt Creator startup though is the right thing to do, since it will slow down every launch. Alternatives that have been discussed in the past: 1. Move the sdktool.exe out of the Qt Creator package, into a separate one, and only make this one mandatory. That means though we'd need to ship separate Qt libraries for this tool only, effectively increasing the size of a 'default' installation. 2. Don't deregister/register toolchains and kits in the qt packages, but in separate virtual (i.e., hidden) packages that are only installed if both the resp. Qt version package and the Qt Creator package gets installed (AutoDependOn in IFW speak). This will only be a workaround though for new packages ... already released qt versions will still have a hard dependency on Qt Creator. 3. Accept the fact that, if people first install a Qt version / toolchain and _later on_ install Qt Creator, the toolchain Qt version won't show up. 4. I still think on Windows using the registry would be the way around this. On Linux and Mac the respective .config dirs. Python for examples does this on installation on Windows and can then be found by looking it up in the registry. This solution is imho portable and allows all Qt versions to be found by all Creator instances as well as other tools (qtchooser would be a good candidate to make use of the same mechanism). Since there are no “system wide” config dirs that would mean using something like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and “current_machine” registry on Windows for “system wide” installations, and “.config” on Unix and “current_user” registry on Windows for “user” installations. Qt should offer a good enough settings API for this. That said, I guess it's currently not the case and we should polish/rewrite/replace/extend QSettings to make it work. Not quite system-wide, but Qt Creator already uses a profile-wide config dir, no? I was under the impression that %APPDATA%/Roaming/QtProject was the place where all Qt Creator instances store their settings (on Windows). That would make things much more complicated, and possibly force that information to be compatible between versions of Qt Creator (it’s btw not only about Qt versions here, also all the other things that are specified for kits). This is a valid point. I wonder if it wouldn't be possible to use XML/JSON in a way that it's extensible enough. Worst case the settings need a migration path to newer versions - many tools do that - let you upgrade but now downgrade. Should you then want to downgrade to older Qt Creator versions you may have to re-configure the kits. I think that's a reasonable compromise. I don't imagine that downgrading Qt Creator would be a frequent activity, especially after it becomes a deselectable component of Qt installers. Also, I currently have 5 offline Qt installers installed simultaneously for testing. Using a “machine/user wide” registration mechanism, instead of an “installation wide” registration mechanism would basically disallow that. I think we (those developping Qt and Creator etc.) are still the minority and will always have special setups. The question is if we aim at getting the experience right for ourselves or everyone else first. +1 This discussion stemmed from user experience issues. Developer experience is still a very nice thing to have though. Perhaps we can make a little tool which lets us stash existing settings before installing a new build of Qt Creator? From a user point of view, I'd happily have one current and great Qt Creator installation which let's me easily switch between all the Qt versions I have installed on my system. I don't see why this wouldn't
Re: [Development] Converting types in Qt
On Jul 16, 2014, at 1:30 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote: On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote: I don’t think we have a single place in Qt Creator where we want automatic conversions when using QVariant. A search for QVariant(Map) returns 5400 hits. In the map case, we usually expect the one retrieving the value for a key to know the exact type of what was thrown in (that’s usually the same class, or related classes), and then we use item models and QSettings which we use in the same way. From performance point of view it is good to avoid any conversions. I would say even more, if you know all types in your application there is no point in using QVariant. Sometimes it is not possible, and sometimes one just don't want be bothered. I made an extremely unfair experiment. I switched off all conversions in Qt and I recompiled QtCreator. To be honest I expected that it would crash at startup, but no (impressive!). I was able to use menu and open dialogs, nothing more. From the stderr I could deduct that a QVariant conversion was used in reading xml, qws files and in animations. True, we use QVariant::toString for an easy way to write the value of the key-value pairs of basic types in qtversions.xml, profiles.xml, .pro.user, and the sessions (.qws) Even there we keep the type information though, and use that to explicitly convert the variants in the map back to the right type when reading the file, so type conversion should never be outside the reader/writer in that case. What the conversion saves us, is a few case statements in the reader/writer. data variableQtVersion.0/variable valuemap type=QVariantMap value type=int key=Id10/value value type=QString key=NameQt 5.3/value value type=QString key=QMakePath/Users/Shared/qt/qt/5.3/64/qtbase/bin/qmake/value value type=QString key=QtVersion.TypeQt4ProjectManager.QtVersion.Desktop/value value type=bool key=isAutodetectedfalse/value /valuemap /data No idea what happens in animations, but I’d suppose that any conversions there would be accidentally. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Wednesday 16 July 2014 15:01:53 Ziller Eike wrote: No idea what happens in animations, but I’d suppose that any conversions there would be accidentally. QPropertyAnimation is based on modifying QVariants, isn't it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
On Jul 16, 2014, at 4:03 PM, Sze Howe Koh szehowe@gmail.com wrote: On 7 July 2014 19:11, Frederik Gladhorn frederik.gladh...@digia.com wrote: Mandag 7. juli 2014 10.02.55 skrev Ziller Eike: On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn frederik.gladh...@digia.com wrote: Mandag 7. juli 2014 07.10.00 skrev Koehne Kai: No. When running an installer (online or offline), Qt Creator is a compulsory component (although Qt itself is non-compulsory). I remember someone saying that Qt Creator is made compulsory because of interdependencies between the Maintenance Tool and Qt Creator. What are these dependencies? I'm willing to have a go at reducing this coupling, if I know where to look. I believe one of them is for the installer to register auto-detected kits. Instead of having the installer perform this registration, would it make sense for it to simply add a search path to a global Qt Creator config file, and let Qt Creator search for and register new copies of Qt at startup? Registration of Qt versions, kits, and toolchains is indeed the primary problem. We call Qt Creator's sdktool.exe in the installation/deinstallation scripts of the Qt versions the mingw toolchains . I'm not sure doing too much (file system) magic on Qt Creator startup though is the right thing to do, since it will slow down every launch. Alternatives that have been discussed in the past: 1. Move the sdktool.exe out of the Qt Creator package, into a separate one, and only make this one mandatory. That means though we'd need to ship separate Qt libraries for this tool only, effectively increasing the size of a 'default' installation. 2. Don't deregister/register toolchains and kits in the qt packages, but in separate virtual (i.e., hidden) packages that are only installed if both the resp. Qt version package and the Qt Creator package gets installed (AutoDependOn in IFW speak). This will only be a workaround though for new packages ... already released qt versions will still have a hard dependency on Qt Creator. 3. Accept the fact that, if people first install a Qt version / toolchain and _later on_ install Qt Creator, the toolchain Qt version won't show up. 4. I still think on Windows using the registry would be the way around this. On Linux and Mac the respective .config dirs. Python for examples does this on installation on Windows and can then be found by looking it up in the registry. This solution is imho portable and allows all Qt versions to be found by all Creator instances as well as other tools (qtchooser would be a good candidate to make use of the same mechanism). Since there are no “system wide” config dirs that would mean using something like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and “current_machine” registry on Windows for “system wide” installations, and “.config” on Unix and “current_user” registry on Windows for “user” installations. Qt should offer a good enough settings API for this. That said, I guess it's currently not the case and we should polish/rewrite/replace/extend QSettings to make it work. Not quite system-wide, but Qt Creator already uses a profile-wide config dir, no? I was under the impression that %APPDATA%/Roaming/QtProject was the place where all Qt Creator instances store their settings (on Windows). That’s per user, so it cannot be used for an installer that installs for all users. That would make things much more complicated, and possibly force that information to be compatible between versions of Qt Creator (it’s btw not only about Qt versions here, also all the other things that are specified for kits). This is a valid point. I wonder if it wouldn't be possible to use XML/JSON in a way that it's extensible enough. Worst case the settings need a migration path to newer versions - many tools do that - let you upgrade but now downgrade. Should you then want to downgrade to older Qt Creator versions you may have to re-configure the kits. I think that's a reasonable compromise. I don't imagine that downgrading Qt Creator would be a frequent activity, especially after it becomes a deselectable component of Qt installers. Especially if Qt Creator can be deselected, and all Qt Creator installs read the same configuration for the Qt versions, it becomes vital that installing a newer Qt does not make the global Qt Creator configuration unreadable by older Qt Creator versions. Assume I have a Qt Creator install that I use and that works, now I want to try some newer or other Qt, and install that without upgrading my Qt Creator (why should I). That’s exactly my point. Also, I currently have 5 offline Qt installers installed simultaneously for testing. Using a “machine/user wide” registration mechanism, instead of an “installation wide” registration mechanism would basically disallow that. I think we (those developping Qt and Creator etc.) are still the minority
Re: [Development] Converting types in Qt
On Jul 16, 2014, at 5:04 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 16 July 2014 15:01:53 Ziller Eike wrote: No idea what happens in animations, but I’d suppose that any conversions there would be accidentally. QPropertyAnimation is based on modifying QVariants, isn't it? True, but I’d claim that that shouldn’t need automatic conversions between types. If I create a QPropertyAnimation on a “qreal” property, and set “qreal” start and end values, then there should not happen any automatic conversions. If I’d set end value “10.0” (i.e. QString), then I’d consider that very bad style. Maybe we have some int/real conversions happening there, which could at least argued to not do much harm. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1
On 7 July 2014 15:10, Koehne Kai kai.koe...@digia.com wrote: 2) In Qt Creator, the Qt version and kit are still listed as Qt 5.3.0, even though it has been upgraded to Qt 5.3.1. Since it is an auto-detected entry, the user cannot change the name. Yeah, that's something we should fix in the next Qt Creator release. The forum user reported another issue: After upgrading from Qt 5.3.0 to Qt 5.3.1, he now has 2 copies of documentation (.530 and .531) Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
