My notes to the BoF minutes

[Matt Rogers]

On Jul 3, 2007, at 1:49 PM, Alexander Dymo wrote:

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

So what is it? Not funny to say "i have a solution" but yet leave us  
in the dark as to what the solution is.

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

Somebody should set up a cmake dashboard for kdevelop
--
Matt