My notes to the BoF minutes
mattr at kde.org
Wed Jul 4 00:59:30 UTC 2007
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
>> 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
> Hm, a menu might not be good. Think about when you have a large
> 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
> if you can implement something with Qt, do with it.
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
More information about the KDevelop-devel