Hackathon notes

[Vladimir Prus]

For the benefit of those who could not attend the hackthon, and for
posterity, below are the notes I took during that week. I've previously
circulated those between those who attended, and nobody complained so 
hopefully I did not misrepresent any opinion.

- Volodya

Shortcuts
---------

We have agreed that currently, shortcuts are a mess. Some of us like
Emacs shortcuts scheme -- where there's multi-key shortcuts, like
"Ctrl-h" been a general prefix for all help commands. It was also
suggested that if at all possible, shortcuts use a single modifier
key. And furthermore, Alt key is the most convenient modifier, so
we better use Alt-<Key> for the most frequent operations.

For one specific case, it was suggested to use Ctrl-O for quick
open, as opposed to the current Ctrl-Alt-Q.

There are couple of problems:

- Kate grabs all shortcuts. Alex posted a kdelibs patch for
a general solution, I don't know if that moved anywhere.
- Qt grabs Alt for menu accelerators. I don't actually care
for menu accelerators. Is there any way we can disable specific
menu accelerators?

On a related topic, it would be nice if tooltip text for each
action mention the keyboard accelerator. Alex, you've said this
is easy, so maybe you can do that?

Perspectives
------------

Alex and Andreas and myself discussed perspectives (or areas, if you like),
on Thursday. The highlights were:

1. We should have predefined area types. Those have a name, and a list of views
that must be shown in that area. For each view, a position is also specified.
When that area is shown, only the listed views are shown. Other views can be
only explicitly added by the user. We eventually agreed that we don't care
exactly show views a identified (non-i18n string, or GUID, or whatever) and
if views change a name. Both standard areas and standard views are under our
control, so we don't care.

2. We can have several areas with the same type in different main windows.
For example "Code" area type. Internally, those are two different Area instances,
the layout of views, set of documents, etc, is remembered and saved independently
for those two instances.

3. There should be API and UI support to switch to a area of a given type in
the current window. If an area of the requested type is not created for a given
window, it is created.

4. There should be API to 
   - Find all areas of a given type that already exists, across all windows.
   - Create new windows with a new area of the given type.
The UI for that is undecided. We have some debugger-related use cases.
First, is when you code in one window, and debug in another window. Another
is that you have two debug windows where you debug different applications.
And yet another is that you have one window for coding and debugging. It's not
apparent what UI will allow the use to select the desired behaviour.

File navigation
---------------

Nobody liked the combobox as the way to select files, so it went away. Alternative
solutions were:

1. Tabbar. This one is good, but does not scale very well.
2. Tabbar, plus a button that opens list of all files. This is what Eclipse has, and
does not scale very good in case the file list is ordered alphabetically. MRU might
work better. We probably should not have both document list as toolview and a list
that drops out of tabbar. So, either we remove document list toolview, or we make
a button on the toolbar activate the document list.
3. Breadcrumbs. This is "File -> Class -> Function" navigation interface. Clicking
on the name of the current File, Class, or Function brings up a list. Alex
wrote a widget for that, but haven't hooked that in.
4. Back/forth nativation like in Konqueror was also discussed. I'm not sure what's
general opinion on that.


UI general
----------

We talked about ctags. The conclusion is that we don't need ctags to be apparent
in UI. ctags is good as symbol table backend, especially for non C++ languages
(including C). However, we should try to have single UI to find a symbol, which
uses ctags data if configured so by the user.

It's desirable to be able to edit build system files with an editor directly. (I
think Aleix might have already did it for CMake :-) )

We probably want to place two tool views alongside.

We probably want the list of current jobs, with a way to terminate any.

We talked that probably we should have have a sinlge console window
for everything. There, different console types "Run", "Build", "GDB", etc
would get a tab, and inside each tab, there will be back and forward
nagivation. (I think Adreas worked on something like that, but I don't think
it's fully done).

Various
-------

Would be nice to have debugger not step to "third party" code automatically.
Can we trace code with debugger, and generate UML diagram from that.

Call graphs and "search in hierarchy" are two very important tools missing
in KDevelop's C++ support right now.

Transcribed sticky notes
-------------------------

Note that I had trouble to understand if a note is positive or negative
in some cases. It might be best to use differently colored sticky notes
in future.

Plugins only in C++
Support for languages other that C++
Windows + Mac support
Non C++ languages
Missing cross compiling
Web site sucks
No custom editors for non-C++ file types
Multiproject handling sucks
(?) VCS integration
Hard to understand the setup of an import of a project
Open any KDE project in KDevelop
Need too much user configuration
+? integrated GUI designer
Missing KIO_SLAVE support for projects
Tabbar missing
SLow debugging
Missing remote debugging
Hovering in debugger should show value
C++ Parser
Code completion on C++ works
Parser not perfect
C++ Parser still not reliable
Does it parse C++ Boost yet?
Stay in my code debugger
Missing tutorials for using advanced features (YouTube)
Qt 4.4 documentation support
Startup speed
Slow
Totally ad-hoc extension mechanism
Perfect integration of Qt
+ Syntax highltighit
Good C++ code completion
Fast C++ parsing
- Tree-View usability
Hard to find the right place for a setup
KDevelop3 has too many user options
Lots of windows and buttons by default
Cluttered workspace showing everything by default
Code folding should be saved
Code folding looks ygly.
Editor not emacs
Simple switching between different build setups (compiler switches, local/cross)
+ Debug integration
+ Doxygen integration
Use local project files
+ It's good to be able to use gdb graphically
+ C++ Debugger
integrated documentation browser
+ Not written in java
+ Class/Folder views
+ Problem reporter
+ Cross language
+ Valgrind
Templates blah-blah out of the box
Quick open is greak
- Support by cmake
Simple internal structure
Easy to understand
Simple for beginner
- Having to setup build env
Missing quick build env switching
Should be fast scalable minimal configuration
To many setting menus
Shortcuts mess
- Dock windows? Free movable?
- BLocking UI after project config
UI layout not persistent
Duplicated functionality (ctags, for example)
- Startup time
- Build system
- Code folding must be saved
- Debugger does not support QString, QVector, etc
- COnfiguring executable for running by selecting exec file
- Shortcuts are a mess
- C++ parser still not reliable
+ easy to undersatnd
- Not written in Java
- perfect integration of Qt
- good XXX of doxygen


- Volodya