Page MenuHome

WIP Fix for T64956: Improving Window Border Selection
Needs ReviewPublic

Authored by Harley Acheson (harley) on May 26 2019, 3:57 AM.



I doubt this is a good time to consider such changes, but maybe for 2.81. This patch fixes a problem that most people are probably not aware of and is therefore difficult to explain...

To resize editor windows we need to place our mouse in the gaps between them and drag. But sometimes it is more difficult to position your mouse correctly than you would expect, especially if using a tablet pen. This is because the borders that you see are not the same size as the actual gaps.

The following table lists the difference between the gaps and the borders. You will see that not only are they always different, but that difference varies in unpredictable ways.

This patch makes it so that the positions of the editors and the gaps between them exactly match the borders that are drawn. This way you can always be assured that you can drag while your mouse is anywhere in the gap.

I tried to make it so that default sizes are as close as possible as they are now so most people would not notice a difference. Headers are currently defined as 26 pixels tall even though we see them to be 24 (because 2 pixels are covered). So this patch changes the header height definition to 24 pixels and removes an adjustment for this.

Doing this does bring us very close to being able to have borders widths as a user preference. This would be ideal as width of the borders should not really be tied to line width. You might be perfectly happy with how it all looks but then get a graphics tablet that requires wider borders. Unfortunately doing this would have to wait. The border line drawing code ties the border radius to the width of the border. So this would have to be change so we can keep radius (tied to scale) but vary only border width.

Diff Detail

rB Blender

Event Timeline

User Preference for Border Widths

As mentioned in earlier comments, the gaps we currently see between editors is not the same size as the actual gaps. This patch fixes that so what you see is what you get, making it easier to get the "resize window" placement correct. Right now we might see a 3-pixel border but have to hit a single pixel, or see seven and have to hit three.

Why a User Preference for Border?

Because this is not related to anything else. You might be perfectly happy with everything else and then get a tablet, for example. Or have perfect eyesight but have mobility issues making it difficult to hit the resize areas.

It looks like this in

Note that I'd missed some magic somewhere so this setting is not saving between sessions. Not sure why yet...

I'd go for what you see is what you get. Clicking on the gap even with +1 pixel on each side for extra safety. No user preference.

I've seen people (and myself) struggled with the current small action zone using both mouse and tablet. The current behavior is not something we want to keep.

@Pablo Vazquez (pablovazquez) - I'd go for what you see is what you get...No user preference.

Just to be clear though, this patch makes it always show a visual border between editors that matches pixel-for-pixel with the actual gaps between editors.

That alone probably helps. But I don't know if that will help enough in all circumstances. I have had (a small number of) people ask for thinner borders for some reason. But the (large number of) people asking for wider are quite often users of tablets and other pointing devices with lower precision.

So this patch has four user-selectable widths: A default that roughly matches what we see now, but should be easier to use. A "Thin" that looks interesting and works about as easily as regular does now. And two wider settings for tablet user and those with mobility issues.

But I don't have a tablet or any variation of equipment to test with. So it is possible that the multiple widths are not needed. Although my gut feeling is that the users who would need it would quite appreciate it.

@Pablo Vazquez (pablovazquez) ... with +1 pixel on each side for extra safety....

Yes, that has been something I also wanted to play with. Obviously can't do that now without what-you-see-is-what-you-get. But would still take some investigation as we do place some content close to the edges. If this patch is enough then adding an extra pixel on each side might be unnecessary. And would break that WYSIWYG advantage a bit when trying to select a corner "pin" button or open an area disclosure arrow (for things like Sidebar).

William Reynish (billreynish) requested changes to this revision.Aug 15 2019, 8:26 PM


The good:

  • It's now way easier to grab the area dividers

The bad:

  • There are visual artefacts along some borders:

  • The default border size has changed, and is now unacceptably thick:

This revision now requires changes to proceed.Aug 15 2019, 8:26 PM

@William Reynish (billreynish) - It's now way easier to grab the area dividers


There are visual artefacts along some borders:

There are. Some editors are drawing some things near their edges that we haven't seen before because they have been covered up by the current borders which are too wide. Something we'd have to address for that editor.

The default border size has changed, and is now unacceptably thick:

Yes, that sample (and I have confirmed) shows a border that is wider than my expected result (at 2X scale, auto line width, and default border width). Will investigate and fix.

It should now be giving the border sizes that I intended for larger interface scales.

Fixes an issue with TopBar displaying a 1-pixel wide region below header area (was cut off by the overlapping borders before so not seen)

"Area Options" menu works with variable-sized border widths.

Note that rounded corners are temporarily turned off while I hunt down a few more issues. But otherwise this patch is quite complete and I'd welcome any input.

Apply it, compile (including your source target), then go to Preferences / Interface and you should see a new "Border Width" option to experiment with.

Fixes a small glitch. Panel menus on right side were not completely filling their area with bg color. Out by one pixel. But we couldn't see that mistake because the over-wide borders were covering it up.

Nicer vertical centering of header content

Harley Acheson (harley) retitled this revision from Fix for T64956: Improving Window Border Selection to WIP Fix for T64956: Improving Window Border Selection.Fri, Oct 4, 6:58 PM

Updated for current master.

In a better shape for current direction of experimentation.

No corner rounding still. But the gap widths are user-selectable and are exactly WYSIWYG.

Small Adjustments.

Tab Azones (area reveal arrows) adjusted so they are consistent size, right at edges and with arrows centered. They were (mostly) assuming that a pixel or two were cut off, but this is not done here so have to move slightly.

No need for borders at left end right window edges.

Updated for current state of master.

Now lopping off the corners.

Experimenting a bit. Currently showing an extra outline around the active area - something we can't do now because of the way we currently overdraw the lines.

Following shows a portion of a window at 1X scale, with "Exta-wide" borders. It is certainly easier to hit these wider gaps when resizing.

Removing the (experimental) active area highlight

Adding a 5th border width. The Preferences panel now looks like the following:

Forgot to remove a little hack.