[Qt-qml] Fw: Why can't I stylesheet a font?

[Jason H]

If that doesn't work, how about this: "Think of the children!" <rimshot>

Seriously though lets think about this in terms of apps on a desktop, because 
that has clearly not been thought about. To make a classic Qt app, you only need 
to know your system settings (fonts, color palettes), widgets, and their layout. 
In QML you don't care too much about color and font. But you have two options 
when it comes to resize events: scale or let the layout handlers assign pixels. 
In QML, we can scale, or we can use anchors and let one Element get it all. (It 
might be a composite element) but basically, you'll have something that 
resembles a classic centralWidget style application. The central widget will 
have to be specified in some way, with its borders touching parent or sibling 
anchors.

1|2|3
-+-+-
4|5|6
-+-+-
7|8|9

(5) is the central element. And in fact, 5 can be subdivided as well. Eventually 
though one element will get the pixels. Fonts will likely be the primary factor 
in size calculations - just like they are with preferredSizes in Qt. Padding 
will consume some more. Ultimately the font size will reign supreme. A cool 
trick in making touch UIs in Qt was to change the globalStrutSize. This was very 
effective at making all the controls touch friendly with just one function call. 


Anyway, its 3:40am here, I am rambling. But let's not forget the desktop. Mmm 
kay? I understand more stuff will be arbitrarily sized, which makes the need for 
this property mechanism all that more important. Stylus-driven devices don't 
need a finger-sized control. But iPhones, Androids and N8s do. I'd like to 
target each one - and Android has a lot of screen pixel variance. If I were 
writing for that platform, I'd be using anchors as much as possible. If I were 
writing for more than one platform, I'd be using anchors as much as possible. 
(PS. Nokia, you are because MeeGo is now shipping on Aava, Quanta Redvale 
tablets.) And how will you ever handle screen rotations (essentially a resize), 
if your app is all pixel-coded?

I expect tweaks of course, but these should be managed from a config.qml which 
would be applied on a per-platform basis, leaving the meat of your application 
intact.

PS. How does one handle resize/screen rotation events in QML?





----- Original Message ----
From: Jason H <scorp1us at yahoo.com>
To: qt-qml at trolltech.com
Sent: Tue, July 13, 2010 2:56:00 AM
Subject: [Qt-qml] Fw:  Why can't I stylesheet a font?



>You might go so far as a file per Item per style, but that is unlikely. You 
>create the MyStyledText element, and use that for all your Text. What other 
>primitives would you style? Some, like ListViews, you'd likely want to style 
>per-instance and not in general (so you just declare those properties on that 
>ListView). What items were you planning to style this way?

All of them. Literally, all of them. Since these are just JS objects, they have 
attached properties and values, it should not matter. Just let me collect the 
properties/values into groups, and assign those groups to items. 


> When comparing QML/C++ with HTML/CSS, keep in mind that QML is the style part 
> and C++ is the data part. So it is not like HTML where you want to get all the 



> style out of the file. QML files should contain the styling, and can still use 



> components and global variables to style from the same source. This is much 
> more mixing of style and substance than in HTML/CSS, where the HTML contains 
> the building blocks of the UI and CSS styles them, but for UIs I think this is 



> a lot more appropriate and helps for a good look and feel (especially since 
>the data is still somewhere else, which I thought was the real point of CSS).

You silly trolls! Always mixing your controller with your view! (Delegates!?) 
The paradigm is MVC.  What we want is to specify the controller part apart from 
the view part. There is a little co-mingling, but HTML always defined the 
structure, CSS defined the look. Same for Qt Style sheets. The UI files 
specified the interface elements, the CSS specified the look of those elements. 
The same is true for this. 


One of the short-comings of CSS, is they weren't actually cascading. Sure, they 
"cascaded" from site to local, but what they sorely lacked was internal 
Cascading:
H1 { }
H1.bold { H1, font-weight: bold}
(Its been a while this may not compile, but you get the point)

Being able to specify an application-wide base font is huge. 
Being able to specify an application-wide color scheme is huge. 
Being able to change either with one edit to a file: priceless. Seriously, do 
you know how much editing it would take?

I can't count the number of times when someone said: 
"Make it blue-er"
"Make it bigger"

Would you really have me go through all the files and add 1 or 2 to every 
font.pointSize or pixelSize? Or would you rather go into theme.qml and change 
one setting - the base font size? Would you rather me repeat that for colors? 
QML is supposed to be about sexy interfaces - Developers and Arts working 
together. 


I have a complete disdain for hardcoding anything in a UI. (Blame yourselves and 


your awesome layout managers.) Everytime I see something hard coded, I shudder. 
This might not be a problem for whole screen apps, on pixel limited devices 
(phones, tablets) but this is huge problem on the desktop. (I still don't know 
how to react to the viewer resize... (my preference is scale everything)). The 
only thing that should ever be hard-coded is the initial Rectangle which defines 


the viewport, and the base font size. Everything else should be dynamically 
resolved through anchors. 


You're so close to Nirvana... just add this feature! 

>> And the fact that I can specify font and color (which isn't a part of
>> font!?) at the same time is really handy.

>Perhaps I didn't understand what you meant here, but why can't you do that 
>with the separate file?

You said: "This means that you only use the properties relevant for that  type." 


Which is true. I can't specify font color, with the font. (Which is a whole 
other can of worms, because in HTML, <font color="... and in CSS, font-color: 
...) Meaning that I can't use the proposed approach optimally because I have to 
specify color everywhere.

Consider this: I change my color scheme from bluetext/evergreen background to 
black text/bright green background. How many places should I need to change? 
Two. The font color and the background color. Without this I'd have to hunt for 
every mention of "White" and all its other variations (RGB FFFFFF). Nokia seems 
to recognize this with the color.lighter()/darker() mechanism which provides 
relative colors. 


If you go to market without this in QML 1.0, the world won't implode but we'll 
be forced into maintianing many more thousands of lines of QML which are all 
basically duplicates of the same thing. 






> ----- Original Message ----
> From: Alan Alpert <alan.alpert at nokia.com>
> To: qt-qml at trolltech.com
> Sent: Tue, July 13, 2010 12:30:37 AM
> Subject: Re: [Qt-qml] Why can't I stylesheet a font?
> 
> On Tue, 13 Jul 2010 10:48:46 ext Gregory Schlomoff wrote:
> > I second that. Would be very useful to be able to create a predefined
> > group of properties, and then assign the group as a whole to any
> > object.
> > 
> > Something like this:
> > 
> > PropertyGroup {
> > 
> >   id:bigText
> >   font.face = "Arial"
> >   font.pointSize: 30
> >   color: "red"
> > 
> > }
> > 
> > Text {
> > 
> >   text:"Hello"
> >   properties: [bigText, anotherSetOfProperties]
> > 
> > }
> 
> Something also like that, but that you can do in QML today, is:
> 
> MyText.qml
> Text{
>     font.face: "Arial"
>     font.pointSize: 20
>     color: "red"
> }
> main.qml
> 
> MyText{
>     text: "Hello"
> }
> 
> This approach has the advantage of being linked to the type. This means
> that you only use the properties relevant for that type. Also the
> precedence is clear, so if you want to set a different color but keep the
> other properties, that's easy and should be unambiguous.
> 
> The downside of this approach is that you need an extra file, but
> presumably if these properties are worthwhile separating out you may want
> to use them in multiple files anyways.

-- 
Alan Alpert
Software Engineer
Nokia, Qt Development Frameworks


      

_______________________________________________
Qt-qml mailing list
Qt-qml at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml