apocalyptech / eschalon_utils

Eschalon Books I, II, and III Character and Map Editors
http://apocalyptech.com/eschalon/
GNU General Public License v2.0
8 stars 3 forks source link

Issue with drop downs on edit item window? #40

Open raverdave2k opened 10 years ago

raverdave2k commented 10 years ago

Just discovered a bit of an issue that I'd not seen previously regarding all the drop down boxes on both tabs of the edit item window.

They appear with a large amount of white space at top on some (All of the modifier ones) and the bottom on others (Caeagory) and I can scroll right off the top / bottom (using the mouse wheel) until there is only white, however if I scroll until the first / or last entry are at the edge of the list the issue seems to correct and I can no longer scroll back to the white space.

The subcategory drop down appears fine when first opened but I can still scroll off the top, with the exception of one line the 'white spaces' are not actual highlight able entries.

All of the drop downs on the main window are unaffected and display exactly as they should.

I've upload a picture what will hopefully explain what I'm talking about: http://eschalon.raverdave.co.uk/drop_down_issue_img1.jpg

raverdave2k commented 10 years ago

Just looked a little further and it applies to some of the drop downs on the same window in the map editor as well, namely the "Entity Type" and "Object Type" fields.

apocalyptech commented 10 years ago

I actually think that's largely a function of the gtk+ theme in use (and possibly the exact gtk+ version, too?), and probably not something we can directly control too well... I've been used to the dropdown whitespace thing from other gtk+ apps, though on my Linux box, I can't actually scroll to a state of full-whiteness like you can.

The theme which we're now bundling in with the Windows executable (committed an hour or two ago) seems to not display this behavior at all, at least on my box. Could you see if a compiled version exhibits this behavior on your end? Thanks!

raverdave2k commented 10 years ago

The version I was running when I noticed this was actually built from the latest code in your working branch that I'd only just downloaded after seeing you had resolved the theme issue.

Strange though that it only happens on some drop downs and not others, does it depend on the number of entries?

apocalyptech commented 10 years ago

Yeah, basically the dropdown allocates as much space as it would need to draw the entire dropdown on the screen at once. So for dropdowns with tons of items, the "currently selected" item has to be wherever your cursor is (somewhere in the middle of the screen) but it likes to have an area to draw into as you scroll down, hence all the unused whitespace.

I agree it's pretty odd. I could see if there's some way to restrain the dropdown draw heights, I suppose, though I do rather like having as much of that info on the screen at the same time as I can.

apocalyptech commented 10 years ago

Oh!

Well, actually, I'm wrong - it's pretty easy to avoid. Hm. I suppose I should probably put that in place to avoid the weirdness. I'll get that in for 1.0.0. Thanks!

(For my own reference more than anything else, it's set_wrap_width(1) on the ComboBox which prevents the whitespace.)

apocalyptech commented 10 years ago

FYI, I don't think a fix for this one will make it into 1.0.0. I'm actually not too fond of the behavior we get with set_wrapwidth(1) (I'd actually prefer the weird whitespace)_ - set_wrapwidth(2) (or even three)_ actually looks pretty cool, but we'd have to sort the items differently manually in the code. Which is relatively trivial as these things go, but I just haven't found the time to do it, and I'd rather not delay the 1.0.0 release any further.

So yeah, we should hopefully get this addressed by 1.0.1 or so.