Upcoming changes in the next plasma-nm release

It’s been 3 months since the last plasma-nm (Plasma networkmanagement) release and we have been working really hard to bring you again a better release than the previous one. Unlike previous releases, this one is focused on internal changes which are not mostly noticeable on the outside, but I believe they are welcomed.

The most significant internal change is a new model. This one is more complex and easier to maintain and one of it’s advantages is that we can now use it also in the connection editor, so if there is a problem we can just fix it in one place. It should better handle various cases which were not properly handled in previous versions, like when you have more wireless cards. Also various NetworkManager changes are now properly propagated to the applet, i.e. we are not now limited to three connection states (disconnected, connecting, connected) as before, but when you activate your connection you will see the exact device state like “getting IP address” or “waiting for authorization” and so on. Regarding the connection editor, you can now activate/deactivate connections there which is probably something what nobody will use, but since this is possible because of the new model, then why not to add this option.

From visible changes I could mention new notifications. I added various notifications to inform you about successful or failed actions. This is quite useful when you do some action and nothing happens, usually when you are not authorized to do it. You can see new available notifications on the screenshot below.
notifications
Note: This screenshot is from Plasma 5 version and unfortunately not all notifications are also available in KDE 4 version, because I had to change API in libnm-qt (NetworkManagerQt) and this was possible only in the Qt5 version which is not released yet.

We were also working a lot on porting plasma-nm to KDE Frameworks 5 and I’m happy that plasma-nm is now part of Plasma 5 which means it will be released together and regularly also with bugfix releases, so you won’t have to always wait until we decide to bring you a new version. This change came quite late and there were no tarballs previously available until now, so I would really appreciate if you can test it together with the rest of Plasma 5. Regarding the KDE 4 version, we will probably release it together with Plasma 5 release, but if you want to try it now, you can just compile it from git and use branch called 0.9.3.

Here are some screenshots from Plasma 5 version. As you can see Plasma 5 version has a scrollbar \o/. Unlike KDE 4 version there is no traffic monitor, because it hasn’t been ported yet, but we will add it in future and details will probably get a new look.
Details Password dialog

I hope you will like all the changes above and please do not forget to report all issues you spotted to our bugzilla.

Advertisements

25 thoughts on “Upcoming changes in the next plasma-nm release

  1. Great improvements overall!

    We should however have a look at those new notifications. Many of them don’t seem to make sense as notifications. See the HIG:
    “Use a notification to inform about a non-critical problem that is not directly relevant to the user’s current task. ”
    For example a connection doesn’r remove itself, does it? I assume it’s always the direct result of a user action, and therefore part of that user’s current task, and so it should not be shown in a notification. Notifications are only for things which are not the immediate result of a user’s action. The same goes for failures, unless the failure only becomes apparent with a considerable delay so it can be assumed that the user thought the action was successful and has already moved on to a different task.
    If, however, the user clicks something and the immediate result is a failure, this, again, should not throw a notification. Immediate results of an action must be shown directly in the UI where the action was executed, not in a notification.

    I fear this will affect most of these new notifications but I strongly suggest that Plasma-NM complies with that guideline.

    • Hmm, you are right, I didn’t even know that there is a HIG for notifications. We would have to leave it as it is now for Plasma 5.0 and then find a better solution for 5.1.

      • That’s okay.
        Let’s just hope that there won’t be some users who write a 100-line script which does magical things when the deletion of a connection fails, so that removing that notification later would break their hearts 😉

    • Some of the notifications don’t make sense at all. Like connection lost/disconnected – how could anyone miss that, it is so obvious. Same goes for connected, isn’t it enough obvious. These kind of notifications are better served through Unity style popup or Android style Toast notification.

      • You mentioned probably two most useful notifications. How would you notice that you were disconnected? Like when the AP you are connected to disappears or someone unplug your ethernet cable. You wouldn’t notice it until you open the applet. Same for connected notification, what if the AP suddenly appears again and you are automatically connected to it?

      • That’s true, but you can be also connected to ethernet and wifi at the same time and then the icon won’t be changed. Another thing is the icon is quite small and watching changes in a such small area gives you high chance you will miss something. Btw. if you don’t want to use those notifications, you can simply turn them off.

      • > That’s true, but you can be also connected to ethernet and wifi at the same time and then the icon won’t be changed.
        Yes, that’s true. Then you can show a notification in such cases.
        Anyway, as others mentioned, there is not need to show “Connection ??? deactivated/activated” when you pressed “Disconnect”/”Connect”, as you obviously know what you did.

      • I would like to, but this is not unfortunately possible as this change comes from NetworkManager and there is no such information whether a connection was disconnected due to user interaction or there is another reason.

      • The persistent notification (popup) is super annoying. Any time system is suspended, anytime you leave home wifi, join school or work wifi, etc. in all of these instances you get connection activated, connection deactivated popups in system tray. You have to dismiss this notification many times a day.

        KDE is the only desktop/mobile operating system I have used that forces its users to notice that network has gone down. Android, iOS, Gnome, Unity, Windows, etc. none of these operating systems create persistent notification that have to be dismissed.

        Persistence notification is a bad idea for state changes. KDE needs Unity or Android’s Toast notification.

        The biggest user base of KDE should be mobile users (including laptop and tablets) and they constantly move. They don’t have to be notified that they are moving away from the network.

        System tray icon is more than sufficient to tell users that he or she is not connected to the internet. Connected, disconnected, wifi, ethernet, mobile, bluetooth etc. all should have different icons to let users know about their connection state.

      • We don’t use persistent notifications, they are all set to be closed on timeout and if this doesn’t work, then it’s probably a bug in KNotification. Again, if you don’t want to be informed about activated/deactivated connections, why don’t you simply turn off these notifications?

      • > We don’t use persistent notifications

        I mean’t the pile of notifications that get collected in system tray.

        > Why don’t you simply turn off these notifications?
        I don’t have a problem. I am just discussion(learning from you) how things should be.

      • Anything that can happen without user action can make a useful case for a notification, at least for some users.
        I’d vote for having notification hooks available for these changes, but don’t show a notification by default. That way people who want to b e notified can activate them.
        Regarding the “persistent notifications”: These notifications are indeed not persistent like Jan said, in that they go away automatically after a set time. The only problem I have with Plasma’s notification system (but that’s not Plasma-NM’s fault) is that even though the notifications go away, they still pile up in the notification list, so the number in there goes up and if you look at the list, it consists mostly of notifications which have long since become irrelevant (like connection state changes from an hour ago). But again, that’s not for Plasma-NM to fix.

      • Yeah, with the persisted notifications I meant the pile of notification list that I have to get rid of every few hours. Just think about number of those notification items you get when you use Kmail and get 100s of emails.

        Notifications can easily become noise. I think there should be an usability group to handle how notifications are handled by users like Visual design group is thinking about each and every pixel of the plasma desktop.

      • There is a usability group, consisting of three people. We’re just currently not focusing on notifications.
        I’m trying to get Celeste, former leader of the KDE usability group, who happens to have written her PhD thesis on the very topic of desktop notifications, to work with us on this, so it will be taken care of!

  2. I am currently missing my KDE bugzilla credentials and I dont believe I will remember to send it in, so I will at least mention it here.. there is no possibility to use WPS from the gui

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s