My notes to the BoF minutes

[Matt Rogers]

On Jul 3, 2007, at 12:16 PM, Andreas Pakulat wrote:

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

We need to draft a set of guidelines instead of a policy. Policy  
implies required enforcement. Guidelines are things that you should  
be doing because it's in the project's best interests although they  
don't always have to be applied.

We can still use QTestLib for testing our GUI. Or we can go for a  
free as in beer tool that's available such as Squish.

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

Anything that we can do to take advantage of the facilities provided  
by the EBN would be good, as long as they don't go seriously overboard.

>
> ,----
> |  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 ;)
>

It means several things. It means that external changes will be taken  
into account as they occur. (i.e. file watcher). It means that  
KDevelop will provide the ability to graphically edit the project  
being worked on. I don't know to what extent I want the graphical  
editing, but for things like creating new macros or new Find*.cmake  
files, I never intended to be able to do that graphically.

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

We need to be using the best tool for the job, the platform it works  
best on be damned. (IMHO)
--
Matt