This patch tries to make header buttons' offsetting a bit more predictable and smooth by postponing the offset check at drawing time in a non-destructive way.
An example can clarify.
If you have resized the 3d window and moved its header for instance to have fast mouse access to the Snap Tools and you temporarily widen the 3d view because you need a little more space for modeling, when you resize back the 3d view to its original thinner size the Snap Tools buttons become hidden again because when there's more space to make the old offset invalid the offset gets hard-set to a value that fits the space, which is conceptually wrong. What it should do is to check if the offset is valid or not and if it's invalid use a valid one for drawing but leaving the old user-selected value intact. The offset value should be hard-set only when actually modifying the value (ie, when MMB-moving the header). This patch does exactly this and so avoids this problem because when you resize the 3d window the Snap Tools remain visible because the old offset is used being now a valid value.
Another example for those who use vertical buttons windows. When using them vertically in order to be able to see all the material sub-context buttons you have to MMB-move the header but if you then select the editing context buttons and reduce the application on the taskbar and then resume it you'll find that your buttons are moved and if you now select the material's buttons they'll stay at the new position and you'll have to again MMB-move the header to its original offset in order to see all the sub-context buttons again.
Long description I know but it's a little bit hard to explain with words, better trying it out repeating the steps above on the current trunk and then with the patch applied.
Description
Description
Event Timeline
Comment Actions
Could you check if the old behaviour that you're trying to fix still exists in 2.5? The headers there have been recoded already, so this fix is probably not relevant there.
Comment Actions
Actually the old behavior is still present in 2.5 although I'm not really sure this patch is still valid for 2.5 (I highly doubt it).
Anyway this was just a small fix for 2.4x as I don't believe a final production-ready 2.5 will be ready until next september which means almost 9 months of 2.4x are still there.
Comment Actions
Hi, trying to update the status of the patch tracker. Please respond if this patch is still viable/useful and needs review or if it can be closed.