I had some bridged connection made for my virtual machines with the network manager before the upgrade to Plasma 5.9 and now I can not see any connection. Because the adapter was bridged the applet is completely empty! I can't even change my IP address. I have found this commit: https://cgit.kde.org/plasma-nm.git/commit/?id=aae4b7886bcf865d976e98910e24b13436521f8f which says: "[bridged connections] are not used on desktop anyway". This is not true! Anybody who has virtual-box, vmware workstation or virt manger installed uses this. Please add the options back. I had to install the Gnome Network manager to be able to edit my connections. Please revert this decision, this is a regression.
As I already told you on GitHub, I don't plan to revert this as I believe this shouldn't be visible to regular users. If you want to edit your bridge connections, then you can use nm-connection-editor (which is the Gnome NM tool you mentioned I guess) or use nmcli or nmtui. Even Gnome as a such doesn't show and support that, they had that some time ago, but dropped support for these connection types recently as well. [1] - https://git.gnome.org/browse/gnome-control-center/commit/?id=20b634b4544d1cfa62cf37932b20396198fd84d9 [2] - https://git.gnome.org/browse/gnome-control-center/commit/?id=b38bf8b67207b55df9d9c1f9433699c5b0395c89 [3] - https://git.gnome.org/browse/gnome-control-center/commit/?id=99743428656618b64e5115e2216339676c0e7510 [4] - https://git.gnome.org/browse/gnome-control-center/commit/?id=a4729411b564ae1e69522101984818a11ca94efe [5] - https://git.gnome.org/browse/gnome-control-center/commit/?id=8861d4409921235c76b8792db42cd6f42d903a7a
*** Bug 376785 has been marked as a duplicate of this bug. ***
Even you don't want support ability to create this type of connections, why not leave the opportunity to connect through an applet to already created connections?
If you want more info why we decided to go this way check: https://mail.kde.org/pipermail/kde-hardware-devel/2015-December/003573.html
I've read. Is sad, when the familiar functionality worked for several years is lost and you need to rebuild the workflow. Can you point to the commit for applet, because i want to revert it for my build?
Here are commits I found related to that, but I'm not sure whether this is all and I cannot guarantee that reverting those will not break something. - https://cgit.kde.org/plasma-nm.git/commit/?id=aae4b7886bcf865d976e98910e24b13436521f8f - https://cgit.kde.org/plasma-nm.git/commit/?id=0a89268a65a5cb6321b03d954421978493fca4fc - https://cgit.kde.org/plasma-nm.git/commit/?id=da09936c127e9f2a90a5dca431d349f3616f7cfc - https://cgit.kde.org/plasma-nm.git/commit/?id=ca903e1e1e07ef569e80b9d8fba8ed71a547096f - https://cgit.kde.org/plasma-nm.git/commit/?id=5a065e9a176c305776a16e6de174eade076961f5
We are agree with imraro and revan. Before in plasma vlan support worked perfectly until someone has decided to remove it. https://cgit.kde.org/plasma-nm.git/commit/?id=aae4b7886bcf865d976e98910e24b13436521f8f&h=Plasma%2F5.10 Me and my company think that's not the right thing. We've installed kde distributions because we work with networks and plasma has fast support in creating network profiles and vlan. Even windows has graphical support for vlan and its is a desktop use! But vlan creation is not as fast as it was in plasma. I do not understand why to remove a very convenient function that has always worked. Please reapply it. Thanks for attention.
*** This bug has been confirmed by popular vote. ***
I agree with the all the others. After I decided to update to Neon version of KDE I felt completely surprised about this decision. I think is a very usefull feature and I also think there is no apparently reason for removing it. Despite the same result could be accomplished using other tools, it could even be both time-consuming and counter-intuitive. I also think it should be up to the user deciding whether this function could be visible or not, setting permissions as usual. Considering that I ask to re-introduce this feature as soon as possible.
I fully agree with the message above
*** Bug 382024 has been marked as a duplicate of this bug. ***
"they are not used on desktop anyway." sorry, this is bullshit! It's also bullshit to remove working functionality
Make KDE NM great again.
To force the people to a NetworkManager but then only pass the half of the functionality is just bad design. If you do not want to have a VLAN, Bridges or whatever, then the NetworkManager is not the right choice.
It is frustrating to see again "WONTFIX". In our office, for example, the primary connection is delivered by vlan. For us it is not a choice. in this case a major feature are broken.
Created attachment 106846 [details] bring back functionality
ok, have a look: 1. Gnome drops support cause "supported by Cockpit already" 2. You ask on kde-hardware-devel about dropping too. One persons says yes, another no: 2:1 - in my opinion this isn't "we decided"! 3. you drop support cause of "gnome do so & not used on desktop anyway" 4. 9 people says, that you brick their setups! 9 people says, that she use it on the desktop! Your argument "not used on desktop anyway" is invalid, should we use cockpit in future now, because gnome said so? I'm confused. Gnome is known for reducing functionality with every release, KDE not. But not plasma-nm, you decided to follow gnome way. I added patch from https://forums.gentoo.org/viewtopic-t-1066054.html to bring back functionality, so you have no work to bring back functionality! Please, don't ignore userbase anymore.
(In reply to Jack Prom from comment #16) > Created attachment 106846 [details] > bring back functionality Thanks for this... But yet another User patch to (potentially) re-base with every kde-plasma release. Sad times... :-(
Thanks Jack for your support. I agree with what you have said I would just add that they are not only 9 people to whom this arbitrary decision has created problems. I'm talking about the technical department of our company, we always preferred an open source approach because the official distro of our assurance department is kubuntu 16.04 while we at the tech department were excited about kde neon we have a medium sized network and for many years ( 5-6) we never had a problem (working with vlans, bridges and sometimes bonding). We have some management tools (Voip etc ...) that require a distro upgrade to work properly but until this feature would be restored for us it is counterproductive to upgrade. If we do not recover shortly, we will be forced to change distro or switch to proprietary systems :(
Hi, I'm aware that some of you may be unhappy with the change we did and sorry for not responding earlier, I had some personal stuff to do. Back to the problem, I'll try to bring this back to discussion and we will see if we are going to revert the removed support back or not. We removed it because for 99% of users this is useless and may just confuse/scare people who know nothing about those certain connections, also they kinda mess with the UI (e.g. when you use virtualbox you will end up with automatically created virbr0 connection taking place in the applet). Stay tuned. Thanks.
Then I suggest a package to install separately for adding all of this functions
(In reply to Jan Grulich from comment #20) > We removed it because for 99% of users this is useless and may just > confuse/scare people who know nothing about those certain connections. But this is no reason to completely remove the code. You can hide the creation of such Connections behind an "Expert-Mode". In this way Plasma-NM could still display existing connections without confusing the user.
(In reply to Stefan Schmid from comment #22) > (In reply to Jan Grulich from comment #20) > > We removed it because for 99% of users this is useless and may just > > confuse/scare people who know nothing about those certain connections. > > But this is no reason to completely remove the code. You can hide the > creation of such Connections behind an "Expert-Mode". In this way Plasma-NM > could still display existing connections without confusing the user. The code is still there, those connections are just filtered and not shown in the main UI.
Yes but the user now is unable to use advanced network features talked above
(In reply to Jan Grulich from comment #20) > We removed it because for 99% of users this is useless 99% based on which statistic? ;) > may just confuse/scare people who know > nothing about those certain connections This is the typical Gnome argument to remove functionality from release to release. On the contrary KDE and we love it. To going the gnome way is inconsistent and the resulting problems you see now in this bug report. For us it's broken software ;) Had you ever got bugs caused by confused people? So confused, that they can't work without the broken applet? I doubt that. > The code is still there, those connections are just filtered and not shown > in the main UI. For removing of the filters you need experience in compiling. I think this can confuse users many time more as the possibility to configure bridges or bonding.
(In reply to Jan Grulich from comment #23) > The code is still there, those connections are just filtered and not shown > in the main UI. "remove code from upstream" and "filtering" are not the same! On Gentoo is this no Problem (userpatch to "/etc/portage/patches" and its fine) but on a binary-Distribution is it no so simple.
(In reply to Jan Grulich from comment #20) > Back to the problem, I'll try to bring this back to discussion and we will see if we are > going to revert the removed support back or not. Please post here a discussion link, if one is created. Thank you!
Any news? Working with nmtui is a nightmare!
Here is the link to the mailing list where I asked: https://mail.kde.org/pipermail/kde-hardware-devel/2017-August/003878.html
> Just reverting the patches is going to be > another big visual change that might annoy someone else who will ask to > change it again. See the picture? I don't understand the logic behind this oppinion. The point to remove was another and we miss functionality. I guess, that nobody would come again to let remove functionality because she exists.
(In reply to Jack Prom from comment #30) > > Just reverting the patches is going to be > > another big visual change that might annoy someone else who will ask to > > change it again. See the picture? > > I don't understand the logic behind this oppinion. The point to remove was > another and we miss functionality. I guess, that nobody would come again to > let remove functionality because she exists. Please, reply in mail thread. To see this all.
Git commit 4634aa6e68e2e4d5a1177a3ee90a6461a9e3f44a by Jan Grulich. Committed on 31/08/2017 at 12:38. Pushed by grulich into branch 'master'. Add option to allow managing virtual connections If this option is enabled, users will see virtual connections in applet and in the connection editor and they will be able to create new virtual connections as well. This option is disabled by default as we don't want regular users to be bothered by this. M +4 -0 applet/contents/config/main.xml M +10 -0 applet/contents/ui/configGeneral.qml M +1 -0 applet/contents/ui/main.qml M +1 -0 libs/CMakeLists.txt R +20 -7 libs/configuration.cpp [from: libs/declarative/configuration.cpp - 070% similarity] R +6 -5 libs/configuration.h [from: libs/declarative/configuration.h - 077% similarity] M +0 -1 libs/declarative/CMakeLists.txt M +2 -15 libs/declarative/connectionicon.cpp M +2 -20 libs/declarative/networkstatus.cpp M +1 -0 libs/editor/CMakeLists.txt M +28 -0 libs/models/creatableconnectionsmodel.cpp M +14 -7 libs/uiutils.cpp https://commits.kde.org/plasma-nm/4634aa6e68e2e4d5a1177a3ee90a6461a9e3f44a
I think, I speak for all of us: thank you <3
It works perfectly, thanks! Neon latest version OK.