On 11/21/2011 11:50 AM, Knoll Lars (Nokia-MP-Qt/Oslo) wrote: > On 11/21/11 10:49 AM, "ext Samuel Rødal"<[email protected]> wrote: > >> On 11/21/2011 08:48 AM, ext Alan Alpert wrote: >>> The thread about Window{} has progressed, and I still prefer that >>> attached >>> property approach compared to a Screen property on Window. The attached >>> property allows you to access the properties of your current screen >> >from any >>> graphical object easily, without having to find the current Window. If >>> we >>> added screen to Window, we'd then need to add a window attached >>> property so >>> that elements which didn't create the window can still find the screen >>> attributes (think components). Since there's nothing else in the Window >>> API >>> that arbitrary objects would need, I don't like having the extra >>> "Window." >> >> Good points. The only argument I could see against would be a desire to >> have rotation animations be centrally controlled. However, DPI and such >> might be useful even for sub-components. Though they need to be careful >> to use the average DPI and not the horizontal and vertical DPIs if they >> want to be rotation-agnostic. > > Isn't it the Window{} that announces the apps orientation? Screen only > exposes how the device is being held by the user.
But who makes that decision? I imagined the decision might be made in QML, since for fullscreen applications it's up to the application itself which orientations it supports. The QWindow::setOrientation() is mainly there for giving a hint back to the compositor about which orientation the application is rendering itself in. > With regards to DPI I wonder whether the separation between dpiX and dpiY > makes sense on a QML level at all. Shouldn't we simply expose the average > DPI only? Yeah, that seems like a good choice, at least until we see some actual demands for separating the two. -- Samuel _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
