touch-packages team mailing list archive

Thread
Date

[Bug 1352251] Re: Splash screen is shown as soon as QGuiApplication is instantiated

To: touch-packages@xxxxxxxxxxxxxxxxxxx
From: Alberto Mardegan <1352251@xxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Nov 2014 07:54:04 -0000
Reply-to: Bug 1352251 <1352251@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

This bug is still valid: while all the UI interactions involving trust sessions are working fine (there is no splash screen -- as I believe is correct), there are still cases where the Online Accounts UI is not invoked within a trust session, and that's typically when the client process is not a GUI application. This is the case of scopes and some system services (sync-monitor, and maybe telepathy in the future).
As I wrote in comment #1, many times even if the OAuth access token is expired, the cookies are still valid and we might be able to get a new access token without showing a web page. But we cannot know this in advance: we'll know it only after loading a webview (and Oxide requires a QGuiApplication) which we'll keep hidden until either we get redirected to the page where we get the access token (in which case the user will not see any UI at all) or until it's clear that we cannot proceed without the user interaction, in which case we can either show a snap decision or just return an error to the client.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity8 in Ubuntu.
https://bugs.launchpad.net/bugs/1352251

Title:
  Splash screen is shown as soon as QGuiApplication is instantiated

Status in Qt integration with the Mir display server:
  Confirmed
Status in “unity8” package in Ubuntu:
  Confirmed
Status in “unity8” package in Ubuntu RTM:
  Confirmed

Bug description:
  On the phone, a splash screen is shown as soon as QGuiApplication is instantiated; however, a QWindow might be created much later, or not be created at all.
  We have for example a D-Bus service (ubuntu-system-settings-online-accounts) which is a QGuiApplication, but creates QWindows only as client requests arrive. In the common case, this works fine because the service is generally started when a window needs to be displayed, but we are now preparing for implementing trust session support, and that would require either this bug to be fixed, or a deeper refactoring of our code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qtmir/+bug/1352251/+subscriptions