Controllers don't have any GUI and don't depend on the frontend
technology.
Views are implemented in a specific GUI tech (QtWidgets, QtQuick, etc).
For now only QtWidgets work. There's still a lot to decouple.
This will make it easier to introduce non-Qt backends.
Because some build systems don't support public/private includes,
and would require us to add private/ to the public include path.
This allows for an easier integration with some more exotic
build systems
The previous commit fixed that the dock widget wasn't
getting focused on tab change, but didn't fix the signal.
When changing tabs, FocusScope::setFocused() would bailout
early because it was already focused, so never emitted
the signal for the new focused dock widget.
Refactored the code a bit and it's more robust now.
Setting the current focused widget is now centralized in
DockRegistry. Before it was split in two different places.
Fixes issue #188
When we focus a FocusScope we focus the last focused widget
inside that scope. But it could happen that the last focused widget
was the tab bar itself, which isn't very useful.
Fixes issue #188
They don't work as expected across DLL boundaries on MSVC: connecting
to Frame::isFocusedChanged using the PMF syntax fails.
The reason has to do with how MSVC implements pointers to virtual
function members: they are "regular" function pointers to a DLL-local
stub that implements the virtual call. For that reason, a connect()
happening in client code would generate a pointer for the signal that
doesn't compare equal to the same pointer generated from inside KDDW;
and moc-generated code relies on this comparison to find the index of
the signal.
Just avoid the whole thing: rename the non-signal virtual call into a
"callback", and reimplement it in the first QObject subclass to turn it
into a proper signal.
When clicking on a TitleBar the focus will be redirected to either:
- Last widget that had focus inside the scope
- To the DockWidget. Implies the user setting a guest widget that
accepts focus
Fixes: #56
Github issue #56 is not a KDDW bug, it's how Qt works. QtWidgets don't
have focus scope. But let's workaround and handroll our own FocusScope.
Now the title bar can be colored differently if the dock widget it controls
contains any focused children.
This just implements half of the story. You have to focus a child
for the title bar to change color. Clicking the title bar directly
isn't done yet. Needs to be figured out. What do we focus when clicking it?
TitleBars usually don't care about keyboard focus. Probably we
just use the user's widget as a focus proxy.
