Bug 194025 - Enhancements to the platform Clean... dialog
Summary: Enhancements to the platform Clean... dialog
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.4 M6   Edit
Assignee: Paul Webster CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
: 210959 214342 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-22 14:33 EDT by Mark Melvin CLA
Modified: 2013-08-21 05:57 EDT (History)
7 users (show)

See Also:


Attachments
Patch implementing build only selected projects functionality (18.16 KB, patch)
2007-10-26 13:17 EDT, Mark Melvin CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Melvin CLA 2007-06-22 14:33:43 EDT
Currently the Clean... dialog allows you to clean the entire workspace, or a subset of projects.  If autobuild is enabled, then a build will automatically be triggered on those projects after the clean.  If autobuild is *disabled*, then there is a checkbox shown in the Clean... dialog that says "Start a build immediately", which always rebuilds the entire workspace whether you are cleaning the entire workspace or a subset of projects.  However, this is rather non-intuitive way for *some* builders - in particular builders that are Ant or make-like in nature.  One might argue that this behaviour is correct in the platform sense in that the cleaned projects are built "fully" and the rest of the projects in the workspace are built "incrementally".  However, there is an edge case here that I feel is being missed and I think it can be met with a simple improvement the dialog.  Currently, the dialog does not meet the requirements of a user with an Ant/make-like build that always runs with autobuild turned OFF and simply wants to do a "Clean and immediate rebuild" of a selected set of projects.  This is currently impossible to do in one action.

So, I would propose the following behaviour change that I think would satisfy
everyone:

With autobuild ON:
- There is no issue as there is no checkbox.

With autobuild OFF:
- If the user selects "Clean all projects", then the current behaviour is fine.
 A single *option* should be shown allowing the user to trigger a rebuild of the
entire workspace or not.

- If the user selects "Clean projects selected below", then I think one of the
following should be done:

  a) Leave a single option and change the behaviour to only rebuild the
selected projects.  I would also change the description of the checkbox in this
case to be "Start a build of the selected projects immediately"

  b) Change the checkbox to a radio button (or add a combo box in addition to
the checkbox) in this case with two options:
       - "Start a build of the entire workspace immediately"
       - "Start a build of the selected projects immediately"

Personally, I would prefer option "b".

Incidentally - while we are talking about improvements to this dialog I can say that almost every single one of our users have been confused about the fact that when you select "Clean all projects", and the checkbox list view of projects is disabled, the checkboxes all look like they are still enabled.  When you glance at the dialog quickly (which you often do when cleaning) it is very easy to think you are only cleaning a subset of projects because the checkboxes are all green and checked, when in fact you are about to accidentally clean your *entire workspace* - which could be a HUGE operation and most definitely not what you intended.


(Please refer to Bug #70554 for more background)
Comment 1 Greg Smith CLA 2007-10-04 12:45:47 EDT
During usability testing, the issue about the not-disabled looking checkboxes came up as well. It occurs with winxp (using the default Windows XP theme) and GTK (using the Bluecurve and Clearlooks themes), but not in some other themes (looks at the screenshot on bug 110624). It could just be a native painting issue.

Additionally, in this dialog, the text should probably be "Clean projects checked below" since it's possible to select a project but not check it. And, the project list is single-selection, but it should be mulitple-selection (so you can keyboard select multiple and hit space to check)
Comment 2 Mark Melvin CLA 2007-10-22 17:29:11 EDT
I have been looking at a way to improve our builder by using triggers and perhaps trying to act more like the way Ant launches, or the CDT works.  At first it looked like I could use these triggers to make my builder smarter and possibly work around this issue.  However, everything I tried made my builder behave *worse* under certain circumstances and there seems to be no way around this issue.  If I make my builder respond to everything except autobuild, I still get "incremental" build requests on all of my projects after a clean when the "Start a build immediately" is checked.  So, I started wondering - why is it an "incremental" build, and not an "auto" build, but it makes sense that it would be an incremental build because autobuild has been turned off.
I also can't just not respond to "after a clean" type builds (FULL builds) because then my builder is *never* run no matter what I do after a project is cleaned.

So, this is basically impossible to work around without changing the dialog as I suggested.  I guess I'll start in on a patch for this, and hopefully it could make it into 3.4 at some point.
Comment 3 Mark Melvin CLA 2007-10-26 13:17:36 EDT
Created attachment 81279 [details]
Patch implementing build only selected projects functionality

Here is a patch implementing the behaviour I think would be quite useful.  It seems large, but most of it is whitespace differences (I use spaces) - as you will see from the diff when you apply it.

I attempted to integrate the patch in 110624 as well, but could not find a clean way to do this.  Changing from cleaning all projects back to selecting individual projects leaves everything checked, and trying to be smarter started to snowball into more state and buttons so I just left it out.  I think the real way to fix that issue it to make the SWT controls themselves look disabled.

I also did not change the selection wording mentioned in this bug.  I'll leave that up to the Eclipse committers to decide.
Comment 4 John Arthorne CLA 2007-11-23 11:52:52 EST
Option b) sounds reasonable.
Comment 5 Tim Kelly CLA 2007-11-26 11:51:06 EST
I tried out the patch (option b) and it would work for our needs.
Comment 6 John Arthorne CLA 2007-11-27 08:56:02 EST
*** Bug 210959 has been marked as a duplicate of this bug. ***
Comment 7 Mark Melvin CLA 2008-03-04 10:56:51 EST
Would it be possible to get a fix for this into 3.4 (using the attached patch, or something similar)?
Comment 8 Paul Webster CLA 2008-03-19 09:29:32 EDT
Released to HEAD >20080318
PW
Comment 9 Paul Webster CLA 2008-03-25 12:36:55 EDT
In I20080325-0100
PW
Comment 10 Mark Melvin CLA 2008-03-25 13:09:20 EDT
Cool!  Thanks, Paul!  I'll try it out as soon as I have some time to grab the latest.
Comment 11 Mark Melvin CLA 2008-04-02 12:32:36 EDT
This looks good to me in M6.  Thanks again.
Comment 12 Kim Horne CLA 2008-05-16 14:36:22 EDT
Did some or all of Marks patch make it into CVS?
Comment 13 Paul Webster CLA 2008-05-16 14:49:19 EDT
Yes, I committed Mark's patch.
PW
Comment 14 Dani Megert CLA 2013-08-21 05:57:38 EDT
*** Bug 214342 has been marked as a duplicate of this bug. ***