obsolete(?) code in KApplication::notify()

Andreas Hartmetz ahartmetz at gmail.com
Fri Nov 17 20:45:05 GMT 2006

2006/11/17, Reinhold Kainhofer <reinhold at kainhofer.com>:
> Am Freitag, 17. November 2006 18:45 schrieb Andreas Hartmetz:
> > Actually, the code goes on like this:
> > ## snip ##
> >           // Ctrl-U deletes from start of line.
> >           if (key == Qt::CTRL + Qt::Key_U)
> Qt does not have that shortcut it seems (it only has Ctrl+K to delete to the
> end of line), so to be able to add it to all QLineEdits in that KDE
> application, the event needs to be intercepted and not handled by Qt.
> I don't know if there is a nicer way to change widget-specific shortcuts in
> Qt4 than incercepting the event in notify.
> Of course, the hardcoded key is really wrong. OTOH, there is no such
> shortcut
> to configure for "delete from start of line" in the kcontrol module.
> > As I said, it looks really, _really_ wrong, including hardcoded key
> > shortcuts.
> Apart from the hardcoded keys, what looks so really wrong to you? That code
> is
> adding functionality to all QTextEdits and QLineEdits without the need to
> subclass it and use K(Text|Line)Edit.
> But then, I don't know how the app-specific shortcuts (Ctrl+A for select
> all,
> Ctrl+X for cut, etc.) that are configured in kcontrol are handled and
> propagated to the Q* widgets properly. From my tests on a kde 3.5.5 system,
> it appears that these KDE-configurable shortcuts (apart from "select all")
> are not propagated to the Q* widgets at all...
> Cheers,
> Reinhold
> --
> ------------------------------------------------------------------
> Reinhold Kainhofer, Vienna University of Technology, Austria
> email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
>  * Financial and Actuarial Mathematics, TU Wien,
> http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
You _can_ add functionality to many classes by inserting random hacks
somewhere else. If you should do this is another question and IMHO the
answer is "no". And by the way, it still only works in KDE apps
because it's in KApplication. If your application is a subclass of
KApplication, chances are that you're also going to use KLineEdit,
which does already exist.
In a nutshell, I don't want to discuss whether this is good design but
whether it might be necessary because there is no better way to do it.

More information about the kde-core-devel mailing list