A problem with adjusting nested LayoutPart was that adjustments were
"duplicated". For example, if two HalfSplit parts were nested, resizing
one window will adjust both parts instead of one. This behavior is not
desirable.
So, to fix this, ILayoutPart#adjust now returns a RectDelta, to change
how outer parts behave. For example, an inner part can remove a field in
RectDelta(e.g. north) to prevent outer parts from reusing the field for
another adjustment. So, the duplicated adjustment can be fixed by
"consuming" delta values in inner parts.
Implemented only `apply`. Need to work on `adjust` and shortcuts.
It's unclear if the split ratio values should be derived from window
weights, or keep them independently in the layout. I think the latter is
more practical. Maybe both, but let's see what can be done.
This implements rotation of master of Tile layout. Not implementing
rotation for stack at this point, because it requires an access to
window list, which isn't possible atm.
This is a little timer-based hack that make the script work without
compositor.
This is not a "true" solution, because, rarely, it takes longer than
50ms to get "windowShown" signal after "windowAdded", and, if this
happens, the window *might* freeze. If the delay is longer, it ruins the
experience.
I also tried to get the state of compositor through
`option.compositingInitialized`, but it seems like the property is
removed in the actual code. I couldn't find any other reasonable
methods.
The original logic relied on the fact that each layout instance carries
around predefined class IDs. However, this is cumbersome and pretty
hacky in terms of design. Also, it's not easy to declare multiple
layouts using a single layout class(ILayout).
In the new method, IConfig instances are reponsible for providing ID,
order, and factory of each layout. That is, the mapping b/w the
layout ID and the actual layout is only known to IConfig. This allow
clear separation of responsibility.
Note: there's another solution which might work better: layout
expression. This is an over-engineering in the current state of the
script, but once the support for external config file is implemented,
this can be pretty useful.
RotateLayoutPart allows rotating its child LayoutPart (and also supports
layout adjustment).
Note that "rotation" here isn't real degree-based rotation. This is an
intentional decision to preserve stack-growing direction (top-to-bottom,
left-to-right).
Resizing one window adjusted windows in both stacks. This was because
all tiles were passed for adjustment to either ones. This was fixed by
passing only tiles that belong to each of the stack.
Krohnkite implements a policy that automatically floats all
non-resizable windows to prevent breaking layouts. However, when a
window is started directly in fullscreen, KWin naturally reports that
the window is not resizable, even when it' resizable in non-fullscreen.
This causes confusion in Krohnkite, and the script wrongfully floats
such windows.
This commit fixes this by delaying the application of the policy as much
as possible. New windows are initially marked "undecided", and the test
will be performed only when it's required.
The previous default behavior was derived from dwm. It totally make
sense for dwm, because it has "tag" system instead of virtual desktop.
However, most people are more used to virtual desktop system and
consider each desktp as physically independent entity. Thus, it makes
more sense to turn this on by default.
This allows backends to decide what "maximization" actually is. This is
better than directly controlling maximized windows in Engine, because:
1. This works well with the KWin maximization animation effect.
2. The logic is simpler and more adaptable.
This feature is implemented by adding a new window state: Maximized.
It's almost like FullScreen, but window geometry should be manually set
by Engine.
