My notes to the BoF minutes

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

My notes to the BoF minutes

Thread: My notes to the BoF minutes