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
---
- check all output lines instead of stopping at first empty line (1.2 messages contain empty lines)
- check against new message spelling (tested against 1.2)
CCBUG: 341284
In the cases where we returned before calling KApplication::exec(), we
would end up leaking pointers such as |batchJob|, |window| and
|addToArchiveJob|.
Fix it by explicitly deleting |window| (since we do not have another
QWidget to make it a child of) and making |batchJob| and
|addToArchiveJob| be children of our main KApplication so that we do not
need to explicitly delete them under any circumstances.
