As we have been working down some bugs from earlier changes, we
introduced some additional error conditions in the logs. Now that the
new focus approach is available, switching the stackbar to that means we
can avoid needing to pass down ForceUpdate and FocusChange events for
non-windows, which removes many of these cases.
In addition we do a check in should_manage that the target object is
actually a window, ignoring the event if it is not.
We had been setting managed windows to HWND_TOPMOST which is a sticky
and viral parameter. This was also the cause of the border window ending
up behind other windows in an undesirable fashion, as even though it was
marked WS_EX_TOPMOST, we were then having to mark it HWND_NOTOPTMOST
when raising it to avoid it ending up drawing over other windows.
Since we've fixed the border window to no longer be visible when
unmanaged windows are focused, we can now set the border window to
HWND_TOP when we reposition, which will ensure it's drawing in the order
that we want.
Now we also set managed windows only to HWND_TOP, rather than
HWND_TOPMOST which stops us from incorrectly reordering internal
concerns vs. child windows and owned windows that we're not managing.
Windows are still brought to the foreground as expected/desired, but
they're no longer 'sticking' there, nor are they drawing over the border
window.
This change does have a slight transition behavior as it initially rolls
out, as prior versions of the Komorebi have been setting HWND_TOPMOST,
which as a sticky parameter won't be cleared until the application or
host system removes that flag. This means that the final z-order
behavior will come good eventually.
To immediately see the correct results, restarting affected apps or
logging out / in will do. Unfortuantely we can't just set
HWND_NOTTOPMOST, as similarly to setting HWND_TOPMOST, this can cause
issues with an applications intended owned-window Z-Ordering - mostly
affecting toolwindows and child windows, such as file dialogs, toolbars
and so on, most of which we do not manage.
Use the same method as FancyZones to enable setting the foreground
window. This makes it possible then to remove the thread attachment
behaviors that have a number of other complex side effects, and aren't
always allowed.
In addition, cleanup old focus/raise methods some, in particular the
border window is now explicitly not activated when it is raised, as it
should never be activated.
We had a mut requirement on some of the Window functions which may have
been vestigial or in preparation for more state on Window objects, but
presently unused. I removed that, as the Window struct is currently just
carrying an HWND value that's essentially always immutable - there's no
advantage to ever reusing a Window struct vs. making a new one for
another HWND.
In doing so we then no longer needed to be passing in mutable events, so
I applied a little simplification of the event receiver / dispatcher to
process_event. After that it became obvious that we could just pass the
owned event directly into process_event instead, which substantially
simplifies the ownership model and lifetime for those objects.
This is small, and shouldn't create any meaningful behavioral change.
Previously we were dropping events that don't pertain to managed
windows, with one exception in should_manage that could probably do with
further cleanup (DisplayChange).
This first step fixes the latent border window problem, where we would
retain a border window when the last managed window was closed and focus
transitioned to an unmanaged window.
This trades one issue for another, in order of importance:
- Pop-up windows such as a file upload dialog box for Firefox no longer
have a window border drawn over the top - better.
- Opaquely bordered windows without DWM decorations, combined with a -1
offset / single pixel border end up as invisible borders (e.g. EPIC
Games Launcher).
The default window corner rounding is still slightly visible at offset
-1 until this corner radius that completely closes up the transparent
region, without needing to invasively draw over the target window.
topmost has a special meaning, in that it is a sticky raise, which is
not what we want - we don't want to be permanently above all other
windows, as this leads to bugs where for example the windows can end up
stuck above non-topmost windows in a different security context, such as
programs running with administrator priviliges.
In the new border painting strategy, the 20 pixel border is huge. The
border is now offset -1 by default, so as to draw over the standard DWM
1px border (avoiding a "1 pixel see through gap"), and the default width
is 8px.
The SetWindowPos API will inset the provided dimensions by the amount of
space required for window decorations (shadows, etc). Compute the size
of the decorations and add them as padding to the provided size,
resulting in windows being set precisely to the target dimensions.
An active_window_border_width=1, active_window_border_offset=-1 will now
paint over the 1px window decoration consistently.
The border window is always made topmost on resize, so that it paints
over custom borders (e.g. EPIC Games Launcher) as those borders are
opaque and as such a 1px border configuration as above becomes invisible
in that condition.
The layout should leave the space configured for the border, so that the
border always stays within the workspace bounds.
Border offset is cleaned up, as it is no longer a rect, but instead just
a fixed value.
The rect function for adjusting padding now takes a concrete value, as
the optional has no local meaning to the operation, being equivalent to
the default value.
A margin function is added to centralize the notion of increasing the
size of a rect by the given margin, the opposite of the padding
operation.
This fixes a regression from an earlier commit that dropped the DWM
style borders without fixing corner rounding on Windows 11. This is now
fixed for Windows 11 again, while avoiding the extra system border
decorations.
This makes the borders pixel-perfect, and border_overflow can be
disabled on all applications.
Unfortunately this also means we lose the corner rounding, so that may
need to be done differently or the offsets refined in some way to
address that.
Switch to using the DWM API to get Window bounds so as to exclude the
outside of window decorations from the computation.
This is getting close to a precise window size, you can now set an
active border width of 1 and an offset of 1 and get a 1 pixel line
around most windows, except that there's some extra top padding I have
yet to find the cause of.
This implementation needs to be DPI aware, but I haven't yet tested if
the DPI scaling approach is entirely valid - we may instead need to get
the per-monitor DPI scale, identify the monitor the window is on, and
scale to that, rather than using the system wide scale.
Maybe fixes#574
Maybe updates #622
- Use a single thread to bind the hook, and then start dispatching.
- Use a blocking loop for message dispatching.
- Remove the locks around crossbeam channel, as it's already Send + Sync
Replace the client socket with replies sent on the other side of the
querying stream, for both UDS and TCP clients. This has two results:
unix socket clients such as komorebic no longer race on the socket bind,
fixing the out of order bind error, and the response mixup conditions
that could occur. Queries over TCP now receive replies over TCP, rather
than replies being sent to a future or in-flight command line client.
James Tucker