[Development] Enumerations in QML

Alan Alpert 416365416c at gmail.com
Tue Dec 11 20:00:50 CET 2012

On Tue, Dec 11, 2012 at 5:17 AM, Knoll Lars <Lars.Knoll at digia.com> wrote:
> On Dec 11, 2012, at 4:47 AM, Alan Alpert <416365416c at gmail.com> wrote:
>> People keep asking for enumerations in QML. See QTBUG-15483 and
>> QTBUG-14861, both assigned to old Nokia identities (so don't trust
>> that 'in progress' ;) ). Now I don't know when these issues will be
>> resolved, but there's an important discussion to have before it can
>> even be scheduled: What would proper enum support look like in QML?
>> QTBUG-15483 suggests 'property Bar::Weather weather: Bar.Sunny', for
>> using the C++ 'enum Weather { Raining, Sunny, Cloudy }'. But
>> QTBUG-14861 does not include a suggestion of what the QML syntax for
>> declaring an enum should be (just a suggestion for how we could hack
>> it in there). It's totally not obvious to me what a good QML API for
>> declaring enums would be, and that could have run-on effects on how
>> they're used in property declarations. All we know is that Bar.Sunny
>> is how you use the enum exposed from C++, and that will need to
>> continue to work with QML defined enums. Note that "property
>> Bar::Weather weather" is just a suggestion as well, I actually suspect
>> "property Bar.Weather weather" would fit in better (but it depends on
>> how you declare them).
> I'd prefer:
> Item {
>         enum Weather { Raining, Sunny, Cloudy }
>         property Weather weather: Weather.Sunny;
> }

And this propagates correctly throughout the file? The case I'm
wondering about is

Item {
     enum MyState { Good, Bad }
     Item {
         enum MyState { Bad, Good }
         property MyState myState: MyState.Good
     property MyState myState: MyState.Good

Not only does this have to resolve properly using contexts (should be
doable), how can you manually choose? There's no exposed typename for
the inner item, if I wanted to refer to that enum from the outer item
how would I specify that? Or is this name-conflict-in-context case one
we can just live with?

Is this particularly easier than the C++ style of dropping the enum
type when accessing it? e.g. property Weather weather: Sunny? This
would also make the usage outside be Bar.Sunny instead of
Bar.Weather.Sunny. I think this would be a lot easier for C++ devs to
adapt to.

> Since enum is already a reserved keyword in Ecmascript this should be doable without problems.
> If the enum is declared in a different context, the property declaration should IMO be
> OtherItem {
>         property Bar.Weather weather: Bar.Weather.Sunny;
> }

So with the OtherItem example, it actually has to find the Bar type
and look for a Weather enum on it? This leads to you having to be
careful exposing enums from other types, but I suppose that
restriction is the same as C++. For example:

AnotherItem {
    OtherItem { id: foo; weather: WeatherItem.Weather.Sunny? } //Now
AnotherItem needs to be able to find the WeatherItem type for that
enum (same as in C++)

Alan Alpert

More information about the Development mailing list