My notes to the BoF minutes
apaku at gmx.de
Tue Jul 3 18:53:43 UTC 2007
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 :)
Today is the first day of the rest of your life.
More information about the KDevelop-devel