QuickOpenPart addition

Jens Dagerbo jens.dagerbo at swipnet.se
Sun Feb 15 17:08:04 UTC 2004

Hash: SHA1

Re http://bugs.kde.org/show_bug.cgi?id=74941


Very nice addition! I've used it for a few days and it works well. :)

Some thoughts before we import it into CVS:

# License. 
All source files added to CVS _should_ have a license header. (Not all have, 
but that's not intentional..)

# .ui.h 
In general we tend to stay away from the .ui.h scheme since the KDE build 
system still doesn't work too well with them. Basically, a change to a .ui.h 
will not cause the related generated .cpp file to be rebuilt. This causes 
confusion and is best avoided.

# .rc file version update
Whenever one changes a KDE XMLGUI .rc file, one has to also update the version 
number (found at the top of the file). If one neglects to do so, the change 
may or may not be noticed by the users, depending on wether or not they have 
made any related customizations.

Other, more general thoughts about the Quickopen plugin:

# refactoring
There is now three dialog classes that have about 50 identical lines that as 
far as I can tell could be easily shared. I'll fix this unless someone else 
feels interested..

# menu placement
Why do we have these in the "Edit" menu? Would they make more sense in the 
"Tools" menu? I'd like to put them there and also use "Quickopen" name to 
associate them with the Quickopen plugin.

So: "Quickopen file", "Quickopen Class" and "Quickopen method" in the Tools 
menu. Any against? Or else I'll do this.


Version: GnuPG v1.2.3 (GNU/Linux)


More information about the KDevelop-devel mailing list