[feature request] notify user of action result

[rien333]

One feature from nm-applet that I miss in networkmanager-dmenu are "exit status" notifications. Especially because dmenu itself provides no indication of wether your action was (un)succesfull, and, optionally, why something failed. I therefore often have to rerun networkmanager-dmenu in order to know wether an action has succeeded, sometimes multiple times.

Adding notifications when an action is completed (or failed) would remedy the need to run this program multiple times to know what's going on. For example, nm-applet uses notifications to let the user know wether the device is in the process of connecting, and, when it finishes, wether the connection attempt was succesfull. It's likely that not everyone needs this (extra) reassurance, so I suppose showing notifications would be made optional. (In a more minimal/unix-y fashion, it could also be an idea to only show failures to the user)

This seems easy enough, so I could implement this myself, if/when I find time.

[firecat53]

Seems like a reasonable request. I'll leave this open until someone is able to submit a PR. Thanks!

[firecat53]

If you all can try out the develop branch, I pushed a commit that should address this request. Let me know if you have suggestions for modifications/improvements!

[rien333]

Ah yes! I tried to implement this a little while ago, but understanding how to correctly do the glib-nm interfacing proved more difficult than expected.

I'll try the new branch now!

[rien333]

The basics seem to work, many thanks!

However, I do have a couple of suggestions. The first is more serious. Say I have nm-applet running (which I currently often have, given that its notifications pair pretty nicely with networkmanager-dmenu). When I then attempt to connect to a network with networkmanager-dmenu (henceforth nmd), I get an immediate notification from nmd about the connection being succesfully established. nm-applet, however, reflects a rather different state at this point, namely of still being in the process of connecting. So far so good, but when nm-applet is in this state, I have frequently noticed that connections can still fail. Therefore, I very much worry that nmd too quickly concludes that the network connection has been succesfull. (which destroys much of the purpose of having notifications in the first place). (Note that what I'm suggesting is not that you replicate the fact that nm-applet shows that it's still connecting, but rather that I worry that ndm currently is a bit too eager about its notifications)

Second, some title lines of notifications are rather long. Maybe I've grown too accustomed nm-applet, but I think longer notification messages are frequently split up to be more parseable. You could probably show a message much like nm-applet does, i.e. something like notify-send 'Connection established' "You're now connected to 'foo'" (no need to reinvent the wheel here I think).

Third, the message paired to "Rescan wifi networks" shows some odd looking characters, though this could be a bug on my end.

[firecat53]

1. I'll have to investigate this more. I see what you're saying about the connection failing later.

2. I reworded some to shorten a bit, but they were all just a handful of words. What notifications did you see that were too long? The example you provided was significantly longer than any of the notification messages that I coded!

3. This seems like maybe a font issue on your end. The text in the code is just plain "Wifi scan complete". What notification daemon are you using? I tested with Dunst and xfce4-notifyd.

[rien333]

What notifications did you see that were too long? The example you provided was significantly longer than any of the notification messages that I coded!

Okay, I probably could've worded this suggestion better. It's not really that the notifications are too long as such, but it's just that the title/summary part is too long for what I'm used to. By default, dunst splits it's notification into a "summary" and "body":

    # The format of the message.  Possible variables are:
    #   %a  appname
    #   %s  summary
    #   %b  body
    ...
    format = "<b>%s</b>\n%b"

For example, this discarded PR makes use of this split:
#77. Now, I personally find it less readable to have a rather long, bold summary, and no body. So my suggestions was more that you look into splitting all long messages into a body and summary. "Long" messages here probably only include those messages that have a network name into them, which should probably be moved to the body of the notification (kinda in the way nm-applet and the previous PR do it).

This seems like maybe a font issue on your end. The text in the code is just plain "Wifi scan complete". What notification daemon are you using? I tested with Dunst and xfce4-notifyd.

I'm using Dunst as well. I'm having another weird issue with this font currently, so it's probably something on my end then.

[rien333]

This seems like maybe a font issue on your end

Think I got it, some apps try to draw ligatures but show them weirdly. Nothing you can do here.

[firecat53]

You're gonna have to show me some examples of what you mean with the whole body/summary split. In my dunstrc I have format = "%s %b". The longest message I get from networkmanager_dmenu is Problem activating Ethernet Connection 1. That's it...no other words. I just don't see how that is too long and less readable.

[rien333]

I see you've significantly shortened the notification messages, so kind of whatever actually. I actually feel kinda of terrible writing so much on a nitpicky, aesthetic preference of mine (and maybe a few others), so please leave it be if you don't care

You're gonna have to show me some examples of what you mean with the whole body/summary split

See the images below.

Most OSes (say macOS, and I guess nm-applet) split notifications into a "title" and "body" part (what in dunst is called a summary and body). networkmanager-dmenu currently does not make use of this split, and puts the full message into a notification's title/summary area.

This is an example of what I've been trying to suggest (and what #77 was actually doing). It matches the style of nm-applet. Now, the exact text doesn't match what you've currently implemented, it's just an example. Notice how short the title is (it's a summary, without any details), and how the body and title are styled differently (as is the default in dunst)

A similar message, but one that only makes use of the title area (as networkmanager-dmenu currently does)

I personally prefer the first notification style, but again, kind of whatever. You can generate the first example by calling something like notify-send 'Connection succesfull' "You're now connected to 'Xiaomi Router 4C'".

[rien333]

@firecat53 As I worried already, networkmanager-dmenu can send out a notification before a connection is successfully established. The notification is basically instantaneous, whereas the actual connection completes (or fails!) much later.

As such, it can happen that networkmanager-dmenu shows that a connection is complete, whereas it actually fails. I'm able to consistently reproduce this with a faulty VPN configuration (the first notification is from nm-applet, the second from networkmanager-dmenu):

I'm pretty sure that something like this could happen when connecting to regular wifi networks too, which defeats the purpose of having notifications. For example, if I switch to a different network, the notification is instantaneous, whereas the actual moment I can acces the internet is seconds later (something nm-applet does in fact reflect in its notifications).

[firecat53]

This is going to be a hard problem to solve (I think) without daemonizing this tool, which is something I intend to avoid. Nm-applet is able to continuously monitor connections and notify when they go up and down for whatever reason because it is always running.

I'll reopen the issue and see if I can at least improve notifications for failed connections that are initiated from networkmanager-dmenu.

However, if it has to stay running for a significant amount of time to detect these failures then I think maybe we need to reconsider showing the notifications at all. There has to a balance between keeping the simplicity and non-daemon nature of the tool vs user friendliness.