Finding shortcut

[Aaron J. Seigo]

On January 31, 2010, Michael Jansen wrote:
> By doing an api review and pointing out problems and not repeating the same
> old arguments in unrelated posts again and again.

get*() is not the standard design for Qt / KDE API. the main exceptions (rom 
reading through the APIs, anyways) seems to be when a variable is passed in as 
a parameter to the method/function and then set within the function, or when 
it will result in user interaction:

e.g.:

static QFont QFontDialog::getFont ( bool * ok, const QFont & initial, QWidget 
* parent, const QString & title, FontDialogOptions options )  

which has both properties, or:

void getContentsMargins ( int * left, int * top, int * right, int * bottom )

which appears in several classes and which doesn't return a value, but sets 
the values of the parameters passed in.

the methods in KGlobalAccel don't seem to follow this pattern, but it's more 
important to keep a class self-consistent imho and we obviously can't change 
the names of the other methods if we even wanted to at this point (at least, 
not until KDE5 :).

so i suggested "getGlobalShorcutByName" which probably shouldn't have a "get" 
in the name of it, except to keep KGlobalAccel self-consistent. ergo the 
comment that i don't know why 'get' is used: so that someone else didn't pop 
up and say "we shouldn't use 'get' in that case because it isn't consistent 
with the rest of the API in Qt/KDE".

you and i both know that we disagree quite strongly about other matters 
related to global shortcuts, matters which cause usability problems for 
plasma-desktop (and other apps, i imagine) which we therefore work around in 
our application code but which you have your own reasons for having 
implemented them as you have. this, however, has precisely nothing to do with 
the topic covered by John's email or my reply and no sarcasm or argumentation 
was used in my reply to John. i'm sorry if you read that into it, it was not 
intended in the least.

btw, you may also notice that i try to keep up with as many kdelibs API 
threads/reviews as possible. frankly, there aren't "enough" people who pay 
attention on a regular basis to kdelibs issues (though thankfully there are 
more who do so than have in the past, so progress is good! :). my reason to 
reply to John's email had nothing to do with it being about global accels and 
everything to do with it being about kdelibs API and it not having received 
any attention yet.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks