touch-packages team mailing list archive

[Gerry Boland <1352251@xxxxxxxxxxxxxxxxxx>]

Unity8 tries to draw a splash screen for an app as soon as possible, so the UI is responsive to the user. It will paint a splash screen when either of these things happen:
1. user taps an app icon in launcher
2. when upstart notifies it an app is starting
3. when Mir notifies it an app connected

For point 3, note I said "connected" - not created a surface and set it
to show(). A QGuiApplication will create a Mir connection on
instantiation. A QCoreApplication will not show a splash, as that does
not create a Mir connection. Creation of a QWindow has no relation to
the creation of a splash screen.

This isn't something we want for desktop ofc, but for phablet I think it
makes for a good user experience to paint a splash screen quickly.

As a result, I don't believe there's a way a binary can tell shell not to paint a splash screen for it. 
Instead these are the only options I can think of:
1. shell having some heuristics to decide what apps should not get a splash screen
2. app supplies metadata via desktop file to specify if it wants a splash or not

I dislike option 2, as I fear it could be abused by app developers, and
make our platform appear slow to react to user input. Option 1 is also
poor, as heuristics would be unreliable. So no path forward is clear to
me on this matter.

-- 
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

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