Community
Participate
Working Groups
I20080507-2000 The last two entries of the Problems view's view menu are: - Columns...: allows to configure column width and ordering - Preferences...: allows to configure visibility of columns It's a bit confusing that "Columns..." does not allow to configure visibility as well. Could the visibility also be moved into the "Configure Columns" dialog (using a checkbox like in Windows Explorer > View > Choose Details...)?
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Considering using work from Bug 303001 Comment #25.
Created attachment 183471 [details] Patch V01 Released to CVS HEAD.
Created attachment 183494 [details] Patch2 V01 Further clean-up with regard to how column widths and order are restored.
Marking as FIXED, and updating fields to indicate inclusiveness of the fix.
Putting the "Limit visible items" field into the "Columns..." dialog is wrong. Please move it to the "Configure Contents..." dialog. The validation of the number fields also needs work. You should not try to prevent the user from entering "wrong" content (and the current code is incomplete, since it e.g. allows me to paste other characters). The validation is also wrong, e.g. if I type "-", I get an error message although the filed contents looks. The validation just below the field was a lot easier to understand and less intrusive. The "...zero or blank..." instructions are too much to read and we don't use that style in other places. Please revert to using a checkbox and a field. Top-notch solution would be to make the limit configurable per filter (bug 111619).
(In reply to comment #6) > Putting the "Limit visible items" field into the "Columns..." dialog is wrong. > Please move it to the "Configure Contents..." dialog. > Good suggestions.Thanks. I'll take it up as a part of work for other bugs that pertain more to this.I also noticed that copy-paste omits the number validation ... this work is likely to be part of one of the depending bugs.
The "polish" is not over here ;-)
Created attachment 183680 [details] Patch3 v01 Patch released to CVS HEAD. Please update the bug accordingly.
The direction (i.e. get rid of preference view menu item and put column config on one dialog) is good but there are several UI issues with the solution in HEAD: - 'Configure Contents' dialog: - When opening in a new workspace it comes up with a warning at the top, which is against the UI guidelines. - Only the new limit field can causes errors, hence it's better to show the message close to that field or even not show it. The status field at the top has to go away again. - The new limit field is the least important one and hence it should not be at the top but at the bottom. - A single field does not deserve its own group. - 'Configure Columns' dialog: - Up/Down buttons are too small (must not be smaller than the minimal width). - Up/Down buttons are cut off at the left border. - Up/Down buttons need to be at the top not at the bottom. - Buttons must never change size on resize. - The order of shift arrows must be: <,>,>>,<< as per user guidelines. - In Eclipse we normally add some text to those shift buttons (see e.g. Plug-in import wizard page. This also makes the button easier to access the buttons via mnemonics. - The width label/field should be left aligned. - The extra group around all the controls is not needed. - Column labels are wrong (should be: "Hidden:" and "Shown:") Having said all that: why didn't you do it as suggested in column 0 i.e. do it the same way as one configures columns in the Windows Explorer?
Hitesh, can you please polish that for M4? Thanks.
The polish work will have to be done past M4.
*** Bug 332021 has been marked as a duplicate of this bug. ***
*** Bug 332022 has been marked as a duplicate of this bug. ***
'Configure Contents' dialog: - If my focus is elsewhere and I want to go back to edit the text field, I can hit Alt+I...but that will actually uncheck the checkbox and disable the text field as the mnemonic is actually for the checkbox and not for the text field. - Select some configurations so you have no warnings about missing configurations. Click 'Restore Defaults', the configuration are cleared. Now click it again, now suddenly the warning message returns even though you would think multiple clicks to 'Restore Defaults' would not be any different. - The 'D' mnemonic is used for both the 'Description:' toggle arrow and for 'Restore Defaults'. 'Configure Columns' dialog: - The 'D' mnemonic is used for both 'Down' and 'Restore Defaults'. - It is not possible for me to use the keyboard to grant focus to the 'Hide' and 'Show' tables.
Just to be clear you can ignore my duplicated bug 332021 and bug 332022.
Regarding the "Limit visible items" field": Why don't we just use a Spinner widget and let the OS deal with illegal inputs? Then we can remove all the annoying messages, including the warning when the limit is turned off.
Created attachment 184969 [details] MockUp V01
(In reply to comment #18) > Created an attachment (id=184969) [details] [diff] > MockUp V01 What is this for? In what state is it? It looks quite technical to me at this point. Why not follow the solution suggested in column 0?
>Why not follow the solution suggested in column 0? Comment 0.
We need to do something here: either pull out the new code or polish it.
Created attachment 187825 [details] Config Dialog I'm planning to simplify the Configure Contents dialog by removing the filter information to another dialog. Attached is the Config dialog
Created attachment 187826 [details] Dialog for editing individual filters
Dani/Markus/Remy, Expecting your thoughts on this.
I don't find it simpler when I have to deal with even more dialogs just to see or change a single setting. Also, your attachment 187825 [details] is missing a title for the configurations table (for accessibility and as mnemonic target). I don't think the Configure Contents dialog needs fundamental changes. This bug is mostly about reverting the bad changes in HEAD and fixing the columns dialog. Comment 10 pretty much sums up what should be done. What's indeed confusing in the Configure Contents dialog is the inconsistent terminology regarding "filters" and "configurations". "Filter" is a wrong term, since the configurations don't filter (remove elements from the base set), but they pick and choose what to show (they add elements to show). The configurations should either consistently be called "configuration", or they should get a consistent new name like "items set" or "markers set" (or specific to each view "problems set", bookmarks set", ...). Moving the "Show results matching:" to the top would be OK for me.
(In reply to comment #25) > What's indeed confusing in the Configure Contents dialog is the inconsistent > terminology regarding "filters" and "configurations". "Filter" is a wrong term, I agree. We should not use Filters and stick to Configurations. > I don't think the Configure Contents dialog needs fundamental changes. Looking at the dialog, I don't agree. If we are to have a single dialog, we need to change a few things. For the first time user, it is not clear from that the dialog uses master-details. We need some basic changes in the layout. (like the height of the details composite should not be bigger than the height of the master composite/both master and detail should come under the Configuration label/etc) Also there is no visual/verbal hint that checking the item in the list means "enabled". If we edit all the details of a configuration in the details composite, then we should ideally have a check box called "Enabled" there. But with that approach, one cannot find the list of configurations that are currently enabled by just looking the the list of configuration, unless we use some font/color decorations. Even if we use decorations, enabling/disabling the configuration would need two mouse clicks (one to select the configuration and then click the Enabled checkbox in the right) > I don't find it simpler when I have to deal with even more dialogs just to see > or change a single setting. I agree. I myself don't like the dialog-on-dialog-on-dialogs... But after several trial & errors like the ones described above, I finally settled with this. This goes with the same Progressive Disclousure technique applied in other places of SDK like the Installed JREs/Task tags preference page. As per my understanding, the frequent use for this dialog would be to enable/disable a configuration or to change the marker limits, which can be done in with the first dialog. This should cover most of the cases. The less frequent activity would be to create/edit the filters, which needs the additional dialog. If that assumption is not correct then we should go back to the single dialog method.
>I don't think the Configure Contents dialog needs fundamental changes. This bug >is mostly about reverting the bad changes in HEAD and fixing the columns >dialog. Comment 10 pretty much sums up what should be done. I fully agree with Markus here. I also agree that the configure dialog (in 3.6) isn't THE beauty but that's another issue. In 3.6 I can see the configuration in the dialog and that should not be removed due to collateral damage from trying to fix another problem.
(In reply to comment #27) > >I don't think the Configure Contents dialog needs fundamental changes. This bug > >is mostly about reverting the bad changes in HEAD and fixing the columns > >dialog. Comment 10 pretty much sums up what should be done. > I fully agree with Markus here. I'm working on "Configure Columns" but, is there anything in Comment #10 not addressed in the new "Configure Contents" dialogs? > I also agree that the configure dialog (in 3.6) isn't THE beauty but that's > another issue. In 3.6 I can see the configuration in the dialog and that should > not be removed due to collateral damage from trying to fix another problem. I'm not trying to "beautify" the dialog. The 3.6 dialog is confusing. It throws everything in a single dialog and that is the major cause for the confusion. The configuration details are moved to address that problem - not something else.
> The 3.6 dialog is confusing. It > throws everything in a single dialog and that is the major cause for the > confusion. The configuration details are moved to address that problem - not > something else. This bug is about the columns config and not about the contents/filter config. If you also want to solve that issue then that's fine but it's not what this bug here was initially about.
Note that in the config dialog as shown in https://bugs.eclipse.org/bugs/attachment.cgi?id=187825 the labels in the checkbox list are just labels (except of the locked ones). Even if it says e.g. 'All Tasks' it can be something else. Only if you edit, you'll see what's behind. This makes the checking/selection in that dialog - and hence the dialog - pretty useless as the user has to open the modal dialog to know exactly what's behind it.
Just hit this. Change the marker limits in one Markers view (say in the Bookmarks view), it will reflect in the others (say Tasks/Problems view)
Created attachment 188753 [details] Patch v04
(In reply to comment #10) > Having said all that: why didn't you do it as suggested in column 0 i.e. > do it the same way as one configures columns in the Windows Explorer? I tried that way and didn't like it (will raise a bug & attach the patch there). The current way gives a nice overview of what is shown and what is hidden.
Created attachment 188880 [details] Patch v05 Patch v04 + minor fix in restoring defaults
Patch v05 released to HEAD
Sorry but this is not good as I no longer see what the contents settings mean in the 'Configure Contents' dialog. As I tried to explain in comment 30, as soon as one edits an entry, the label might be completely misleading. Compared to 3.6 this is lost functionality for no good reason and a no go. The fix introduces some new issues (one of which is major): 1. The logic of reading and storing the settings has changed. This results in a broken Problems view when starting an old workspace: it reads the width for all columns as '1', see attached screen shot and I can't restore it, see next bug. 2. 'Restore Defaults' in 'Configure Columns' dialog is broken: it sets the width to '1' for each column. 3. Out of the box the 'Location' header is truncated which was never the case so far. Also, the new dialogs don't (correctly) disable dependent widgets if the parent option is disabled.
Created attachment 188988 [details] Image showing broken Problems view
(In reply to comment #37) > Created attachment 188988 [details] > Image showing broken Problems view Dani, Can you attach the old workspace? I couldn't reproduce the problem.
(In reply to comment #38) > (In reply to comment #37) > > Created attachment 188988 [details] [details] > > Image showing broken Problems view > > Dani, > Can you attach the old workspace? I couldn't reproduce the problem. I already fixed my workspace manually and it's > 1GB plus has confidential stuff in it. I assume it goes through the same/similar code path as when I hit the restore button in the dialog (that one you can easily reproduce with a new workspace).
(In reply to comment #37) > Created attachment 188988 [details] > Image showing broken Problems view I have the same problem in I20110215-0800. If this is not fixed on Monday, you have to revert these changes.
(In reply to comment #40) > I have the same problem in I20110215-0800. If this is not fixed on Monday, you > have to revert these changes. Did you mean to write: "I have the same problem in I20110215-0800. Opening an existing workspace results in 1 pixel wide columns in the Problems view, which is a major problem as it appears as if there was no content. This should really be fixed for the next integration build. If you don't have a fix ready by Monday, I suggest that you revert the changes to give you more time to investigate, without causing productivity losses for those who are using integration builds." In particular: - Very dense comments are really easy to misinterpret, and might easily be taken personally. - When you ask that this be looked at urgently, can you please be as specific as possible about which part of the problem is urgent. Thanks.
(In reply to comment #40) > (In reply to comment #37) > > Created attachment 188988 [details] [details] > > Image showing broken Problems view > > I have the same problem in I20110215-0800. If this is not fixed on Monday, you > have to revert these changes. This will be fixed before Monday
(In reply to comment #41) > (In reply to comment #40) > > I have the same problem in I20110215-0800. If this is not fixed on Monday, you > > have to revert these changes. > > Did you mean to write: > > "I have the same problem in I20110215-0800. Opening an existing workspace > results in 1 pixel wide columns in the Problems view, which is a major problem > as it appears as if there was no content. This should really be fixed for the > next integration build. If you don't have a fix ready by Monday, I suggest that > you revert the changes to give you more time to investigate, without causing > productivity losses for those who are using integration builds." > > In particular: > - Very dense comments are really easy to misinterpret, and might easily be > taken personally. > - When you ask that this be looked at urgently, can you please be as specific > as possible about which part of the problem is urgent. > > Thanks. Thanks for the meta-comment. A problem with this bug is that several tries happened to fix it but once after providing some feedback nothing happened afterwards and actually its no better than when this bug got reported - actually the current code is worse.
Created attachment 189400 [details] Patch v06
Patch v06 released to HEAD
Created attachment 189461 [details] Patch v07 Fix for Restore Defaults issue.
Patch v07 released to HEAD
It's better and the column width issue is fixed but this is still not something I'd call "polished". ;-) >3. Out of the box the 'Location' header is truncated which was never the case > so far. This is still the case. Just compare a new 3.6.1 workspace with a new one started from HEAD. I went over both dialogs and here are the things we should fix for M6: 'Configure Columns' dialog: - In the SDK we use "<--" and "-->", see e.g. PDE import wizard. - The "<--" needs to left to the label. - 'Width of selected column' label not grayed/disabled when unavailable. - The disabling of that column width field is confusing if none of the lists has focus: depending on which list had the focus before, the field is enabled/disabled but that's not detectable by the user. Given the option is already placed below the right list, I would control the enabled state only based on that list i.e. not disable if I select something from the left list. - The first buttons need to be horizontally aligned to the top of the lists. - 'Restore Defaults' should not remove the selection from the two lists. - All numerical values in the SDK are entered through text fields. While it might be interesting to use the Spinner widget we do not use it for consistency reasons. - Almost every mnemonic is used twice. Whenever possible, they should be unique. 'Configure Contents' dialog: - In fact lots of changes were made but the only real change that was needed was to add the group limit. I would simply restore the 3.6 state and then add the limit at the bottom - except for the 'Show all' thing (see below). This will also fix the following new issues: - The additional vertical space (around 50%) that's taken compared to 3.6.1 is not good. The dialog looks worse than before. - The dialog looks like a wizard page due to the white area at the top. That needs to be removed. - Remove the 'Configuration' grouping again (restore 3.6.1 look) - The new name filed on the right is redundant and only adds clutter given that renaming is a rare operation this should be removed again (and the buttons brought back). - Don't show the '?' help button - especially because the shown help that appears doesn't give any additional help. - I like the new 'Show all' checkbox but given we have so much empty vertical space in the list on the left, we should move the new part above the list and make the radio labels a bit shorter so that we don't increase the width of the left configuration area. - Dependent widgets are not indented correctly (indented too much). - All numerical values in the SDK are entered through text fields. While it might be interesting to use the Spinner widget we do not use it for consistency reasons. - All newly added mnemonics are already taken. - In a next round (not as part of this bug) we might even move the new limit field to the right and allow users to set the limit per configuration. That way, one could e.g. choose to limit warnings but not errors, see bug 111619.
(In reply to comment #48) Thank you for the detailed feedback!
We need quicker progress here. The state of the problems view preferences is unbearable now, and we're quickly approaching M6. Apart from all the problems Dani already mentioned, I can't even change the number of visible items any more (in N20110227-2000). I.e. I can change the number in Configure Contents, but the Problems view doesn't show the items (still says "Filter matched 100 of xxxx items").
(In reply to comment #50) > Apart from all the problems Dani already mentioned, I can't even change the > number of visible items any more (in N20110227-2000). I.e. I can change the > number in Configure Contents, but the Problems view doesn't show the items > (still says "Filter matched 100 of xxxx items"). This issue and few others are fixed in HEAD
All of the major issues have been fixed. Let me know if I'm missing anything. I prefer to mark this one as fixed and discuss the minor pending issues in Bug #338912
(In reply to comment #52) > All of the major issues have been fixed. Let me know if I'm missing anything. Sorry, I'm out of cycles for today, but please simply go through the detailed list I provided in comment 48 and you easily see whether you are done or not. If one of those item is not done yet then polish is not complete ;-). Maybe Markus has some time for another feedback round.
Dani wanted me to update this bug on my thoughts. So here it goes ... In 3.6 dialog the biggest mistake in the UI was to have the Details area taller than the Master area. I have not seen such thing elsewhere and I don't think its a good idea to have it that way. Besides, there is no visual clue about the existence of the master-detail areas. In 3.7 (after few rounds) I had put the master-details in a group and made them the same height. I believe that this gives the correct visual clue and is better than 3.6. I'm not going to implement (1) "Remove the 'Configuration' grouping again (restore 3.6.1 look)" and (2) "given we have so much empty vertical space in the list on the left, we should move the new part above the list and make the radio labels a bit shorter so that we don't increase the width of the left configuration area." Implementing these would cause the dialog to go back to old stage and I'm not for it unless there are any strong reasons. Apart from these two items, I'm done with this bug. Dani/Markus, If you agree with the above, you can mark this bug as Fixed.
Created attachment 192542 [details] 3.6 Dialog
Created attachment 192543 [details] 3.7 Dialog
(In reply to comment #54) I can agree with that. However, I would indent the configuration area since it also depends on the master switch (as discussed in the chat). In addition the new mnemonics are still conflicting (as already mentioned before). Some additional items: - Add more vertical space before the "Use item limits". - Remove some vertical space after the "Use item limits". - Remember the checked configurations: currently when I deselect 'Show all items', select some configurations and then check 'Show all items' again, I loose my previous settings. - We should either make the list a bit wider or the dialog, so that one doesn't get clipped items out of the box by default. Most of the feedback from comment 48 about the 'Configure Columns' dialog has not yet been incorporated: - In the SDK we use "<--" and "-->", see e.g. PDE import wizard. - The "<--" needs to left to the label. - 'Width of selected column' label not grayed/disabled when unavailable, e.g. when focus on left list (it seems that one can only change the values for the right list). - The disabling of that column width field is confusing if none of the lists has focus: depending on which list had the focus before, the field is enabled/disabled but that's not detectable by the user. Given the option is already placed below the right list, I would control the enabled state only based on that list i.e. not disable if I select something from the left list. - The first buttons need to be horizontally aligned to the top of the lists. NEW: The 'Width of the selected...' UI element hangs in the air as it is not aligned to something reasonable for the user. It should be left aligned to the left border of the right list.
(In reply to comment #57) > - Add more vertical space before the "Use item limits". Why?
(In reply to comment #58) > (In reply to comment #57) > > > - Add more vertical space before the "Use item limits". > > Why? Because it looks like glued to the group and looks ugly.
(In reply to comment #59) > (In reply to comment #58) > > (In reply to comment #57) > > > > > - Add more vertical space before the "Use item limits". > > > > Why? > Because it looks like glued to the group and looks ugly. I don't think so. Esp after adding indenting the Configuration area. The indenting is available in HEAD. Can you check it once and confirm whether the vertical space is still needed?
Just go to e.g. the 'Workspace' or 'Keys' preference pages and see how check boxes are separated from their upper elements, especially when they are not related to that widget. On the config dialog it looks it's almost glued to the group and that looks really ugly. It also looks like you did some changes to the 'Configure Columns' dialog but it still suffers most issues listed in comment 57 (alignment is fix).
(In reply to comment #61) > Just go to e.g. the 'Workspace' or 'Keys' preference pages and see how check > boxes are separated from their upper elements, especially when they are not > related to that widget. Don't look at the check boxes but at how the different controls are vertically separated.
>- The "<--" needs to left to the label. This seems to be fixed. >- In the SDK we use "<--" and "-->", see e.g. PDE import wizard. Actually we should change it to '<-' and '->' as shown in the MS Windows 7 and Vista UX guidelines (page 109). Fixed that in HEAD.
(In reply to comment #57) > Some additional items: > - Add more vertical space before the "Use item limits". > - Remove some vertical space after the "Use item limits". > - Remember the checked configurations: currently when I deselect > 'Show all items', select some configurations and then check 'Show all items' > again, I loose my previous settings. > - We should either make the list a bit wider or the dialog, so that one doesn't > get clipped items out of the box by default. These additional items are done. > Most of the feedback from comment 48 about the 'Configure Columns' dialog has > not yet been incorporated: > - In the SDK we use "<--" and "-->", see e.g. PDE import wizard. Done. > - The "<--" needs to left to the label. This was fixed long back. > - 'Width of selected column' label not grayed/disabled when unavailable, e.g. > when focus on left list (it seems that one can only change the values for > the right list). > - The disabling of that column width field is confusing if none of the > lists has focus: depending on which list had the focus before, the field > is enabled/disabled but that's not detectable by the user. Given the option > is already placed below the right list, I would control the enabled state > only > based on that list i.e. not disable if I select something from the left list. Since the alternatives are actually not better than the current state, me and Dani agreed to leave it is in the current state. > - The first buttons need to be horizontally aligned to the top of the lists. This has been changed. We agreed to have the buttons vertically center aligned rather than having it top aligned. Done. > NEW: The 'Width of the selected...' UI element hangs in the air as it is not > aligned to something reasonable for the user. It should be left aligned to the > left border of the right list. Done.
Resolving as Fixed.
Verified in HEAD.
