KDevelop UI cleanup initiative

[Andras Mantia]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Seems that my mail sent via KNode didn't reach the list. Resending now 
from KMail.)

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
- -- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAut+OTQdfac6L/08RAqh4AJ4suj5Lr7+0lORAIIxTlclZHbhvBwCgruFe
ib07/uOge/LaBNFIApYs9Jk=
=bJ5g
-----END PGP SIGNATURE-----