>
> > So, "MyTheme.qml" is my not-so-great stand-in until I can find
> > something good, or can implement a good one.
>
> Is that a publicly available example?
>
It's kind of a mess, because I can't decide if it's better to "centralize"
this in a single MyTheme file, or "distribute logical attributes" across
styles that logically relate to their classes. (I'm honestly not sure what
should be my approach.)
For example, I *started* with text attributes in MyTheme.qml, with
centralized (default) attributes like "fontFamily", "fontSize", etc. Then,
it further grew to handle "deferred problems" like centralizing computations
of item size based on text strings (since QFontMetrics is not yet exposed to
QML, and at that time I didn't yet hook up much to C++). So, it was stuff
like:
// FILE: MyTheme.qml
import Qt 4.7
QtObject {
id: myTheme
property string fontFamilyDefault: "Arial"
property real fontPixelSizeDefault: 10
property color fontColorDefault: "black"
// Track an "importance" percentage that defaults to "1" for
// "100%", but may scale larger or smaller depending on some
// "importance scale". For example, larger values might be
// more "important", and thus have a bigger font.
//
property real importanceValueDefault: 1.0
function getFontFamilyScaled(scalePercentZeroToOne) {
... return family for this scale ...
}
function getFontPixelSizeScaled(scalePercentZeroToOne) {
//...switch to return scaled size ...
return myTheme.fontPixelSizeDefault *
SOME_SCALED_VALUE(scalePercentZeroToOne);
}
function getHeightForStringOfScale(textString,scalePercentZeroToOne) {
return myTheme.getFontPixelSizeScaled(scalePercentZeroToOne);
}
function getWidthForStringOfScale(textString,scalePercentZeroToOne) {
return SOME_CONSTANT * textString.length *
myTheme.getFontPixelSizeScaled(scalePercentZeroToOne);
}
}
As you can see above, I started playing with an "importanceValue" that I
intended to use to implicitly select font family and size. (For example,
different heading levels would have a graduated importance value). Then,
after putting things like that in one place, I ripped it out to move the
attributes into specialized classes (e.g., text attributes to MyText
element, image attributes to MyImage element, etc.).
For example, I created (and am still using) MyText.qml, which has this
"knowledge" of its own "importance":
//FILE: MyText.qml
import Qt 4.7
Text {
id: myText
property real myImportance: myTheme.importanceValueDefault
font.family: myTheme.fontFamilyDefault
font.pixelSize: 10
color: myTheme.fontColorDefault
onMyImportanceChanged: {
updateFromTextAndImportance();
}
onTextChanged: {
updateFromTextAndImportance();
}
function updateFromTextAndImportance() {
myText.font.family =
myTheme.getFontFamilyScaled(myText.myImportance);
myText.font.pixelSize =
myTheme.getFontPixelSizeScaled(myText.myImportance);
//myText.color = myTheme.fontColorDefault;
myText.height =
myTheme.getHeightForStringOfScale(myText.text,myText.myImportance);
myText.width =
myTheme.getWidthForStringOfScale(myText.text,myText.myImportance);
}
}
On the bright side, no matter what I do, it works. It's actually kind of
weird -- it *always* works, no matter what weird stuff I try to do.
Amazing.
My confusion specifically relates to the fact that since I have so many
options, I'm unsure how I *want* it to work: How should I think about the
elements? In a "centralized" model, I have central attributes, and
"myImportance" is the only customization across the interface. In a
"distributed" model, since it's so easy to create a "MyText.qml", maybe I
should think about "MyTextHeading.qml" and "MyTextNormal.qml" and
"MyTextLink.qml" ? Or, maybe I should simply assume "MyText" is *not* a
reusable element at all, and merely assume each application or part of my
interface should have its own customized "MyText" thing?
I've broken out at least half-a-dozen different designs that really are
*totally* different, and I can't figure out what works "best". For example,
is "myImportance" a property for text things, or maybe it should be a
universally recognized property for *all* my components in my theme? Should
I centralize attributes in MyTheme, centralize them in element-specific
types, distribute them, or leave them totally as application-specific (or
platform-specific)?
Weird stuff. But then, I'm slow. ;-))
Right now, I distributed most of my theme ideas to MyElement things for
which I've found a need. For example, I merely instantiate MyText{}
elements, set the "text" and "myImportance" values, and that's all
(everything is handled in the MyText.qml implementation, which I change
every now-and-then to tweak the theme). This model currently works (very
well) for me, but I'm not married to it -- I know with very little cost I
can drop it and grab something better (if I ever figure out what that might
be).
>> It seems there's currently no official support for theming in
> >> QML so I'd like to learn how to best go about this. If I come
> >> up with something reasonable myself I'll share it here.
> >
> > That would be great. I'm interested. ;-))
>
> Me too, I think. Total noob here so does this mean if I create
> a Rectangle that includes some text and an svg image and then
> change the size of the Rectangle (perhaps being the qmlviewer
> window) that there is no way, or easy/obvious way, to auto
> re-size the elements inside the Rectangle?
>
IMHO, you've now touched onto something else (a "big" something else) about
which I'm unsure.
(1) What you describe is easy to do. I think you have many options, most of
which are "easy-and-simple".
(2) I'm unsure if you're properly thinking about the interface (I struggle
with this for my work).
The "QWidget" world (and the last few decades of GUI) have implied component
clipping -- widgets are totally self-contained (for drawing, for
layout/parenting, and often for event handling). However, that's no longer
true in QML:
(1) QML does *not* clip. (And, you probably don't want clipping in this
"gestures" and "animated" and "dynamic" world.)
(2) Because of (1), a "parent" size is NOT implied based on its children.
Of course, we might *want* to imply that (such as for a layout container).
However, since children in QML can happily exceed the bounds of their
parent, like baby ducks running all around Momma Duck, ... it's unclear to
me how Momma Duck should behave differently as baby ducks come-and-go. The
"proper" way in QML to create a shadow around a Rectangle is to make that
shadow a "child" that exceeds the parent's boundaries, and *not* to have a
"shadow" attribute on the parent itself (as would be done with widgets).
Sorry, that's a silly metaphor. However, I'm *trying* to assert:
(a) Declarative is NOT Imperative. Don't treat them the same.
...similarly...
(b) Layout is NOT the way to think about QML elements. Don't think that
way.
In your assertion, you're talking about (a) -- resizing parent based on the
child. Of course, in the "real" world you'll probably have legitimate need
for BOTH "imperative" and "declarative", and similarly have a legitimate
need for BOTH "layout" and "food-fight-free-for-all".
For example, QML has "anchors", and you *can* do layout very easily, and
even parent-item-resizing-based-on-child. However, layout is fundamentally
"wrong" when you start moving into "states" and "transitions". Layout
fundamentally "fights" your ability to do rich presentation for today's
sophisticated users limited only by precious screen real-estate.
I'm still trying to re-wire my brain for this transition ... it's some
wickedly wild stuff.
Good luck! Let me know if you come up with theme ideas.
--charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
