Re: [Development] Enumerations in QML
On Dec 11, 2012, at 4:47, Alan Alpert 4163654...@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).
What should enumeration declarations in QML look like?
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug around a
bit, and behold:
The problem with enums is that we couldn't make them fast. They will always be
a lot slower than normal string literals. That is mostly because we could not
avoid the name lookup. Think about,
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment, Vertical,
and something. Also, there is no way for you to distinguish Types (e.g.
Item, Rectangle, and co...) from Enums (in our case Alignment). That means,
you cannot build the correct list of dependencies when loading a QML Component.
-- Erik.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Unto all so did sayeth Alan:
What should enumeration declarations in QML look like?
Did respondeth Erik:
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug
around a bit, and behold:
The problem with enums is that we couldn't make them fast. They will
always be a lot slower than normal string literals. That is mostly because
we could not avoid the name lookup.
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment,
Vertical, and something. Also, there is no way for you to distinguish
Types (e.g. Item, Rectangle, and co...) from Enums (in our case
Alignment). That means, you cannot build the correct list of dependencies
when loading a QML Component.
Ouch. That is quite unexpected.
We seem to have multiple intentions regarding adding Enums to QML:
(1) Those with a native (C/C++) background may have thought Enum to be
faster than String (e.g., performance-goal)
(2) Some may prefer the cleaner-look by using an unquoted Enum over a
quoted string literal
(3) Some may expect a compile-time check for (valid) enumerated-values,
as compared with a run-time check with string-lookups (? this may not be
a real consideration depending on how the QML parsing engine works)
(4) Lack of Enums in QML is (another) example of how QML might be
considered a second-class-citizen (mentioned by Chris, another example
being composite types in QML are not backed by a QQmlType and thus are not
available in JavaScript as are types defined in C++)
IMHO, the performance is the biggest issue, as we have currently
work-arounds to enable enumerations in QML.
Some of the post-V8-engine discussion may address the performance issue,
at which point all of the above considerations could be achieved. (Lars
may comment on this?)
So: I want Enums in QML, but only if they are as-fast-or-faster than
string lookups. I'm quite happy to defer this feature until that can be
achieved.
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Hi,
On Wed, Dec 12, 2012 at 10:51 PM, Charley Bay charleyb...@gmail.com wrote:
Unto all so did sayeth Alan:
What should enumeration declarations in QML look like?
Did respondeth Erik:
And, also important: how much slower is it allowed to be than the current
implementation?
I remembered that there was talk about enums in QML before, so I dug
around a bit, and behold:
The problem with enums is that we couldn't make them fast. They will
always be a lot slower than normal string literals. That is mostly because
we could not avoid the name lookup.
Text {
alignment: Alignment.Vertical | Alignment.something
}
there is no way for you to remove the name lookups for Alignment,
Vertical, and something. Also, there is no way for you to distinguish
Types (e.g. Item, Rectangle, and co...) from Enums (in our case
Alignment). That means, you cannot build the correct list of dependencies
when loading a QML Component.
Ouch. That is quite unexpected.
We seem to have multiple intentions regarding adding Enums to QML:
(1) Those with a native (C/C++) background may have thought Enum to
be faster than String (e.g., performance-goal)
With v4vm, I believe (Lars or Simon can correct me if I'm wrong) every
single time we have a JavaScript expression (well, one which doesn't do
something totally crazy like build a dynamic expression up as a string and
then eval it, but if you're doing that in your code please be aware that
you're the cause of mass kitten suicide) every symbol will be resolved at
compile time where possible (ie, if the evaluation context cannot change).
Thus, once typenames of QML document defined types are resolvable, we
should get great perf from enums.
(2) Some may prefer the cleaner-look by using an unquoted Enum over a
quoted string literal
If the syntax isn't nice, I don't want it in QML ;-) Times like these I
wish we hadn't included grouped properties :-/
(3) Some may expect a compile-time check for (valid) enumerated-values,
as compared with a run-time check with string-lookups (? this may not be
a real consideration depending on how the QML parsing engine works)
As I mentioned earlier, this should be doable in the future. Enums are
looked up from the Q_ENUMS registered with the type with the given type
name, and should be resolvable at compile time (for both binding
expressions and bound signal expressions, and other dynamically added
functions).
(4) Lack of Enums in QML is (another) example of how QML might be
considered a second-class-citizen (mentioned by Chris, another example
being composite types in QML are not backed by a QQmlType and thus are not
available in JavaScript as are types defined in C++)
It is an example of that, but my point was that implementing enums in QML
is meaningless until we have fixed the problem with unresolvable
typenames. This entire thread should be revisited after QTBUG-24799 is
fixed.
Cheers,
Chris.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
On Tue, Dec 11, 2012 at 4:47 AM, Alan Alpert 4163654...@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).
What should enumeration declarations in QML look like?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
I found myself in the exact same situation where it would've been
really convenient to have enums in QML. However, one thing that is
easy to forget is that you still have the full power of JavaScript at
your disposal. And while JavaScript doesn't support enums as those
that you have in C/C++, you still can have it's syntax.
Look at this link: http://stackoverflow.com/questions/287903/enums-in-javascript
The thing i'm using in my project is:
var SIZE = {
SMALL : 0,
MEDIUM: 1,
LARGE : 2
};
and i'm somewhat sure that you can also do that in a qml property
with something like this:
property variant SIZE: {
SMALL : 0,
MEDIUM: 1,
LARGE : 2
};
Not tested so it probably doesn't work, but you get the idea.
The only downside is that QML doesn't allow the first character (the
S of SIZE) to be written in capital letters and you also assign the
property as QVariant.. It's not ideal but works just fine.
Also, another possibility is adding a separate JavaScript file in
which you just have the var as in my first example. Works like a charm
in my case :) Take a look at my example where i use FontAwesome in my
QML code where i call it as JsUtil.FA.the_icon_i_want [1, 2, 3]
[1] http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/main.qml
[2]
http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/javascript/util.js
(JsUtil)
[3]
http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/javascript/fontawesome.js
(FontAwesome)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
On Dec 11, 2012, at 4:47 AM, Alan Alpert 4163654...@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;
}
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;
}
Cheers,
Lars
What should enumeration declarations in QML look like?
--
Alan Alpert
___
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] Enumerations in QML
People keep asking for enumerations in QML. snip,
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?
snip,
I'd prefer:
Item {
enum Weather { Raining, Sunny, Cloudy }
property Weather weather: Weather.Sunny;
}
+1 for enums (whatever the reasonable syntax).
If they are added, IMHO they should be available for identifying
States/Transitions, since the string-labels that are currently used are
logically enum values.
And, I'd rather my QML code use the token-unquoted for identifying
states-and-transitions, because I'm lazy (less typing) and it looks
cleaner (QML was brilliant to not quote the keys, like does JSON). ;-))
--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
On Tue, Dec 11, 2012 at 5:17 AM, Knoll Lars lars.kn...@digia.com wrote:
On Dec 11, 2012, at 4:47 AM, Alan Alpert 4163654...@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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
On Tue, Dec 11, 2012 at 12:26 AM, Mark mark...@gmail.com wrote:
On Tue, Dec 11, 2012 at 4:47 AM, Alan Alpert 4163654...@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).
What should enumeration declarations in QML look like?
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
I found myself in the exact same situation where it would've been
really convenient to have enums in QML. However, one thing that is
easy to forget is that you still have the full power of JavaScript at
your disposal. And while JavaScript doesn't support enums as those
that you have in C/C++, you still can have it's syntax.
Look at this link:
http://stackoverflow.com/questions/287903/enums-in-javascript
The thing i'm using in my project is:
var SIZE = {
SMALL : 0,
MEDIUM: 1,
LARGE : 2
};
and i'm somewhat sure that you can also do that in a qml property
with something like this:
property variant SIZE: {
SMALL : 0,
MEDIUM: 1,
LARGE : 2
};
I just tested it and it almost works. In QML 2 you can do
property var sIZE: {
SMALL : 0,
MEDIUM : 1,
LARGE : 2
}
But if you don't like those changes, you can do the var in a global
(.pragma library) script file and use that. Maybe this means proper
enum support isn't that urgent ;) .
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enumerations in QML
Hi, I figured I weigh into this discussion: But if you don't like those changes, you can do the var in a global (.pragma library) script file and use that. Maybe this means proper enum support isn't that urgent ;) . It's not that the functionality is urgent; it's that currently, QML-document-defined-types are most definitely second-class citizens in QML. It would be very nice to unify the various type-definition processes to be more equal, in my opinion. Enum support is certainly one of these areas. However, unfortunately, there's another related area which precludes any such extensions to QML document-defined types: typename support in JavaScript. Currently, composite types are handled in a different manner to other (C++-defined) types: they're not backed by a QQmlType, and the typenames are not exposed to JavaScript. Being able to define enums in QML documents is of minimal utility if the typename itself is unavailable for use in JavaScript expressions. It would certainly be very nice if the QML type system could be improved to unify handling of different type definition sources (it'd also allow Qt.createComponent(typename) to be implemented, finally), however the amount of effort required to implement the type system changes is not negligible. Cheers, Chris. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
