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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
