[Ktechlab-devel] KDE4 port

[P Zoltan]

On Mon, 16 Nov 2009 15:57:19 +0100, Julian Bäume <julian at svg4all.de> wrote:

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

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

>
> 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?

>
> 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?

>
> 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 agree on MVC, but in a different way:

- View: strictly the visible parts; including its location on canvas, etc.

- Controller: pass messages and events between view and model

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

  I guess we will need more layers of abstration this way, but looks more  
logical to me.

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