[Ktechlab-devel] using SVGs

Julian Bäume julian at svg4all.de
Tue Nov 17 11:32:02 UTC 2009


moin,
I want to separate this discussion from the original thread. Here is, what I 
have in mind, when thinking about how the visualisation of components should 
work:

First there is a circuit. It is represented in a CircuitDocument, which can be 
saved and loaded from disk (in form of some XML-files). This part of the code 
works good and I have no intentions to change that (except for porting it to 
kdevplatform base-classes, which I have done already). Everything needed for 
painting that circuit into a scene is stored within the CircuitDocument. E.g. 
the positions of the components, rotation, connections,...

Now about how to visualise each component. This is were the current 
implementation is somewhat flawed. The code painting components in the KDE3 
version is directly integrated into the component classes. It is done, using 
basic painting operations on QCanvas. This is were I started reimplementing 
things. The shape of a component should be described in SVG-files. The dynamic 
parts of a component (like the little voltage/current indicators) can be 
positioned and layed out with place-holder elements in the SVG-file itself and 
view will take care to visualise the data from the model respecting the layout 
described with these elements. It can even decide not to visualise any dynamic 
parts, at all. This will result in a plain visual representation of the 
circuit, which could be exported (as plain SVG or some other kind of vector 
graphics) and included into some technical paper.
This is a first milestone I want to reach. Paint a plain circuit, loaded from 
a .circuit-file, into a QGraphicsWidget. This is nearly done, using 
abstractions of these classes (in form of KDE's plasma framework). I want to 
remove these dependencies on plasma and do it with plain Qt classes. What 
still requires some work is collecting all components, we got now (and some 
additional ones, like the US-resistor-symbol,..), as SVG-files. This could be 
a base for all components. Since now we got these voltage/current indicators, 
rendered onto the pins of each component, these could be integrated in this 
step, too. I'm not sure about that, since it can also be done later. May be, 
the SVG-files should contain that information (constraints of the indicator, 
represented by an SVG <rect /> element). This information can be classified 
using the class-attribute.

One next step is to implement "interactive components". There are some 
components with discrete states (switches), some with analog states (variable 
resistors) that the user should be able to interact with. This can be done by 
clicking or dragging. As before, all layout specific information should be 
defined in the SVG file and the Qt classes will take care of the interactive 
part. Again, these specific elements can be classified in the SVG file to 
provide a semantic meaning that can be evaluated by the drawing object.

Well, there needs to be done even more, I just wanted to start. As soon as I 
can edit the wiki, I will setup pages containing this information, to provide 
a starting point for a definition and documentation for the visual part of the 
KTechLab components.

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20091117/375c3ce1/attachment.sig>


More information about the Ktechlab-devel mailing list