[Ktechlab-devel] KDE4 port

[Julian Bäume]

On Monday 16 November 2009 19:41:06 P Zoltan wrote:
> On Mon, 16 Nov 2009 15:57:19 +0100, Julian Bäume <julian at svg4all.de> wrote: 
>   I've created a wiki page for documenting what we discuss, here:
> 
> http://sourceforge.net/apps/mediawiki/ktechlab/index.php?title=Ideas_about_
> KDE4_port
> 
>   It should be filled up sooner or later...
Great, I started, but it's far from finished, I guess ;)

> > A long time ago, we discussed using kdevplatform as a base framework. I'm
> > still very addicted to this idea and have some working code and some open
> > problems with that. What does it mean for KTechLab? We need to rewrite
> > some
> > components concerning document handling, project handling and things like
> > that. I implemented a document-plugin, that is able to load
> > circuit-documents
> > in the same way, as it is possible, now. I was able to reuse some old
> > code and
> > it was quite straight-forward, because at the moment everything
> > concerning
> > project- and document-handling works similar to kdevplatforms ideas of
> > doing
> > these things.
> 
>   Can you give some links to documentation about this? What the platform's
> benefits?
The only documentation regarding KDevPlatform is it's API-docs. They can be 
found here: http://api.kde.org/4.x-api/kdevplatform-apidocs/
This documentation could be better, I guess (it took some time to get into 
it), but it's okay.
Another way to get started is to have a look at how kdevelop makes use of 
this. Even quanta could be worth a look, but I think. I did learn quite a lot, 
while reading the main classes of these projects. (most of the regarding code 
is very straight-forward)
 
> > I have problems creating a customized ktechlab-specific main-window
> > based on
> > kdevplatform, but IMHO these can be solved. I'm just not sure, how
> > exactly. ;)
> > kdevplatform is still under development, as you might have noticed, but
> > the
> > first stable release will be part of the next stable KDE4.4 release (if
> > everything goes, as expected).
> 
>   What is custimized, except the QCanvas?
No, this has nothing to do with KTechLab as it exists, now. The KDevPlatform 
main-window that is started by the default shell (shell is the name of a 
default implementation of all core-functionality defined as interfaces) has 3 
pre-defined "areas". "Code", "Debug" and "Review". These might fit into the 
workflow a developer uses when developing software, but doesn't for electric 
circuits. I wanted to change these, but didn't have much luck. It keeps 
crashing, when I try to remove the areas ;) I know, there is a way to do it, 
I'll keep looking into this issue.


>   I agree on MVC, but in a different way: 
> - View: strictly the visible parts; including its location on canvas, etc.

> - Model: the electronic model for the specified component. It registers
> itself in the simulator, and the simulator should query it and create the
> voltage/current matrixes and solve them, then send these values to the
> model.
Registration to the simulator should be done by the controlling part of the 
code. This way, it would be possible to link other simulators (may be gnucap 
or something like that) without touching the model. ("to register" is an 
action of control)

> - Controller: pass messages and events between view and model
right. It "controls", where View, Model and (in our case) the simulator get 
it's data and to whom send the data, and so on. Okay, now I see the need of 
something called "Controller". One could argue, that all questions regarding 
timing should also be handled by the controller. I don't think so. These 
things should be done using signals and slots of the Qt framework. That's the 
reason, why I try to avoid the term "controller", because in this case it 
doesn't control (everything).

>   I guess we will need more layers of abstration this way, but looks more
> logical to me.
I think, we only have a slightly different opinion on how things should be 
done. I hope this clarifies my ideas a little bit.

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/20091118/3c389803/attachment.sig>