Re: [Development] RFC: Improved Q_ENUM
On 2015-02-18 16:53, Thiago Macieira wrote:
On Wednesday 18 February 2015 12:16:58 Matthew Woehlke wrote:
I have not tried QSettings yet, but since it works with QVariant it
should
work.
Sure, I'd expect it to work, also :-). What I meant was, does it get
written as an integer, or as a string?
Neither.
It's written as @Variant(QDataStream serialisation of the type goes here)
where the QDataStream serialisation includes the type's name. It also only
works if you've registered operator and operator for your type.
enum foo {bar};
QSettings().setValue(foo, bar);
Didn't check, but considering I haven't even registered the metatype,
I'm pretty sure this writes foo=0. However, that goes back to my
previous point; adding Q_ENUM(foo) is not going to change this, because
the value is already converted to numeric when the QVariant is
constructed, when I'm doing it this way.
If I'm doing QVariant::fromValuefoo(bar), then presumably I already
have my own QDataStreap and operators, and Q_ENUM isn't going to
change that either (at least not without me as a developer being very
aware of that change, which I think is sufficient).
A better question might be if this works:
Q_ENUM(foo) // assume same 'foo' as above
QSettings().setValue(foo, QVariant::fromValuefoo(bar).toString());
auto v = QSettings().value(foo);
v.valuefoo(); // does this return foo::bar?
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 2015-02-18 11:44, Olivier Goffart wrote: On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to strings and vice versa is very common, but I'm not aware of a generic solution to the problem until now. (Yes, bidirectional; as mentioned, use in settings, UI, file export etc. are all existing non-debug uses. Not that the QDebug support isn't killer by itself :-).) I have two questions, though: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? I have not tried QSettings yet, but since it works with QVariant it should work. Sure, I'd expect it to work, also :-). What I meant was, does it get written as an integer, or as a string? 2. If I have a QString that I want to convert to the enum, is there a way to test if the string matches an enum value? (Also, is the conversion case sensitive?) Yes, the conversion is case sensitive. It works using QMetaEnum. In Qt 5.5 you can do QMetaEnum::fromTypeMyObject::MyEnum().keyToValue(ABCD); That's rather... unfortunate. For the QVariant case (e.g. QSettings, UI guts) it's maybe tolerable. For the explicit keyToValue, would it be possible to add a case insensitive option? (I'm thinking of e.g. reading from user input, where it is desirable to follow a 'liberal in what you accept' policy.) Because I am lazy :-), can you give us a brief summary of how string conversion works (or does it?) for flags? Flags, are not yet supported within QVariant. Maybe for 5.6 Fair enough. I'd originally thought that was the case, but when you later mentioned Q_FLAG, I was less sure. (Obviously this gets into interesting cases like, how do you convert to/from string when the flag value is a combination of enum values and does not exactly match an enum value? Solvable, but requires putting a little more thought into it.) Related: do you gracefully handle unknown enum values? Also, If I have a QString that I want to convert to the enum, is there a way to test if the string matches an enum value? (I don't mean some particular value, in case that was unclear. Rather, how do you handle failure of keyToValue because the string doesn't match any enum value? Does it rely on returning a magic value that must not be a valid enum value to be detectable? Is there an optional 'okay' parameter? Is there a way to test first if the conversion would be valid?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On Wednesday 18 February 2015 17:44:05 Olivier Goffart wrote: On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to strings and vice versa is very common, but I'm not aware of a generic solution to the problem until now. (Yes, bidirectional; as mentioned, use in settings, UI, file export etc. are all existing non-debug uses. Not that the QDebug support isn't killer by itself :-).) I have two questions, though: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? I have not tried QSettings yet, but since it works with QVariant it should work. But if already worked, this means the new file format will be different than what it used to. We may actually have to keep the current format so old applications can read the settings file produced by new applications. That brings the question: does QDataStream format change? -- 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] RFC: Improved Q_ENUM
On 2015-02-18 12:14, Thiago Macieira wrote: On Wednesday 18 February 2015 17:44:05 Olivier Goffart wrote: On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? I have not tried QSettings yet, but since it works with QVariant it should work. But if already worked, this means the new file format will be different than what it used to. We may actually have to keep the current format so old applications can read the settings file produced by new applications. (Did you mean to say that backwards? I would generally expect new settings may not be compatible with old code...) I'm not sure there is an issue here. If I do this: settings.setValue(key, enumValue); ...I think this relies on implicit conversion to int (because QVariant can't construct from an arbitrary type without fromValue, correct?), and so will (continue to) write a number. Even with Q_ENUM. Therefore, this won't break. Similarly, a QVariant with a genuine enum type was not previously convertible (correct?), so anyone that is *using* fromValue to serialize is also overloading the stream operators anyway, and in such case probably will not switch to Q_ENUM (or at least will be aware of the possible consequences of doing so). IOW I don't think any existing code will change by accident just by starting to use Q_ENUM. (There might be a case for allowing conversion of QVariant with an int to an enum, if the int is a valid enum value. For that matter, does the other direction work? If I have a QVariant with an enum, can I get the numeric value from that without knowing the enum type?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On Wednesday 18 February 2015 12:16:58 Matthew Woehlke wrote: I have not tried QSettings yet, but since it works with QVariant it should work. Sure, I'd expect it to work, also :-). What I meant was, does it get written as an integer, or as a string? Neither. It's written as @Variant(QDataStream serialisation of the type goes here) where the QDataStream serialisation includes the type's name. It also only works if you've registered operator and operator for your type. -- 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] RFC: Improved Q_ENUM
On Wednesday 18 February 2015 12:49:55 Matthew Woehlke wrote: But if already worked, this means the new file format will be different than what it used to. We may actually have to keep the current format so old applications can read the settings file produced by new applications. (Did you mean to say that backwards? I would generally expect new settings may not be compatible with old code...) No, I really meant forwards. It's uncommon but entirely possible that a configuration file written by a new application or Qt will be read by an old application or Qt. Anyway, the point is moot as I don't think the format changed at all. See the other email. -- 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] RFC: Improved Q_ENUM
On 2014-12-15 08:38, Olivier Goffart wrote: I have been working on some improvements to moc and the meta type system to improve Q_ENUM. Those changes are targeting Qt 5.5 [...] If you use Q_ENUM, you get: - Using it with qDebug prints the actual string of the value. - a QVariant containing that enum can automatically be converted to QString or QByteArray with the value name. Also, if the QVariant contains a QString or a QByteArray with a value name, it can be converted to the enum type. (This could be useful for QML as well, as you should not need to artificially expose the enums to QML anymore) Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to strings and vice versa is very common, but I'm not aware of a generic solution to the problem until now. (Yes, bidirectional; as mentioned, use in settings, UI, file export etc. are all existing non-debug uses. Not that the QDebug support isn't killer by itself :-).) I have two questions, though: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? 2. If I have a QString that I want to convert to the enum, is there a way to test if the string matches an enum value? (Also, is the conversion case sensitive?) Because I am lazy :-), can you give us a brief summary of how string conversion works (or does it?) for flags? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On Wednesday 18 February 2015 11:25:54 Matthew Woehlke wrote: Sorry to jump in so late, but... *THIS IS AWESOME!* Converting enums to strings and vice versa is very common, but I'm not aware of a generic solution to the problem until now. (Yes, bidirectional; as mentioned, use in settings, UI, file export etc. are all existing non-debug uses. Not that the QDebug support isn't killer by itself :-).) I have two questions, though: 1. How does this interact with QSettings? If I directly pass an enum to e.g. QSettings::setValue, is it written as an int or an enum (I guess int)? What about if I use QVariant::fromValue (i.e. so the variant type is the enum)? I have not tried QSettings yet, but since it works with QVariant it should work. 2. If I have a QString that I want to convert to the enum, is there a way to test if the string matches an enum value? (Also, is the conversion case sensitive?) Yes, the conversion is case sensitive. It works using QMetaEnum. In Qt 5.5 you can do QMetaEnum::fromTypeMyObject::MyEnum().keyToValue(ABCD); Because I am lazy :-), can you give us a brief summary of how string conversion works (or does it?) for flags? Flags, are not yet supported within QVariant. Maybe for 5.6 -- 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] RFC: Improved Q_ENUM
Hi, The support in moc was already merged, but I am still waiting for reviews. Mainly: https://codereview.qt-project.org/103529 QMetatype: Register the QMetaObject of a Q_ENUM or Q_FLAG https://codereview.qt-project.org/91865 Introduces QMetaEnum::fromType https://codereview.qt-project.org/89416/ Add a qDebug operator overload to handle registered enum (I know it does not work yet for QFlags, but that can come later) https://codereview.qt-project.org/91862 Use Q_ENUM and Q_FLAG in the Qt namespace (needed for the test of the first patch) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org On Monday 15 December 2014 14:38:00 Olivier Goffart wrote: Hello, I have been working on some improvements to moc and the meta type system to improve Q_ENUM. Those changes are targeting Qt 5.5 You can see the list of change there in the q_gadget topic (I put the changes in that topic even if it is an orthogonal changes to the Q_GADGET changes that are already in) https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:d ev+topic:q_gadget,n,z This is something that I have actually started working on a long time ago. The problem I wanted to solve was to show the actual string of the value when using qDebug with enum values that are registered with Q_ENUMS I tried many different option, and finally got a working solution, but it does require small changes, so I added a new macro Q_ENUM to keep compatibility Q_ENUM is almost the same as Q_ENUMS, but: - It can only contains one enum at the time, while you can put several in a Q_ENUMS - It need to be placed *after* the enum declaration in the class. Q_ENUMS is still existing and do not regress. But if you use Q_ENUM instead, you get: - Using it with qDebug prints the actual string of the value. - It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore - It is also possible to get the related QMetaObject from the QMetaType. - You can get the QMetaEnum using the new QMetaEnum::fromTypeT() - a QVariant containing that enum can automatically be converted to QString or QByteArray with the value name. Also, if the QVariant contains a QString or a QByteArray with a value name, it can be converted to the enum type. (This could be useful for QML as well, as you should not need to artificially expose the enums to QML anymore) At first, I wanted to deprecate Q_ENUMS and show a warning when Q_ENUMS is used. But because it is a bit of work to move to Q_ENUM, I just did not put a warning yet. I can already hear the resistant to change nay-sayer I like to put my Q_ENUMS at the beginning of the class with all the meta-stuff. Well, Q_ENUM can go directly after the enum in question, so it stays together. This is also where you would put things like Q_DECLARE_FLAGS Any opinions or comments? You can review the patches. (First patch is there: https://codereview.qt-project.org/89415/ ) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On 15 December 2014 at 14:38, Olivier Goffart oliv...@woboq.com wrote: Any opinions or comments? Quick and simple comment from me: this feature sounds great! A big, shiny +1 from me. It will come in handy in many projects I am involved with. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
While I cannot come up with direct application of toString() feature in the projects I am involved in by the moment (except for debugging), I really like it, and remember myself being in a need in such features some time ago. So, me also would like to thank you, Olivier, for the job you've done. I am sure many people will find it handy. Bits like It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore are what makes Qt more comfortable to use. On Tue, Dec 16, 2014 at 11:28 AM, Tomasz Siekierda sierd...@gmail.com wrote: On 15 December 2014 at 14:38, Olivier Goffart oliv...@woboq.com wrote: Any opinions or comments? Quick and simple comment from me: this feature sounds great! A big, shiny +1 from me. It will come in handy in many projects I am involved with. ___ 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] RFC: Improved Q_ENUM
Dmitry Volosnykh schreef op 16-12-2014 09:35: While I cannot come up with direct application of toString() feature in the projects I am involved in by the moment (except for debugging), I really like it, and remember myself being in a need in such features some time ago. So, me also would like to thank you, Olivier, for the job you've done. I am sure many people will find it handy. Bits like It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore are what makes Qt more comfortable to use. We use it for things like settings and serialization, so yes, it is useful to have. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Improved Q_ENUM
On Tuesday 16 Dec 2014 09:50:04 André Somers wrote: Dmitry Volosnykh schreef op 16-12-2014 09:35: While I cannot come up with direct application of toString() feature in the projects I am involved in by the moment (except for debugging), I really like it, and remember myself being in a need in such features some time ago. So, me also would like to thank you, Olivier, for the job you've done. I am sure many people will find it handy. Bits like It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore are what makes Qt more comfortable to use. We use it for things like settings and serialization, so yes, it is useful to have. André We use Q_ENUMS in Gluon to extract and expose enums in the editor UI, and this will, certainly, make that code much more pleasant to read. Very glad to see this, very shiny! :) -- ..Dan // Leinir.. http://leinir.dk/ Co- existence or no existence - Piet Hein ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] RFC: Improved Q_ENUM
Hello, I have been working on some improvements to moc and the meta type system to improve Q_ENUM. Those changes are targeting Qt 5.5 You can see the list of change there in the q_gadget topic (I put the changes in that topic even if it is an orthogonal changes to the Q_GADGET changes that are already in) https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:dev+topic:q_gadget,n,z This is something that I have actually started working on a long time ago. The problem I wanted to solve was to show the actual string of the value when using qDebug with enum values that are registered with Q_ENUMS I tried many different option, and finally got a working solution, but it does require small changes, so I added a new macro Q_ENUM to keep compatibility Q_ENUM is almost the same as Q_ENUMS, but: - It can only contains one enum at the time, while you can put several in a Q_ENUMS - It need to be placed *after* the enum declaration in the class. Q_ENUMS is still existing and do not regress. But if you use Q_ENUM instead, you get: - Using it with qDebug prints the actual string of the value. - It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore - It is also possible to get the related QMetaObject from the QMetaType. - You can get the QMetaEnum using the new QMetaEnum::fromTypeT() - a QVariant containing that enum can automatically be converted to QString or QByteArray with the value name. Also, if the QVariant contains a QString or a QByteArray with a value name, it can be converted to the enum type. (This could be useful for QML as well, as you should not need to artificially expose the enums to QML anymore) At first, I wanted to deprecate Q_ENUMS and show a warning when Q_ENUMS is used. But because it is a bit of work to move to Q_ENUM, I just did not put a warning yet. I can already hear the resistant to change nay-sayer I like to put my Q_ENUMS at the beginning of the class with all the meta-stuff. Well, Q_ENUM can go directly after the enum in question, so it stays together. This is also where you would put things like Q_DECLARE_FLAGS Any opinions or comments? You can review the patches. (First patch is there: https://codereview.qt-project.org/89415/ ) -- 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
