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