Community
Participate
Working Groups
I20080827-0935 This is a follow-up to bug 7845. Combos are still a big pain point in SWT applications under Windows. Only few developers find and apply the hack from bug 7845 to make combos usable. The only justification I've heard for keeping the non-native default visibleCount at 5 was bug 7845 comment 12: > Because 20 would be wrong in other situations? However, the default visibleItemCount is already platform-dependent, and even non-controllable on some platforms. If some applications cannot live with a bigger default, they can always set a smaller value manually. But I cannot imagine any application where it is preferable to force to user to look through a small keyhole and scroll around with an 8 pixels high thumb. I would set the default to 30 (as e.g. Windows Control Panels do), but I could live with any value >= 20. Please just consider this as normal bug, fix it, and make 99.99% of all users of SWT applications happy.
Could you please fix this? Nobody could come up with a reason for this keyhole on Windows, and there are ample reasons for making it just work like on other platforms (GTK and the Mac have no artificial limits). That's one small step for SWT, one giant leap for usability.
In cocoa the native count is 5, in carbon it is 6, in GTK is many items as it can fit in the screen (getVisibleItemCount() returns 5 in GTK but it is lie). In win32, as we know, it is 5 (non-native). Silenio, how do you feel changing the default visible item count in cocoa/carbon/win32 to 20 ?
> In cocoa the native count is 5 Oh, sorry, I only checked read-only combos (those are unlimited). Interestingly, Apple shows 10 items in editable Combos in the System Preferences. It would also make sense to set a bigger default on the Mac.
the test code I used (tested only DROP_DOWN) public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); Combo combo = new Combo(shell, SWT.DROP_DOWN); for (int i = 0; i < 50; i++) { combo.add("item"+i); } System.out.println(combo.getVisibleItemCount()); shell.setSize(200, 200); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
I searched through some apps on Windows and Mac: FileExplorer Address combo: 15 Printer Page Setup: >13 Font dialog: 7 Run dialog in start menu: >15; Excel/Word font name combo: 12 Excel/Word font size combo: 12 Date & Time Closest City on mac: 10 Display Resolutions on mac: 10 I guess there is no real standard here. My vote is to change all platforms to 15. Or mac to 10 and windows/gtk to 15. I have no stronge feelings about either.
> FileExplorer Address combo: 15 That's quite a special case, since it mainly shows the parent folders of the current folder, so the list is often not that big. > Font dialog: 7 The only combos I see there are Color and Script, and they are both unlimited (16 and 9 items on my system) > Excel/Word font name combo: 12 > Excel/Word font size combo: 12 I hope we agree that those are UI bloopers. MS was probably scared that the custom font preview rendering was not fast enough. Even the font combo in WordPad shows 30 items. And all the options in the Control Panels (e.g. Regional options) show 30 as well. So the most commonly used size on Windows (XP) is 30.
+1 for any visibleItemCount larger than 5 (which is just painful).
(In reply to comment #6) > > FileExplorer Address combo: 15 > That's quite a special case, since it mainly shows the parent folders of the > current folder, so the list is often not that big. In my machine, the list is always big (around 30 items). I believe the file explorer is the most common app on Windows. That is why I suggested 15 as the default value. > > Font dialog: 7 > The only combos I see there are Color and Script, and they are both unlimited > (16 and 9 items on my system) I am talking about the the "Font", "Font Style" and "Size" combos. They are SWT.SIMPLE style combos. We should not increase the visibleCount for these kind of combos, since it would take to much space in a dialog. > And all the options in the Control Panels (e.g. Regional options) show 30 as > well. > So the most commonly used size on Windows (XP) is 30. I could argue this is just one case, but the same goes for my FileExplorer case. Anyways, we all agree that 5 is too small, but the limit is really application specific. So applications that care about how many items are visible should call setVisibleCount(). I will write a patch that changes the limit to 15 on Windows and 10 on Mac and also take into consideration the SWT.SIMPLE style.
The visible count on Motif is 10. I am not going to change that value.
Created attachment 162691 [details] patch for win32
Created attachment 162692 [details] patch for cocoa and carbon
I agree that the default for SWT.SIMPLE-style Combos should stay small. Re the File Explorer address "Combo": That may be reminiscence of the days of 13" monitors. Today, it's just a UI blooper. Have you ever thought: "Thank heavens that they only show me 15 items and not all the 30 at once. Finally I can put my scroll wheel into good use!". I haven't. Ever. Nowadays, even the Microsoft User Experience Guidelines recommend 30 items: http://msdn.microsoft.com/en-us/library/aa511458%28v=MSDN.10%29.aspx#DropDownLists44 : "Choose a list length that eliminates unnecessary vertical scrolling. Because drop-down lists are displayed on demand, their lists should show up to 30 items."
Ok, 30 it is. Fixed > 20100322
We have to revisit this. If we have a fixed number of visible items that high, we will have problems in small resolution screens (like WinCE). The list will be bigger than the screen height. I believe the list height should be a percentage of the screen height. I am going to attach a patch that makes the list height 1/3 of the screen. This looks like a reasonable size to me and it is actually 30 items a my screen (1600x1200).
Created attachment 163307 [details] patch for win32 to uses the screen height to determine the default visisble item count
(In reply to comment #14) I agree. At least WinXP behaves badly when the popup and the text area need to overlap because there's no space. And thanks a lot for fixing this bug!
Fixed > 20100329
