On Mon, 16 Nov 2009 15:57:19 +0100, Julian Bäume <julian@...> wrote:
> I want to discuss some thoughts and some work, I put into porting to
> I found it useful to divide porting into different steps. Some of these
> 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
> port, but a plan, how to get started and proceed.
I've created a wiki page for documenting what we discuss, here:
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
> components concerning document handling, project handling and things like
> that. I implemented a document-plugin, that is able to load
> 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
> project- and document-handling works similar to kdevplatforms ideas of
> these things.
Can you give some links to documentation about this? What the platform's
> 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
> 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
> After that, we need ways to re-integrate all features of nowadays
> 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
> 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
> toolchains for different MCU-architectures. We should start with PIC, to
> feature-parity, but we can also take other architectures into account,
> most parts need to be rewritten, anyway. (However, we might be able to
> most of the toolchain related code)
> Then there is flow-code and circuit-simulation. Reading some mails on
> 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
> circuit-simulation but got distracted by that kdevplatform stuff,
> 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
> list, contains information about a circuit. Which components are where,
> voltage- and current information, everything like that. Wires are also
> 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
> the circuit. I can't be more specific here. ;) The controller also must
> sure to update the physical values in the model. The view uses all
> information from the model to visualize the circuit and the corresponding
> values for each component. The model is used for communication between
> simulator and the view. E.g. update the simulation data, when the
> circuit is
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
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
> be similar to the work that needs to be done for circuits, just not as
> work, I guess.
> Well, that's about my plan on how to proceed. We should use the wiki to
> down a plan and organize our forces.
> well, that's it from here, I'm looking forward to hear you comments.
> bye then