-
-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[appimaged] Implement desktop notifications #657
Comments
Might just be my personal taste, but I dislike notifications. They should really only show up if something (badly) goes wrong. The last thing I want to see is a notification "hey, I just "installed" AppImage $foo". Because this kind of thing should "just work". Like on the Mac. |
Given that in many cases, appimaged doesn't "just work" yet, and debugging is overly complicated due to this annoying "am I installed already" check, notifications would help. Furthermore, a lot of users, me included, prefer to be able to see what's going on. I would highly appreciate being notified about new AppImages on my system. |
I am fine with it as a developer option that the user needs to enable; but not something normal users will see. |
I also think that desktop notifications like "VLC was added to your start menu" are a bit annoying. I will stand with @probonopd i think that a log for developers will be more than enough. |
It seems that we are not implementing this. |
Right. Desktop integration is to supposed to "just work" and not need any UI. See AppImageCommunity/appimaged#30. The Mac never brings up any dialog boxes or notifications regarding system integration, it "just works". |
People expect that there, though. Also, I'm not sure if it won't show a first time message to explain basic UI concepts like that to users... |
appimaged performs a lot of operations, of which the user is never informed. To fix this problem, we should implement desktop notifications. Since the daemon is run per-user and not system wide, this is pretty easy to implement.
Operations I could imagine we should inform the user about:
The operations during both startup and runtime are actually the same (they're just triggered by different data sources, one is the initial filesystem search, the other one is inotify), but I think it might make sense to differentiate here, usability wise.
Especially during startup, sending a single notification per event might spam a lot of notification windows. Therefore, I'd group those notifications (e.g., one joint message after startup listing all the integrations and removals in two bullet point lists). During runtime, I find it difficult to group the messages, due to how the daemon is written at the moment. We could, however, introduce a notification queue, and check it for messages in the event loop occasionally. Whenever a certain message timeout has run out, we could then send all the messages in a single notification. But I think just sending single messages should work as well, it's not too common to delete a directory with maybe 20 AppImages or something like that.
The original libnotify is LGPL, so I figured we should just bundle
notify-send
fromlibnotify-bin
[1], which is really simple to use in my opinion. We could also bundle some notification icons, although I found an alternative to this, which seems to work well cross-platform:As long as an icon with such a name is available in
/usr/share/icons/{gnome,breeze,...}/...
, the icon will be shown. Otherwise, the notification will not have an icon. So, instead of bundling an icon, I'd rather try to use the system icon. That'll also give notifications of a native touch. And I know @probonopd likes stuff that looks as native as possible.References:
[1] https://wiki.ubuntuusers.de/Benachrichtigungsdienst/
The text was updated successfully, but these errors were encountered: