KDevelop UI cleanup initiative

[Andras Mantia]

Hi,

 I saw this thread and thought that I will send you my opinion and
complaints.

> 3. The toolbar mess.
>
> We have a lot of bugs related to the toolbars (for instance:
> http://bugs.kde.org/show_bug.cgi?id=79793). I have no idea if we're doing
> something fundamentally wrong somewhere or if the framework is busted, but
> we sorely need someone who understands this issue to take a look at it.

The toolbar mess may come from the heavy "partification" of KDevelop. The
code must be really double-checked that you are not trying to work against
XMLGUI. Sometimes it's not so clear what is done automatically and what you
should/shouldn't do. We have strange errors in Quanta as well, and even now
there is a problem related to XMLGUI which leads here to messed up menu
order. If someone points me where is the toolbar handling code which
influents this bug (or others) I may look at it. I also had a problem with
disappearing buttons yesterday (I was using autoproject), but cannot
reproduce now.

Toolbars... I always wondered: why isn't there an Open button on the main
toolbar?

>> # Close, Close All, Close All Others are in both the File and Window
>> # menu.
>> Close and Close All Others are also in the Editor Context Menu  (ECM).
>> I guess the File menu is more or less standard, I wouldn't mind them gone
>> from the Window menu and at least the "Close All Others" form the ECM.
>> Given that "Close All Others" is a special case of selective close
>> anyway, we could just dump it completely and refer to the FileList for
>> this functionality.
> 
> For Close All Others i totally agree. Close All should be available
> through window menu. I would like to have a "close" in ECM; but i am not
> sure, if it really belongs there. If we're in need of space in the ECM, we
> should remove it. If not, we should let it there.
> 

Just my opinion (bases on user feedback and discussion regarding the Quanta
UI):
1. Why were the Close/Close All Others removed from the tab context menus?
Or more exactly, why were the tab context menus removed? Switching to
another toolview (File List) is one step in plus.

2. Many people will search for close all others in the tab (or editor)
context menu as it means, let's close all the other opened windows but the
current one.

3. Where to put the Close item? File->Close is something that everybody
knows, but when you use KMDI and have a Window menu, that is the menu that
manages the user visible windows, the visual representation of a file.
Aside of that you may have windows containing something other but files,
like the documentation pages. I think that the most  consistent place is
the Window menu, if you have one. That is used to close a file, a window,
close all files & windows, etc.

4. Consistency across KDE. Well, there isn't much, but here are some
examples:
- KMDI applications by default have a Window menu with Close items
- Konqueror has a Window menu with Close items
- Konqueror & Quanta has a tab context menu with Close, Close Others and
Switch To
- Kate has a slightly stripped down KMDI interface without tabs, but their
file list has Close & Close All. They don't have a Window menu, so the
Close items are in the File menu.

I suggest to take all of the above in the account. From this list I think
it's clear what I suggest.


> I still cannot believe that there is no way to build the ECM from XMLGUI.
If 
> it can't we should work for that to come in KDE4. XMLGUI is the nicest way
of 
> creating a gui that i've ever seen. But lacking of support for dynamic 
> context menus is a damned big lack.
> 
>From the Quanta code and .rc file:
  <Menu name="popup_editor">
    <Action name="edit_current_tag"/>
    <Action name="select_tag_area"/>
    <Action name="context_help"/>
    <Action name="open_file_under_cursor"/>
  </Menu>

  KTextEditor::PopupMenuInterface* popupIf =
dynamic_cast<KTextEditor::PopupMenuInterface*>(w->view());
  if (popupIf)
     popupIf->installPopup((QPopupMenu
*)quantaApp->factory()->container("popup_editor", quantaApp));

w->view() is the KTextEditor::View object, quantaApp inherits from
KMdiMainFrm.

I'm using this way of building the context menu since ages.

> # The new Documentation plugin is very cool, but what are the chances that
> the current word will actually find a match in a man or info page? IMHO,
> "Manpage", "Infopage" and "Look in index" should all be gone from the ECM,
> they are simply going to match too rarely to justify a context menu entry.
> "Search" is different.

It can be important if someone codes in plain C and needs some libc or
kernel functions. My opinion (and some bug reports) about the ECM is:
- the ECM is too long, maybe you should use submenus (Documentation ->
Search, Search in manpages, etc.)
- there are two separartors between Grep and Cvsservice
- IMHO Toggle Breakpoing may go away as you can set a breakpoint using the
icon bar (BTW, why isn't Breakpoint the default mark type? I always have to
switch it after I start KDevelop...)
- I think Undo/Redo can be removed from there as one usually uses the
keyboard to undo/redo or can use the toolbar
- Go To Declaration and Implementation: it's not context sensitive (well,
partly, it's sensitive to the current document) and in some cases it may
bring up a very big menu which covers the whole screen. I don't really have
a solution, maybe filter it based on the text under the cursor. I just read
that Jens has the same problem...

And about the new documentation plugin (mainly bugs, annoyances):
- Index is not so useful as it doesn't list the methods
- the vertical scrollbar for Contents appears only if you make the toolview
wide enough (I don't know how can users without a wheel mouse scroll there)
- related to the above, some button on Search & Bookmarks are only
half-visible if the toolview isn't wide enough.
- the items under the KDE API documentation are sorted in descending order 
(e.g kwallet is before kdecore which is before arts,  and KURL is  before
KAccel)

> # View -> Tool Views / Tool Docs and whatnot - of very questionable value
> in IDEAl where toolviews can't be hidden, only undocked and the tooldocks
> are readily available through buttons and shortcuts (such as they are).
I'm
> not sure we can remove these though, IIRC they are merged in from KMDI.

I'm not 100% sure, but I think their appearance is controlled by
setStandardMDIMenuEnabled(). Tool Views doesn't make much sense in IDEAl,
but it does in other modes.

> # Tools -> Version Control -> CVS service (or other vcs) -> action submenu
> - as a menu that acts on the active file, this is quite nuts. The VCS menu
> is already accessible through the ECM and the FileContext (which is almost
> everywhere). I say we remove it from the already crowded Tools menu.

Having such document specific entries hidden so well in the main menu
doesn't make sense for me...

> # Tools -> Difference Viewer... - I honestly don't see what good this is.
> So I can look at a diff, so what?
Never used it and it looks like this is useful only because it highlights
the diff. But the katepart highlights it as well. I certainly won't miss it
in the current form. If you can compare the current document with something
or two separate document, it might make sense to have.

> - The 'Build' - and 'Clean API Documentation' entries make more sense in
> the Project than in the Build menu. The build menu should be reserved
> for the actual code building proccess. API documentation is closely
> related to projects.
Hm,maybe, but I would search them in Build. Regarding Build->Make Messages
and Merge. It tries to run gmake package-messages instead of gmake
admin/Makefile.common package-messages and it fails. I also have problems
with Build->Build Active Target and Compile File... The first says that
there is no Makefile in the directory  and wants to run configure (of
course there is a Makefile) and the second says that it can compile only
files belonging to the project (and of course the file belongs to the
project). I'm using builddir != srcdir.


One final note regarding the class view (once I filed a bug report for it,
but IIRC now it's closed). In KDevelop2 and for some time in Gideon it was
possible to open the declaration or the implementation of a method by
pressing the middle or left button. The middle button functionality was
removed at some time, I complained and it was added back, but was removed
some time later. Any reason to do so? It's much easier to use the middle
button than right click and use the menu. Of course the menu may remain for
those having only two mouse buttons.

Oh, and structures are not listed anymore in the Class view and
autocompletion does not work for them...

Andras