On Mon, 16 Nov 2009 15:57:19 +0100, Julian Bäume <jul...@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 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
