[Ktechlab-devel] kde4 port: CircuitModel instantiation from tests

[Julian Bäume]

hi,

On Tuesday 23 March 2010 15:42:24 Alan Grimes wrote:
> 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.
Well, "porting" the GUI means rewriting it. At least in our case. Since the 
QCanvas things are so tightly coupled to our Components and everything, this 
will also effect some parts that _should_ be quite easy to port..

> Moving to loadable components at this juncture goes into Deep Design
> Decisions which I want to have a say in. =\


> And because I don't have the tools to work on the new version right now,
that issue should be fixed.. but you must set-up these tools. the wiki 
describes some details you have to take into account, but basically it is 
possible to make it work ;) (for me it was just installing a recent version of 
KDevelop including the kdevplatform-devel files. After that, it's only fine-
tuning...

> I am really dismayed that changes are being made that will be difficult
> to revert in the future because I want to take it in a different direction.
I don't think most of the decisions I made are hard to revert. I haven't 
written too much code, I think. I checked for possibilities and reverted quite 
a few things, I tested and found that they wouldn't work very good for us.

> Elsewhere in your post, you described the plugin loader as working by
> "magic". This is unacceptable. If it isn't documented well enough to be
> well understood, then it should be ignored.
Well, I understand the technology behind all this. I called it "magic", 
because IMHO it's not an easy task to provide a nice infrastructure for a 
plugin-system, that is portable to many platforms. All this is provided by the 
KDE framework and therefore I use it.. and really like to use it. Qt itself is 
quite advanced with handling plugins, but the KDE Plugin-system makes it even 
more easy to use. You can have type-safe Plugins without dynamic casts and the 
way you describe the Plugins is really beautiful. Mostly all this is a 
collection of macros (providing an easy way to create factory classes that 
will create instances of your plugin) and the c++ template system to provide 
compile-time casting of your plugins. KDE will also provide better features to 
ship new plugins as 3rd party modules than Qt does, so I think, we really 
should stick to the KDE infrastructure here.

> Consider, we have a new volunteer (or even myself), how do we bring that
> new person up to speed on the project if they (or me), can't understand
> how it's actually working?
I think, I have a quite good understanding of the KDE infrastructure and it 
technology. If anything is unclear, just ask and we will figure it out.

> My own solution to the scaling problem is to provide a user editor and
> viewer for components that will allow you to inspect and edit the model
> for that component. This would work with .component files or something
> that would be viewable and editable (to some degree) in something like
> kxmleditor.
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 that after the port. This should be okay, if 
we just strip every GUI related stuff out of the ECNode classes. After that, 
they should be really easy to port.

> Once again, these changes are for versions AFTER the port is stabilized.
I agree. As I said. Porting the GUI means rewriting it.

well, that's enough from me, for now ;)

bye then
julian