My notes to the BoF minutes

[Matt Rogers]

On Jul 3, 2007, at 12:34 PM, Andras Mantia wrote:

> 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.
>

You can test interaction as well. QTestLib should be fairly adequate  
for our needs, it can intercept signals, etc.


>> 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.
>

exactly

>> (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
>

No, really, you should use an existing tool if it's the best tool for  
the job rather than reinventing the wheel and the tool. I tried that  
with the cmake support by trying to use cmake itself. It wasn't the  
best tool, so I had to ditch it. Sure, people will say that it's NIH  
syndrome or whatever, but that's fine. I don't care what they think.  
I'm happy with what I got and since I'm the developer, that's what  
should matter.
--
Matt