blue-build / modules

BlueBuild standard modules used for building your Atomic Images
Apache License 2.0
22 stars 26 forks source link

feat(default-flatpaks): Prompt & explain the user new flatpak install & uninstall #188

Open fiftydinar opened 3 months ago

fiftydinar commented 3 months ago

Introduction

Thanks to @qoijjj for the idea.

Uninstalling a flatpak automatically sounds nice if you are the maintainer & user of the image at the same time.

However, for other users, it can still be a pain experience, even if it's possible for them to circumvent that.

The issue is the lack of further information & documentation, regarding flatpak uninstallation to the user. Another issue is that the flatpak uninstallation process is invasive process itself, since it doesn't ask the user about it at all. That's a degrading experience for the user, especially if he used that app daily.

Uninstallation process can be improved.

Idea

The idea is to prompt the user in notification if he wants to uninstall the flatpak.

Explain the reason in notification why flatpak is removed.

Depending on how flatpak remote is configured, give instructions to the user on how to keep using the uninstalled flatpak by the OS.

By "how flatpak remote is configured", I mean this. While having system flatpak remote for the OS & user flatpak remote for the user is the best way to solve this, we still need to support single remote usage, which is the most frequent in usage of custom images. Instructions differ between those configurations in this sense:

System flatpak remote for the OS & user flatpak remote for the user:

Single flatpak remote:

When user says "Yes" in both scenarios, uninstallation process normally occurs.

It's still not the ideal experience I guess, but I'm open for improvements regarding this.

What also needs to be accounted is what to do if user misses the notification. Do we inform him again about it through another notification, or do something else? Is some kind of more prominent window pop-up more desirable in this case, to assure that user focus is in-place?

Implementation

Currently, don't know how.

Notification system in desktop environments need to be checked if they support prompts like it's imagined here, if currently used notify-send support this etc.

What also needs to be figured is to implement the notification feature without having boilerplate in the code by using some templates or something.

fiftydinar commented 3 months ago

Similar system can be also beneficial in installation process too, in order to inform the user why the new flatpak is installed.

Flatpak install may not need a prompt, since it does not degrade the user experience like uninstallation process does.

xynydev commented 3 months ago

This prompting is literally the purpose of Yafti. Ublue initially had a Zenity progressbar for installing Flatpaks, which I don't believe showed the user any prompts. That was replaced with Yafti, to allow toggleable package sets and other commands being presented to the user as optional setup steps. Then Bluefin & Bazzite started using their Flatpak managers to "pre-install" a non-optional set of Flatpaks on their custom images. This feature was ported to BlueBuild as default-flatpaks, as it's frankly a very useful tool for custom image maintainers.

But to be frank, I never was quite sure what the actual usecase of Flatpak removals were. For personal images, it is somewhat understandable, but for images with multiple users I'm not so sure. It's probably still an alright to feature to keep in, though, as image maintainers may anyway make decisions that degrade the user experience for some users. It is ultimately up to the image maintainer to do Flatpak installs and removals, and how they are accomplished. The user-configurability of the module helps with the degradation too.

I am not so sure if adding the prompts to the default-flatpaks module is a good idea (right now), when its purpose would overlap with that of Yafti. With a Yafti rewrite being on it's way, the usability of Yafti for a purpose such as prompting the user to remove some Flatpaks could get even better.
Some other concerns I have with regards to prompting:

fiftydinar commented 3 months ago

This prompting is literally the purpose of Yafti.

Oh, I forgot about it, thanks for mentioning it.

Yafti can be used as strictly prompt, but it's mostly used as the 1st run optional setup these days.

It's configurable in yml, with option to modify the running frequency of yafti. So it can be used as optional setup, prompt or something else, which is great. It can also be configured as an information pop-up too, which would be used for things which do not present a prompt, but important information only. I think that window size can be configured too for those things, to make the experience less distracting depending on the type of the dialog.

I am not so sure if adding the prompts to the default-flatpaks module is a good idea (right now), when its purpose would overlap with that of Yafti. With a Yafti rewrite being on it's way, the usability of Yafti for a purpose such as prompting the user to remove some Flatpaks could get even better.

I think it's a good idea to wait for yafti refactor due to this.

Some other concerns I have with regards to prompting

When thinking about it, I believe that something like Zenity dialog or Yafti prompt is better than strictly using notifications.

We wouldn't have to worry about the compatibility for various notification systems that you mention. We would assure that user will see & read the prompt.

It may look more distracting than notifications, but it would prevent some issues that you mention.

Now about Yafti prompt vs Zenity dialog, I think that Yafti is more refined to use. It looks better, can be more configured & we wouldn't have to reinvent the wheel with Zenity.

We can also optionally keep notifications-only for maintainers who wish less distracting experience.

What do you think?

xynydev commented 3 months ago

I think let's wait until the Yafti refactor is used in Bazzifin. The default-flatpaks should keep notifications as optional, and the usecase here is prompt-less, so I think that if a maintainer wants a prompt they should just reach for Yafti. We may conceive ways to direct maintainers towards choosing Yafti for Flatpak changes which might be degrading for end-user experience.