[Ktechlab-devel] KDE4 port

[Julian Bäume]

hi,
I want to discuss some thoughts and some work, I put into porting to KDE4.

I found it useful to divide porting into different steps. Some of these steps 
will be quite invasive to the code-base and could also be called rewriting of 
some parts. I won't refer to everything that needs to be done to finish the 
port, but a plan, how to get started and proceed.

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.

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).

I put a lot of effort into this part of the port. Too much, for my 
understandings, but somehow I didn't come very far. I think, it's time to 
discuss problems with other developers to see some progress in that field.

After that, we need ways to re-integrate all features of nowadays KTechLab 
into this new hull. This is: code-editing possibilities for PIC, flow-code and 
circuits. (unordered list)

Since there is some basic support for C in kdevelop, we can use these features 
in KTechLab, too. Doing so, we can provide a more development oriented way of 
editing C-code, asm-code and microbe-code. We can use kdevplatform to provide 
toolchains for different MCU-architectures. We should start with PIC, to reach 
feature-parity, but we can also take other architectures into account, since 
most parts need to be rewritten, anyway. (However, we might be able to re-use 
most of the toolchain related code)

Then there is flow-code and circuit-simulation. Reading some mails on this 
list, it should be clear, that the visible part needs to be rewritten. (I 
refer to everything under the heading of QCanvas...) I started to do so for 
circuit-simulation but got distracted by that kdevplatform stuff, mentioned 
earlier.

As I understand it, there's been some refactoring going on concerning 
simulation (Alan and Zoltan working on that). I've been working on 
visualisation and how to glue both parts together.
They key, I see here is an MVC-approach. The Model, some kind of component-
list, contains information about a circuit. Which components are where, 
voltage- and current information, everything like that. Wires are also stored 
in there (meaning, which components are connected how). The controller 
(simulator) constructs the matrix from this information to do it's 
computations like current-flow-analysis and all that is necessary to simulate 
the circuit. I can't be more specific here. ;) The controller also must make 
sure to update the physical values in the model. The view uses all available 
information from the model to visualize the circuit and the corresponding 
values for each component. The model is used for communication between the 
simulator and the view. E.g. update the simulation data, when the circuit is 
altered,...

I'll leave everything concerning flow-code editing open for now. This should 
be similar to the work that needs to be done for circuits, just not as much 
work, I guess.

Well, that's about my plan on how to proceed. We should use the wiki to nail 
down a plan and organize our forces.

well, that's it from here, I'm looking forward to hear you comments.

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/20091116/7d341351/attachment.sig>