Community
Participate
Working Groups
I20080327-2251. Since M1 the ShowViewDialog has an F2 hint to show the view description (see bug 128529), however there are no (i.e. 0) views in the SDK that have a description. I assume same applies to most of our clients. Giving users the impression to get some info and then failing for all our views is not nice and forcing all SDK components and upstream plug-ins to add this seems overkill given that this attribute is optional. Either we remove that new feature completely or at least remove the hint in the view. Boris I can take care of that if you want. Just let me know which approach you prefer (remove all or only remove the label).
How about just showing the description of the selected view below the tree (instead of the label "Use F2 ...")? When there's no description or selection count != 1, just leave the text empty. This makes the description available for views that need it and does not clutter the UI for others. Open Perspective > Other... should use the same approach as Show View.
Sebastian, this is about the feature you contributed early in the 3.4 cycle. I like Markus' suggestion, what do you think?
I like it too.
Marcus' suggestion is definitely an improvement since the current behaviour of hitting F2 to only discover there's no description is irritating. But I still have some concerns: 1. There isn't enough space there to show much of a description, especially once we NLS them (e.g. German tends to be longer). Since I couldn't actually find example descriptions its hard to say how it'll play in practice. Also its this narrow little space because the dialog is narrow, which doesn't lend itself to a sentence description of arbitrary length, and almost certainly would require multiple lines. 2. I can't think offhand of anywhere else we do that (show description beneath the tree chooser). We do show error information in some dialogs though. However, typically description information has a dedicated spot, like the banner of wizards (e.g. New->Other, Import/Export) and with these it shows against a white background for readability, is a place you expect there to be guidance content, is a nice long horizontal space for a proper sentence, there's Help access for further details, etc. 3. Since existing views don't have descriptions (none that I could find), that area will in practice remain blank, so we end up with a big empty area (esp. if its big enough for a decent description) which in usual practice has no purpose that people can figure. Sorry to be so negative. I really like the idea of providing more guidance to the user but I'd prefer an approach that we felt confident about using consistently throughout the IDE, not a one-off solution for the view menu. Maybe it'd help if there was more background to our intention here. Are we planning on putting descriptions in for all our views? Are we recommending others do the same? Are we recommending that new views have them? Would this go into the style guide?
>2. I can't think offhand of anywhere else we do that (show description beneath >the tree chooser). Not description but at least also additional info is shown by Open Type/Resource dialog at the bottom. >Are we >planning on putting descriptions in for all our views? I don't think that's realistic. An effort might "force" SDK developers to do this but what about all the other clients? While I like Markus's idea I think for now the best is to simply remove it again for 3.4. Leaving in the feature but without hint for the user is probably useless as no one would detect it.
(In reply to comment #4) > 1. There isn't enough space there Same problem as in wizard title area (e.g. New > Other...). Solution: Just reserve 2 lines. If contributors are dumb enough to write novels there, rely on user smartness to tab into the text and move the caret down. Or vote for bug 27096 or bug 180027 to get scrollbars only if necessary. Since the description has not been visible for years, chances are marginal that elaborated descriptions can be found in the field. > 2. I can't think offhand of anywhere else we do that (show description beneath > the tree chooser). I also have this for the Package Explorer in my workbench (view at left edge, workbench window status line at bottom-left shows full path to selection) > 3. Since existing views don't have descriptions (none that I could find), that > area will in practice remain blank, so we end up with a big empty area. Could repeat the view name to avoid the blank if there's no description. Nevertheless, I would also not have a problem with removing this altogether. BTW: 'Customize Perspective > Commands' has the same problem.
> 2. (show description beneath the tree chooser) Other examples can be found in preference pages, e.g. Label Decorations, Colors and Fonts, Execution Environments, etc. (I would have added Keys, but it's broken again, see bug 186522 comment 25)-:
(In reply to comment #6) > Same problem as in wizard title area (e.g. New > Other...). > Solution: Just reserve 2 lines. If contributors are dumb enough to write novels > there, rely on user smartness to tab into the text and move the caret down. True but the wizards have lots of width for sentence text, while as this little view chooser doesn't (its pretty thin). (In reply to comment #5) > >2. I can't think offhand of anywhere else we do that (show description beneath > >the tree chooser). > Not description but at least also additional info is shown by Open > Type/Resource dialog at the bottom. (In reply to comment #7) > > 2. (show description beneath the tree chooser) > Other examples can be found in preference pages, e.g. Label Decorations, Colors > and Fonts, Execution Environments, etc. Right so these are good examples but what's interesting is that in each we have a dedicated area with a drawn bounding box for the text. You expect, and always see for each selection, text showing up. If we were to follow that approach, then you'll have a text box that is almost guaranteed to always be empty (since we'll have no descriptions). People will think its a bug. So either: 1) We need to put descriptions in everywhere (which I agree with Dani is unrealistic) 2) We put some other text in there if no description (Markus suggested just the name, I guess it'll work but will look odd though no?) 3) Don't use the drawn text box, or only turn it on when there's content. Either way you end up with blank space with no apparent purpose. All this is leading me to believe that unless we're going to commit to putting description content in for all views in the SDK for 3.4, we should just not show it. If we believe that in the future this will persist (ie. it'll be the exception for views to have description text) then we need a subtler approach for showing it than a dedicated text box. If we have a clever idea for 3.4 then I'm game to try it.
Maybe the description could be displayed in a tooltip for the item under the mouse in the tree (automatically rather than requiring the user to press F2)? (In reply to comment #4)
Could someone please give me some information about the current status of this discussion? I just saw this behavior again in 3.5 M6. The F2-Hint is still shown, but no descriptions are available. I like the idea of providing tooltips! IMHO F2 in general could be misleading for the user. Outside of this dialog, descriptions (Context Help) regarding the selected View are available via F1 (Shift+F1).
(In reply to comment #10) > Could someone please give me some information about the current status of this > discussion? It looks like we haven't decided what to do, but what's worse, I am not sure we will have time to address this for 3.5. Patches are always welcome of course, see http://wiki.eclipse.org/Platform_UI/How_to_Contribute . Kevin, I hope you don't mind watching this bug.
Created attachment 133498 [details] Patch to remove the feature Here's a patch that removes the feature for now as for sure we won't have time to fill in the information for 3.5. I didn't commit it since it's your call to decide. To bring the feature back the patch can be reverse applied or CVS can be used: org.eclipse.ui.workbench: org.eclipse.ui.internal.dialogs.ShowViewDialog.java rev.1.43 org.eclipse.ui.internal.WorkbenchMessages.java rev. 1.116 Eclipse UI/org/eclipse/ui/internal/messages.properties rev 1.397
Could anyone please provide an update on this Eclipse bug? What is the current plan for addressing this issue?
Boris, I suggest to apply my patch unless someone steps up to add all the descriptions.
Patch released to HEAD.
Boris/Dani, What does the patch "remove the feature" does ? What would be the new behavior after you applied your fix/patch ? Thanks!
(In reply to comment #16) > What does the patch "remove the feature" does ? > What would be the new behavior after you applied your fix/patch ? The description (and the hint about pressing F2) is no longer displayed.
Does that mean users can still hit "F2" and see the description for the views that have description available ? Is that correct that "removing this feature" going to happen for Eclipse 3.6 ?
(In reply to comment #18) > Does that mean users can still hit "F2" and see the description for the views > that have description available ? No. The code that handles the key press has been removed as well. > Is that correct that "removing this feature" going to happen for Eclipse 3.6 ? Yes. I inadvertently released the change to the 3.5 maintenance stream but I am working on fixing this.
Reverted the change in R3_5_maintenance.
This time, really released to HEAD.
Our product is built on top of Eclipse and our customers have asked to provide a description for the views that our product has contributed. Based on this request from our customers we have added descriptions for some of our views. Based on this, when our product will be moved on top of Eclipse 3.6 in the future then our customers will no longer be able to hit F2 to see the description. Is this correct? If so, what is the alternative that is being provided ? Will the description that is currently available for the views that our product has contributed be displayed at the bottom of "Show View" dialog ?
(In reply to comment #22) > Our product is built on top of Eclipse and our customers have asked to provide > a description for the views that our product has contributed. Based on this > request from our customers we have added descriptions for some of our views. > Based on this, when our product will be moved on top of Eclipse 3.6 in the > future then our customers will no longer be able to hit F2 to see the > description. Is this correct? If so, what is the alternative that is being > provided ? Will the description that is currently available for the views that > our product has contributed be displayed at the bottom of "Show View" dialog ? Ah, I understand. Looks like the assumption in comment 0 that there are no clients who use this was wrong. One alternative would be to keep the feature, provide descriptions for all views in the SDK, and recommend that clients provide descriptions as well. Another alternative would be to keep the tooltip, but make it easier to discover (for example, show the tooltip when the user hovers with the mouse as well as on F2) and then remove the hint about F2. The problem with the first alternative is that we are very resource constrained. This is also why we were leaning towards removing the feature completely. Pavan, do you have a preference? Would you be able to help us with a solution?
reopening
(In reply to comment #23) I would prefer the alternative # 2 that you mentioned below. Since it allows users to see the description one way or the other. It also addresses your resource constraint problem in doing alternative 1. > Another alternative would be to keep the tooltip, but make it easier to > discover (for example, show the tooltip when the user hovers with the mouse as > well as on F2) and then remove the hint about F2. Is that possible for you to easily display the description as a tooltip (when available) ?
>Ah, I understand. Looks like the assumption in comment 0 that there are no >clients who use this was wrong. No it is not wrong and still holds, as I said "in the SDK ... I assume same applies to most of our clients.". I've modified the fix so that the hint is only shown if there's a description and F2 is only working if the hint is shown. Please open separate bug reports for more advanced solutions like tool tip or showing the description inside the dialog.
