[Ktechlab-devel] Summary of latest IRC discussions about KTechLab

[Julian Bäume]

Am Sonntag, 3. April 2011, 22:14:09 schrieb Zoltan Padrah:
>    Hello,
> 
> in this email I'm summarizing the discussions on IRC, related to ktechlab.
> ( #ktechlab on freenode.net)
> 
> The topics discussed were the following:
> - kdevplatform API stability
> - merging the simulator and master branches
> - asking about possible cooperation with the Caneda project
> 
> I'm starting to detail the last item, as it might be more interesting for
> many people.
> 
> Julian mentioned about the Caneda project (
> http://sourceforge.net/projects/caneda/ ). As I've understood, they are
> also trying to simulate circuits. Their gui is also based on Qt, just as
> ktechlab. By a quick look at the source code, i haven't found a simulator
> in their codebase, so they might be interested in reusing ktechlab's
> simulator. Because both caneda, and the simulator core depends only on Qt,
> technically integrating the two should be quite simple.
> 
> I'm sending this email also to the project admin of Caneda. 

Yes, I’m curious about their opinion on this. IMHO both projects could 
benefit.
 
> Next item: merging the simulator and the master branches
> 
> It is useful to have all the codebase in the same tree, so it can be more
> easily managed. Merging is not that trivial, as the source code for the
> simulator has been re-imported to my simulator branch again, so if we want
> to keep the git history, we need to fix the conflicts during merging. A
> simpler solution would be to move all the simulator tree in a new
> directory, rebase all the commits on that, and then merging should be
> trivial. After having everything in the same tree, we can reorganize all
> the source code.
> 
> This needs some experimentation with git. Any tips are welcome.

I read how to do such things on http://help.github.com/subtree-merge/ but 
seems, I am to late ;) I knew it was possible, somehow. Anyway, having in 
mind, that we want to cooperate with caneda on that, we might consider keeping 
the simulation branch separated and make a library out of it. I’m not sure, if 
a subtree-merge is reversable, so we might want to wait a little longer ;) But 
we can start working on making your code a library. It would be nice to have, 
even if we do the merge.

> Finally: ktechplatform API stability
> 
> I've tried to compile Julian's master branch, but I got compile errors.
> The reason has been found as the different kdevplatform versions: he uses
> version 1.2 and I have 1.0. It seems that there is no backwards
> compatibility on the used APIs. This means that having a separate GUI from
> the simulator core it really the way to go, as we will have less
> version-dependent code in the project.

Even worse, once running KDE4.6 you are forced to use 1.2 version and can’t go 
back. So it’s quite hard for me to test things with older versions.

> In order to work around the version mismatch problem, we agreed to have
> conditional compilation of code for various kdevplatform versions. This is
> feasibly because it is relatively little code affected by the API changes.
> Also the .desktop files for plugins need to be adjusted for different
> kdevlpatform versions.

I will work on that. Already have some ideas on how to do it. Thanks for 
reminding me about the cmake hack I once did, it could really be useful to 
make this work.

> After fixing the compilation errors, ktechlab still doesn't work on my
> computer. By some strange reason, It doesn't load the component plugins.
> More investigation is needed.

Yeah, would be great to know, what’s going on. Doesn’t seem to be a general 
problem, because the "optional" plugin is loaded. I have no clue, yet.

bye than
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/20110404/821ff750/attachment.sig>