Virtual methods in KLineEdit

[Christian Schaarschmidt]

> It is very very much an exception for an application to sub-class
> (K/Q)LineEdit for a customized context menu. I don't think your case of a
> sub-sub-class is realistic. Mechanisms like QWidget's context menu policy

it might not be realistic, but there is an example in KMail ...

> make it easy to implement custom context menus without the need to
> subclass. And even in the very rare case that an application would have to
> re-implement contextMenuEvent() of KLineEdit it is absolutely trivial code:
>
> QMenu *menu = createStandardContextMenu();
> [ ... modify it ... ]
> menu->exec();
> delete menu;

this is only true for the first subclass, not if I have a hierarchy. For a 
hierarchy createStandardContextMenu(); AND contextMenuEvent() has to be 
overwritten. This is not very C++ like.

> I think it makes perfect sense to shadow QLineEdit's
> createStandardContextMenu() implementation with one that provides a KDE
> style menu. That keeps the API 100% consistent and people don't have to
> learn yet another mechanism for dealing with context menus that is specific
> to KLineEdit only.
>
> Let's please not make the same mistake as in Qt 3 where every third
> function was virtual just because one can. Almost every property pair there
> had a virtual setter which was also a slot. There is a price to it and I
> think we should just be a bit more careful in kdelibs4, too.

I don't see the price as an argument, however the compatibility with QT is, 
even though I don't like the way QT those it. I was not aware that the whole 
thing was build with this (IMHO) unusual design.
Committed revision 628348.

Christian