single window + has focus -> active border
single window + no focus -> inactive border
multiple window + regardless of focus -> active border
a) option set:
1) Single *visible* window in the layout - always draw a border
border color = active if os_window is focused else inactive
2) multiple visible windows in the layout - no change in existing
behavior, in particular draw_minimal_borders is respected as before.
b) option unset - no changes from present behavior
option default to false.
Adds a new configuration option `draw_borders_when_focused` that allows
borders to be drawn around windows when the OS window is focused,
regardless of the layout or number of windows.
This is useful for:
- Seeing which terminal window has focus in layouts like stack that
normally don't show borders
- Showing borders even when there's only a single window
- Providing visual feedback about OS window focus state
When enabled, borders use the active_border_color when the OS window is
focused and inactive_border_color when unfocused. This behavior only
applies when the option is enabled, preserving existing behavior by
default.
The implementation:
- Adds the draw_borders_when_focused config option (default: no)
- Modifies border drawing logic to check OS window focus state
- Triggers border redraw when OS window focus changes
- Only affects behavior when the option is explicitly enabled
Add a "copy_or_noop" option which copies the text, and if there is no
selected text passes through the key. This allows applications to
implement native text selection but also have cmd+c still function as a
copy key since they can now receive it.
Make this the default on macos. This should have very little impact on
users because when no text is selected, the application can
(potentially) handle the key.
This was needed to fix various corner cases when doing blending of colors
in linear space. The new architecture has the same performance as the
old in the common case of opaque rendering with no UI layers or images.
In the case of only positive z-index images there is a performance
decrease as the OS Window is now rendered to a offscreen texture and
then blitted to screen. However, in the future when we move to Vulkan or
I can figure out how to get Wayland to accept buffers with colors in
linear space, this performance penalty can be removed. The performance
penalty was not significant on my system but this is highly GPU
dependent. Modern GPUs are supposedly optimised for rendering to
offscreen buffers, so we will see. The awrit project might be a good
test case.
Now either we have 1-shot rendering for the case of opaque with only ext
or all the various pieces are rendered in successive draw calls into an
offscreen buffer that is blitted to the output buffer after all drawing
is done.
Fixes#8869
