My notes to the BoF minutes

[Andras Mantia]

On Tuesday 03 July 2007, Andreas Pakulat wrote:
> I'm not so sure about the "don't enforce test-writing", 
It's rather: don't enforce test-writing before we really have test in 
kdevplatform. Once most of the code has tests it is possible to make 
writing tests mandatory before introducing new classes.

> Having said that: I have no idea how we should test our GUI. 
There are some test tools for GUI (IIRC KDAB and basysKom has such 
tools, have to check out), even if they are not GPL, they are created 
by KDE people and free to use for KDE.
Also it is possible to write tests against GUI classes with QTestLib. Of 
course with such tests you will mostly verify only if the behavior of 
the public methods did change or not (or crashes or not), but that's 
also fine.

> Yeap, currently kdevplatform is nearly krazy-free but there are quite
> many documentation bugs found by the doxygen-checker run on the ebn.

More problem is that the documentation is missing in many cases (or it 
is wrong/outdated). That will not be catched by krazy. ;) But there 
will be a review of the interfaces here (without me, though), and we 
agreed to document them. And doing while reviewing would be a good 
thing.

>        How can we make a visual representation of many open files and
> ease navigation?
>
> I also don't like tabs anymore. At lesat not for KDevelop :) Jens
> (Dagerbo) actually brought me to try KDev3 without tabs and all that
> I'm really missing is having a small overlay-window that shows my
> current file and the last 5 and next 5 in a list while I cycle
> through editing history (or just file order). IMHO if we'd have this
> we don't need any tabs or other switcher. 

Yes, this is one of the most important issues: grouping, showing the 
neighbours and switching between them. This is not possible with the 
current solution, but was with tabs. So a solution is needed.

> Have a Navigation Menu with such things? Currently Quick-Open-File
> should be relatively easy to find (its in the File menu) but
> Quick-Open-Class/Method are in tools. I think some other things can
> be moved out of tools as well (all those code-formatting stuff for
> example)

Hm, a menu might not be good. Think about when you have a large project 
with many files and classes/methods. The drop-down box approach is 
probably better, especially with filtering capabilities.

> |    Conclusion: We want to have full read/write support that
> | preserves local modifications (full parser). General agreement that
> | a split between simple graphical and advanced textual editing is
> | not what we want.
>
> `----
>
> Uhm, so instead what? Full graphical support?? 

I think here the minutes are not correct. As far as I understood, the 
consensus was to write our own parser to support as much features as 
possible from the GUI both for reading AND writing. Users who don't 
want very strange things in CMake, should be able to just create and 
manage their project from the GUI. But the GUI should not stop anybody 
changing the CMakeList.txt file in an editor, and should not destroy 
information that was added in an editor.

> (as long as its standard C/C++ and not some gnu extensions). The real
> problem are external dependecies, like Boost, CommonC++, Subversion.

I'm not experienced in this, but this all comes down to the same thing: 
if you can implement something with Qt, do with it.

Andras


-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org