mobile: android splash screen (and issue 513) opacity weirdness

[Lubomir I. Ivanov]

On 17 November 2017 at 10:52, Jan Mulder <jlmulder at xs4all.nl> wrote:
> On 16-11-17 23:05, Lubomir I. Ivanov wrote:
>>
>> On 16 November 2017 at 23:06, Jan Mulder <jlmulder at xs4all.nl> wrote:
>>>
>>> While investigating issue #513 ([Bug] Mobile: Startup splash screens
>>> display
>>> 2 different background color (Black then White) I found the commit that
>>> introduces this splash screen stuff (04e994b57558ed9). First, let me
>>> reset
>>> the complexity on GitHub from low to high :-) as the issue is related to
>>> the
>>> app bootstrap phase on device, and there is exactly one color defines in
>>> that whole process (which is white background), so where the black
>>> background phase is coming from is still is a mystery to me.
>>>
>>> Reading mentioned commit and the referenced internet page, and carefully
>>> reading the code in main.qml I find 2 opacity related pieces of code
>>> commented out (by Tomaz), telling "ApplicationWindow has no Opacity calls
>>> no
>>> more." (commit 4db80aa1a404dc). Hmm, weird. I just looked at the Qt docs:
>>> opacity on ApplicationWindow is a property since Qt 5.1, Tomaz: there is
>>> probably something I do not understand, but can you explain that commit?
>>>
>>> I enabled that opacity code again. No visible effect, so I change the
>>> fade-in animation to 10 sec (yes ridiculous long, but ease to spot while
>>> running the app). No visible fade in anywhere. Question for Dirk: as
>>> original author, have you ever seen that fade in?
>>>
>>> The referenced internet page (from commit 04e994b57558ed9), also explains
>>> that there needs to be a QML Loader object, and we do not have one. (So,
>>> I
>>> believe there was never a fade-in animation). I added one ... and
>>> suddenly
>>> ... I have a nice 10 seconds opacity fade-in of the app :-) That is: on
>>> desktop.
>>>
>>> And now it gets even more confusing. Running this changed code on
>>> Android,
>>> results in numerous (probably 10000 (milliseconds)) error strings in the
>>> log: "This plugin does not support setting window opacity". So, a piece
>>> of
>>> Qt code is called that is not implemented for Android. But ... the
>>> current
>>> app has some transparency features, for example the toast notifications.
>>> So
>>> where is that coming from? Anybody knows?
>>>
>>
>> given that message, i would say that the support for ApplicationWindow
>> opacity is not available on Android and the calls should be removed.
>> i couldn't see a screenshot from the original issue report, and
>> clearly i did not understand what the reported means. do you have a
>> screenshot or a GIF/video for the two different colors?
>
>
> Since the original OP wanted to remove his screencast ... I just made a new
> one and added to the GibHub issue. It is made with the default Android
> screenrecord utility (so no fancy app), and shows the issue.
>
>> since ApplicationWindow is first set to "visible = false", and only
>> set to "visible = true" on Component.onCompleted(), this might create
>> something in those lines.
>
>
> No, this is not relevant. When setting the visible = true from the very
> start (in main.qml), the black/white effect is still there.
>
> And I found some more weirdness in opacity context. Also the divelist is
> "faded-in" (see around line 425 of main.qml). And that one works perfectly.
> So, that is not triggering the "This plugin does not support setting window
> opacity". Obviously, opacity IN the app is something different then opacity
> on the ApplicationWindow which interfaces with the external window manager.
>
> Notice that this whole discussion comes to live over an issue 513 that is
> low-prio, but as the startup of a program gives a very solid first
> impression to user, it would be nice to get all the weirdness and flashing
> screens to a minimum.
>

i didn't see this PR:
https://github.com/Subsurface-divelog/subsurface/pull/827

it's seems like a good fix. does it work?

lubomir
--