[Ktechlab-devel] A random thought that made me smile (and another point in favour of GUI separation)

[Matthew Ayres]

>> I like the suggestion of SVG graphics, especially as the SVG standard
>> has official room for customisation which may be useful.  I would be
>> happy to build up a library of graphics, if that meets with approval.
>
> I read the wikipedia entry on that. Okay, so it's an XML format... I
> have not been able to find any authoring tools yet (much less figured
> out how to use them...)

For my standard SVGs I use Inkscape, which is fantastic.  We can
always expand the SVG DTD/Schema (which ever we decide to use) for our
purposes and add in code (and strip unneeded code) in a text editor.
It looks as though Julian is already working on the SVGs so I guess
I'd risk duplicating work?

> It is very reasonable to do this prior to the KDE4 port because the
> existing code does essentially the same thing in QT3 calls written in
> C++. Converting these to SVG sounds very reasonable. I just don't know
> how to do it myself. =P

Agreed, naturally.

> There are some places where the shape of the component needs to be
> responsive to the configuration of the part. It seems reasonable that
> dynamically generating/editing the SVG in those cases should work.

Yes, that would be particularly nice.  I can think of a couple of
examples (LEDs for instance) but if you would like to list the ones
you're thinking of that might be helpful.

> One thing I would like to see is the standard ---/\/\/\/--resistor
> symbol in place of the existing box shape.

My understanding is that the box symbol is the international standard.
 It's certainly what every textbook I've had has used ;)  However, it
might be worth having a little function in the GUI to switch between
the two systems, especially if there are more differences.

>> How about a discussion thread to agree on what the interface for a
>> base component class should be?
>
> I'm not sure what you mean.

Julian has indicated he's taking care of creating the discussion
space.  But what else I mean is that we should have a clear idea of
what the software interface will be for the base class (non-visual) in
the component hierarchy should be.