HomeLubuntu Development

Changed connection editor to nm-connection-editor

Description

Changed connection editor to nm-connection-editor

Summary: Changed connection editor to nm-connection-editor from network-manager-gnome

Test Plan: check if nm-tray open nm-connection-editor instead of nmtui

Reviewers: wxl, tsimonq2

Reviewed By: wxl, tsimonq2

Subscribers: hmollercl

Differential Revision: https://phab.lubuntu.me/D16

Details

Provenance
hmollerclAuthored on Jul 4 2019, 7:10 PM
wxlCommitted on Jul 4 2019, 7:11 PM
wxlPushed on Jul 4 2019, 7:11 PM
Reviewer
wxl
Differential Revision
D16: Changed connection editor to nm-connection-editor
Parents
rNMTRAYPACKAGING5458d6d4f05d: Upload to Cosmic.
Branches
Unknown
Tags
Unknown
References
tag: ubuntu/0.4.1-0ubuntu2

Event Timeline

Oh no! I just realized there's a problem with this: we need to make network-manager-gnome a dependency in debian/control! Perhaps better to call it a recommend as it's supposedly a "pure Qt application" according to the description. At least this will be important for non-Lubuntu users of the package.

One other thing: the referenced bug is a duplicate. It should be:
https://bugs.launchpad.net/ubuntu/+source/nm-tray/+bug/1782579

I don't get it.
the patch is only for us, right? Or it is for whole ubuntu?

brgds
HPM

Nope. Everything we put in the archive affects anyone that installs it. Every package is available to everyone.

So, I wanted to change debian/control to add network-manager-gnome as recommended and I found out that debian/control for nm-tray is different in sid that in our phab? The difference I'm pointing out is the "depends" on sid there is network-manager and qterminal, in phab none.
Look:
https://phab.lubuntu.me/source/nm-tray/browse/ubuntu%252Feoan/debian/control
vs
https://salsa.debian.org/lxqt-team/nm-tray/blob/debian/sid/debian/control

Since we have changed nm-tray to use nm-connection-editor instead of nm-tui, it's not relevant to depend on a terminal; otherwise it would make sense.

As for the network-manager dependency, I think this is resolved by depending on libkf5networkmanagerqt-dev. Unfortunately, that's an erroneous depend as that's a build depend not a runtime one. That should probably be fixed. On the other hand, it's also not relevant where we have a dependency on network-manager-gnome.

Part of me wonders if we shouldn't actually reverse all these changes and leave nm-tray as it is and instead use conman like upstream suggests. @tsimonq2 seems to be against it but it's not clear why.

NACK on using connman.

Using network manager is a platform expectation, and connman to n-m can be considered like sqlite to postgresql. It works, but it's meant for embedded purposes.

Of course, agaida will argue otherwise, but platform expectations trumps upstream.

Is it really a platform expectation? Or it's a platform expectation like, say, Ubiquity is? Either way I'm concerned that we're changing nm-tray to require the whole NetworkManager GNOME stack when it's meant to be pure Qt. I guess the alternative is that we don't change the dependencies of nm-tray and instead deal with that in the seed. Furthermore, we would want to make sure that nm-tray is XDG-compatible so we could make this configuration change in lubuntu-default-settings. Isn't this palinek's baby? And wasn't he the one that got that XDG-compatibility patch in lxqt-globalkeys so fast?

Yes, I'm not comfortable changing it.

NACK on making the change in the seed if we're changing the package itself. However, if we get this to follow XDG, this change should be reverted (along with the added dep) and it should be done in the seed and default settings.

What I'm arguing is that changing the package as we've been aiming towards is probably a bad idea for non-Lubuntu users of the package given the goal of the software. Make sense? Maybe we should revert everything back to normal and provide an advanced configuration guide for using nmcli.

For me, main problem is that nmcli does NOT support VPN, so, to use VPN network-manager-gnome (plus teh required NPN packages) should be installed.

Maybe instead of modifying the package, we could run a script after installation which modifies /usr/share/nm-tray/nm-tray.conf and change the editor.

You're thinking of nmtui but I mean nmcli. It's not intuitive or user friendly but it does do VPNs and anything else NetworkManager (the backend, not the oft-associated but technically separate GNOME frontend) is capable of.

Your script idea is not bad. We're still modifying the package but this could be an added benefit because it could ensure everything was in place to use what editor you needed. To do this well, we should consider all the possibilities. At that point, it should go to Debian. We should probably talk to agaida about this idea.

the link you provided for vpn with nmcli needs to install network-manager-gnome.

Install NetworkManager on Debian / Ubuntu
If you are running Ubuntu or any other Debian family operating system. Install the following packages
sudo apt-get install network-manager network-manager-openvpn
With Gnome Desktop Environment, then include:
sudo apt-get install network-manager-gnome network-manager-openvpn-gnome

and i t doesn't open it because it already has the config file. But I don't believe nmcli has the option to create a new config file.

The need for the GNOME packages is true iff you're on GNOME and actually I suspect its only value is for additional integration into the DE. Even in GNOME, you shoudl be able to do everything with just network-manager and the OpenVPN plugin.

Looking at the examples documentation for nmcli, it looks like it has a rather rudimentary connection editor, much like the key editor in gpg2. nmcli connection edit type vpn is all it takes to get started (and, yes, I confirmed that works even without network-manager-gnome. It's still not *easy*, but it's doable.

To reiterate and clarify my observations and feelings:

  1. Making any changes to nm-tray makes changes to the entire package for any user, despite the desktop environment they are using. This is not necessarily Lubuntu's package only.
  2. nm-tray is meant to be a pure Qt application, so users probably don't want GNOME stuff.
  3. nm-tray currently lacks a native editor and there doesn't seem to be any progress on this front.
  4. The default editor, nmtui is ugly since it's a curses UI (but that doesn't make it a GTK UI).
  5. Despite its ugliness, nmtui does work for most of people's networking needs.
  6. nmtui also lacks the ability to do more advanced configurations, but that's where nmcli comes into play.
  7. Much like with advanced partitioning in Calamares where it's not necessarily easy or foolproof, using nmcli will not be simple for the novice user, but to use the parlance that the Calamares devs use: "we expect you know what you're doing."
  8. Couple nmcli with good documentation (of which that examples page covers a lot of, but we can add one in our manual specifically for a real VPN, especially if it's a popular one).
  9. Doing this would help us eliminate the modification of the package and would provide us with a fully functional interim solution while we wait for a native interface.

Total aside as it relates to VPNs and doesn't impact my thoughts above, but the new riseup-vpn is free; requires no accounts, authentication or configuration; respects your privacy more than any other VPN service out there; and is just stupid simple.

I understand your concern, maybe we could leave nmcli (as default) and add network-manager-gnome. So users when tray to edit connections with nm-tray will open nmcli, but they stilll can open network-manager-gnome.
And we could change the default with a post-install script, or not, if we decide to be more anti-gtk purist.

On the vpn issue, I have an lptp vpn I need to connect to. I can see it in nmcli, but I cannot edit/modify the parameters.

conman consumes a LOOOT of resources.

On the ant-gtk purist, we have all our printer manager, connection, etc... in gtk. It's the same.
And even LXQT uses Galternatives, we ask agaida and he had no problem with using it.

My idea is, in things that are not used much, gtk is a better solution than a terminal one.

I agree that we can't get rid of all the GTK things right now but we should continue to be working to remove them at every moment. It's a goal to work towards. In my mind, the fact that we have GTK bits is no excuse to not try to remove other ones or keep new ones from coming in. We should resist this as much as we resist things which increase the system load. These are essentially design goals for us. That doesn't mean we won't do anything that violates them (this is all part of the "new" Lubuntu not being strictly lightweight), but those would be because there are no other viable alternatives.

The problem using network-manager-gnome as a depend or requirement of nm-tray is it is totally against the purpose of the package, which is essentially anti-GTK. I really should have considered this before but it wasn't until agaida said something to me about it that it became obvious. Whatever we do, I can safely say we cannot do this to the nm-tray package and must revert the change.

I have no problem keeping network-manager-gnome in the seed but it's going to be unusable unless we figure out some solution to change the value in nm-tray.conf. The postinst script is a complicated solution to this. Upstream XDG support would be way better.

There is another alternative: drop nm-tray altogether and just use nm-applet + network-manager-gnome like we did pre-LXQt.

One other clarification about nmcli: I am not suggesting it as an alternative to nmtui. I'm suggesting that we revert this, keep nmtui as the default editor, but then make "advanced networking configuration" documentation in the manual showing how to use nmcli.

Regarding your VPN, I would urge you to check upstream with GNOME. There must be a way to do this. nmcli is, from what I can tell, a fully functional frontend for NetworkManager supporting all of its features. In fact the manual flat out says "It can be utilized as a replacement for nm-applet or other graphical clients."

If we go with the nmtui solution, network-manager would still be usefull.
nm-connection-editor (from network-manager-gnome) already has an entry in the menu. Preferences->Advanced Network Configuration.

will revise nmcli

funny thing:
nm-applet consumes less resources than conman.

So we should:

  1. keep network-manager-gnome in the seed
  2. revert this change
  3. change documentation to demonstrate how to use network-manager-gnome for more complicated needs

Right?

Or should we just go with nm-applet?

I agree with your proposition, nm-tray with nmtui as default, but living network-manager-gnome for more complicated things.

nm-tray also consumes less resources than nm-applet.

In terms of resources consumption:
nm-tray < nm-applet < connman

@hmollercl excellent. If you could forge ahead on making those changes, I'd appreciate it.

@lynorian bringing you in here because we're making a change that should affect documentation for 19.10. Instead of using network-manager-gnome as the connection editor for nm-tray, we're going to keep nmtui. We'll keep network-manager-gnome (as accessed through the menu) as a solution for more advanced needs. This will probably need some documentation.

How is this revert done? Doesn't exist an "undo" action for doing it?
I don't even know how to search for it, "fork ahead"?

@hmollercl not to dig up the past but I think I was a little too rash to shoot this down. Looking at this post on Discourse got me thinking on the subject and I realize we can instead implement this change in rDEFAULTSETTINGS by using $XDG_CONFIG_DIRS, specifically dropping our own nm-tray.conf in /etc/xdg/xdg-Lubuntu/nm-tray. I just tested this in 19.10 and it works fine and overrides the default in /usr/share/nm-tray. Interestingly, though [/usr/share traditionally is in $XDG_DATA_DIRS](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) (and it is for us), we also have it in $XDG_CONFIG_DIRS so it works. nm-tray uses QSettings to manage configuration and [it uses $XDG_CONFIG_DIRS](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored) so this makes sense. So want to fix this once and for all in Focal?

sorry, so @wxl you want now nm-connection-editor to be the default instead of nmtui?

@hmollercl not to dig up the past but I think I was a little too rash to shoot this down. Looking at this post on Discourse got me thinking on the subject and I realize we can instead implement this change in rDEFAULTSETTINGS by using $XDG_CONFIG_DIRS, specifically dropping our own nm-tray.conf in /etc/xdg/xdg-Lubuntu/nm-tray. I just tested this in 19.10 and it works fine and overrides the default in /usr/share/nm-tray. Interestingly, though [/usr/share traditionally is in $XDG_DATA_DIRS](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) (and it is for us), we also have it in $XDG_CONFIG_DIRS so it works. nm-tray uses QSettings to manage configuration and [it uses $XDG_CONFIG_DIRS](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored) so this makes sense. So want to fix this once and for all in Focal?

@hmollercl Of course I don't want it, but it's the best we got. I had supported the change here but only decided against it because I didn't feel it was fair to non-Lubuntu users. For some reason we didn't thing it was XDG-respecting, but it turns out it is. I think my last comment should explain why.

@hmollercl Of course I don't want it, but it's the best we got. I had supported the change here but only decided against it because I didn't feel it was fair to non-Lubuntu users. For some reason we didn't thing it was XDG-respecting, but it turns out it is. I think my last comment should explain why.

ok, now I understand.

LGTM though I'd append a "no changes needed" to the standards bump in
the changelog to clarify that we didn't need to do anything other than
just switch the version number.