Current status is that the panel shows two "Wired" entries in the list, each of which shows the state of one of the connections, but with no indication anywhere of which entry corresponds to which device (other than the Hardware Address)

Maybe a reasonable thing to do would be to show the interface name in this case, identifying them as "Wired (eth0)" and "Wired (eth1)"?

We could also show the device names somewhere like the menu does (see screenshot on bug 677142), though that's less useful in a machine with multiple identical ethernet cards, which is probably the more common case...

Created attachment 222564 [details] [review]
network: use interface names to disambiguate devices of same type

here's a patch that implements the above suggestion

Review of attachment 222564 [details] [review]:

::: panels/network/panel-common.c
@@ +141,3 @@
+                 * (non-localized) interface name, like "eth0".
+                 */
+                return g_strdup_printf (C_("device name", "%s (%s)"),

Do we really need to localize "%s (%s)" ?

Looks ok in principle. I wonder if we want the strings to be the same in the network menu and the panel, though.

(In reply to comment #3)
> Do we really need to localize "%s (%s)" ?

I dunno, translators might want to use localized parentheses or something?

I suppose since it's string semi freeze now anyway we could just not translate it and see if anyone complains.

(In reply to comment #5)
> (In reply to comment #3)
> > Do we really need to localize "%s (%s)" ?
> 
> I dunno, translators might want to use localized parentheses or something?
> 
> I suppose since it's string semi freeze now anyway we could just not translate
> it and see if anyone complains.

I think that would be my preference.

*** Bug 681533 has been marked as a duplicate of this bug. ***

Created attachment 222931 [details] [review]
network: Rename "Wireless" to "Wi-Fi" in the UI

We support multiple kinds of wireless networks; clarify which kind
we're talking about here.

Also, add "Wi-Fi" and "Wifi" to the desktop file search keywords
(leaving "Wireless" there as well).

Created attachment 222932 [details] [review]
network: Rename "Wired" to "Ethernet" and prepare for other types

Change "Wired" to "Ethernet" in the UI.

Likewise, rename NetDeviceWired to NetDeviceEthernet, but split out
most of the code into a new NetDeviceSimple superclass that can later
be used for other device types that we provide only minimal UI/support
for.

Created attachment 222933 [details] [review]
network: use interface names to disambiguate devices of same type

eg, if there are two ethernet devices, call them "Ethernet (eth0)" and
"Ethernet (eth1)" instead of calling them both just "Ethernet".

(In reply to comment #9)
> Created an attachment (id=222932) [details] [review]
> network: Rename "Wired" to "Ethernet" and prepare for other types
> 
> Change "Wired" to "Ethernet" in the UI.
> 
> Likewise, rename NetDeviceWired to NetDeviceEthernet, but split out
> most of the code into a new NetDeviceSimple superclass that can later
> be used for other device types that we provide only minimal UI/support
> for.

Really don't like that change. The backend name change is fine, but for 99% of our users, there's only one type of wired, and it's Ethernet. If you had Infiniband or whatever other wired type, then name those devices by their real name, but changing "Wired" to "Ethernet" is unhelpful.

(In reply to comment #10)
> Created an attachment (id=222933) [details] [review]
> network: use interface names to disambiguate devices of same type
> 
> eg, if there are two ethernet devices, call them "Ethernet (eth0)" and
> "Ethernet (eth1)" instead of calling them both just "Ethernet".

What about using the name of the device? Or the connection type (Built-in vs. USB vs. ...)?

My argument in bug 681532 was "even Apple calls it Ethernet".

Anyway, this is what Allan's current design shows. Whatever decision is made here needs to stay in sync with bug 677142.

(In reply to comment #11)
> If you had
> Infiniband or whatever other wired type, then name those devices by their real
> name, but changing "Wired" to "Ethernet" is unhelpful.

Note that most machines with InfiniBand will have Ethernet too (since basically all motherboards have onboard Ethernet these days), so you'd have both "Wired" and "InfiniBand" in the list. (Unless we changed it to say "Wired" when you only had Ethernet devices, and "Ethernet" otherwise, which was also suggested at some point.)

(In reply to comment #12)
> > eg, if there are two ethernet devices, call them "Ethernet (eth0)" and
> > "Ethernet (eth1)" instead of calling them both just "Ethernet".
> 
> What about using the name of the device? Or the connection type (Built-in vs.
> USB vs. ...)?

I guess there are 2 major cases:

  - machine has multiple identical NICs. (eg, server-class machines)
  - machine has one built-in NIC plus a single additional PCI, USB, or
    CardBus NIC

I chose interface name because it's the only thing that works to differentiate the NICs in the first case, but yeah, it isn't all that great for the second case. I guess we could show interface names iff there would be two devices that would otherwise have the same name based on whatever other rules we use.

Device names are what nm-applet and gnome-shell use in 3.4, but they suck. My onboard NIC is "Intel 82579LM", which means nothing to anyone. My USB NIC identifies itself as an "ADMTek USB To LAN Converter", which does at least have the word "USB" in it, although that's the *only* word it has in common with what's actually written on the device ("Belkin USB 10/100 Ethernet").

"Built-in" vs "USB" is nice. Do we have a reliable way of knowing that a device is built-in?

(In reply to comment #13)
> My argument in bug 681532 was "even Apple calls it Ethernet".
<snip>
> "Built-in" vs "USB" is nice. Do we have a reliable way of knowing that a device
> is built-in?

Not as such. We can find USB ethernet adapters, we can find DisplayPort or PC-Card ones. Still, that's another layer of policy we can use to get that name.

The majority use case of "one ethernet, one wifi" should be the one we target, and then make the distinction possible, with the minimum amount of data.

See bug 678360

From bug 678360 comment 8:
"
I would rather that the differentiation was:
- first through type:
Wired
Wired
becomes:
Ethernet
Infiniband

- secondly through connection type:
Ethernet
Ethernet
becomes:
USB Ethernet
PCI Ethernet

- thirdly through vendor/product:
PCI Ethernet
PCI Ethernet
becomes:
Intel Ethernet
Realtek Ethernet

Finally through using interface names:
Intel Ethernet
Intel Ethernet
becomes:
Intel Ethernet (eth0)
Intel Ethernet (eth1)
"

We'll show the interface in the details page.

(In reply to comment #16)
> From bug 678360 comment 8:
...

Makes sense to me.

*** Bug 678360 has been marked as a duplicate of this bug. ***

Created attachment 225288 [details] [review]
network: Rename "Wireless" to "Wi-Fi" in the UI

We support multiple kinds of wireless networks; clarify which kind
we're talking about here.

Also, add "Wi-Fi" and "Wifi" to the desktop file search keywords
(leaving "Wireless" there as well).

Created attachment 225289 [details] [review]
network: Factor out most of NetDeviceWired, create NetDeviceEthernet

Rename NetDeviceWired to NetDeviceEthernet, but split out most of the
code into a new NetDeviceSimple superclass that can later be used for
other device types that we provide only minimal UI/support for.

Created attachment 225290 [details] [review]
network: disambiguate devices of the same type

If there are multiple devices that would end up with the same name in
the device list, disambiguate their names (in increasingly geeky ways,
as needed).

For full functionality (specifically, being able to distinguish via USB vs PCI), this requires the danw/client-bus branch of NetworkManager. (It will compile with the released NM, it just won't have the USB vs PCI functionality.) It would be possible to do that check in control-center itself, by using gudev directly (which it already depends on indirectly via libnm-glib anyway), but I didn't...

Bastien's example talked about disambiguating by "product", but his examples only used the vendor name, and that's what I implemented here, because "Intel Corporation 82579LM Gigabit Network Connection Ethernet" doesn't really fit very well in the list...

libnm-glib has a bunch of code that handles name fixups if that's what you're looking for; it's completely localization ignorant but since all that information about "Intel Corporation XXX Gigabit" comes from pciids and usbids, the source is completely unlocalized anyway.

I'm not specifically against adding a "bus" property, but keep in mind that not all network devices are attached with a "bus".  On more embedded systems there will often be custom interfaces (even on-chip SoC lines) which are not busses, but point-to-point.

So I would rather go with "subsystem" or something like that, based not on the net interface, but the parent or grandparent.  There's already code in NM that figures that out by walking up the hierarchy (up the the grandparent) to find out the actual physical subsystem.

Next problem is that virtual devices like bridges, bonds, TAP/TUN devices, IPSec tunnels, and also some embedded drivers are actually "virtual" and have no real hardware backing.  So these either won't have a subsystem/bus or will have one called "virtual".

Honestly, what you *really* want here is internal vs. external, right?  What you're really trying to show is whether it's built-in or not, it seems.  While that's pretty hard to figure out these days (though the kernel can now tell you whether USB devices are internal or external, and we may be able to figure out if the PCI-E slots are internal or not) using the bus type seems like a kludge.

Another case where this breaks down is ExpressCards.  They're also 'pci' just like internal devices.

That's the point; the bus doesn't matter, it's whether or not the device is removable, I suppose, and these days we have a good chance of figuring that out from the kernel.  That's if the internal/external distinction actually makes sense in the first place...

But also, we don't necessarily have to patch NM for this, given that NM already provides the sysfs path of the device in the "Udi" property, which means you can pass that directly to g_udev_client_query_by_sysfs_path(), I think, and then the client can do whatever they want with that data for presentation.

But if we feel like internal/external is something that is useful, then there are a couple of ways to deal with that which might make more sense than putting that logic into NM, like making sure the kernel has a good interface for figuring that out (or that udev provides that info) before we start adding proxies for the thing we really want to the NM D-Bus interface.

Created attachment 225714 [details] [review]
network: disambiguate devices of the same type

If there are multiple devices that would end up with the same name in
the device list, disambiguate their names via new libnm-gtk API.

(requires libnm-gtk from git-master network-manager-applet)

Looks good to me. Are we going to use the same function in the shell menu, so we get the same strings in both places.

yes, see bug 677142 (though after attaching it I realized that there are supposed to be other UI changes there too)

Dan, which one of those patches am I supposed to apply then (having problems applying to master)? Can you also make sure that the required versions for libnm-gtk gets bumped?

Created attachment 226201 [details] [review]
network: Rename "Wireless" to "Wi-Fi" in the UI

We support multiple kinds of wireless networks; clarify which kind
we're talking about here.

Also, add "Wi-Fi" and "Wifi" to the desktop file search keywords
(leaving "Wireless" there as well).

Created attachment 226202 [details] [review]
network: Factor out most of NetDeviceWired, create NetDeviceEthernet

Rename NetDeviceWired to NetDeviceEthernet, but split out most of the
code into a new NetDeviceSimple superclass that can later be used for
other device types that we provide only minimal UI/support for.

Created attachment 226203 [details] [review]
network: disambiguate devices of the same type

If there are multiple devices that would end up with the same name in
the device list, disambiguate their names via new libnm-gtk API.

oops, apparently I hadn't "git pull"ed since late August... rebased patches attached. Still needs a configure.ac update.

I added some more keywords to the list. The patches seem to work fine for me, I've tested with a USB ethernet adapter being plugged into my desktop, and it shows both a PCI and a USB Ethernet, which is what I would be expecting (though they were labelled "Ethernet" and not "Wired" but I'll live with that).

Attachment 226201 [details] pushed as 9e5a8eb - network: Rename "Wireless" to "Wi-Fi" in the UI
Attachment 226202 [details] pushed as 71c0325 - network: Factor out most of NetDeviceWired, create NetDeviceEthernet
Attachment 226203 [details] pushed as 6375645 - network: disambiguate devices of the same type

(In reply to comment #33)
> shows both a PCI and a USB Ethernet, which is what I would be expecting (though
> they were labelled "Ethernet" and not "Wired" but I'll live with that).

That's how you put it in your examples above. And "USB Wired" doesn't really sound right anyway...

(In reply to comment #34)
> (In reply to comment #33)
> > shows both a PCI and a USB Ethernet, which is what I would be expecting (though
> > they were labelled "Ethernet" and not "Wired" but I'll live with that).
> 
> That's how you put it in your examples above. And "USB Wired" doesn't really
> sound right anyway...

My mistake, never mind.