QEP: QGraphicsView

QEP: QGraphicsView

The idea is to use the QGraphicsFramework [http://qt-project.org/doc/qt-4.8/graphicsview.html] for drawing schematics. It is a high performance framework, allowing for a higher level of abstraction.

Current implementation seems to be rather low-level drawing routines with rather complicated architecture, and no separation between a schematic model and graphical representation. Some classes (essentially QScrollview) used will not be support by Qt5 anymore => long-term issue to make the code future-proof.

QGraphicsView and QGraphicsScene implements simple mouse interaction, such as selection and movement. This framework allows for extensions via overrides. Everything shown in the scene is derived from QGraphicsItem. Manipulations of the schematic model can be implemented through QUndoCommand. QundoCommands are created by "User actions", and may be associated to QGraphicsItems keeping track of elements in the SchematicModel.

(old: The proposal is to make all components subclasses of QGraphicsItem and the schematic becomes a QGraphicsScene / QGraphicsView. Wires will be subclasses of QGraphicsItem class as well.)

(NB: Making all components subclasses of QGraphicsItem is not a necessity to achieve the above, hence it should not be done. Legacy code should be moved around, out of the way, and made optional, but changed as little as possible.)

Status

• Current work in progress is https://github.com/felix-salfelder/qucs/tree/refactor%2Bqt5. It implements the basic framework for SchematicModel, Symbols, "mouse actions" and an undo stack. It lacks Diagrams.

• There are ready to use svg-based symbols that could be used instead of the ad-hoc Component graphics based on graphics primitives written in C++. https://github.com/damiansimanuk/qucs-qt4. (cf https://frhun.de/qucs-icon/preview/ for alternative looks).

• There is a proof of concept here https://github.com/ClemensFMN/QucsQT5PoC which allows placement of components, connecting them via wires, and exporting the schematic as a netlist. Component attributes (e.g. resistance...) is not implemented; this should be no big issue. What is complicated, though, is the drawing of wires on a grid in a rectangular fashion. It is also unclear how to integrate this standalone approach back into qucs.

• There is one branch "new_GraphicsView" on sourceforge git, one at Github [https://github.com/guitorri/qucs/tree/GraphicsView] which are based on the current qucs source. Components subclass QGraphicsItem, but currently no wries are supported.

• In the move to QGraphics Framework we should attempt to clearly separate the logic from the graphics and UI. That would make easier if we decide to change again the graphics in the future. Documentation is also welcome. (This is the approach pursued in the "refactor" branch -- felix).

• 2014/03/17 see [https://github.com/Qucs/qucs/tree/QGraphics_test] for a cherry-picked set of commits, rebased on current master.

• See [https://github.com/Qucs/qucs/tree/QGraphics_test] for a simple proof of concept:

  • sections where commented out, grep look for the !out marker withing commented code
  • sets the schematic as a QGraphicsView
  • subclass Component from QGraphicsItem
  • implemented rudimentary Component::paint enabling to draw components
  • can pick and place components into schematic
  • that is pretty much all it does
  • draws the grid, sets the background color, and enable some interaction with the scrolbar/zoom
  • ... I (Guilherme) tried a few other things, I am not yet really familiar with QGraphics Framework

• See below an screenshot for the current status of the branch QGraphics_test

Alternatives

• Another option is to redesign the graphics around the recent Qt QML. QML [wiki] [Qt] is a javascript-base declarative language for designing UI interfaces. It is meant to make use of OpenGL and used in touch based devices. Supposedly it performs better than QGraphicsFramework (which is said not to receive any further performance improvements). This move would mean that the Qucs GUI logic and graphics need to be clearly separated, which is not a bad thing, perhaps very laborious task.

• Counter argument against QML. QGraphicsFramework is good enough to very good. Learning QML at this moment is not the best for the project. To exemplify, other applications [KLayout] can draw an immense amount of things effectively with this framework. In the following Qt Forum thread [Qt for 2D graphics] QGraphicsFramework is indicated for circuit schematics due to better documentaion, C++ compatibility and scalability.

• There is nothing wrong with alternatives. With a proper code base, it should be possible to add a document tab with an openGL view, implemented whichever way. There is currently no indication that this is neccesary, but it could be interesting.