Only applied in a really few cases actually.
To reproduce:
* Open User Preferences *in own window*
* Search for node wrangler add-on (it's one of the few cases where this happens)
* Enable and open details
* Click on one of the menues in the add-on preferences
Actually this was reproducable in any window, user preference area just had to take up most/all of the width.
Note: I'm not totally sure if just disabling these lines is correct, but I didn't find any issues or any information why this was needed. So it seems to be redundant.
Needed to allow modal UI keymaps, but I'm sure we'll need this more often in future.
First item will be modal eyedropper keymap coming in a following commit.
With continuous grab disabled, non-linear mapping for int buttons
wasn't working usefully with small mouse movements.
Now 2x pixels motion adjusts by at least 1 w/ int buttons.
Displaying a button would clamp the value if the button was outside the range.
This could be OK in some cases,
however it's problematic with object dimensions which would re-scale objects on showing the panel.
Add `ui_but_update_edited` when its OK to modify the value.
Now a 'More' item is added to the pie when there are too many items. It opens a sub-pie that contains the remaining items.
Note that this only touches operator-enum pies (like the object mode pie is), it is not a complete support for pies with more than 8 items. For this further design and code work would be needed, but this is too urgent to wait for that.
This is a better fix for T46973, should definitely be applied for 2.77 release.
Patch D1800 by myself with some edits by @campbellbarton, thanks!
Each LINES draw call is now responsible for its own line width. No need
to set it back to its 1.0 default after every draw.
This eliminates half our calls to glLineWidth , similar to last week’s
work on glPointSize.
UI_panel_category_draw_all was setting PolygonMode to LINES before
drawing LINES.
stitch_draw was setting PolygonMode to its default FILL value — any
function that deviates from the default should’ve changed it back to
FILL.
I put all usage of GL_POINTS under the microscope. Fixed problems &
optimized a couple of spots.
- reduce calls to glPointSize by about 50%
- draw selected & unselected vertices together for UV editor & EditMesh
- draw initial gpencil stroke point the proper size
- a few other smaller fixes
New policy: each GL_POINTS draw call needs to set its desired point
size. This eliminates half our calls to glPointSize (setting it back to
its 1.0 default after every draw).
