The events simply need to be forward from QWindow to the FloatingWindow.
That happens automatically for QWindow/QWidget, but not with
QWindow/QQuickItem, so add this behaviour to QtQuick too, so it behaves
the same as QtWidgets and we have a single code path for aero snap
This gives a lot of power to the user to disallow tabbing two dock
widgets, while still allowing them to be docked side by side. As
this can't be achieved with affinities.
Instead of adding API which might not be enough soon, just allow
the user to pass a lambda and implement his very custom requirement.
Fixes#91
Native dragging is much better as Windows deals with crossing screen
boundaries, there's no reason not to want that.
Client-side moving is buggy within Qt, depending on the HDPI setting.
Fixes#86Fixes#78
The layouting was becoming too complex to maintain and to introduce
new features. Was even buggy, the fuzzer was constantly finding
bugs, which took hours to workaround.
Problem with the old layout engine is that there was a catch 22, between
Items driving the separators, and separators driving the anchors.
The new layout is much simpler, both in implementation and conceptually.
There's simply a recursive hierarchy of Item elements. An Item can either
have a QWidget to show, or be a ItemContainer, which contains Item children,
and so forth. Each ItemContainer is either vertical or horizontal. That's enough
to represent the "nested multi-splitter" concept which KDDW uses.
After each item insertion/deletion/resize, the separators are regenerated. They
are essentially dumb now.
TODO:
- Separators are drawn, but are not interactive yet
- There's 5 tests failing
- LayoutSaver scalling functionality
The static separators are the left,right,bottom,top ones. Since
they don't move, they don't need to be visible nor occupy space.
They only exist to make the algorithms easier
The framework uses a few QWidgets (FrameWidget, TabbarWidget, TabWidget
TitleBarWidget). This factory allows the user to provide his own,
to achieve different appearence.
