proposal for kaction api change

Jens Herden jens at kdewebdev.org
Sat May 6 03:10:40 BST 2006


On Friday 05 May 2006 23:25, Jason Harris wrote:
> Hello,
>
> On Friday 05 May 2006 16:29, Hamish Rodda wrote:
> > > The CustomShortcut is now null, and so the program reverts to the
> > > "default" shortcut that was defined in the init code ("Ctrl+N").
> >
> > This I again disagree with for the reason above.  You should have to set
> > the CustomShortcut to the same as the default shortcut, otherwise you
> > could not disable the default shortcut.
>
> I think you still have the point of view where CustomShortcut is always the
> one that is actually used, and it's just a question of whether or not it
> matches the Default.  I am proposing a shift in the way shortcuts are
> handled internally, such that the Default shortcut is the one that is
> actually used...by default.  The Custom one is only used when it is
> defined.  This is more consistent with what the words "Default" and
> "Custom" actually mean.
>
> What exactly do you mean by "disable the default shortcut"?  In my imagined
> scheme, the Default is always there, it is simply overridden if a Custom
> shortcut has been defined, and when the Custom is undefined (i.e., set to
> null), the shortcut reverts to the default.  What is the use case for
> needing to "disable" the default in some other way?


My proposal is to call it just shortcut and not customShortcut!
This is in line with QT and I think less hard to understand. 

I see a problem with falling back to the default if you have no shortcut. What  
if the user wants to remove a shortcut? You would need to remove the default 
as well and then you are never able to revert to a default value in a 
settings dialog. 
So from my understanding the default should be: "use it if the user wants to 
reset the settings" and not "use it in case there is no shortcut"
Maybe we could change the name defaultShortcut to make it more clear?

Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060506/711cfac9/attachment.sig>


More information about the kde-core-devel mailing list