Changed connection editor to nm-connection-editor
Description
Details
Event TimelineComment Actions 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: Comment Actions I don't get it. brgds Comment Actions Nope. Everything we put in the archive affects anyone that installs it. Every package is available to everyone. Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions 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? Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions the link you provided for vpn with nmcli needs to install network-manager-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. Comment Actions 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:
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. Comment Actions 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. 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. My idea is, in things that are not used much, gtk is a better solution than a terminal one. Comment Actions 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." Comment Actions If we go with the nmtui solution, network-manager would still be usefull. will revise nmcli funny thing: Comment Actions So we should:
Right? Or should we just go with nm-applet? Comment Actions 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: Comment Actions @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. Comment Actions How is this revert done? Doesn't exist an "undo" action for doing it? Comment Actions @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? Comment Actions @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. Comment Actions LGTM though I'd append a "no changes needed" to the standards bump in |