Add document type

[Tectu]

Currently, the Scene represents the actual contents. A better approach would be to have a separate Document type representing the document itself. The Scene will then have a load() interface to load a Document and save() interface to save to a Document. This will essentially decouple the diagram/schematic itself from the scene logic.

[bjornstromberg]

a dream would be to be able to have a document, of documents

so a component can be expanded into its own dynamically

exactly how this would look in reality is still kinda foggy for me, but essentially it would be start with a component and just explode it deeper and deeper..

would this be useful?

well if I had a wall of screens in the office I sure would like to have everything on screen at the same time..

i'll check back in like 5years and see if i got that wall of screens yet.. :roll_eyes:

[Tectu]

Nested documents - yeah. The current "solution" based around QSchematics::Items::Item technically was meant to do that. Have a look at the features/subgraph. There's a bit of a conflict with visual representation vs. data though. Ideally, you'd want the two to be entirely separated. However, Qt does not make that easy without writing a lot of boilerplate code.

The proposal of this issue is mainly focused around taking out the business logic of the Scene. Right now, when you consume this library in an application which has a properly designed data/document/file storage and I/O layer, you're essentially passing the scene around in there which certainly does work and doesn't really have any real consequences that would result in problems/show-stoppers but it's definitely not pretty from a software design perspective.

This library started off as a hobby project when I was quite young (< 20) and didn't have enough software engineering experience yet to design things properly. I'm trying to improve that step-by-step without introducing any drastic changes. Eventually, a v2.0 will be necessary tho.

[bjornstromberg]

i think you miss understood my 'idea'/'request'

say you have Component X, Y, Z they are defined each in a 'Document'

in Component L2 we consume X, Y, Z, but those are only stored as a component overview, placeholder or whatever for that type of diagram. they though got a uuid so we can 'load' the contents on demand of that subsystem if its needed.

so the Document should have support to load other documents it depends on, but also to encapsulate that as a Component in-case that information is not yet needed.. this way the documents can reside in a server-side datastore until they are needed..

so if say i where to build a real time UI on top of a SCM/CI/CD system where stuff dynamically happen with animations, it should be able to load that data on-demand.. who knows one document type could even be a error or a report of some kind.. that one maybe get opened in a different view.. then they should defentivly be decoupled..

thats the beauty of Qt as a UI, most people hate QGraphicsView Framework, but after messing with it back and forth for years (pretty much since Qt 5.0 was a new thing.. i've actually coded in Qt4 back when it was the latest.. and hated it.. warmed up with Qt5.0), and making about every misstake possible i think its pretty damn good due to the extendability. but that is also the reason why its so easy to shoot yourself in the foot with it..

biggest issue i have with QGraphicsView Framework is the fact that you can have one Scene in multiple views, but you cant have one view with multiple scenes.. (stacked in a hierarchy)

[Tectu]

I did indeed misunderstand your idea/request.

What you're describing is partly what one of our applications does (which consumes this library). We're using the QSchematics::Items::Node class as a visual-only-container. The data is entirely decoupled from it and managed by our application. When a scene is loaded, those items get loaded in on-demand. We also have implemented that "get opened in a different view" approach.

I guess I was not clear myself before either: I like Qt and the QGraphicsViewFramework. In fact, I was devastate when Qt was discussing to deprecate it for Qt5. I'm very glad they didn't. The intention of QSchematics (or at least how we use it) is to serve as the view part. The data part is handled by the consuming application. When I stated that "Qt does not make that easy" I was referring to further separating views & data within the QSchematics library (which technically is already a view-only type thing).

biggest issue i have with QGraphicsView Framework is the fact that you can have one Scene in multiple views, but you cant have one view with multiple scenes.. (stacked in a hierarchy)

That is actually possible (and something we do in our application). But you have to "hand roll" it yourself. I'm honestly not sure how Qt could provide more infrastructure to facilitate this as it's IMHO very application specific.

[bjornstromberg]

I did indeed misunderstand your idea/request.

What you're describing is partly what one of our applications does (which consumes this library). We're using the QSchematics::Items::Node class as a visual-only-container. The data is entirely decoupled from it and managed by our application. When a scene is loaded, those items get loaded in on-demand. We also have implemented that "get opened in a different view" approach.

sounds like what I intend to do with QSchematics wont be much of an issue then

I guess I was not clear myself before either: I like Qt and the QGraphicsViewFramework. In fact, I was devastate when Qt was discussing to deprecate it for Qt5. I'm very glad they didn't. The intention of QSchematics (or at least how we use it) is to serve as the view part. The data part is handled by the consuming application. When I stated that "Qt does not make that easy" I was referring to further separating views & data within the QSchematics library (which technically is already a view-only type thing).

yea i understood that, Items::Node solution is a lower level encapsulation, the Document will be a higher level encapsulation, which i think should have links to other Documents, think of analogu as dynamic loading a library as a runtime plugin for example, the Document will hold a minimal object to identify the Nodes child Document, and if loaded a pointer to that document. reason for this is when stuff is 'owned' by different stakeholders and lives in different places they should not belong to the same file (the Document object) but they can and should be able to reference stuff they depend on.

biggest issue i have with QGraphicsView Framework is the fact that you can have one Scene in multiple views, but you cant have one view with multiple scenes.. (stacked in a hierarchy)

That is actually possible (and something we do in our application). But you have to "hand roll" it yourself. I'm honestly not sure how Qt could provide more infrastructure to facilitate this as it's IMHO very application specific.

i know its possible, and i've done it before, and shot myself in the foot a few times in the process.. and i think the Document between Scene and items is what is needed, its a idea I've had a few years now to decouple scene and items but not really sure how it should look..

requirements between apps can differ pretty much when trying to specify this requirement document for the Document..

make it general enough to not be perfect anywhere or AbstractionDocument + a general Document implementation and make the abstraction minimal viable, then override in Scene for specialized Document type interface..

the later was the solution i leaned towards, but its more work.

[Tectu]

yea i understood that, Items::Node solution is a lower level encapsulation, the Document will be a higher level encapsulation, which i think should have links to other Documents, think of analogu as dynamic loading a library as a runtime plugin for example, the Document will hold a minimal object to identify the Nodes child Document, and if loaded a pointer to that document. reason for this is when stuff is 'owned' by different stakeholders and lives in different places they should not belong to the same file (the Document object) but they can and should be able to reference stuff they depend on.

Yep, that is exactly what our application using QSchematics is doing :) Although not as elegantly as we'd like yet. We have a generic loader interface but we only implemented three types so far. The "located on remote storage" is somewhat high up on our ToDo list at the moment.

make it general enough to not be perfect anywhere or AbstractionDocument + a general Document implementation and make the abstraction minimal viable, then override in Scene for specialized Document type interface..

the later was the solution i leaned towards, but its more work.

Indeed.