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...

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

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.

Updated to current state of master.

Also now supports all integer widths. The current code only gives odd-width borders, and my old code yielded just even-width borders. Now it does any integer so eliminates any large jumps as settings and scale are changed.

Default width is now 3 pixels at 1X scale with auto line width, which is exactly what we get visually currently, but is three times easier to hit (hit size is 3 pixels rather than 1)

Default width is 6 pixels at 2X scale with auto line width, so exactly double which is ideal. 1 pixel narrower than at that scale currently (is 7) but still twice as easy to hit. Hit size is 6 pixels versus 3 now.

Because all integers are supported the setting is now an integer range:

Updated to current state of master. Now allows 1-10 border width (3 as default). Corners are rounded a bit nicer.

Updated to current state of master. And corners are now AA...

Updated to current state of master plus...

Removed the user preference for border width. Instead it starts at defaults that match what we see currently and (like now) changes with the Line Width setting.

TL;DR version:

At 1X scale (and default line width) the borders look the same as now but are three times easier to hit. At 2X scale the borders are 6 pixels wide (versus 7 pixels now), but are still twice as easy to hit.

Generally the widths change in nicer and more predictable ways but still remain much easier to hit. For example, selecting "wide lines" while at 1X gives a width of 5 pixels (instead of the current 7 which is too much of an increase), but is still 1.5X easier to hit (5 times easier than current regular width). Wide lines at 2X gives 10 pixels, which is about the same as now (9) but is twice as easy to hit. Basically what you see is what you can hit. LOL

Some details:

I had hoped to simplify the editor-spacing code in area.c a bit, but it turns out that I do have to continue supporting arbitrary border widths. The current code always results in odd-sized gaps and widths, but this code necessarily results in a more scaled result. So a 3-pixel gap at 1X results in 6 pixels at 2X, rather than the seven we get now. So obviously I need to support even and odd values.

A couple changes seem disconnected from the main issue. This is because removing the overprinting lines can expose some problems not noticed before. Like on the right side of the tabs in the Sidebar there was a faint line so had to make a one-pixel fix there. TopBar similarly has a (mostly) hidden main region that was always drawing a line below it. Couldn't remove that unused area so just clear it to outline color.

I'm hoping nobody notices that I have not altered the define for header height. With this patch the entire height of the defined header is shown, rather than having a couple pixels cut off at the top of it. But we can really use the extra couple of pixels there.

In creating the rounded corners I had to copy in some AA_JITTER values into screen_draw.c because I could not figure out how to get at them otherwise.

But seems to work quite well.

Updating to current state of master.