Cutter: Layout saving/switching

[xarkes]

The idea is to have some presets layouts (Default, Debug, ...) and have a menu that allows one to switch from one another.
Also the menu should provide a way for the user to save a layout and reopen it later.

[ITAYC0HEN]

@optizone you may want to have a look on this :)

[karliss]

Here is my proposal for this.

• Add serialize(QJsonObject) and deserialize(QJsonObject) methods to CutterDockWidget. Different widgets can then store their view related fields in there. For example word width and kind for hexwidget or layout algorithm for graph view. That would allow saving a layout containing multiple widgets in different configurations.
• Move unsync status saving to serialize(QJsonObject) for MemoryDockWidget.
• Define the layout as structure consisting of
  
  
  
  • list of widgets
  
  
  • geometry
  
  
  • dictionary with serialize(QJsonObject) output for all widgets
  
  
• refactor mainWindow to load save layout to this structure instead of bunch qsettings fields

[thestr4ng3r]

Sounds very good to me! QSettings is actually more powerful than how we currently use it since it has builtin support for arrays and groups, but I find it kind of awkward and json can definitely be more flexible and clean here.

[karliss]

My current plan is:
As for the actual plan:

1. refactor all the layout state into single structure, making it obvious where it's being operated with. Change the functions so that the GUI code calls more less only (getLayout(), setLayout(), loadLayouts(), saveLayouts()). Instead of current situation with initLayout, readSettingsOrDefault readDebugeSttings, saveSettings, saveDebugSettings, resetToDebug, RestoreToDebug, resetToDefault, ......

All the layout changes should function more or less the same initializing things more or less from 0.

1. Allow CutterDock widgets to include part of their configuration as part of layout. As described above.
2. In a separate PR allow saving more layouts. After the previous refactoring this should be relatively easy.

[ITAYC0HEN]

Sounds about right. I'd be happy for helper functions for layout authors to basically read the author's mind and sitck the widgets as they plan. Not sure how much of them helper functions Qt provides by default, I don't find it very nice to design the looks how I want via code.

Also, we have some glitches in the layouts sometimes and maybe we should discuss them as part of the PR - for example, the surprising change of Cutter's window size on emulation&debug, the opening of new widgets outside the main dock, etc

[karliss]

Yes, I saw some suspicious code related to resizing and was thinking if size should be part of layout or not. I guess it's less surprising to preserve the current window size instead of restoring whatever was used when layout was created. Will look into how it interacts with dock state restoration and detached docks. It's probably possible to come up with setup where window size is important part of layout but most of the time resize is unexpected.

[karliss]

Basic stuff is working. Created the layout saving and switching earlier than expected because it's easier to test it that way.

I am currently working on window size handling. Looks like not changing it when switching profile doesn't cause problems.

Rest of the remaining work:

• [x] geometry restoration when opening main window
• [x] action checkbox state
• [x] initial tabs
• [x] part sizes after reset
• [x] new dock widget placement (plugins and changes in Cutter)
• [ ] layout management UI polishing

[karliss]

When working with creating the initial dock layout from code it seemed that when using addDockWidget((left|right|top|bottom), dock) it produced layout that seemed ok, but behaved buggy when you tried to interact with it. Buggy behavior includes: inability to resize some of the docks in specific directions, slowly changing dock size when moving mouse over the division line, dock disappearing and later popping back when you try to resize other docks. Reproducing the same layout by manually dragging the docks resulted in working layout. Maybe this function and corner config works better in situation where you have a central widget and the placement of 4 sides is clearer.

Switched to using only splitHorizontal and splitVertical which didn't seem to have the same problem.

[karliss]

694 implements most of the changes. Second part should add layout management UI.

• simple dialog for renaming and deleting layouts
• in the layout save dialog use input combox instead of plain line input to allow more easily update existing layout.