Written by okirmis the 16 Jul 12 at 15:28.

Use only texts like "Updating application (name)..." or "Installing system update..." (here without package name, would be too confusing) would make things a lot easier for newbies to understand. The Muon Software Updater in Kubuntu already shows how you can display the "real" appliction name in the updater and not the package name.

Use only texts like "Updating application (name)..." or "Installing system update..." (here without package name, would be too confusing) would make things a lot easier for newbies to understand. The Muon Software Updater in Kubuntu already shows how you can display the "real" appliction name in the updater and not the package name.

Written by puxkggn the 19 Jul 12 at 15:52.

What solution #1 does but with option to show detailed information. It should be possible for power users to see the details. A lot of newbies think hiding stuff makes them quicker/easier while they hide important information. This hiding leads to a false sense of knowing how it works. By hiding how things are going, false sense of knowing can continue to exist. While people who know what's going on know enough to not care about the details.

What solution #1 does but with option to show detailed information. It should be possible for power users to see the details. A lot of newbies think hiding stuff makes them quicker/easier while they hide important information. This hiding leads to a false sense of knowing how it works. By hiding how things are going, false sense of knowing can continue to exist. While people who know what's going on know enough to not care about the details.

Written by lionbeast the 16 Nov 08 at 17:37.

Ubuntu Brainstorm was updated in January 2009. Since the idea #15681 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #15681 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by AdemoS the 1 Nov 08 at 23:23.

I suggest getting the changes list ready BEFORE uploading the new packages to the repository pools.

I suggest getting the changes list ready BEFORE uploading the new packages to the repository pools.

Written by arckeda the 21 Dec 08 at 19:31.

Ubuntu Brainstorm was updated in January 2009. Since the idea #16709 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #16709 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by Magnes the 1 Nov 08 at 19:00.

Ubuntu Brainstorm was updated in January 2009. Since the idea #15109 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #15109 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by zago84 the 22 Nov 12 at 13:32.

I think it's really useful if during upgrade process, by a drop-down menu in the same update manager window, you can choose the behavior before the end one of them:

- no action
- restart
- turn off

I thought about a drop-down menu that allow you to change your choice at any time during upgrade. Or more simply and less invasively a drop-down menu hidden under a simple icon like a gear.

So, after starting update process, you can get away from the PC and it will do what you choose.

I think it's really useful if during upgrade process, by a drop-down menu in the same update manager window, you can choose the behavior before the end one of them: - no action - restart - turn off I thought about a drop-down menu that allow you to change your choice at any time during upgrade. Or more simply and less invasively a drop-down menu hidden under a simple icon like a gear. So, after starting update process, you can get away from the PC and it will do what you choose.

Written by mikysett the 3 Dec 12 at 16:57.

If the size of the upgrade is really big, when you click on "update" a pop-up will appear telling: "Download and install all this stuff will take a lot of time for me, perhaps you wont be there then anymore, do you want I shoot down automatically when I've done?", with "yes", "no" and "config" buttons.
With this solution you can add in the parameters the minimum size of the download to make the pop-up appear.

So people can make the choice they want without having additional buttons to care about.

If the size of the upgrade is really big, when you click on "update" a pop-up will appear telling: "Download and install all this stuff will take a lot of time for me, perhaps you wont be there then anymore, do you want I shoot down automatically when I've done?", with "yes", "no" and "config" buttons. With this solution you can add in the parameters the minimum size of the download to make the pop-up appear. So people can make the choice they want without having additional buttons to care about.

Written by Endolith the 3 Nov 08 at 14:59.

At the least, we should display the diff graphically, in the same way that tools like meld or kdiff3 display it. Click for screenshots.

We could probably just use the Meld code as a module to display the changes?

At the least, we should display the diff graphically, in the same way that tools like <a href="http://meld.sourceforge.net/meld_file1.png">meld</a> or <a href="http://kdiff3.sourceforge.net/doc/screenshot_diff.png">kdiff3</a> display it. Click for screenshots. We could probably just use the Meld code as a module to display the changes?

Written by Magnes the 1 Nov 08 at 18:47.

Ubuntu Brainstorm was updated in January 2009. Since the idea #15108 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #15108 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by Warbo the 11 Aug 08 at 03:10.

Say that a user has changed the /etc/network/interfaces file to get their connection running, and has edited /etc/X11/xorg.conf to get a tablet working. After updates to the packages which contain/control these files are made the user can be asked if their setup is still working (through the update manager originally, then as occasional popups until all questions are answered). If not then a list of potential solutions can be given (using the new config file, comparing the changes between old and new, etc. maybe even downgrading to the old package version).

I made a rather crude mockup of what I mean here http://bp0.blogger.com/_6BhjMzysLTs/RhcwYV86WOI/AAAAAAAAAAk/Pits9qYzRVY/s1600-h /UpgradeIssuesMockup.png

Some tests could be done automatically, but some cleverness would have to be employed to make sure non-networked computers aren't being thought of as broken, etc.

Say that a user has changed the /etc/network/interfaces file to get their connection running, and has edited /etc/X11/xorg.conf to get a tablet working. After updates to the packages which contain/control these files are made the user can be asked if their setup is still working (through the update manager originally, then as occasional popups until all questions are answered). If not then a list of potential solutions can be given (using the new config file, comparing the changes between old and new, etc. maybe even downgrading to the old package version). I made a rather crude mockup of what I mean here http://bp0.blogger.com/_6BhjMzysLTs/RhcwYV86WOI/AAAAAAAAAAk/Pits9qYzRVY/s1600-h/UpgradeIssuesMockup.png Some tests could be done automatically, but some cleverness would have to be employed to make sure non-networked computers aren't being thought of as broken, etc.

Written by amoalsale the 3 May 12 at 04:52.

a simple notification like
"Installing these updates will require reboot"
should be shown in advance.

a simple notification like "Installing these updates will require reboot" should be shown in advance.

Written by benoyanthony the 15 May 12 at 10:09.

Other than complete reboot, system should initiate service restart with confirmation from user.

Other than complete reboot, system should initiate service restart with confirmation from user.