this happens because transfersChangedEvent() is executed too often,
as a workaround asign a variable that is changed just before the
notifications is emmited and reset on transfer add/remove. I'm not
sure if it has to be reset in the group actions so that may break
the notification in some cases, in any case KGet is far less
annoying now
this had to be done the hardway, at least for now. altough
KHelpMenu can return KMenu pointer it does not play well with the
rest of the code and will require quite some changes (AFAICT) so
for now I opted to re-create standard KHelpMenu with the actions
available for most applications (see TODO bellow). sadly, whatsThis
slot is not yet part of the public KDE UI API (or am I doing
something wrong?) and switchApplicationLanguage has just been made
(see kdelibs) and as such the action does nothing but does not
cause trouble either so - it has been added.
TODO: Tips of the day
since it is a multi-component application some of the translations
did not apply, specificly those that are bundled and only basic
(kdelibs4) translations were loaded. to fix this manually load the
catalogs has to be done
From: Rolf Eike Beer <kde@opensource.sf-tec.de>
Date: Sat, 27 Dec 2014 18:36:12 +0000
Subject: fix importing keys using GnuPG 2.1
X-Git-Tag: v14.12.1
X-Git-Url: http://quickgit.kde.org/?p=kgpg.git&a=commitdiff&h=dfd166f04c2567133f06c1963f69dbdcb0a94030
---
fix importing keys using GnuPG 2.1
More fields at the end of GnuPG output may be introduced in new implementations
and should just be ignored if they are not explicitely handled.
BUG:342249
FIXED-IN:14.12.1
---
