kde at michael-jansen.biz
Mon Mar 17 19:44:29 GMT 2008
> Yakuake presently defaults its Open/Retract action to F12.
> At first startup, it displays a first run dialog with an
> info message, along with a KKeyButton that shows the glo-
> bal hotkey and allows changing it, which is also where
> the conflict checking takes place. After clicking Ok or
> Cancel in the first run dialog, the main window rolls out.
> On subsequent application startups, the main window re-
> mains hidden until the global shortcut is triggered to re-
> veal it (the shortcut is shown in a KPassivePopup in the
> screen corner at subsequent startups, unless it is dis-
> abled). The KShortcutDialog is only accessible through the
> main window.
That's what i meant with doing the right thing. If the application is
absolutely unusable without the global shortcut present a dialog on first
start. If i say no "global shortcut please" tell me "sorry no app then" and
> Bottom line: If global shortcuts are made opt-in, that opt-
> in must be public API so that e.g. said first run routine
> can register the shortcut as active, even when the user
> dismisses the dialog with its default value (since the app
> won't be accessible without it once the window gets closed
> or during the next app session). If it's public API, how-
> ever, apps authors are going to do it anyway, pretty much
> screwing over the opt-in thing.
I don't think so. No api. KShortcutsEditor could get that functionality. They
call KShortcutsEditor and we inform them if the user allowed their shortcuts.
If they insist on their shortcuts they can do an exit immediately. No publi
API for an developer to enable global shortcuts out of the reason you gave.
They would use it all.
Only kdebase is allowed to enable shortcuts by default without user
interaction. noone else
Available for contract work ( Development / Configuration Management )
More information about the kde-core-devel