Bugzilla – Full Text Bug Listing
| Summary: | [IDE] [Wizards] Improvements to the advanced section of new folder wizard | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Susan McCourt <susan> | ||||||
| Component: | UI | Assignee: | Serge Beauchamp <serge> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, markus.kell.r, prakash, pwebster, remy.suen, serge, Szymon.Brandys | ||||||
| Version: | 3.6 | Flags: | daniel_megert:
review+
|
||||||
| Target Milestone: | 3.6 RC1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Susan McCourt
Another question/issue: We allow users to create linked folders with empty locations. We get a little warning decorator on the folder. But nothing bad happens until I do something like try to create a file in this folder, and then it fails (error dialog - the wizard did not catch it). Do we still intend to support linked folders with an empty location? That seems a little funny in light of virtual folders. Maybe we should force a location. Created attachment 154160 [details]
error dialog
we need to clean up the error messages associated with virtual folders to use the new terminology. Here is an error message I got when I tried to create a file underneath a virtual folder.
(In reply to comment #2) Not only error messages. The term 'Groups' should be removed everywhere (I e.g. see it on the Resource properties page as well). (In reply to comment #3) > Not only error messages. The term 'Groups' should be removed everywhere (I e.g. > see it on the Resource properties page as well). See bug Bug 297459 I raised today. (In reply to comment #3) > (In reply to comment #2) > Not only error messages. The term 'Groups' should be removed everywhere (I e.g. > see it on the Resource properties page as well). yes, of course. I was annotating this bug as I ran into them, that was the first one. Here are the various wording and behavior suggestions copied over from bug 296565. bug 296565 comment 19 > The text of the advanced options looks complicated to the user and the newest > option should be last. I suggest to change it to: > > ( ) Create folder in the workspace > ( ) Link to folder in the file system > ( ) Virtual folder > +1. This was the original proposed ordering (and your phrasing is nicer, more active). bug 296565 comment 21 > ( ) Virtual folder (can only contain links) Technically it can contain links and other virtual folders. I still think that if the location box gets updated as the radio is clicked, that will help with the explanation. From a doc/screen snap point of view it'd be nice if the wording were generic enough that it would survive implementation changes. bug 296565 comment 2 > First button - location box goes gray but shows the actual location (like the > new project wizard does now) > Second button - location is enabled and you must choose a location to complete > the wizard > Third button - location box goes gray and is blank I started to implement this when reviewing the patch but it was just a bit too involved given the current factoring and I felt best to address later. It requires opening up the CreateLinkedResourceGroup to be able to get the text (not just URI), etc. Just wanted to note that the 'Browse...' and 'Variables...' buttons and their associated Text control does not honour the dialog font setting. Setting Target Milestone so this doesn't get forgotten. removing target, since unsure about it. >removing target, since unsure about it. At least the polish work must be done for 3.6, e.g. comment 6. (In reply to comment #9) > >removing target, since unsure about it. > At least the polish work must be done for 3.6, e.g. comment 6. (In reply to comment #6) > Just wanted to note that the 'Browse...' and 'Variables...' buttons and their > associated Text control does not honour the dialog font setting. This was addressed already before and is verified on I20100429-1549. Reading the comments in this bug, the bugs raised are either all addressed (removing references to 'groups', etc...), or not suitable for RC1 as fas as I can see. If we keep the original comment from Susan (adding the location in parenthesis when the default location is selected), then this should be the issue at hand in this bug report, and not the other points (which are resolved anyway). (In reply to comment #10) > (In reply to comment #9) > > >removing target, since unsure about it. > > At least the polish work must be done for 3.6, e.g. comment 6. > This was addressed already before and is verified on I20100429-1549. No it has not or it had been done lazily. Simply change the font using I20100429-1549 and you will see that those buttons aren't using the new font. Also, there's a mnemonic conflict (V). (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > >removing target, since unsure about it. > > > At least the polish work must be done for 3.6, e.g. comment 6. > > This was addressed already before and is verified on I20100429-1549. > No it has not or it had been done lazily. Simply change the font using > I20100429-1549 and you will see that those buttons aren't using the new font. > Also, there's a mnemonic conflict (V). Oh, I see, I wasn't looking at the same dialog. Created attachment 166939 [details]
Patch
Fix.
By the way, note that all those issues (besides the mnemonic duplication) existed in 3.5 as well.
Can you please add a review flag so I can commit it? Thanks, >By the way, note that all those issues (besides the mnemonic duplication)
>existed in 3.5 as well.
Indeed. Thanks for fixing it ;-)
The patch works but a better solution than setting the font all over the place would be to use Dialog.applyDialogFont(...) on each composite and remove the setFont(...) calls. Suggest to use the patch at this point and clean this up in 3.7 (==> please file new bug).
+1 for RC1.
Now fixed on head. |