My notes to the BoF minutes

[Andreas Pakulat]

Hi,

,----
| Topic: Code Quality 
|    Alex: How can we make sure to keep quality? Shall we establish a policy?
|    Harald: Review work as long as their are immediate.
|    Andras: Platform commits can go to the mailing-list? Harald: That's a lot of noise.
|    Harald: Unit testing can ensure to keep stability - but we can still be open to commits.
|    Jens: Policies have to be enforced - tricky with a community. With the current lack of developers, it doesn't make sense to write down a policy.
|    Harald: Tests can improve getting new developers in - they'll be less scared if there are tests to verify behavior.
|    Aleix Pol: Maybe the problem is calling it policy - it should be a recommendation so we won't scare volunteers away.
|    Jens: Once we have 90% test coverage, we can get a policy in - otherwise new developers have to work in a different way than all the others.
|    Alex: Find a good way to sell the idea of testing to community.
|    Alex: In KDevelop, we have a lot of regressions, tests are badly needed.
|    Johnny: Why not stricly enforce it?
|    Harald: We're a community, we shouldn't enforce.
|    Andras: New interfaces should be documented by default.
|    Alex: Agreed - this should be a stricter policy.
| 
|    Action Point: Harald: Write a document why/how to test for KDevelop.
`----

I'm not so sure about the "don't enforce test-writing", it takes some
time and brain to write good tests and people may want to work on new
features than writing tests (I know this people includes me, it took me
several weeks to finally sit down and complete the test suite for the
qmake parser). 

Having said that: I have no idea how we should test our GUI. Testing
small widgets like kdeui/ in kdelibs is rather easy, you can create a
test-executable that creates some events or you can just display the
widget to the user. However testing the project settings gui isn't that
easy, as it needs a kdevplatform application, the manager plugin and a
project. 

,----
| Sub-Topic: EBN 
|    Harald: We can use the EBN to upload scripts to check our code quality (e.g. enforce documentation on all interfaces)
| 
|    Conclusion: Agree - we should make better use of it.
`----

Yeap, currently kdevplatform is nearly krazy-free but there are quite
many documentation bugs found by the doxygen-checker run on the ebn.
Fixing such things is something that we can give to new developers as
"starting point". It allows them to dive into the API slowly and getting
to know everything while doing something meaningful at the same time.


,----
|  Topic: UIs 
|    Alex: Gave a history of KDevelop UI
|    Jakob: Doesn't like navigate by history - no visual indication where you'll move
|    Harald: Navigating Tabs and navigating history are two different concepts - should not be mixed
|    Jakob: HIG specifies shortcuts for history-based (Alt-Left/Right) and order-based (Ctrl-Comma/Dot) navigation
|    Harald: Why not involve the HIG group?
|    Jens: If I go from one split view to the other, I want to go back where I was - no matter in which split view.
|    Jens: Have to think of new developers vs. old developers - they have a different amount of files opened at a time. The file list was not optional. Suggestion: Go back to tabs - although you don't see all opened files at a time, but it's a good indicator. Tabs - you see more from the file name.
|    Jens: QuickOpen was coolest feature - but well hidden.
| 
|    heated discussion too fast to protocol
`----

       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. Just my 2 cents, hope this doesn't start another
"heated discussion".

       How to make QuickOpen more visible / easily usable.

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)

       Status Bar vs. Tab - where to display the current file info?

How about a toolbar? It needs to be rather short of course, something
like insert-mod as an icon+INS text, row/col and maybe the lineending.
If we keep our toolbar small (i.e. few entries, certainly no navigator
like in kdev3) it shouldn't be a problem to have this there. 

,----
|  Topic: CMake 
|    Aleix Pol gave an overview of the CMake status in KDevelop
|    
|    Trouble: How to write back changes to a CMake/qmake/whatever project file that was hand edited?
| 
|    Alex: Wants to read/write project files without destroying local modifications
|    
|    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?? Thats not really a good
idea. CMake is too complicated and while it may sound neat to click
together a CMakeLists.txt with a graphical editor this doesn't work in
practice. At least thats the impression I get at work, where practically
nobody uses the grapical xml editor in eclipse, but rather uses the text
version. Instead we make heavy use of auto-completion in that to close
and create tags as well as filling in attributes and content. 

Or does that just mean that I should be able to edit the CMakeLists.txt
and the results show up in the simple gui? If thats the case I'm all for
it ;)


,----
|  Question: How about cross-platform code? 
|    Conclusion: Keep the way of working - the Mac and Windows guys fix their platforms. Try to use Qt whenever possible instead of system calls.
| 
`----

I guess I should say here that system calls aren't the real problem (as
long as its standard C/C++ and not some gnu extensions). The real
problem are external dependecies, like Boost, CommonC++, Subversion.
Probably also small binary db's like berkley db or samba's tdb. These
are often not buildable on windows or are a PITA to build (Subversion is
now buildable, but I still didn't try wether it actually works, its
probably going to be easier in the future with the next major release as
their libs will then support dynamic linking).

So whenever somebody wants to add a feature which uses an external
program or library, it would be nice of him to check wether it is
supported under windows and if not see if he can easily find a
replacement.

Andreas

-- 
Don't let your mind wander -- it's too little to be let out alone.