Ambiguous wording in confirmation alert box

The judgement of computers cannot ever be fully relied on...

I'm not sure which wording would be better. I would like it if people who don't know what they do would not accidentally remove packages by mistake, and thus I chose a fairly severe wording.

I'll be happy to reconsider the wording for karmic. For jaunty, we're past the string freeze, so any changes to it would require a freeze exception, and I'm not currently sure it's worth it. I'm happy to be convinced otherwise by enough people telling me they really hate the current wording.

This one is waiting to be fixed, do we like the initial proposal, or does the message need to articulate the warning more strongly?

I'm not sure the "Are you sure you want to remove these packages?" will help either, but then again, I would call the entire janitor a papercut. A user seeing that message will probably be afraid too and close the janitor. That is a lot more likely than the user starting to googling every package to check if it's safe to remove. I have said so before, and say it again; the computer janitor should not even offer to remove packages the user needs! How do we know what the user needs? He probably wants to keep the manually installed packages at least..?

I agree with Åskar. I raised the dupe of this bug - my main problem with Janitor is that either it needs to take responsibility and just remove the packages with confidence, or it should provide all the info that the user needs (in a form the user understands) to make the decision. Saying 'Are you sure?' is pointless.

Very well, let's remove janitor. I am not ever confident enough to say that specific packages are always safe to remove.

I think Janitor should remain, but there needs to be a way to differentiate between user created cruft (manual packages) and system created cruft.

Perhaps having a history of changes would help (with the ability to rollback/reinstall). Then users could be more confident knowing that, should things go wrong, they can always come back and click undo. This somewhat relies on the assumption that users who don't know what they are doing would stick to software from repos, which could easily be reinstalled, but if less technical users are being forced to manually install debs then that sounds like another paper cut.

Design suggestion:
  * See attached mockup.

Design suggestion (revised):
  * See attached mockup.

Mockup reflects change in wording (in labels and on buttons) only.

I'll take a look at it. If not heard from me in a day I didn't have the time.

I am still convinced that until there is a reliable way to detect packages that are safe to remove (and solve the halting problem), toning down the wording such that people will (again) remove packages they want to keep and thereby break their systems is a bad idea. I don't wish that to happen.

So, should I change the text?

I don't think we've "toned down" the text. We give the user fair warning that removing packages can cause errors, and we ask for an administrator's password. In lieu of solving the halting problem, Marcus, please proceed.

After running the application I'm not sure if we should call it "remove packages" as it's not only packages that will be removed. As in my attached screenshot - it also shows a file that will be removed.

However, I've created a patch with the new text.

Please review the patch as I'm not that sure of the correct way to set buttons text/icon.
Also if no packages is selected - the message is just: "Do you want to continue?"

If I'm reading the patch correctly, it seems that you're changing the response types in the buttons but not in the actual dialog response handling.

dialog = self.gtk.MessageDialog(parent=self.window_main,
                                         type=self.gtk.MESSAGE_WARNING,
- buttons=self.gtk.BUTTONS_YES_NO,
+ buttons=self.gtk.BUTTONS_NONE,
                                         message_format=msg)

The response types were GTK_RESPONSE_YES and GTK_RESPONSE_NO before..

+ dialog.add_button(self.gtk.STOCK_CANCEL, self.gtk.RESPONSE_CLOSE)
+ remove = dialog.add_button(self.gtk.STOCK_OK,self.gtk.RESPONSE_YES)

And here the buttons added use GTK_RESPONSE_YES and GTK_RESPONSE_CLOSE.

If I'm not missing anything here, the cancel response code is not important.

The rest of the code goes on with this;

        dialog.show_all()
        response = dialog.run()
        dialog.hide()
        if response != self.gtk.RESPONSE_YES:
            self.update_sensitive()
            return

        cleaner = Cleaner(self, crufts, self.pm.get_plugins())
        cleaner.start()

Okay cool, I didn't look at the full code only the patch. I'm at Guadec and the network isn't responding very well, so I never got to respond to your actual question.. so here is my only other thought on the patch.

+ #FIXME: is there a better way to set the title AND have a stock icon?
+ remove.get_children()[0].get_children()[0].get_children()[1].set_label(_("_Remove Packages"))

There's not really a way to change the text in a more direct way without messing up the icon (because conceptually, stocks are really "icon + text" combinations so using button_new_from_stock is really just a convenience function), but if you want to do something a little less cryptic looking (although maybe with a bit more code) you could do something to the effect of:

void set_button_text_and_icon (GtkButton *button, gchar *stock_id, gchar *label)
{
   gint image_spacing;

   gtk_widget_style_get (GTK_WIDGET (button),
                           "image-spacing", &image_spacing,
                           NULL);
   hbox = gtk_hbox_new (FALSE, image_spacing);

   image = gtk_image_new_from_stock (GTK_STOCK_CANCEL);
   gtk_box_pack_start (hbox, image, FALSE, FALSE, 0);

   label = gtk_label_new (_("_Remove Packages"));
   gtk_box_pack_start (hbox, label, FALSE, FALSE, 0);

   gtk_widget_show_all (hbox);
   gtk_container_add (GTK_CONTAINER (button), hbox);
}

Sorry, I'm not familar with pygtk so this is the best I can offer. It's up to you, this is just a suggestion that I think makes the code a little bit more obvious in my opinion.

I personally would prefer to do something like this:

button = gtk.Button(_("_Remove Packages"))
image = gtk.image_new_from_stock(gtk.STOCK_CANCEL, gtk.ICON_SIZE_BUTTON)
button.set_image(image)
dialog.add_action_widget(button, gtk.RESPONSE_CANCEL)

Just my personal preference though.

Thanks Matt, that looks much better. I'll change my patch later.

As a snew Ubuntu user (non-programmer), I like David Siegel's mock-up on post #10 best.

Matt, I tried your code but the button gets higher than the cancel button, see attached screenshot. Why?

Hmm, I just tried it and the buttons were the same size for me. Maybe something like this will work better?

button = dialog.add_button(_("Remove Packages"), self.gtk.RESPONSE_YES)
image = self.gtk.image_new_from_stock(self.gtk.STOCK_OK, self.gtk.ICON_SIZE_BUTTON)
button.set_image(image)

I have no idea why the size would be different; I'd never heard of either method changing the button size.

Thanks, that worked! :-)
Updated patch.

Replacing the text "Really clean up" with "Are you sure you want to remove these packages?" is wrong. The janitor does not just remove packages.

Note also that I'm replacing the entire UI with a new design and implementation, see the lp:~systemcleaner-hackers/systemcleaner/new-ui branch.

Lars, will your updated UI land in Karmic?

David, yup, once I polish it some more and get back home.

Awesome. Please update this bug when it does.

I've uploaded the new UI with a hopefully acceptable new dialog to my PPA

https://launchpad.net/~liw/+archive/ppa

The upload is still processing as I'm writing this, the version of interest has ppa5 at the end.

The issue is more complicated than the mockups that have been posted in this bug allow for. CJ does not only remove packages, it does other kinds of things as well. That's why all wording specific to package removal needs to be adjusted if there's other stuff happening as well.

However, I'm capitulating and accepting the toned down wording. I expect this will cause a few people removing stuff they shouldn't, but I don't expect to have to deal with the bugs after karmic so I don't have the energy to stand my ground on this issue, either.

This bug was fixed in the package computer-janitor - 1.13.2-0ubuntu1

---------------
computer-janitor (1.13.2-0ubuntu1) karmic; urgency=low

  * New upstream version. Closes bugs in Launchpad:
    - System cleaner removes explicitly installed third-party packages
      (LP: #285746)
    - I do not want to remove '/' (LP: #337241)
    - computer-janitor incomplete error description (LP: #365325)
    - computer-janitor commandline interface not pipe-friendly (LP: #375094)
    - Python 2.6 DeprecationWarning: Accessed deprecated property
      Package.candidateDownloadable (LP: #407127)
    - Should use GtkBuilder rather than libglade (LP: #403537)
    - Ambiguous wording in confirmation alert box (LP: #349336)
    - computer-janitor-gtk crashed with UnicodeDecodeError in
      get_description() (LP: #352461)
    - Can't deselect fixes with space in computer-janitor (LP: #355535)
    - relatime tweak will not be necessary in karmic (LP: #369151)
    - computer janitor needs filesize column (LP: #396522)
  * Packaging now uses dh from debhelper 7.

 -- Lars Wirzenius <email address hidden> Fri, 21 Aug 2009 15:48:12 +0300

I'm perplexed by this bug.

To sum up things, a user with a perfectly working system may ask Computer Janitor to do some cleanup. Then Computer Janitor will suggest to remove some packages. If the user decides to follow this advice, Computer Janitor will then warn him : "Hey ! Don't play fool you may break everything"

It's unfair that Computer Janitor gives non-reliable advices and ask user to assume all responsibility.
I don't think that replacing a warning (« This may break your system, if you need them. ») by another (« Removing packages that are still needed can cause errors. ») can be called a bugfix

Computer Janitor should be secured or removed

@antistress:
This bug report is about the ambiguous wording in the app. Hence that was fixed...
What you mention is the subject for a separate bug report. Kindly open a separate bug report.

ok, that's bu#482647