Skip to content
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

[Feature Request] Buttons on Popup/Notifications #477

Open
GreenLunar opened this issue Aug 17, 2021 · 10 comments
Open

[Feature Request] Buttons on Popup/Notifications #477

GreenLunar opened this issue Aug 17, 2021 · 10 comments
Milestone

Comments

@GreenLunar
Copy link

Hello, I'm a happy ArchLinux user of OpenSnitch under Xfce desktop, and I want to ask for a new feature.
Following issue #476, I'd like to suggest to have an option to enable notification using a notification balloon.

The notification balloon would have 3 three buttons "Deny" "Allow" "Expert"
"Expert" button (or whatever name you have in mind) will open the popup dialog which we currently have.

Reason: Intrusiveness
While Notification Balloon will be on the top layer of the display, just as the current popup dialog, it will not be intrusive in the sense that it will not cause a fault of a current user's action.

Example: Intrusiveness
User is in the middle of adding tags to a bookmark in a web browser, and the popup dialog of OpenSnitch just caused it to be closed.

@gustavo-iniguez-goya
Copy link
Collaborator

Hi @GreenLunar ,

I like the idea of accepting/denying a connection from a notification, mainly because on some systems there's no systray area, and besides something is changing on this matter https://wiki.debian.org/Ayatana/IndicatorsTransition, https://lists.debian.org/debian-devel/2018/03/msg00506.html

However I think that it should be configurable, users should choose what kind of pop-ups to display: normal (current pop-ups) or minimal (icons on the notification). We already talked about making the pop-ups smaller here #424 and I even prototyped a simpler pop-up, but I think this approach is better.

@GreenLunar
Copy link
Author

Yes, making it configurable (optional) is a good idea.
P.S. The current popup is great.

@gustavo-iniguez-goya gustavo-iniguez-goya added this to the 1.5.0 milestone Sep 10, 2021
@gustavo-iniguez-goya
Copy link
Collaborator

Partially done. On GTK based DEs works from Ubuntu >= 16. On KDE (and others probably) I need to figure out how to start dbus mainloop or attach to the existing dbus session in order to show buttons on the desktop notifications. But it's doable, i.e.: python3-notify2 exists on all major distros since at least ubuntu 16.

Probably I'll add dekstop notifications using libnotify first, to replace systray balloon messages, and then study how to show buttons on notifications in all DEs.

@gustavo-iniguez-goya gustavo-iniguez-goya changed the title [Feature Request] Buttons on Popup [Feature Request] Buttons on Popup/Notifications Jan 7, 2022
gustavo-iniguez-goya added a commit that referenced this issue Jan 7, 2022
WIP.

Until now we used Qt's systray notifications. They couldn't be disabled
and didn't integrate well with non-Qt based Desktop Environments. Also
we depended on the system tray availability, which is not always
available (i3, phosh, ...).

Now the user can choose to use Qt's notifications, the system
notification service or disabled them completely.

Pros:
 - The notification style is defined by the Desktop Environment.
 - Can be configured globally from the system settings.
 - In many DEs, the notifications are grouped into a single view. So if
   you miss any event, you can go there and check out what happened.
 - Now we can display notifications on DEs where we couldn't before.
 - It's a standard supported by major DEs.

Cons:
 - Sometimes we can't connect to the D-Bus mainloop instance. We need to
   investigate it.

TODO:
 - Deny/Allow new outgoing connections from the notifications,
   replacing the current pop-ups.

Requested here: #468 , #476 and #477 .
@gustavo-iniguez-goya
Copy link
Collaborator

This is how it'll look like (with proper formatting):
image

@GreenLunar
Copy link
Author

Awesome!

What about a "Details" or "More Info" button?
--- WAIT!
By all means, the suggested button is good and I'd love to use it just as it is right not

So... What about a "Details" or "More Info" button?

  • Assuming the default action is directed by default on executable.
  • However, user wants to entirely block the given IP that is displayed on the notification.
  • User clicks on "Details" button, and then does the complex action on the popup which we currently have.

@gustavo-iniguez-goya
Copy link
Collaborator

What about a "Details" or "More Info" button?

Could be added, but these pop-ups don't offer many options. Out of the box, you can only display text and buttons, so no comboboxes, no checkboxes, no lists, etc.

The "More info" could display all the fields of the connection, and there could be another button to open the GUI.

@GreenLunar
Copy link
Author

Of course not. The "More Info" button will open the popup dialog that we currently have now

@GreenLunar
Copy link
Author

GreenLunar commented Jan 26, 2022

This is how it'll look like (with proper formatting):
image

I don't have buttons. I've tested with xfce4 and dunst.

@gustavo-iniguez-goya
Copy link
Collaborator

Yeah, I haven't added it for this release, only system notifications without buttons. I need to figure out how to show the buttons in all DEs.

@gustavo-iniguez-goya gustavo-iniguez-goya modified the milestones: 1.5.0, 1.6.0 Jan 26, 2022
@GreenLunar
Copy link
Author

Buttons are the most crucial part.
Either way, whether you will add it or not, users of other notification software who won't have button, would still, not have buttons.
I suggest to add button, and add note, "Support GNOME, KDE, DE, DE, DE)".

@gustavo-iniguez-goya gustavo-iniguez-goya modified the milestones: 1.6.0, 1.7.0 Mar 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants