> > > 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