Contributor cparker15
Allow Editing Gnome Menu Items from Inside the Menu
Written by rouge568 the 29 Feb 08 at 00:39.
Global category: System.
Won't implement
As of now, if one wants to add/edit a menu item, one has to right-click on the gnome menu title bar, select to edit the menu, and then navigate through another hierarchy. It would be much simpler to add an option to "edit this item" or "add a new menu item" through right-click when you are navigating the menu normally.
edit: Also moving items in menu just by drag and drop.
1568
votes
1856
3
288
39
votes
44
6
5
Solution #2:
Integrate current "edit menu" dialog with the applications menu
When you right-click on a submenu's menu item, it should not close the submenu. Instead, it should bring up a context menu with additional options to edit this submenu in the menu editor, and to hide this submenu (as well as the existing options you would get from right-clicking on a menu item within that sub-menu).
For a menu item, add extra context menu options to edit this menu item in the menu editor, to directly edit the menu item's launcher's properties, and to hide the menu item.
It should also be possible to drag menu items (including entire sub-menus), within each menu. Additionally, each sub-menu item should have a "lock to menu" checkbox option on its context menu to prevent it from being dragged (similar to panel items' "lock to panel" checkbox option).
It may even be possible to use panels and drawers to build the menus and use common code to handle the behaviour of both consistently.
The edit menus item would still be needed to remove items, and would still be useful for "bulk" changes where the user may not want to open the applications menu each time.
When you right-click on a submenu's menu item, it should not close the submenu. Instead, it should bring up a context menu with additional options to edit this submenu in the menu editor, and to hide this submenu (as well as the existing options you would get from right-clicking on a menu item within that sub-menu).
For a menu item, add extra context menu options to edit this menu item in the menu editor, to directly edit the menu item's launcher's properties, and to hide the menu item.
It should also be possible to drag menu items (including entire sub-menus), within each menu. Additionally, each sub-menu item should have a "lock to menu" checkbox option on its context menu to prevent it from being dragged (similar to panel items' "lock to panel" checkbox option).
It may even be possible to use panels and drawers to build the menus and use common code to handle the behaviour of both consistently.
The edit menus item would still be needed to remove items, and would still be useful for "bulk" changes where the user may not want to open the applications menu each time.
-7
votes
4
5
11
Solution #3:
"Unlock" the menu for allowing drag and drop
Written by
leael the 18 Apr 09 at 13:48.
To be consistent with the panels, the user has to unlock the menu in order for the drag'n'drop to become possible. Possible implementations could be a global "Unlock Menu Elements" or better "Allow Dragging of Menu Elements".
To be consistent with the panels, the user has to unlock the menu in order for the drag'n'drop to become possible. Possible implementations could be a global "Unlock Menu Elements" or better "Allow Dragging of Menu Elements".
7
votes
9
4
2
Solution #4:
Use the context menu for each item with "Move"
Written by
leael the 18 Apr 09 at 13:58.
To be consistent with the panels, each item gets an "Move" entry in its context menu, thus locking the item in the mouse and let the user drag it to other locations as also into submenus, until the mouse button is clicked again.
To be consistent with the panels, each item gets an "Move" entry in its context menu, thus locking the item in the mouse and let the user drag it to other locations as also into submenus, until the mouse button is clicked again.
212
votes
251
13
39
Selected solution (#1):
Change name to "Wired Network 1"
Written by
samtatr the 22 Feb 11 at 11:43.
This would make it more obvious as to what it does, and looks a lot cleaner when the notification pops up too. This has already been done for wireless networks (e.g. "Connected to NETGEAR"), so it shouldn't be too hard for wired ones.
This would make it more obvious as to what it does, and looks a lot cleaner when the notification pops up too. This has already been done for wireless networks (e.g. "Connected to NETGEAR"), so it shouldn't be too hard for wired ones.
7
votes
56
28
49
Selected solution (#2):
Change name to "Ethernet Connection 1"
Because a network can represent a lot of things (mostly external to the computer) and don't accurately represent a computer's NIC, I'm proposing "Ethernet Connection" to be more precise while maintaining simplicity.
Call it what it is (or what the 802.3 spec calls it) but make it more recognizable to users (ie, don't start indices at 0).
Because a network can represent a lot of things (mostly external to the computer) and don't accurately represent a computer's NIC, I'm proposing "Ethernet Connection" to be more precise while maintaining simplicity.
Call it what it is (or what the 802.3 spec calls it) but make it more recognizable to users (ie, don't start indices at 0).
-107
votes
3
6
110
Selected solution (#3):
"WiredNet 1"
Written by
sivanmyl the 5 Mar 11 at 05:00.
Combined word looks more attractive while easy to understand.
Combined word looks more attractive while easy to understand.
10
votes
47
9
37
Selected solution (#4):
Leave the name Auto eth0 but add a description
Written by
phix the 7 Mar 11 at 21:47.
Names are important, especially because commandline tools use the real name of the connection, Auto eth0. It's simple, symbolic, and descriptive. A longer name runs the risk of sounding dumbed-down and vague, like the dreaded "Wireless Connection 2" nonsense from windows. A description keeps the name short, while providing new users more information.
If the user had to do anything through the command line later on, they'll already be used to seeing "auto eth0" as their wired connection.
Names are important, especially because commandline tools use the real name of the connection, Auto eth0. It's simple, symbolic, and descriptive. A longer name runs the risk of sounding dumbed-down and vague, like the dreaded "Wireless Connection 2" nonsense from windows. A description keeps the name short, while providing new users more information.
If the user had to do anything through the command line later on, they'll already be used to seeing "auto eth0" as their wired connection.
-37
votes
18
6
55
Selected solution (#5):
Change Name to "Wired Network eth0"
This is a mix of Solution #1 and #4
This is a mix of Solution #1 and #4
-10
votes
30
7
40
Selected solution (#6):
Name the wired connection: "Wired Network (Auto eth0)"
Written by
turbolad the 8 Mar 11 at 11:13.
Newbies see "Wired Network" and advanced users see "Auto eth0" in brackets/parenthesis.
I explain in the comments why this helps EVERYONE.
Newbies see "Wired Network" and advanced users see "Auto eth0" in brackets/parenthesis.
I explain in the comments why this helps EVERYONE.
-1
votes
0
0
1
Selected solution (#7):
Combine network type, profile and interface name
Written by
mtrudel the 24 Mar 11 at 16:08.
I'm suggesting the name of the profile to be something like "Default". It should not be tied to any particular adapter.
This way, any new connection use that profile which will have default settings to use DHCP and the usual (as Auto eth0 is set). All adapters could share it, so adding a new interface to a computer would still just "work".
For notifications, I suggest the following changes:
- The title should mention "Wired network", and probably the same of the interface (eth0 in most cases).
- The text of the notification should say:
Connection established, using profile "Default"
or whatever profile in use.
I'm suggesting the name of the profile to be something like "Default". It should not be tied to any particular adapter.
This way, any new connection use that profile which will have default settings to use DHCP and the usual (as Auto eth0 is set). All adapters could share it, so adding a new interface to a computer would still just "work".
For notifications, I suggest the following changes:
- The title should mention "Wired network", and probably the same of the interface (eth0 in most cases).
- The text of the notification should say:
Connection established, using profile "Default"
or whatever profile in use.
0
votes
0
0
0
Selected solution (#8):
Add a 'DESCRIPTION' field to udev
Interface names like 'eth0' and 'wlan0' are assigned by udev based on the interface's mac address (or other criteria you can specify in /etc/udev/rules/d).
Machine-readable interface names (like 'eth0') are an essential part of making networking work properly, and messing with the structure of those names is opening a can 'o bugs.
But *adding* an additional human-readable field (DESCRIPTION=='ethernet jack') makes the human-readable name accessible to all network applications. It also means the name is user-editable without upsetting the whole network stack.
So Network manager can show 'ethernet jack' (description) instead of 'eth0' (name). And the name can be changed by the user (or script) at any time, for example to match the name of the current network ('SpamNet [ethernet]')
Interface names like 'eth0' and 'wlan0' are assigned by udev based on the interface's mac address (or other criteria you can specify in /etc/udev/rules/d).
Machine-readable interface names (like 'eth0') are an essential part of making networking work properly, and messing with the structure of those names is opening a can 'o bugs.
But *adding* an additional human-readable field (DESCRIPTION=='ethernet jack') makes the human-readable name accessible to all network applications. It also means the name is user-editable without upsetting the whole network stack.
So Network manager can show 'ethernet jack' (description) instead of 'eth0' (name). And the name can be changed by the user (or script) at any time, for example to match the name of the current network ('SpamNet [ethernet]')
remove need to always crank down/up volume for headphone use
Written by kiko_ubuntu the 26 Feb 11 at 21:34.
Global category: Hardware support.
Implemented
When switching to headphone use, the computer/laptop already detects the change and mutes the speakers. Why not nudge the volume at the same time so users don't get sound-blasted every time?
When you drag the slider with headphones plugged the level is remembered, same goes for unplugged volume. They are just stored independently internally and restored on the switch.
There should be very few use cases where the user wants to adjust headphone volume when not actually having the headphones on at the time (and vice versa).
In a sense this is an invisible change, but it's the kind of thing that sets good products apart.
Simple, useful, very Ubuntu.
You know it makes sense. Thanks for the support.
Add WiMAX switcher to the Network Manager
Written by Oleksa the 17 Feb 11 at 21:03.
Related project: Network Manager .
In development
WiMAX wireless connection becomes more popular and wide spread, however it is not supported in Ubuntu. Currently, if you succeed to set up the drivers, it can be seen as Ethernet wmx0 connection.
47
votes
48
11
1
Selected solution (#1):
Add special user interface for WiMAX connections
Written by
Oleksa the 17 Feb 11 at 21:03.
I propose to add a special user interface for the WiMAX wireless network connection to the Network Manager similar to wifi, when a user can switch on/off, get specific information about the signal level, close base station, set up IP address, try to locate existing channels (providers), share the connection with others, possibility to change the power mode for the device etc. A special tab should be added in the Network Manager, as well.
Related link:
http://cgit.freedesktop.org/NetworkManager/NetworkManager
I propose to add a special user interface for the WiMAX wireless network connection to the Network Manager similar to wifi, when a user can switch on/off, get specific information about the signal level, close base station, set up IP address, try to locate existing channels (providers), share the connection with others, possibility to change the power mode for the device etc. A special tab should be added in the Network Manager, as well.
Related link: http://cgit.freedesktop.org/NetworkManager/NetworkManager
Update manager tries to update even without internet connection
Written by mydoghasworms the 10 Feb 11 at 19:04.
Related project: Update manager .
Implemented
When you have no Internet connection, update manager or synaptic will still try and connect, giving you a list of warnings for each package.
This can be confusing for many users.
In fact, this could happen if you use your laptop at work and forget to switch off the proxy settings. So there could be several causes. A bunch of errors telling you that something could not be downloaded is unhelpful and unfriendly.
234
votes
240
9
6
Selected solution (#1):
Check if there is internet, if not, tell the user
As a general rule, I think one ought to try avoid throwing up a lot of errors where a friendly message could tell you what the matter is.
What is the harm in stating the obvious to the user: "You cannot update because you are offline". It's way more elegant that throwing a bunch of errors in someone's face.
If there is no Internet connection, tell the user, so that there is no guesswork as to why packages could not be downloaded.
As a general rule, I think one ought to try avoid throwing up a lot of errors where a friendly message could tell you what the matter is.
What is the harm in stating the obvious to the user: "You cannot update because you are offline". It's way more elegant that throwing a bunch of errors in someone's face.
If there is no Internet connection, tell the user, so that there is no guesswork as to why packages could not be downloaded.
70
votes
81
14
11
Selected solution (#2):
Not just for Update Manager, but all apps should have the feature in Solution #1
This isn't just a problem for Update Manager, but also for Firefox and just about any other App that requires an Internet connection.
If Ubuntu isn't connected and Firefox is opened, instead of showing an error, Firefox (or Update Manager, or any other app) should just show a list of available connections for the user to choose.
This isn't just a problem for Update Manager, but also for Firefox and just about any other App that requires an Internet connection.
If Ubuntu isn't connected and Firefox is opened, instead of showing an error, Firefox (or Update Manager, or any other app) should just show a list of available connections for the user to choose.
15
votes
17
3
2
Selected solution (#3):
Check if destination server is reachable (modified solution 1)
Written by
mat128 the 9 Mar 11 at 15:24.
Instead of simply checking if you are online, check if you can access the servers listed in the configuration. If access is impossible (servers are down, you are offline, or anything else), simply tell the user and offer him the possibility to retry.
Instead of simply checking if you are online, check if you can access the servers listed in the configuration. If access is impossible (servers are down, you are offline, or anything else), simply tell the user and offer him the possibility to retry.
Solution #1:
Add a "take photo now" option
When you go to change the user account picture (system--> Preferences--> about me) and click to change the icon, a nautilus file browser pops up, and allows you to choose a picture.
I think it would be good to have a "Take a picture now" option, that uses the webcam to take a picture. If the user likes it, it could be used as the account picture. If the user doesn't like it, another picture could be taken (discarding all previous attempts) until the user is happy. They could cancel at any time.
When you go to change the user account picture (system--> Preferences--> about me) and click to change the icon, a nautilus file browser pops up, and allows you to choose a picture.
I think it would be good to have a "Take a picture now" option, that uses the webcam to take a picture. If the user likes it, it could be used as the account picture. If the user doesn't like it, another picture could be taken (discarding all previous attempts) until the user is happy. They could cancel at any time.
Evolution needs integration with Empathy
Written by CydeSwype the 27 Jul 09 at 19:14.
Related project: Evolution Mail and Calendar .
New
Evolution currently has an option to sync with Pidgin but Pidgin is going away as the default messenger client as of 9.10. As a result, people who like the "sync with pidgin" feature will feel pretty left out when they start using the default email application and wondering why it doesn't play nice with the default IM client.
The option for the pidgin sync is under preferences > mail preferences > automatic contacts and is labeled "Synchronize contact info and images from Pidgin buddy list"
This will be very useful when working on 2 or more monitors
Written by jerzyo the 1 Feb 11 at 06:53.
Related project: Gnome .
Already implemented
1. I usually work on 4 Virtual desktops and 2 monitors. 1 desktop is my email and communictator. When I switch between 3 other screens I cannot see what's on my email.
The same issue I have when I work on Virtual Machines, when I do something that requires a lot of computation. I'd like to stick it to an external monitor on my laptop and be able to do whatever I want on my laptop screen.