Hello! Ok, we'll implement both parts of our API (QDeclarativeView visibility and view mode) to the MeeGo specific parts.
Yours, Antti ________________________________________ From: Petrell Joona.T (Nokia-MS/Brisbane) Sent: Tuesday, January 04, 2011 11:48 AM To: Kervinen Antti (Nokia-MS/Tampere) Cc: Rouvinen Timo (Nokia-MS/Tampere); qt-compone...@trolltech.com; Laitinen Harri.T (Nokia-MS/Tampere); Kellomaki Pertti (Nokia-MS/Tampere); Junnonen Tomas (Nokia-MS/Helsinki); Lind Jussi (Nokia-MS/Tampere); Leppanen Olli (Nokia-MS/Tampere) Subject: RE: [Qt-components] [Proposal] Visibility API for QML applications (Revised 2.0) Hi, The viewActive and viewVisible properties sound descriptive and simple, but in QML the term "view" normally refers to model views like ListView, GridView, PathView and WebView. Class QDeclarativeView exists in Qt C++ side, and follows different naming scheme. About providing partial visibility in QML core, I talked with my team, but could not reach consensus on the issue. We will probably limit to providing a read-only application active property in QtQuick 1.1, and leave partial visibility API out from the QtQuick core for now because both the system support and use cases (like orientation handling) are still quite platform dependant, and because we don't want to commit to an API we are not entirely sure about. The property application.active will be part of Qt global object (Qt.application.active) as exposing it independently breaks any existing QtQuick 1.0 applications already using name "application", and because reserving such a common word from global namespace is not the kind of behavior you expect from respected libraries. Qt.application.active is tied to QEvent::ApplicationActivate and QEvent::ApplicationDeactivate events sent by QApplication whenever any application window gains foreground (and focus) or when application loses it to some other application. Basically Qt.application.active equals QApplication::activeWindow() != 0. In QtQuick 1.1, the Application element will probably also gain another global property Qt.application.layoutDirection for querying the default layout direction of your application (basically exposing QApplication::layoutDirection to QML), which will have value Qt.LeftToRight in Western locales, and value Qt.RightToLeft in Arabic and Hebrew locales, where people scan and read graphics elements and text from right to left. Cheers, Joona -----Original Message----- From: Antti Kervinen [mailto:antti.kervi...@nokia.com] Sent: Thursday, December 23, 2010 11:10 PM To: Petrell Joona.T (Nokia-MS/Brisbane) Cc: Rouvinen Timo (Nokia-MS/Tampere); qt-compone...@trolltech.com; Laitinen Harri.T (Nokia-MS/Tampere); Kellomaki Pertti (Nokia-MS/Tampere); Junnonen Tomas (Nokia-MS/Helsinki); Lind Jussi (Nokia-MS/Tampere); Leppanen Olli (Nokia-MS/Tampere) Subject: Re: [Qt-components] [Proposal] Visibility API for QML applications (Revised 2.0) Hello! I'd propose that properties referred as applicationActive and windowOnScreen the earlier discussion would be named as viewActive and viewVisible This would get rid of the "window" part, include "visible" in the name of the latter property, and still keep in mind that we're talking about properties of a view (like QDeclarativeView) rather than an application. Yours, Antti On 12/22/2010 12:16 PM, Petrell Joona.T (Nokia-MS/Brisbane) wrote: > >> On the other hand, I'd prefer something like "windowHasFocus" instead of >> "applicationActive" to make these properties a pair. > > Prefix "has" like in property hasFocus is Qt C++ terminology, the same > boolean property in QML elements would just be called focus. Property > windowHasFocus becomes just windowFocus. > > I agree "applicationActive" is a bit of a mouthful, but I don't like the word > "window" appearing in QtQuick elements either. QtQuick is trying to get away > from traditional desktop GUI WIMP ("window, icon, menu and pointing device") > world, it does not provide support for handling multiple windows (if most > applications only have one window the concept of windows becomes a bit > dubious), you don't have a concept of windows in sibling declarative > languages like HTML5 and JavaFX, and the term "window" is not necessarily as > descriptive for designers using QML as it may be for developers. > >> Joona, do you think windowOnScreen could be a platform-independent > property? We could provide the meego implementation. > > Yeah it could be, partially hidden mode is probably needed on all mobile > platforms. > > Br, > > Joona > > -----Original Message----- > From: Kervinen Antti (Nokia-MS/Tampere) > Sent: Wednesday, December 22, 2010 1:37 AM > To: Petrell Joona.T (Nokia-MS/Brisbane) > Cc: Rouvinen Timo (Nokia-MS/Tampere); qt-compone...@trolltech.com; Laitinen > Harri.T (Nokia-MS/Tampere); Kellomaki Pertti (Nokia-MS/Tampere); Junnonen > Tomas (Nokia-MS/Helsinki); Lind Jussi (Nokia-MS/Tampere); Leppanen Olli > (Nokia-MS/Tampere) > Subject: Re: [Qt-components] [Proposal] Visibility API for QML applications > (Revised 2.0) > > Hello! > > On 12/20/2010 11:24 AM, Petrell Joona.T (Nokia-MS/Brisbane) wrote: >> applicationActive would be true if any one of the application >> windows is the top-most focused window. > > Ok, this sounds very good. I think there's a need to change the > visibility API design to be in line with this. > > In the 3rd edition of the proposal the ViewMode enum has only values > like NormalView, ThumbnailView, IconView. There's no HiddenView anymore. > As said earlier, the viewMode property and the enum are specific to the > MeeGo platform. > > HiddenView in ViewMode is replaced by yet another boolean property, > windowOnScreen. This property informs whether or not the user can see > the window. The value of the property is true in case of the window is > visible, even partially -- no matter who has the focus. In addition to > being visible on the foreground and partially visible in the background, > the property is true also in case the window is visible in a switcher or > grid. > > For all of these three properties the most typical use cases would be: > > - For pausing on loss of focus (game-like apps, video players): listen > to applicationActive. > > - Keep display updating even in case of focus lost and stop it only when > window gets completely hidden (music players, chats): listen to > windowOnScreen. > > - Independently of the above properties applications can follow how > their window is presented (normal, thumbnail, icon) by listening to > viewMode. > > I suppose this would be simple enough in application perspective and > isolate platform-dependent stuff to a completely separate property or > properties. > > Joona, do you think windowOnScreen could be a platform-independent > property? We could provide the meego implementation. > > Timo, would applicationActive and windowOnScreen properties satisfy the > use cases you had in mind for "partially visible" applications? > > btw, if someone comes up with a good name for "windowOnScreen", I'd be > happy to use it. Notification handler (onWindowOnScreenChanged) feels > clumsy. On the other hand, I'd prefer something like "windowHasFocus" > instead of "applicationActive" to make these properties a pair. > > Yours, > > Antti > > >> If some other >> application or global system dialog is on the foreground the >> applicationActive would be false. Old runtime.activeWindow property >> was relying on the fact that the qmlviewer has only one window to >> show the QML content. Even though you can construct multiple >> QDeclarativeView windows for your C++ application, supporting the >> handling of multiple windows from QML is not really in the scope of >> what we are trying to do. >> >>> could this API be used to indicate also partial visibility; e.g. a >>> case where a fullscreen application has a non-fullscreen app shown on >>> top of it? >> > >> We could provide an additional mode for partial visibility, though >> there are some issues with that as well: > >> * partial visibility only really makes sense on mobile platforms like >> Symbian (old Avkon had IsPartialForeground()) and Maemo (MeegoTouch >> has isOnDisplay()), where most active applications take up the whole >> screen estate with global system dialogs shown on top > >> * many applications only care about whether they are on the >> foreground or background > >> * writing "running: Qt.activeApplication" is cleaner than writing >> "running: Qt.viewMode == Qt.FullsizeView", or "running: Qt.viewMode >> == Qt.FullsizeView || Qt.viewMode == Qt.PartiallyHiddenView", or >> even worse "running: Qt.viewMode != Qt.HiddenView" > >> * there is nothing wrong with having more complex handling of this >> issue in platform-specific APIs, with proper transitions and behavior >> defined between the possible application states in the platform >> style-guide > >> On the other hand partial visibility means that the application still >> needs to draw contents properly and thus keep the UI loaded, and >> without partial visibility you cannot achieve use cases that >> differentiate between partial visibility and hidden modes. What are >> the use cases for partial visibility? How would you handle partially >> visible mode on the desktop platforms? >> >> Br, >> >> Joona >> >> -----Original Message----- >> From: Kervinen Antti (Nokia-MS/Tampere) >> Sent: Friday, December 17, 2010 10:40 PM >> To: Rouvinen Timo (Nokia-MS/Tampere); Petrell Joona.T (Nokia-MS/Brisbane) >> Cc: qt-compone...@trolltech.com; Laitinen Harri.T (Nokia-MS/Tampere); >> Kellomaki Pertti (Nokia-MS/Tampere); Junnonen Tomas (Nokia-MS/Helsinki); >> Lind Jussi (Nokia-MS/Tampere); Leppanen Olli (Nokia-MS/Tampere) >> Subject: Re: [Qt-components] [Proposal] Visibility API for QML applications >> (Revised) >> >> On 12/17/2010 09:23 AM, Rouvinen Timo (Nokia-MS/Tampere) wrote: >>> I guess this API is not meant for finding out if the application is >>> fully visible or not? In the past there has been cases where >>> applications needed to know whether they are fully visible/partially >>> visible or completely hidden. >> >> Instead of "partially visible", could we cope with these cases by >> observing that 1) the application window.viewMode() == FullsizeView, and >> 2) the window does not have focus (it's not "active" in the sense that >> hardware keyboard presses would reach it)? >> >> This would allow us to avoid going deeper into the fuzzy semantics of >> "partial visibility". For instance, does an almost transparent message >> box on top of a window make the window "partially visible" -- although >> the user can see all of the contents anyway? >> >> Joona, what's the semantics of the applicationActive property going to >> be? Would it equal to "one of the application windows has a focus"? Or >> would it be true also in the case where a window of an application is on >> the foreground although it could be covered by a system modal dialog, >> for instance? >> >> Yours, >> >> Antti >> >> >>> Seems that using this API an app can >>> find out whether it's visible or not (checking the HiddenView), but >>> could this API be used to indicate also partial visibility; e.g. a >>> case where a fullscreen application has a non-fullscreen app shown on >>> top of it? >> >>> >>> Br, >>> Timo >>> >>> >>> -----Original Message----- >>> From: qt-components-bounces+timo.rouvinen=nokia....@qt.nokia.com >>> [mailto:qt-components-bounces+timo.rouvinen=nokia....@qt.nokia.com] On >>> Behalf Of Petrell Joona.T (Nokia-MS/Brisbane) >>> Sent: 17.12.2010 05:44 >>> To: Kervinen Antti (Nokia-MS/Tampere); qt-compone...@trolltech.com; >>> Laitinen Harri.T (Nokia-MS/Tampere); Kellomaki Pertti (Nokia-MS/Tampere); >>> Junnonen Tomas (Nokia-MS/Helsinki); Lind Jussi (Nokia-MS/Tampere); Leppanen >>> Olli (Nokia-MS/Tampere) >>> Subject: Re: [Qt-components] [Proposal] Visibility API for QML applications >>> (Revised) >>> >>> Hi, >>> >>>> enum ViewMode { >>>> HiddenView, >>>> FullsizeView, >>>> ThumbnailView, >>>> IconView >>>> } >>> >> >>> Some of those states seem specific to a particular look& feel and >>> yeah they should belong in platform-specific part of Qt Components >>> instead of QtQuick. You expect functionality provided by QtQuick >>> elements to work more or less the same on all platforms, which we >>> cannot guarantee for modes like ThumbnailView or IconView. We will >>> probably still introduce applicationActive property in QtQuick 1.1 >>> for convenience as that can be provided for all platforms. >>> >>> A >>> Cheers, >>> >>> Joona >>> >>> -----Original Message----- >>> From: qt-components-bounces+joona.t.petrell=nokia....@qt.nokia.com >>> [mailto:qt-components-bounces+joona.t.petrell=nokia....@qt.nokia.com] On >>> Behalf Of Kervinen Antti (Nokia-MS/Tampere) >>> Sent: Friday, December 17, 2010 1:03 AM >>> To: qt-compone...@trolltech.com; Laitinen Harri.T (Nokia-MS/Tampere); >>> Kellomaki Pertti (Nokia-MS/Tampere); Junnonen Tomas (Nokia-MS/Helsinki); >>> Lind Jussi (Nokia-MS/Tampere); Leppanen Olli (Nokia-MS/Tampere) >>> Subject: [Qt-components] [Proposal] Visibility API for QML applications >>> (Revised) >>> >>> Hello! >>> >>> Thank you very much for the comments! >>> >>> I'd like to present a revised proposal for this visibility API. There >>> are two syntactical changes. >>> >>> 1. The name of the property is changed from "visibility" to "viewMode". >>> We wish to avoid confusion with the boolean-valued "visible" property of >>> visual QML elements. On the other hand, "ViewMode" has similar meaning >>> for instance in W3C standard [1], yet the possible values there are not >>> that suitable for our purposes. Furthermore, ViewMode of certain widgets >>> in Qt affects how their contents is shown. That's what it could do in >>> QML applications as well. >>> >>> 2. A part of the enum name is repeated in the values (thanks to Rich >>> pointing this out). This convention is used in Qt with ViewModes in >>> qlistview.h, qprintpreviewwidget.h and qmdiarea.h, though it's not in >>> the ViewMode of qfiledialog.h. >>> >>> That is, the property definition will be like >>> >>> Q_PROPERTY(ViewMode viewMode READ viewMode NOTIFY viewModeChanged) >>> >>> enum ViewMode { >>> HiddenView, >>> FullsizeView, >>> ThumbnailView, >>> IconView >>> } >>> >>> If nobody starts screaming (please don't hesitate to do so if you feel >>> like it -- it's not too late), we'll go ahead with this. >>> >>> Btw, does anyone have suggestions which branch from which repo we could >>> start with? That is, where could we find a suitable C++ class that'll be >>> exposed as "window" or something similar to QML? >>> >>> Yours, >>> >>> Antti >>> >>> [1] http://dev.w3.org/2006/waf/widgets-vmmf/#view-modes >>> >>> On 12/08/2010 04:12 PM, ext Antti Kervinen wrote: >>>> Proposal: Visibility API for QML applications >>>> >>>> The purpose of the visibility API is to provide information on the >>>> visibility of the window to the application. >>>> >>>> The visibility information can be used for >>>> >>>> - stopping all unnecessary activity when user can't see the window >>>> (everyone must save battery, cpu and memory) >>>> >>>> - quick-saving modified user data when the window is hidden (your app >>>> might be closed/killed when on background) >>>> >>>> - adapting contents of the window and update activities according to >>>> different visibility states. >>>> >>>> >>>> Visibility information will be available in some context object in >>>> QML. The object is to be decided when the page/window question has >>>> been settled. >>>> >>>> The API will consist of a read-only "visibility" property whose >>>> changes can be observed via visibilityChanged(Visibility) signal. The >>>> parameter can get the following values: >>>> >>>> enum Visibility { >>>> Hidden, >>>> Fullsize, >>>> Thumbnail, >>>> Icon >>>> }; >>>> >>>> The idea of different values is that the system displaying the >>>> application window can give a hint to the application on what kind of >>>> content the window should hold. >>>> >>>> Example: a weather application presents 7 days weather forecast when >>>> it's shown in full screen. The same content can be shown when the >>>> window is in the switcher but it is still almost of the real size. >>>> Under the hood switcher sets a window property that states that the >>>> application window is "fullsize" even if it's slightly shrinked. When >>>> the window is shown as a smallish thumbnail in the switcher, switcher >>>> sets the property to "thumbnail" and the application shows only the >>>> weather of today and tomorrow. When it's shown as a very small >>>> thumbnail or like a "live icon" in an application grid, it shows only >>>> the current temperature. In this case the switcher/desktop tells the >>>> window to be of the size of an icon. >>>> >>>> If some UI specs suddenly require switcher to show windows always with >>>> the real content, switcher just sets the window property to be >>>> "fullsize" whenever the window thumbnail is visible. >>>> >>>> For comparison, libmeegotouch provides visibility information with two >>>> separate signals: 1) can be seen on the display, and 2) window is in >>>> the switcher. We believe that combining this information to the same >>>> signal and adding some semantics servers better both application >>>> developers and prototyping different UI designs. >>>> >>>> Any comments are very much welcome. >>>> >>>> Yours, >>>> >>>> Antti >>>> >>>> Ps. We prototyped this by listening to both visibility notifications >>>> from the window manager and changes in the >>>> _MEEGOTOUCH_VISIBLE_IN_SWITCHER (boolean) window property set by the >>>> desktop. Outcome were values hidden/fullsize/thumbnail. We hacked all >>>> necessary code to mdeclarativescreen. >>>> >>>> We had (still unsolved) problems with getting Q_ENUMS(Visibility) >>>> nicely shown on the QML side. Another thing that could be expected to >>>> become an issue in the real implementation is how to connect the id of >>>> the X window to the QML object in case of multi-window applications. In >>>> the prototype we just used QApplication::topLevelWidgets() because >>>> there was only one window and luckily it was already registered to >>>> that list when we installed XEvent handler. >>>> _______________________________________________ >>>> Qt-components mailing list >>>> qt-compone...@trolltech.com >>>> http://lists.trolltech.com/mailman/listinfo/qt-components >>> >>> _______________________________________________ >>> Qt-components mailing list >>> Qt-components@qt.nokia.com >>> http://lists.qt.nokia.com/mailman/listinfo/qt-components >>> _______________________________________________ >>> Qt-components mailing list >>> Qt-components@qt.nokia.com >>> http://lists.qt.nokia.com/mailman/listinfo/qt-components >> > _______________________________________________ Qt-components mailing list Qt-components@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-components
