My notes to the BoF minutes

Alexander Dymo dymo at ukrpost.ua
Tue Jul 3 18:49:10 UTC 2007


On 7/3/07, Andreas Pakulat <apaku at gmx.de> wrote:
> 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.
That's why we need to sit down and first write tests (like Jens
suggested) and only there decide whether "write tests" will be a
recommendation or a policy.

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

Don't worry, the minutes say as if we don't have solution at hands,
but I already have one ;)

>        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.
The problem here is that the toolbar is too far away from the editor,
especially if you have split views.

> 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 ;)
Yes, basically we agreed that we should support Aleix's work on parser.

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

And also we'd need to have a system with nightly builds on linuxes,
macos and windows to make sure we know that the build is broken on
some systems.




More information about the KDevelop-devel mailing list