Community
Participate
Working Groups
I20070327 As shown in the attached screenshot, the ellipsis is confusing. Does it mean that the message is truncated ? This would be weird since there is plenty of space. If it is to show that the user should expect something, shouldn't the ellipsis be at the end of the messae ?
Created attachment 62489 [details] Screenshot of Open Type dialog
(Kevin using Mcq's machine) Adding myself to CC because this interests me from a consistency point of view. I bet we do this in a number of places. As a general guidelines, I'd say that we should use ellipses to show truncation only, but that's just an initial gut response.
Indeed, this is a common pattern that occurs when a progress monitor task ends in an ellipsis ("Searching...") and has a subtask ("* files to index"). It's common usage to just concatenate the two messages with a space, see e.g. ProgressMonitorPart.taskLabel(). I don't think we should try to change this in the Open Type dialog only. If this is to be changed, then it should be a platform decision, and recommendations should be documented in IProgressMonitor.
Created attachment 65371 [details] Changes concatenated messages to <task>: <subtask> The best way to fix this would be to use ": " as separator between the task name and the subtask name (instead of " "). Clients such as the Open Type dialog could then remove the ellipsis, and the concatenated message is still readable. Note that we can't add the colon to the "Searching" task name in the client, since we don't know when a subtask is present and when not. The attached patch applies this change in the two places I found in the platform where messages are currently concatenated with " ".
(In reply to comment #4) > The best way to fix this would be to use ": " as separator between the task > name and the subtask name (instead of " "). I like this suggestion and it would work better than "..."
Interesting: The Progress view already uses ": ", see ProgressMessages.JobInfo_DoneNoProgressMessage.
I think we should do this but its a bit late in the cycle for changing how task/subtask are concatenated, plus the knockon changes to places like Open Type. Lets look at this start of 3.4.
This is one of the items on the polish list, so we would like to tackle these. It's just about fixing the case for the filtered item dialog. You're right that we should go through all other cases in 3.4.
The fix in org/eclipse/jface/messages.properties is not good, since the code using it in ProgressMonitorPart is broken (shows colon even with empty subtask). I've added a better patch for that instance to bug 185347. To fix this bug, only the small change in org/eclipse/ui/internal/messages.properties would be necessary.
OK, I'm fine with fixing it for just FilteredItemsSelectionDialog_subtaskProgressMessage in org.eclipse.ui. There are a number of actual dialogs affected, because the string is used in GranualMessageDialog which is used by org.eclipse.ui.dialogs.FilteredItemsSelectionDialog which has the following subclasses: org.eclipse.jdt.internal.debug.ui.breakpoints.AddExceptionDialog org.eclipse.jdt.internal.debug.ui.launcher.DebugTypeSelectionDialog org.eclipse.ui.dialogs.FilteredResourcesSelectionDialog org.eclipse.jdt.internal.ui.packageview.GotoResourceAction.GotoResourceDialog org.eclipse.ui.views.navigator.GotoResourceDialog org.eclipse.ui.internal.ide.dialogs.OpenResourceDialog org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog org.eclipse.jdt.internal.ui.dialogs.OpenTypeSelectionDialog org.eclipse.jdt.internal.ui.wizards.SuperInterfaceSelectionDialog But, since they're all doing the same thing (showing list of items to select from), I can't think of how this change would be bad in some way for these.
Created attachment 65860 [details] Patch to cover just the Open Dialog concat issue
Note I've logged bug #185453 to track the JDT portion of this fix. It needs to be applied first otherwise the resulting string concatenation will look odd.
Created attachment 66102 [details] Improved patch Also removes '...' from task names in FilteredItemsSelectionDialog.
> Note I've logged bug #185453 to track the JDT portion of this fix. It needs to > be applied first otherwise the resulting string concatenation will look odd. Sequence does not really matter -- both look odd: With Platform/UI patch only: Searching...: 9 files to index (20%) With JDT/UI patch only: Searching 9 files to index (20%) JDT/UI is ready to release for tomorrow's I-build.
Did a quick test with both patches, looks ok. Tod will need to do the commit.
I've released the JDT/UI patch (bug 185453) to HEAD. Tod, could you please release the "Improved patch"?
+1 from me but we need a second committer. Susan could you review this please?
> +1 from me but we need a second committer. Susan could you review this please? Wow, does Platform/UI use an even stricter rule of engagement than the default RC1 rules? I am a committer, and AFAIK, Kevin is also a committer, so that would already be three pairs of eyes (in contrast to the required two)...
(In reply to comment #18) > Wow, does Platform/UI use an even stricter rule of engagement than the default > RC1 rules? I am a committer, and AFAIK, Kevin is also a committer, so that > would already be three pairs of eyes (in contrast to the required two)... I am a committer but not on UI. Guess it depends on whether you count the 2 by team or not (on SWT its same for me and we only had one other set of eyes).
Never mind, the fix has already been released to HEAD ;-).
The fix is in HEAD, but the CVS comment references bug #184688. Was the commit intentional or was it accidentally committed when changes for the other bug were committed? At any rate, the changes look ok to me.
Marking fixed since patches applied
Verified in N0510 (although man those strings go by fast!)
Removed "contributed" keyword as I assume it was tagged in error (don't see any external contributions)
