On Monday, May 26, 2014 17:06:12 Sebastian Kügler wrote: > On Monday, May 26, 2014 16:55:42 Teo Mrnjavac wrote: > > > Now, the most important difference to the approach I've seen in Qt, is > > > that > > > this is a QML binding in our case instead of a scaling factor which you > > > inject in the rendering engine. This means, we can change those not only > > > on > > > runtime, but have different settings for different parts of an > > > application. > > > Think of an application with 2 windows, one on your old school monitor, > > > the > > > other on your retina screen. We could adjust those depending on which > > > screen you're running, even inside the same application. > > > > > > > > > > > > The official docs for this can be found here: > > > http://developer.ubuntu.com/api/devel/ubuntu-12.04/qml/ui-toolkit/resolu > > > ti > > > on -independence.html > > Note that they actually got this wrong: They're not using a binding but an > invokable, meaning that gridUnit changes aren't propagated automatically, > but need to be triggered for re-evaluation. This looks like an API problem > to me, so it's not easily fixable for them (without changing the API). > > We've introduced gridUnits in Plasma as well, and are using them throughout. > The difference with Ubuntu's implementations are: > > - They're notifiable properties in Plasma. so you'd write units.gridUnit * > 2, not units.gridUnit(2), that's the fix for the above problem. > > - gridUnit depends on the fontsize-as-rendered in Plasma, not an arbitrary > scaling factor (Michael isn't clear on where they get this factor from) > > Bottom line is that the Ubuntu gridUnits stuff can very easily be ported > (both ways), but Plasma's mechanism is at a higher level.
I've just heard back from Florian Boucault of Canonical. As far as I understand, Florian is the go-to person for scaling issues in the Unity team, and also a fan of KDE and Plasma (yay!). He's kindly providing some more information on their scaling mechanism, quoted below. > The official documentation for the resolution independence system in Ubuntu > apps is at: > http://developer.ubuntu.com/api/qml/sdk-14.04/UbuntuUserInterfaceToolkit.re > solution-independence/ > > The goals we had in mind when designing the system were: > 1) preserving the perceived size of all UI elements the same regardless of > the distance the user is to the device and regardless of the device's > screen density > 2) making UIs look better without extra effort by: > - making it trivial for developers to implement exactly visual > designs/mockups without wasting time asking for exact measurements or > sacrificing pixel perfectness > - having UI elements tend to align > visually more together > > At the end we settled with 2 units: > 1) The unit everybody knows: the virtual pixel, also called CSS pixel or > point in the Apple world. It is the size of the screen's pixel if the scale > factor is 1 and is generally simply proportional to the scale factor. We > call it "dp" to be consistent with Android. We recommend to not use this > unit if you can avoid it. With the latest resolution independence patches > in Qt, it is also redundant with the regular pixel unit you are accustomed > to in QML. > 2) A unit called "grid unit" that is by definition exactly 8 > virtual pixels. We recommend using that one as it implicitly helps having > UI elements aligned since there is simply less grid units available on any > given screen. > > Backend wise we store the equivalent of the scale factor in GSettings/DConf > under the schema " com.ubuntu.user-interface" with the key " scale-factor". > It contains the current definition of the grid unit in pixels _per_ > monitor. We use that not only for our QML toolkit but also for GTK and the > other "legacy" toolkits used in Ubuntu. Note that to go from the definition > of the grid unit in pixel to a more standard scale factor, it is a simple > division: scale_factor = grid_unit_px / 8 > The definition of a grid unit for > a given monitor is done manually using a formula for a first approximation > and then fine tuning it with the trained eyes of the designers. We are > slowly building a database associating monitors with their grid unit > definitions. My 2¢: the part about having a database of monitors seems very ambitious but might be useful for our own guessing magic some day; and it turns out there's at least some compatibility with "legacy" GTK applications, so I guess that's good. Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
