Page MenuHome

"Menu Shadow Width" theme setting influences tooltip size
Closed, ResolvedPublic


System Information
Win7x64 GTX660M

Blender Version
Broken: 2.72 release

Short description of error
When "Menu Shadow Width" is set to maximum (24), tooltip is shrinked to the point where it truncates content. Conversely, at 0 it creates a big margin around the tooltip.

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Event Timeline

Hadrien Brissaud (hadrien) raised the priority of this task from to 90.
Hadrien Brissaud (hadrien) updated the task description. (Show Details)
Hadrien Brissaud (hadrien) edited a custom field.

I've confirmed this in 11e7679.

Menu Shadow Width: 0:

Menu Shadow Width: 12 (default):

Menu Shadow Width: 24:

@Julian Eisel (Severin), I've been digging into this a bit. It's a similar issue as T41548. It also causes problems with the Search Menu and seemingly any other pop-up menus/UIs. I believe this is due to each of them using the UI_ThemeMenuShadowWidth to define partially define the width and padding of the pop.

Are you aware of any reason why these would be using UI_ThemeMenuShadowWidth?

Lines 669-683 of interface_regions.c

	/* widget rect, in region coords */
		int width = UI_ThemeMenuShadowWidth();
		data->bbox.xmin = width;
		data->bbox.xmax = BLI_rcti_size_x(&rect_i) - width;
		data->bbox.ymin = width;
		data->bbox.ymax = BLI_rcti_size_y(&rect_i);
		/* region bigger for shadow */
		ar->winrct.xmin = rect_i.xmin - width;
		ar->winrct.xmax = rect_i.xmax + width;
		ar->winrct.ymin = rect_i.ymin - width;
		ar->winrct.ymax = rect_i.ymax + width;

Seems to me that the shadow width and padding width should be separately defined?

We (@Jonathan Williamson (carter2422) and myself) talked a bit about this on IRC, but I should share it here, too, so...

The problem we have with the tooltip code is that it is a real mess. There are multiple rectangles to determine the sizes of text, background, padding, shadows, ... The biggest issue is that they depend on each other, quite weirdly, making it hard to do working changes. With the tooltip design update, I did some months ago, this only got worse, but since this was a much needed update, it was worth ignoring the added mess.
However, we could just try to fix this bug only (what would probably make the code worse again), or try to fix the complete system beneath it. I would much prefer the later one, as this would make further changes much, much easier.

I'd like to spend a bit of time on this tooltip code refactor and as I'm quite busy with other projects and the bug itself isn't that high priority (IMHO), I'll postpone it for a really few weeks.

Thanks a lot for the report @Hadrien Brissaud (hadrien)!

I agree with you @Julian Eisel (Severin), the latter method of refactoring the tooltip draw code is a better route. This is a low priority bug in my opinion that most people will never even encounter. Seems to me it's worth doing it right rather than just applying another bandage.