"More" arrow in system menus points right but opens left

Thanks for this thoughtful bug report.

It is standard behavior, across toolkits and operating systems, that if a submenu has not enough room to open to the right, it opens to the left. (This is a slight simplification, but the exceptions don't matter here.) Ubuntu's global menu bar makes this much less likely to happen for window menus, since they start near the left edge of the screen, which leaves plenty of room to the right regardless of where the window is. But it can still happen for context menus (for example, try right-clicking near the right edge of the desktop and opening the "Create Document" submenu) or for heavily nested submenus (for example, for a subsubsubfolder with a long name in Firefox bookmarks). And, as you say, it happens for our current network and sound menus.

That it's standard toolkit behavior doesn't necessarily mean it's good behavior. It does mean, though, that any change to that behavior should be thoroughly designed and tested.

If a menu contained only one submenu, having the submenu triangle point to the left wouldn't look that bad. A submenu title is never also a checkmark or radio item, so the triangle could go in the same column that a checkmark or radio mark does. But what if a menu contains more than one submenu, and at least one of them does have room to open to the right? Should they all open to the left, just for consistency?

A bigger problem is that submenus are sometimes populated on-demand for performance reasons (see bug 771229 for example). This means that the menu doesn't "know" ahead of time how wide all of its submenus will be, which means that it can't position the triangles on the appropriate side ahead of time. For example, some Web browsers have a "Go" or "History" menu that can have thousands of icon-laden items distributed across several submenus. The top-level menu would be extremely slow to open if it had to calculate the widths of all its submenus to position their triangles first.

So, I think the most practical approach is just to minimize cases where submenus open near to the right of the screen in the first place. For example, context menus shouldn't contain submenus. Which leaves the questions of what to do with the network menu and the sound menu.

For the network menu, my design at <https://wiki.ubuntu.com/Networking#menu> does not involve any submenus at all. I suggest that the Network Manager menu adopt that design -- removing the "More networks" submenu entirely, converting any configured VPNs into switch items (replacing "Disconnect VPN") at the top level, and converting "Configure VPN…" into a "VPN Setup…" item at the top level that appears only when any VPNs are already configured.

For the sound menu, I'm wondering whether to remove the "Choose Playlist" submenu -- not solely or even primarily because it opens to the left, but just to simplify the menu in general.

There's some work that may be needed to simplify nm-applet menus, but right now I feel this remains the lesser evil than other designs we've seen (although mpt's idea of dealing differently with VPN connections are great and probably not too hard to implement). I'm not sure I want to jump into doing away with the More networks submenu as a Ubuntu diff unless absolutely necessary.

Note however, there's been some work to implement handling network connections in gnome-control-center so some of this may be on the way to be fixed too.

As a temporary measure I'll see if I can put together a patch that implements these changes and host it in a PPA if it makes sense, so we can get it tested and have a feel for how well it works.

Just reassigning to network-manager-applet since that's the correct package for the UI NM component.

I do think the "More Networks" submenu should go away, not just as an Ubuntu diff but for upstream too -- most importantly because merging it into the "Connect to Hidden Wireless Network" dialog as a general "Connect to Wi-Fi Network" would simplify the menu, secondly because a long list of non-hidden networks in the dialog would be easier to handle than a submenu, thirdly because it would avoid the weirdness of a submenu opening to the left, fourthly because it would avoid the weirdness of two lists that are individually alphabetically sorted despite being subsets of the same list, and fifthly because it would scale better in the edge case where there are more wi-fi networks around than even a submenu can show without scrolling.

Jeremy, at this point I'm not inclined to change the playlist submenus in the sound menu. But if you'd like that considered separately, I suggest reporting it separately so this bug report can focus on the network menu.

Wishlist -> to be brought up with upstream; we might go that way anyway to kind of follow the line of how things are setup in the control center now.