[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