0

The project I'm working on calls for workspace layouts for a large section of it, by which I mean that users can move around panes, resize them, close them, etc., like in VSCode (but more like Emacs since VSCode does not currently support both vertical and horizontal splitting).

The current methodology I'm considering to create a custom LayoutManager that has a json object and injects views into recursive Row and Column objects in a binary-tree-like structure. Before I start this undertaking, I'm wondering if there is a library or set of QtQuick (QML) elements that would let me do this a lot more easily or if there is a better approach to this problem. Or, please just tell me why I'm wrong in doing it this way.

Note: The technologies I'm using are C++ with Qt 5 (currently 5.10).

iHowell
  • 2,263
  • 1
  • 25
  • 49

1 Answers1

1

If you want highly customizable GUI, with the option of persisting UI configuration, it is best to design the whole thing model driven.

QML already has the necessary stuff - list views, repeaters and so on. QML is a little at odds with tree models, but you can essentially fake a tree by using lists of lists.

The model provided here will do the trick, with the added benefit it also supports declarative instantiation. So you can easily set up an initial GUI state declaratively, like you would with normal QML, but then allow the user to make modifications to that initial state which can then be saved and recalled.

Then all you have to do is bind the desired GUI elements to the underlying model data source objects.

dtech
  • 47,916
  • 17
  • 112
  • 190
  • That definitely answers how I would model the GUI state, but then how would I do that binding part? Supposing I just had three view elements, Row, Column, and View1, would I create components that loaded the Rows, Columns, and View1s with loaders in themselves to then handle the next part of the model? – iHowell Jun 27 '18 at 20:14
  • The "binding" part is implemented by providing every model item with information what GUI element to instantiate and source with data. If you want to go a level into the model, then simply that particular delegate implements a view on its own, which is set to use the particular model item as a model. – dtech Jun 27 '18 at 20:41
  • Alright, thank you. Do you know of any examples that would help me to get started? – iHowell Jun 27 '18 at 20:55
  • Well, not really, it is not the typical "by the book" stuff. Just start off with a small tree model and try to visualize that, then build on that design. You can always ask additional questions if you run into trouble. – dtech Jun 27 '18 at 21:22
  • Do you think that a factory would be suitable for this? For instance, each element in the model would have a config with a field for the type of view to use and the factory would inject said view type with the config? – iHowell Aug 06 '18 at 15:52
  • Well, if you save the layout, that is if you serialize it, then you will need some sort of a factory to deserialize the structure, so yes. I use a `QObject` wrapped `QDataStream` object with a `QBuffer` and a `QByteArray` with auxiliary functions for saving and loading from disk, so I can do binary serialization directly from QML. But you could also serialize the structure as valid QML source, and use that to have the QtQuick's own factory handle the instantiation, this way you don't really need the data stream, you can just compose a source string. – dtech Aug 07 '18 at 08:00