Tabbed user interface
Implements UX proposal inbox#2061 (closed) - a tabbed user interface. Inkscape windows can now have multiple tabs. Here it is in action:
The video shows off some of the main new features (albeit of an older version):
-
Operations that formerly opened in a new window (e.g. New, Open, Open Recent / Template) are now diverted to the active window if possible, where they appear as a new tab.
-
The tab bar is hidden by default, and appears when there is more than one tab globally.
(This UX is up for discussion, as is the visual appearance of the tabs, which is just my fairly naff placeholder attempt. It has various easy-to-fix problems (at least for @mkov), e.g. the height is too small, the active tab is hard to distinguish, and the 1px border appearing/disappearing makes them jump around.) -
Tabs can be switched with Ctrl + Tab and Ctrl + Shift + Tab, assuming the current tool (e.g. the node tool) doesn't hijack the shortcuts. I don't know what the equivalent shortcuts are on macOS. These shorcuts sadly had to be hard-coded, i.e. they can't go in the shortcuts file, because GTK reserves Tab as a special key.
-
Hovering over a tab shows a preview. A special case is made for the active tab, where the image is suppressed, leaving only the title.
-
Tabs have close buttons, and a context menu that allows various actions: detach,
duplicate, close. (Others could be added, e.g. close others, move to window...) There is a different menu when you click off a tab. -
Tabs can be dragged to reorder, detach, or migrate them between windows. This part was rather predictably a PITA to implement and only made harder by GTK bugs like gtk#6940.
Sadly, it's unlikely to work properly at the moment on macOS / Windows due to gtk#6906: Drag and drop doesn't work outside of linux (which really needs fixing before Inkscape on GTK4 can be released anyway).Somehow it's reported to work. -
All tab state is persisted, including the active tool. @adam.belis reported that as undesirable in !4692 (comment 1059791774), but I disagree: what if you're in the middle of selecting a bunch of nodes, or in the middle of shape building? Then all the state will be lost if you switch to another tab, change tools and switch back. It's also not what happens if you switch windows in Inkscape today.
-
The document saving logic works the same as before, only now Alt+F4 closes all the tabs in a window, while Ctrl+W closes just the active tab.
Internals and reviewability
This MR takes the point of view that "an SPDesktop is a tab". In doing so, it leverages the existing SPDesktop class heavily to provide the necessary tab-window separation. When you are dragging tabs between windows, what you are really doing is dragging SPDesktops between DesktopWidgets. Of course, DesktopWidget assumes in a lot of places that it only shows a single SPDesktop throughout its lifetime. So, the bulk of the work was to find all those places and fix them up. The main offender was the Toolbar class hierarchy, which makes up 80% of the diff which was dealt with in !6710 (merged). Another 10% comes from depending on !6555 (merged). The remaining 10% (the last commit) is the actual tab enablement.
This MR's commit structure is currently a large blob, from which I intend to break off several manageable chunks for review. The code still has a few fixmes left, so it's still draft and I'm not asking anyone for review yet. Not least because there's a bunch of tangential fixes and refactoring that needs to be split out. That said, if you browse the code and see some major red flags you don't like or design issues, feel free to flag it up. I hope to post some more detailed explanations of the changes on the chunks later. However, it is currently at a stage where testing would be useful, so here we are. This has now been done, leaving this MR as a single minimal commit.