| Summary: | Identify the cause (and if possible fix) the empty white space appearing on top of the machine selection combo box in the 'Image configuration' screen. | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Hob | Reporter: | Giulia <giulia> |
| Component: | hob | Assignee: | Shane Wang <shane.wang> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | belen.barros.pena, jessica.zhang, jiajun.xu, josh, poky.bs.watcher, poky.watcher |
| Version: | 1.2 | ||
| Target Milestone: | 1.2 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
| Attachments: | |||
|
Description
Giulia
2012-03-23 13:24:13 UTC
Giulia, can you give me a snapshot? I can see it on my side. Giulia, can you give some input on this issue? Thanks. Created attachment 411 [details]
Example of the white space
I checked the 'white space' problem again and it seems to appear only when you open the drop down for the first time. Once users scroll up though, the white space is not visible anymore.
OK, thank you, Giulia. It seems you are using Fedora. I am working on Ubuntu but can't see the white space. I will have a try on Fedora machine tomorrow. It was intended to be on Fedora. Without wrap in the image combo, Fedora tries to show more entries in the limited dimension, even for the image combo in pygtk-demo, the seeing is the same. But anyway, it can be changed per request. This seems to be fixed, although the width of the combo when displayed no longer matches the width of the control, which is a bit strange (see screenshots). Marked as verified nonetheless. Created attachment 476 [details]
Width of the combo does not match the width of the control (base image)
Created attachment 477 [details]
Width of the combo does not match the width of the control (machine)
Sadly this is a side effect of the 'fix' for the combo height. Personally I prefer the empty space, rather than the cropped drop-down. I don't prefer any of the 2 :( Is there really no way to get this control working as it's supposed to? (In reply to comment #10) > Sadly this is a side effect of the 'fix' for the combo height. > > Personally I prefer the empty space, rather than the cropped drop-down. (In reply to comment #11) > I don't prefer any of the 2 :( > > Is there really no way to get this control working as it's supposed to? Of course, it works well throughout my OS. We just need to correctly diagnose the issue rather than band-aiding a solution. Until this point I haven't had opportunity to do that but if this is something we care strongly about fixing for 1.2 I can do so now. (In reply to comment #12) > (In reply to comment #11) > > I don't prefer any of the 2 :( > > > > Is there really no way to get this control working as it's supposed to? > > Of course, it works well throughout my OS. We just need to correctly diagnose > the issue rather than band-aiding a solution. Until this point I haven't had > opportunity to do that but if this is something we care strongly about fixing > for 1.2 I can do so now. My apologies, I spoke too soon! This is a feature of the toolkit, it appears. The intent is to have the users active selection be under the cursor when they click on the combo box, the blank space is room for the contents to move into when the user scrolls from the selected position. This leads to all sorts of confusion and I've found multiple instances of folks complaining about this since as long back as 2002[1][2][3][4] ! Per a comment[5] in [2] the only way to change this behaviour is to have the menu of the combobox appear as a list. This, sadly, isn't really a fix. The combo menu as a list doesn't have any logic to prevent long lists from flowing off the edge of a users screen. At this point it looks like we're hobbled by the toolkit between choosing between two less than desirable implementations of the combobox's menu. 1. https://bugzilla.gnome.org/show_bug.cgi?id=72695 2. https://bugzilla.gnome.org/show_bug.cgi?id=129463 3. https://bugzilla.gnome.org/show_bug.cgi?id=559775 4. https://wiki.ubuntu.com/LittleDetails#Gtk.2B-_ComboBox_has_a_big_blank_area_above_the_position_of_its_control Created attachment 478 [details]
Screenshot showing the list style combo
The attached screenshot shows the alternative style. Not only is this, IMHO, uglier but it also doesn't include any way to scroll the combo menu - this is problematic in the attached screenshot where the menu goes off my screen and will only get worse as the user adds layers with more image definitions in.
Created attachment 479 [details]
Patch implementing alternative combo style
A patch demonstrating how to implement the alternative style, so that I don't forget how it's done.
Thanks for looking into this, Joshua. Question for you: is the problem related to the length of the menu, i.e. the high number of items in the combo box? If that's the case, we should be able to do something about it for 1.3 Belen (In reply to comment #16) > Thanks for looking into this, Joshua. Question for you: is the problem related > to the length of the menu, i.e. the high number of items in the combo box? If > that's the case, we should be able to do something about it for 1.3 Yes, it absolutely is. Much of what I read suggested that a ComboBox was wrong for more than half a dozen or so items (and I believe you've said something similar), though I don't think there were good suggestions for an alternative widget. To be honest, I never stopped to think how many base images we could end up having. When I saw the previous version of Hob, the number of items seemed manageable for a combo box. With about 20 items now, we should reconsider the UI control we are using. Should I file and enhancement with target 1.3? Thanks! (In reply to comment #17) > (In reply to comment #16) > > Thanks for looking into this, Joshua. Question for you: is the problem related > > to the length of the menu, i.e. the high number of items in the combo box? If > > that's the case, we should be able to do something about it for 1.3 > > Yes, it absolutely is. > > Much of what I read suggested that a ComboBox was wrong for more than half a > dozen or so items (and I believe you've said something similar), though I don't > think there were good suggestions for an alternative widget. (In reply to comment #18) > Should I file and enhancement with target 1.3? Please do. Done https://bugzilla.yoctoproject.org/show_bug.cgi?id=2345 (In reply to comment #19) > (In reply to comment #18) > > Should I file and enhancement with target 1.3? > > Please do. |