My notes to the BoF minutes

[Andreas Pakulat]

On 03.07.07 20:34:53, Andras Mantia wrote:
> On Tuesday 03 July 2007, Andreas Pakulat wrote:
> >        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. 
> 
> Yes, this is one of the most important issues: grouping, showing the 
> neighbours and switching between them. This is not possible with the 
> current solution, but was with tabs. So a solution is needed.

Right, it was possible to rearrange tabs, even though very few people
knew how to do it (proven by a thread on kde-devel or core-devel quite
some time ago)

> > 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)
> 
> Hm, a menu might not be good. Think about when you have a large project 
> with many files and classes/methods. The drop-down box approach is 
> probably better, especially with filtering capabilities.

I think you misunderstood me. I meant a menu where Quick Open
Class/File/Method entries exist. Which would then open the quick-open
dialog. I don't think we can stuff the things of that dialog into a
menu, thats not realistic. Its just that currently the menu items are
scattered around and are not grouped properly. Those 3 are navigation
features and thus should be under a Navigation menu.

> > |    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?? 
> 
> I think here the minutes are not correct. As far as I understood, the 
> consensus was to write our own parser to support as much features as 
> possible from the GUI both for reading AND writing. Users who don't 
> want very strange things in CMake, should be able to just create and 
> manage their project from the GUI. But the GUI should not stop anybody 
> changing the CMakeList.txt file in an editor, and should not destroy 
> information that was added in an editor.

Aaah, ok. Then we're on the same page :) 

Andreas

-- 
Today is the first day of the rest of your life.