Hey! >Timo, would applicationActive and windowOnScreen properties satisfy the use >cases you had in mind for "partially visible" applications?
>This property informs whether or not the user can see >the window. That's exactly what the property should inform: whether the user can see the window or not. So yes I think this should satisfy the use cases. And I agree that the naming could be better... should it include the word "visibility"? Br, Timo -----Original Message----- From: Kervinen Antti (Nokia-MS/Tampere) Sent: 21.12.2010 17:37 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
