Global shortcuts and i18n
Andreas Hartmetz
ahartmetz at gmail.com
Wed Feb 6 23:30:24 GMT 2008
Am Mittwoch 06 Februar 2008 18:38:05 schrieb David Faure:
> On Wednesday 06 February 2008, Andreas Hartmetz wrote:
> > OK, if the data file solution sucked it should be avoided I guess :)
>
> No no, the kde3 solution was #include
> "../../../kdesktop/kdesktopbindings.cpp", that's the solution that sucked.
>
> krunner installing a KDEDIR/share/apps/kglobalaccel/krunner.shortcuts is
> what I call the "data file solution", and it's currently my preferrence.
That is what I was thinking of because i18ned names shouldn't be in the kded
module, mainly. As I said before (and noticed too late), the i18ned names are
actually needed for messages like "Ooops, Ctrl-Alt-X is currently assigned to
$other_action. Steal it?". For good measure one could throw in friendly and
i18ned names for components.
I do not see much wiggle room there, do you? The data file solution would add
more work without subtracting much as it looks.
The adjustments in KAction are partly independent. I'd favour
setGlobalShortcutsEnabled(true) outright failing(*) in case of an empty
objectName() over using the text() name. This is because the shortcut will
then be bound to that name and won't by default be reassigned to the same
shortcut if it later uses its objectName() as a unique identifier (as it
should have done in the first place).
(*)if enabling will return a bool success and disabling can't in a meaningful
way (it will not fail) I'd actually want
bool enableGlobalShortcut(); and
void disableGlobalShortcut();
to make that more explicit.
More information about the kde-core-devel
mailing list