Page MenuHome

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.Thu, Aug 15, 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.Thu, Aug 15, 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.