<div class="gmail_quote">On Tue, Mar 15, 2011 at 9:08 PM, Miha Čančula <span dir="ltr"><<a href="mailto:miha@noughmad.eu">miha@noughmad.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hello!<br><br>I've moved the Veritas library and the QTest plugin from svn to git playground. After getting to know the code, the first thing I did was change the tree view's look to match the Project toolview. As you can see in the attaches screenshots,  both use a QTreeView with the same indentation and decorations. I also introduced checkboxes, modeled after other selectable treeviews in KDE, such as the one for selecting your collection folders in Amarok. I removed the hover-icon method of selecting and deselecting tests to run in favor of checkboxes. I might not be a usability expert, but I do like consistency, so I tried to make the UI as similar to existing ones (Projects, Snippets, Classes) that use QTreeViews. The plugin itself works as expected (no significant changes to QTestLib while it was unmaintained), so I haven't touched that yet. <br>


<br>My next plan is to remove the remaining hover-icons, and provide a RMB-menu instead. Another thing I'd like to do is remove the project selection dropdown, and just list all projects in the tree. This not only matches the Projects view, but reduces the number of clicks needed to start using the plugin. But before I proceed to mindlessly destroy the hard work of others, I'd like to know what else would have to be done to make the plugin KDevelop-worthy. Aleix (I suppose he read this list), you posted the GSoC idea, what exactly did you have in mind? And how should the the plugin (both the test-tree and the result-view) look to best match KDevPlatform's standards?<br>


<br>And the last thing, I would very much like to work on KDevelop/KDevPlatform as part of the summer of code. I know I haven't made any contributions to KDev* yet, but I am following its development and I'm somewhat familiar with the code (at least the architecture). My first idea this year was this test runner, but as one backend is already working, would it be worth a slot or should I try something else? A possibility would be adding support for other test frameworks, like CppUnit and Boost, but I don't know of any KDE program that would use those. <br>


<br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></div><br><div>What I would like to see in a proposal referring to the Unit Testing integration in KDevelop GSoC is a proposal where the student says he's going to fix whatever it's wrong now and make it usable and gives his thoughts on how does he want it to be integrated in KDevelop. I don't think it should be me who says what the proposal should be about.</div>

<div><br></div><div>Awesome QtTest + cmake integration by the end of the GSoC is a must, but it's not the only thing. KDevelop is about integrating tools, I'd like to see what is the student's idea of how should unit tests be run while developing and how should it be integrated. For instance, what if a test is crashing, how do we debug it? Can we just run the tests that are relevant to the file we're editing? How can we find regressions using veritas?</div>

<div><br></div><div>Aleix</div>