[Usability bug] "Restart preloaded services" enhanced behaviour in PM3 is confusing due to the lack of user feedback

[Olf0]

"Restart preloaded services" does not work anymore with Patchmanager 2.3.3-10.41.1 under SailfishOS 2.1.1.26: When triggered, it simply does nothing! This function (in the pulley menu, after a Patch has been applied or unapplied) was working well with Patchmanager 2.3.1-10.39.1 under SFOS 2.1.0.11 Restarting the "Homescreen" by other means (e.g. Patch: Enhanced Power Menu or Patch: Quick settings on power menu) works under SailfishOS 2.1.1.26

[CODeRUS]

Please verify in http://repo.merproject.org/obs/home:/coderus:/sailfish/sailfish/armv7hl/patchmanager-2.4.0-10.42.1.jolla.armv7hl.rpm

[Olf0]

Sorry @CODeRUS, I missed to test this, when I had Patchmanager-2.4.0-10.42.1 installed for re-evaluating issue #21 in October. Consequently I also did not reply. I am planning to retest with Patchmanager 3 in the next couple if weeks (as you branched off in November, i.e. after commit cb031a00b), after installing and configuring SFOS on Xperia X (supposing that goes smoothly).

[CODeRUS]

Nice to see you still there :)

[Olf0]

Retested with Patchmanager 3.0.36 (beta) under SFOS 2.2.0 on an Xperia X. I think the behaviour has changed slightly (compared to Patchmanager 2 under SFOS 2.1.4 on a Jolla 1): After "Restart preloaded services", the "Accept / Restart services" dialogue is displayed; when hitting "Restart services" the Jolla Settings seem to crash and the view switches to the home screen (with the Settings app being cover-less).

Any suggestions what else to check (e.g, would it be helpful to try Patchmanager 3 under SFOS 2.1.4 on a Jolla 1?) or how to take logs, which may support you in debugging this?

[CODeRUS]

probably you applied patch modifying settings? so settings was killed for patch being properly working :)

btw you can join telegram group for testing fresh stuff before it will be released: https://t.me/joinchat/CaLQAk2RBc--WXbv5rHx1A

[Olf0]

probably you applied patch modifying settings? so settings was killed for patch being properly working :)

Mmmh, I don't fully understand. Well, for PM2 (under SFOS 2.1.4 on my Jolla 1), I don't really care anymore (but may check next week, if my impression was right, that the behaviour was slightly different compared to PM3-beta under SFOS 2.2.0). As you committed a code change WRT this issue, I expected some behavioural change in consequence.

For PM3 the answer is "No" (even though I don't fully understood your statement), as I did:

1. Flash SFOS 2.2.0
2. Install Storeman
3. Install PM3-beta
4. Test the installation and application of a few patches from the web catalog

Thus there were just a few, well known Patches applied.

Anyway, main point is: This still fails to work with PM3 under SFOS 2.2.0 in a freshly and cleanly installed environment.

[CODeRUS]

I mean if patch in Settings category restarting preloaded services will kill settings applicaiton for sure

[Olf0]

O.K. So I did:

1. Unapplied all Patches.
2. Updated Patchmanager to 3.0.51.
3. Applied a single Patch, which does not provide any new entries in the SailfishOS Settings (and does not belong to the category Settings).
4. Hit Restart preloaded services and observed the behaviour.
5. Hit Unapply all patches, again.
6. Goto 3.

After testing more than 5 Patches this way, three outcomes are observed:

• Nothing happens: After hitting Restart services, the view immediately returns to Patchmanager's list of Installed patches. Examples: Enhanced email cover by Ancelad from Patchmanager's web catalog, Android back button by Jakibaki (web catalog), Contacts app cover action by AliNa (RPM) etc. Maybe it is unnecessary to restart the SFOS UI in this case, but IMHO there always should be some visible (or audible) feedback for UI triggered actions (in contrast to classic command line programs, where "no feedback" means "there is nothing to report"), thus a notification "Restarting preloaded services unnecessary" would be nice in this case. But if you are already detecting this (just my speculation), why offering Restart preloaded services in the first place? If not (i.e. a UI restart is necessary, but reproducibly does not happen, currently), this constitutes a functional bug (otherwise a minor usability issue).
• The SailfishOS Settings app crashes / restarts (as originally described above). Examples: All Patches, which alter the SailfishOS Settings app (e.g. new settings entries or Settings cover by AliNa). IIRC Patchmanager 2 restarted the SailfishOS UI in this case. Although this may have just hidden the current behaviour, it appeared to the user as the intended action. With Patchmanager 3 it looks like a crash (although technically a restart of the Settings app might be sufficient). It will make Patchmanager 3 look more trustworthy, if the old behaviour is restored or if the Settings app would open with Patchmanager's list of Installed patches (or at least the opened Settings app, in contrast to currently switching to the Home Screen with the Settings app in the background).
• The SailfishOS UI is restarted (i.e. the expected behaviour) Examples: Free rotate for phone by AliNa (RPM), Device lock faith text by Ancelad (web catalog) etc.

BTW, wow, the log for each Patch applied is cool and useful. I currently have two issues with it:

• How do I save such a Patch log. Idea / suggestion: Make the log text selectable (for Copy&Paste) by a longpress.
• Why does the log for e.g. Enhanced email cover tell me in the first section Test if already applied patch: Unreversed patch detected! Ignore -R [n] (What does the " -R" mean, I would have rather expected a "?".) Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored (Nitpicking: Full stop "." is missing after "ignored".) But subsequently the sections Dry running patch, Applying text patch and Creating backup patch do succeed!?! I had no Patches installed when installing Patchmanager 3.0.36 (as that was carried out on a freshly installed SailfishOS) and unapplied all Patches before updating to Patchmanager 3.0.51 (see above).

[CODeRUS]

I am pretty sure single click on patch log should copy it's contents to clipboard.

And the text of the log is the output of patch utilities. When applying it is checking if patch already applied by dry-running unapply sequence, which is done by -R parameter.

[Olf0]

1. Copying a Patch log: Yes, this is working nicely, indeed. And short- / long-pressing on the log content is what one intuitively tries. But there is any indication missing that something happened (i.e. here, log content is copied to clipboard). Some kind of notification would be nice, e.g. one of those unobtrusive small, black, bar-styled, top of the screen notifications, telling "Patch log has been copied to clipboard".

[Olf0]

2. Just a side note: When playing around with Patchmanager 3.0.51, I noticed that testing Restarting preconfigured services has to be carried out with a single Patch altered. Otherwise (i.e. by applying or unapplying multiple Patches) one still observes the settings app either staying open or being sent in the background (i.e. crashing, but that is expected, as discussed above), but ultimately the SFOS UI is usually restarted, because one of the Patches is triggering that.

[CODeRUS]

Retest with http://repo.merproject.org/obs/home:/coderus:/pm3/sailfish/armv7hl/patchmanager-3.0.53-1.121.1.armv7hl.rpm

[Olf0]

Behaviour unchanged with PM 3.0.53 (compared to 3.0.51) for all three categories ("Nothing happens", "Settings app 'crashes'", "UI is restarted", as described above) and "copy log to clipboard" function. Sorry, I would have been happy to report something more positive.

[Olf0]

Re-tested with PM 3.0.57: The behaviour of "Restart preloaded services" seems to be O.K..

I think I have understood now, that PM3 is doing the right thing technically: Only restart, what really needs to be restarted after applying a single or multiple Patches. Which can be either: (a) nothing (b) the Settings app (c) the whole SFOS-GUI (Lipstick) PM 3.0.57 also seems to always correctly pick the "strongest" measure of these, when multiple Patches have been applied. (Probably earlier PM3 versions already handled this properly, I was just too blind to see.)

Thus the only remaining complaints are about the lack of feedback to the user:

• As PM 2's "Restart preloaded services" stubbornly always restarts the SFOS-GUI (Lipstick), this is an unexpected change of PM's behaviour, which originally lead me to the incorrect conclusion, that "Restart preloaded services" is fundamentally broken in PM3. Suggestions:
  • Denote in the confirmation dialogue of PM3's "Restart preloaded services" what will be restarted: Either the Settings app or the whole SFOS-GUI. (For the "do nothing" case, see below.)
  • Do not trigger offering "Restart preloaded services" after freshly applying Patches, if these specific Patches does not require anything to be restarted. This eliminates the confusing situation, in which "Restart preloaded services" obviously does nothing after being selected and confirmed.
  • If possible (enhancement), accumulate if and which services have to be restarted after applying multiple Patches, until the SFOS-GUI is restarted. Currently this information seems to be discarded when one leaves the PM settings page in the Settings app: If one missed to select "Restart preloaded services" right after applying Patches and already left the PM settings page meanwhile, "Restart preloaded services" is not offered when returning to PM's settings page, although there still are pending changes.
• Copying the Patch log is basically the same: Although working nicely technically, the lack of any feedback to the user makes it look broken. Any proper feedback will resolve this, e.g. telling "Patch log has been copied to clipboard".