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.
The previous method relied on `any` type and `instanceof`, but the new
method relies on string-based mappings, providing better safety and
clearness.
Also, `CONFIG` now maintains a list of layouts, instead of boolean
values (`enable*Layout`). This will allow implementing extra features
like configurable default layout, configurable layout initial states,
etc.
