Julian Bäume wrote:
> On Thursday 25 March 2010 14:14:39 Alan Grimes wrote:
>> Julian Bäume wrote:
>> That's a surprising comment because I had understood ECNode to be a UI
>> class that represented a junction between to wires (connectors),
>> represented by a small dot.
> A sorry, I mixed that u
On Thursday 25 March 2010 14:14:39 Alan Grimes wrote:
> Julian Bäume wrote:
> > That's exactly what I had in mind... Not really with XML, but an easy way
> > to provide the equations from external sources and not hard-coded into
> > many, many cpp files, as it is done right now. Using Qt and KDE
>
Julian Bäume wrote:
> That's exactly what I had in mind... Not really with XML, but an easy way to
> provide the equations from external sources and not hard-coded into many,
> many
> cpp files, as it is done right now. Using Qt and KDE technology will really
> help us, here. You wanted to do
Julian Bäume wrote:
> I don't see an easy way to change this, without bringing back the "one class
> for each component" problem, which IMHO doesn't scale.
Yes,
But,
we are only trying to *PORT* ktechlab right now.
Moving to loadable components at this juncture goes into Deep Design
Decisions
hi,
On Tuesday 23 March 2010 12:15:30 P Zoltan wrote:
> I've looked more closely to the source code of kde4-port, and observed a
> strange thing: CircuitModel needs an instance of Kdevelop::Core, and
> internally has a pointer to a Circuit plugin object. In my opinion this
> can cause problems f
Hi,
I've looked more closely to the source code of kde4-port, and observed a
strange thing: CircuitModel needs an instance of Kdevelop::Core, and
internally has a pointer to a Circuit plugin object. In my opinion this
can cause problems for test case writing, because then running tests
