<div class="gmail_quote">Thanks Millian, yes I am a student and I even applied for this thing at GSOC last year, but as I said I ended up working for Orange instead (which I'm still a bit sorry for). So I'm trying to make up now :)<br>
<br>2012/2/8 Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de">mail@milianw.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this should be done using our plugin architecture, you can "provide"<br>

interfaces in a plugin and other plugins can then "require" interfaces. That<br>
makes it possible to do what you want I think. Take a look at e.g.<br>
IMakeBuilder and such in kdevelop/projectbuilders/makebuilder/*<br>
<div class="HOEnZb"><div class="h5"><br>
cheers<br></div></div></blockquote><div>(and what Aleix said):<br><br>I'm not sure I understand completely, so let me explain my thinking better. The way I envisioned the structure is:<br><br> A) One plugin (let's call it TestViewPlugin) to show all available test. <br>
 B) An interface (ITestProvider, maybe a different name) that specialized plugins (what I called "generator" inappropriately, "provider" is probably closer), which find tests, and run them. Since the tests can be nicely arranged in a tree, I think a tree structure for tests is appropriate. For CTest with Qt, this is a three-level structure (Project -> executable -> function). So the Provider(B) would generate the Test tree and send it to View(A) for display. <br>
<br>Now plugins aren't supposed to link to eachother, so B-plugins shouldn't link to A or vice versa. However, they should be able to share data (B must tell A of all the tests it found, and A should tell B which ones to run). So I would add a shared data class (call it UnitTest or TestCase) for holding [name, executable, arguments, parent, children]. Alternatives that I can think of is having the B-plugins provide a QAbstractItemModel (which also make it hard to display tests for different projects in the same treeview),  having the TestCase class completely abstract, or simply storing everything in the A-plugin. However, all of these complicate the B-plugins with code that could be shared. There are probably other options, so I'd be happy for suggestions. <br>
<br>Millian, if I understand you correctly, you want to define interfaces in a plugin, like IMakeBuilder (and now that I did look around, IExecutePlugin and IExecuteScript) does. But that requires cross-including between makebuilder and its user cmakebuilder. However, in my case, I would like to share a concrete class, along with its implementation. <br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
</div></div></blockquote></div><br>