snapd
snapd copied to clipboard
DT-576: GTK notification if app is refreshing
This MR integrates with https://github.com/snapcore/snapd-desktop-integration/pull/21 to show a Gtk window when a snap is locked because it is being refreshed and can't be launched yet.
It implements part of SD136
Thanks for helping us make a better snapd! Have you signed the license agreement and read the contribution guide?
@mardy Oops... Yep, changed to CamelCase. Sorry O:-)
@mardy BTW: I think that lines 62 to 69 should be removed, because both graphicalSessionFlow()
and textFlow()
functions wait for the inhibit to be unlocked. If I understand it correctly, the current code waits until the lock is removed, shows a notification, waits again for the lock to be removed (which, since it already is, is instantaneous) and removes the notification...
@Meulengracht Done.
@Meulengracht Me too :-)
Done.
@mardy Can you review this, please?
@Meulengracht Mmm... probably when I did a rebase from master without doing a pull previously :-(
I'll recheck all the change suggestions to ensure that all are applied.
Ok, I was using echo refresh > /var/lib/snapd/inhibit/firefox.lock
to simulate a refresh lock, but forgot the "-n" to remove the NL character at the end, so the HINT function didn't identify correctly the state. Taking this into account, the code is simpler.
@mardy @Meulengracht There was a bug in the code: when the snap was locked and a Snapd-Desktop-Integration notification was shown, "snap run XXX" didn't wait until the app was unlocked. I fixed it in the last patch. Can you review it again when you have some spare time, please?
@mardy Added three unitary tests.
@mardy It seems that there is no access to DBus during the tests... Is there a way of fix this?
Added three unitary tests.
The changes in snapd-desktop-integration "required" for this MR are now available in latest/stable.
("required" because if snapd-desktop-integration isn't running, snap will behave like before).
I changed the PR summary to match snapd conventions, which are <effected package dirs>|<effected components>|many: summary
@pedronis Great cleanups! Thanks.
@mvo5 should we mark this blocked as per discussion about preexisting issues?
@mvo5 should we mark this blocked as per discussion about preexisting issues?
What preexisting issues?