D12959: [Breeze Plasma Theme] Fix kleopatra icon to use color stylesheet

2018-05-18 Thread Andre Heinecke 
aheinecke accepted this revision.
aheinecke added a comment.
This revision is now accepted and ready to land.


  Works in Ubuntu 18.04 with default breeze theme: F5855745: 
kleo-plasma-tray.png 
  
  Thanks!

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  fixkleopatrabreezeicon

REVISION DETAIL
  https://phabricator.kde.org/D12959

To: kossebau, #plasma, aheinecke
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

Re: Review Request 127275: Ki18n: Fallback to QLocale::system uiLanguages in language initalisation

2016-03-08 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127275/
---

(Updated March 8, 2016, 3:34 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Localization and Translation (l10n).


Changes
---

Submitted with commit 26750a15fba059d3a703131e9cd400893aa596a6 by Andre 
Heinecke to branch master.


Repository: ki18n


Description
---

The intention for this patch is to fix the inital Language selection for 
Windows where the environment variables used in Ki18n are not set.
This is not a fix for a regression in Ki18n, afaik this never worked on 
Windows, we had some hacks in Gpg4win to write the language into kdeglobals 
during installation in kde4 times.

I don't think this needs to be ifdefed because it only appends so previous 
language selection is not affected.


Diffs
-

  src/klocalizedstring.cpp b24fe9b 

Diff: https://git.reviewboard.kde.org/r/127275/diff/


Testing
---

Tested on a german Windows system and got a "de" localized application.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127275: Ki18n: Fallback to QLocale::system uiLanguages in language initalisation

2016-03-07 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127275/
---

(Updated March 7, 2016, 12:32 p.m.)


Review request for KDE Frameworks and Localization and Translation (l10n).


Changes
---

Added ifndef Q_OS_UNIX around fallback.


Repository: ki18n


Description
---

The intention for this patch is to fix the inital Language selection for 
Windows where the environment variables used in Ki18n are not set.
This is not a fix for a regression in Ki18n, afaik this never worked on 
Windows, we had some hacks in Gpg4win to write the language into kdeglobals 
during installation in kde4 times.

I don't think this needs to be ifdefed because it only appends so previous 
language selection is not affected.


Diffs (updated)
-

  src/klocalizedstring.cpp b24fe9b 

Diff: https://git.reviewboard.kde.org/r/127275/diff/


Testing
---

Tested on a german Windows system and got a "de" localized application.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127275: Ki18n: Fallback to QLocale::system uiLanguages in language initalisation

2016-03-04 Thread Andre Heinecke 


> On March 4, 2016, 3:01 p.m., Chusslove Illich wrote:
> > src/klocalizedstring.cpp, line 368
> > <https://git.reviewboard.kde.org/r/127275/diff/1/?file=447946#file447946line368>
> >
> > I would nevertheless ifdef it. It may be that some strange thing is 
> > intentionally done with locale variables (e.g. to test something or kill 
> > localization), and then the behavior would deviate from that documented for 
> > Gettext.

I'm assuming that QLocale::system() is also changed accodingly in that case so 
I don't think its a problem. The code looks like it's using the same 
environment variables: 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qlocale_unix.cpp#n104
We still have to look at the environment variables in ki18n first because of 
modifier / charset handling, imo otherwise we could just use QLocale here.

For ifdef I would probably do an #infdef O_OS_UNIX instead of a Q_OS_WIN ? I'm 
not sure but I think this probably also makes sense on other platforms like 
android?


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127275/#review93158
---


On March 4, 2016, 2:53 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127275/
> ---
> 
> (Updated March 4, 2016, 2:53 p.m.)
> 
> 
> Review request for KDE Frameworks and Localization and Translation (l10n).
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> The intention for this patch is to fix the inital Language selection for 
> Windows where the environment variables used in Ki18n are not set.
> This is not a fix for a regression in Ki18n, afaik this never worked on 
> Windows, we had some hacks in Gpg4win to write the language into kdeglobals 
> during installation in kde4 times.
> 
> I don't think this needs to be ifdefed because it only appends so previous 
> language selection is not affected.
> 
> 
> Diffs
> -
> 
>   src/klocalizedstring.cpp b24fe9b 
> 
> Diff: https://git.reviewboard.kde.org/r/127275/diff/
> 
> 
> Testing
> ---
> 
> Tested on a german Windows system and got a "de" localized application.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127275: Ki18n: Fallback to QLocale::system uiLanguages in language initalisation

2016-03-04 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127275/
---

Review request for KDE Frameworks.


Repository: ki18n


Description
---

The intention for this patch is to fix the inital Language selection for 
Windows where the environment variables used in Ki18n are not set.
This is not a fix for a regression in Ki18n, afaik this never worked on 
Windows, we had some hacks in Gpg4win to write the language into kdeglobals 
during installation in kde4 times.

I don't think this needs to be ifdefed because it only appends so previous 
language selection is not affected.


Diffs
-

  src/klocalizedstring.cpp b24fe9b 

Diff: https://git.reviewboard.kde.org/r/127275/diff/


Testing
---

Tested on a german Windows system and got a "de" localized application.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127265: Fix windows build of Ki18n

2016-03-04 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/
---

(Updated March 4, 2016, 9:09 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.


Changes
---

Submitted with commit b91904c55ef1aaeeb60f9e8153dc8a1f00d77fb0 by Andre 
Heinecke to branch master.


Repository: ki18n


Description
---

In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
implentations.) Unrelated Windows changes were requested and then introduced 
which in my opinion were wrong (and in the opinion of my compiler ;-) ).

You can't just do an extern "C" dllimport declaration inside a function body:

src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
 extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;


Also that patch changed the Logic from an MSVC specific define to general 
Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW I'm 
pretty sure that the ifndef _MSC_VER was there for a reason.

This patch reverts the declaration move and logic change while keeping the 
__USE_GNU_GETTEXT guard.


Diffs
-

  src/kcatalog.cpp 083443d 

Diff: https://git.reviewboard.kde.org/r/127265/diff/


Testing
---

Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
GNU/Linux.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127265: Fix windows build of Ki18n

2016-03-04 Thread Andre Heinecke 


> On March 3, 2016, 9:35 p.m., Kevin Funk wrote:
> > Ship It!

Oh *facepalm* while pushing I noticed that I had not updated to latest changes 
and Thomas already fixed this issue,..
Anyhow Thomas patch did not use Q_DECL_IMPORT so I'm pushing that part of this 
patch.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/#review93140
---


On March 3, 2016, 5:49 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127265/
> ---
> 
> (Updated March 3, 2016, 5:49 p.m.)
> 
> 
> Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
> implentations.) Unrelated Windows changes were requested and then introduced 
> which in my opinion were wrong (and in the opinion of my compiler ;-) ).
> 
> You can't just do an extern "C" dllimport declaration inside a function body:
> 
> src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
>  extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;
> 
> 
> Also that patch changed the Logic from an MSVC specific define to general 
> Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW 
> I'm pretty sure that the ifndef _MSC_VER was there for a reason.
> 
> This patch reverts the declaration move and logic change while keeping the 
> __USE_GNU_GETTEXT guard.
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 083443d 
> 
> Diff: https://git.reviewboard.kde.org/r/127265/diff/
> 
> 
> Testing
> ---
> 
> Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
> GNU/Linux.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127265: Fix windows build of Ki18n

2016-03-03 Thread Andre Heinecke 


> On March 3, 2016, 4:51 p.m., Aleix Pol Gonzalez wrote:
> > src/kcatalog.cpp, line 150
> > <https://git.reviewboard.kde.org/r/127265/diff/1/?file=447929#file447929line150>
> >
> > Wouldn't it be the same to define it like this?
> > ```
> > #if defined(__USE_GNU_GETTEXT)
> > extern "C" int Q_DECL_IMPORT _nl_msg_cat_cntr;
> > #endif
> > ```
> > 
> > This way we wouldn't have to make special cases for each platform.
> > 
> > I just tried and works here (on Linux+Clang).

Ah nice, did not know / remembered this macro. I think in that case we can also 
drop the extern int declaration inside the function as we already declare it 
now in a platform independent manner as an external variable.

I've tested this again with mingw and GNU/Linux GCC and it still compiled.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/#review93104
---


On March 3, 2016, 5:49 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127265/
> ---
> 
> (Updated March 3, 2016, 5:49 p.m.)
> 
> 
> Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
> implentations.) Unrelated Windows changes were requested and then introduced 
> which in my opinion were wrong (and in the opinion of my compiler ;-) ).
> 
> You can't just do an extern "C" dllimport declaration inside a function body:
> 
> src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
>  extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;
> 
> 
> Also that patch changed the Logic from an MSVC specific define to general 
> Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW 
> I'm pretty sure that the ifndef _MSC_VER was there for a reason.
> 
> This patch reverts the declaration move and logic change while keeping the 
> __USE_GNU_GETTEXT guard.
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 083443d 
> 
> Diff: https://git.reviewboard.kde.org/r/127265/diff/
> 
> 
> Testing
> ---
> 
> Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
> GNU/Linux.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127265: Fix windows build of Ki18n

2016-03-03 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/
---

(Updated March 3, 2016, 5:49 p.m.)


Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.


Changes
---

used Q_DECL_IMPORT for a portable declaration of \_nl_msg_cat_cntr


Repository: ki18n


Description
---

In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
implentations.) Unrelated Windows changes were requested and then introduced 
which in my opinion were wrong (and in the opinion of my compiler ;-) ).

You can't just do an extern "C" dllimport declaration inside a function body:

src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
 extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;


Also that patch changed the Logic from an MSVC specific define to general 
Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW I'm 
pretty sure that the ifndef _MSC_VER was there for a reason.

This patch reverts the declaration move and logic change while keeping the 
__USE_GNU_GETTEXT guard.


Diffs (updated)
-

  src/kcatalog.cpp 083443d 

Diff: https://git.reviewboard.kde.org/r/127265/diff/


Testing
---

Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
GNU/Linux.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127265: Fix windows build of Ki18n

2016-03-03 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127265/
---

Review request for KDE Frameworks, Andreas Cord-Landwehr and Kåre Särs.


Repository: ki18n


Description
---

In review Request 127048 (Restrict _nl_msg_cat_cntr use to GNU gettext 
implentations.) Unrelated Windows changes were requested and then introduced 
which in my opinion were wrong (and in the opinion of my compiler ;-) ).

You can't just do an extern "C" dllimport declaration inside a function body:

src/kcatalog.cpp:190:16: error: expected unqualified-id before string constant
 extern "C" int __declspec(dllimport) _nl_msg_cat_cntr;


Also that patch changed the Logic from an MSVC specific define to general 
Q_OS_WIN. This appears to be wrong, too. While I'm only testing with MinGW I'm 
pretty sure that the ifndef _MSC_VER was there for a reason.

This patch reverts the declaration move and logic change while keeping the 
__USE_GNU_GETTEXT guard.


Diffs
-

  src/kcatalog.cpp 083443d 

Diff: https://git.reviewboard.kde.org/r/127265/diff/


Testing
---

Compiled with mingw and __USE_GNU_GETTEXT for Windows. Also compiled for 
GNU/Linux.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127245: Fix Kdelibs4 config migration for Windows

2016-03-03 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127245/
---

(Updated March 3, 2016, 1:28 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit acd2c096632a5ae54b9b2267a7159b0f658c4243 by Andre 
Heinecke to branch master.


Repository: kcoreaddons


Description
---

The old config was by default in ~/AppData/Roaming/.kde so on Windows we should 
look there, too.

The new config location (as used everywhere in KConfig) should be 
GenericConfigLocation and not ConfigLocation. 
According to http://doc.qt.io/qt-5/qstandardpaths.html this only makes a 
difference on Windows so I think it's still safe to change this.


Diffs
-

  src/lib/util/kdelibs4configmigrator.cpp c8560c1 
  src/lib/util/kdelibs4migration.cpp f631efa 

Diff: https://git.reviewboard.kde.org/r/127245/diff/


Testing
---

On Windows: Made changes to XMLGui rc file and both kleopatra config files with 
a KDE 4 Kleo. Checked that they were migrated and changes show up.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127245: Fix Kdelibs4 config migration for Windows

2016-03-02 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127245/
---

(Updated March 2, 2016, 11:04 a.m.)


Review request for KDE Frameworks.


Changes
---

Use SHGetFolderPath to match behavior of kdelibs4.

Tested this again.


Repository: kcoreaddons


Description
---

The old config was by default in ~/AppData/Roaming/.kde so on Windows we should 
look there, too.

The new config location (as used everywhere in KConfig) should be 
GenericConfigLocation and not ConfigLocation. 
According to http://doc.qt.io/qt-5/qstandardpaths.html this only makes a 
difference on Windows so I think it's still safe to change this.


Diffs (updated)
-

  src/lib/util/kdelibs4configmigrator.cpp c8560c1 
  src/lib/util/kdelibs4migration.cpp f631efa 

Diff: https://git.reviewboard.kde.org/r/127245/diff/


Testing
---

On Windows: Made changes to XMLGui rc file and both kleopatra config files with 
a KDE 4 Kleo. Checked that they were migrated and changes show up.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127245: Fix Kdelibs4 config migration for Windows

2016-03-02 Thread Andre Heinecke 


> On March 2, 2016, 8:19 a.m., David Faure wrote:
> > I couldn't find "AppData" or "Roaming" in kdelibs4 though. Did this come 
> > from windows API calls, or from kdewin maybe? Just wanted to check it was 
> > the exact same logic as in kdelibs4...

In kdecore/kernel/kstandarddirs.cpp line 1733   if ( SHGetFolderPathW(NULL, 
CSIDL_APPDATA, NULL, SHGFP_TYPE_CURRENT, wPath) == S_OK) < This puts 
~/AppData/Roaming in wPath (for Windows Vista and later).
which is then used in: localKdeDir = 
QDir::fromNativeSeparators(QString::fromUtf16((const ushort *) wPath)) + 
QLatin1Char('/') + QString::fromLatin1(KDE_DEFAULT_HOME) + QLatin1Char('/');


Thinking about it the patch would be better if it mirrors that behavior. I 
thought it's ok to hardcode AppData/Roaming (as XP compatibility should not be 
an issue) but it would be better to use SHGetFolderPath. I had not thought of 
cases where upgrades from XP to Vista to newer versions happened. In this case 
I think SHGetFolderPath might return a different path. So it's better to use 
that function.

I'll update the patch accordingly.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127245/#review93055
-------


On March 1, 2016, 4:50 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127245/
> ---
> 
> (Updated March 1, 2016, 4:50 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> The old config was by default in ~/AppData/Roaming/.kde so on Windows we 
> should look there, too.
> 
> The new config location (as used everywhere in KConfig) should be 
> GenericConfigLocation and not ConfigLocation. 
> According to http://doc.qt.io/qt-5/qstandardpaths.html this only makes a 
> difference on Windows so I think it's still safe to change this.
> 
> 
> Diffs
> -
> 
>   src/lib/util/kdelibs4configmigrator.cpp c8560c1 
>   src/lib/util/kdelibs4migration.cpp f631efa 
> 
> Diff: https://git.reviewboard.kde.org/r/127245/diff/
> 
> 
> Testing
> ---
> 
> On Windows: Made changes to XMLGui rc file and both kleopatra config files 
> with a KDE 4 Kleo. Checked that they were migrated and changes show up.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127245: Fix Kdelibs4 config migration for Windows

2016-03-01 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127245/
---

Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

The old config was by default in ~/AppData/Roaming/.kde so on Windows we should 
look there, too.

The new config location (as used everywhere in KConfig) should be 
GenericConfigLocation and not ConfigLocation. 
According to http://doc.qt.io/qt-5/qstandardpaths.html this only makes a 
difference on Windows so I think it's still safe to change this.


Diffs
-

  src/lib/util/kdelibs4configmigrator.cpp c8560c1 
  src/lib/util/kdelibs4migration.cpp f631efa 

Diff: https://git.reviewboard.kde.org/r/127245/diff/


Testing
---

On Windows: Made changes to XMLGui rc file and both kleopatra config files with 
a KDE 4 Kleo. Checked that they were migrated and changes show up.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KWidgetsAddons License (included breeze icons)

2016-03-01 Thread Andre Heinecke 
Hi,

I want to implement a similiar "Show Password" functionality as 
KPasswordDialog from KWidgetsAddons has in GnuPG's pinentry.

I'd like to use the same Icons for this, but Pinentry is GPLv2 or Later while 
breeze is LGPLv3. As I want to include them directly in the Source (without 
need for theme) this would mean changing the License of Pinentry which would 
basically mean I can't use those icons.

But both Icons I'd like to use are also part of KWidgetsAddons.
So, does this mean the icons are licensed (as part of KWidgetsaddons) under 
LGPLv2 or is KWidgetsAddons LGPLv3 and did not have the COPYING files updated?

I've tried contacting the Author of the Icons to ask directly about this but I 
have not received a reply. (Probably a wrong mail)

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-29 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/
---

(Updated Feb. 29, 2016, 4:14 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit f40cc922540c423f424b48ec047da015353071af by Andre 
Heinecke to branch master.


Repository: kxmlgui


Description
---

While packaging Kleopatra's translations for Gpg4win I've noticed that there 
were blank entries in the Switchlanguagedialog.
Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
Windows).

This patch handles this and uses the non native QLocale::languageToString as a 
fallback. The idea is that a non native Name is better then no name (and a 
blank entry in the dialog) at all.

Ideally every language would have a native name but until this is the case I 
think this fallback makes sense.


Diffs
-

  src/kswitchlanguagedialog_p.cpp 039daea 

Diff: https://git.reviewboard.kde.org/r/127136/diff/


Testing
---

See attached screenshots of Kleopatra's switchlanguage dialog before and after 
the patch. Low German is an example where the native name was empty.


File Attachments


Dialog before the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
Dialog after the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-29 Thread Andre Heinecke 


> On Feb. 27, 2016, 1:51 p.m., David Faure wrote:
> > src/kswitchlanguagedialog_p.cpp, line 343
> > <https://git.reviewboard.kde.org/r/127136/diff/2/?file=445160#file445160line343>
> >
> > atleast windows -> at least Windows
> > (missing space)

As Thiago pointed out in the Bug report, my initial analysis that this is a 
Windows issue was wrong. According to the QtBug this is a general Qt problem so 
I've removed the "some platforms / at least Windows" part of the comment.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/#review92833
-------


On Feb. 23, 2016, 3:16 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 23, 2016, 3:16 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-23 Thread Andre Heinecke 


> On Feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?
> 
> Andre Heinecke wrote:
> I've just checked. It's a Windows thing. qlocale_win calls windows API 
> getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
>  ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
> and Indeed this might be fixed at some point in the far Future in Windows.
> 
> But my Observation is Qt does not (and for Windows apparently can not) 
> guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should 
> try to handle this. As I don't know how this is for other platforms and it 
> only adds a tiny overhead I also don't think this should be Ifdefed for 
> Windows.
> 
> Albert Astals Cid wrote:
> well, reading the documentation of the function never mentions it can be 
> empty, and given all languages probably have a way to call themselves I as an 
> api user find it surprising it returns empty. 
> 
> sure I can agree it is a Windows bug, but why workaround it in every 
> single call to nativeLanguageName instead of inside Qt code? 
> 
> I mean, we probably even have this problem in other KDE code.
> 
> And sure, Qt takes a while to update/release so temporarily we may want 
> this workaround committed so our users get the fix earlier but I would really 
> appreciate if you could create a MR for Qt that either documents that 
> nativeLanguageName can return empty or one that makes sure it is not empty by 
> doing the same fallback we do here.

I'm not a qt contributor and this issue is not important enough to me to spend 
the time with this. I'm pretty unwilling to work more on this. It would be 
easier just dropping the exotic languages for which this problem exists. 
(Although I really love the Plattdeutsch localisation of Kleopatra ;-) )
As a compromoise I've reported a bug 
https://bugreports.qt.io/browse/QTBUG-51323 and mentioned this in the patch.

The only other usages of nativeLanguageName in frameworks are sonnet and 
kconfigwidgets/klanguagebutton.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/#review92630
---


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-23 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/
---

(Updated Feb. 23, 2016, 3:16 p.m.)


Review request for KDE Frameworks.


Changes
---

Mentioned Qt bug and that it's platform specific.


Repository: kxmlgui


Description
---

While packaging Kleopatra's translations for Gpg4win I've noticed that there 
were blank entries in the Switchlanguagedialog.
Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
Windows).

This patch handles this and uses the non native QLocale::languageToString as a 
fallback. The idea is that a non native Name is better then no name (and a 
blank entry in the dialog) at all.

Ideally every language would have a native name but until this is the case I 
think this fallback makes sense.


Diffs (updated)
-

  src/kswitchlanguagedialog_p.cpp 039daea 

Diff: https://git.reviewboard.kde.org/r/127136/diff/


Testing
---

See attached screenshots of Kleopatra's switchlanguage dialog before and after 
the patch. Low German is an example where the native name was empty.


File Attachments


Dialog before the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
Dialog after the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-22 Thread Andre Heinecke 


> On Feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?

I've just checked. It's a Windows thing. qlocale_win calls windows API 
getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
 ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
and Indeed this might be fixed at some point in the far Future in Windows.

But my Observation is Qt does not (and for Windows apparently can not) 
guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should try 
to handle this. As I don't know how this is for other platforms and it only 
adds a tiny overhead I also don't think this should be Ifdefed for Windows.


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/#review92630
---


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

2016-02-22 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127136/
---

Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

While packaging Kleopatra's translations for Gpg4win I've noticed that there 
were blank entries in the Switchlanguagedialog.
Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
Windows).

This patch handles this and uses the non native QLocale::languageToString as a 
fallback. The idea is that a non native Name is better then no name (and a 
blank entry in the dialog) at all.

Ideally every language would have a native name but until this is the case I 
think this fallback makes sense.


Diffs
-

  src/kswitchlanguagedialog_p.cpp 039daea 

Diff: https://git.reviewboard.kde.org/r/127136/diff/


Testing
---

See attached screenshots of Kleopatra's switchlanguage dialog before and after 
the patch. Low German is an example where the native name was empty.


File Attachments


Dialog before the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
Dialog after the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-02-03 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---

(Updated Feb. 3, 2016, 11:41 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit cca106313c9ec77f5dc409bd1b104f4e93da3cf1 by Andre 
Heinecke to branch master.


Repository: kxmlgui


Description
---

This is part of a three patch series that aims to allow a "leightweight" build 
of KXmlGui without DBus and KService dependencies. I've added the patches to: 
https://phabricator.kde.org/T1390 I'm not sure if I can create reviews that 
depend on changes from another review, I'll try and if it does not work I'll 
open one after another.

Global shortcuts are a nice optional feature to have. But as they are not 
strictly neccessary for the core functionality of KXmlGui, as I see it, and 
pull in an extra dependency to DBus and need runtime support on the target 
platform they should be optional.

This (and the other changes) add lots of unloved ifdefs, I could understand if 
thats disliked. But let me explain the background of this change:

I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
This is nice. Frameworks are awesome, I can just pick what I need and don't 
have dependencies to lots of things that are actually not needed.
Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to do.
I want:
- configureable "KDE Style" GUI
- configurable Shortcuts
- KDE Standardactions (e.g. Help / WhatsThis)
- kbugreport
- KDE Integration in an KDE Environment

But I don't want:
- Global Shortcuts (we don't have kded so this won't work for us anyway)
- DBus (our dbus is directory scoped and there are no other applications using 
dbus installed by us)
- KService dependency (System configuration has been troublesome in the past on 
Windows and is not neccessary if we provide just a single installation)

So these Patches are my way out of this Problem. Without the optional packages 
KXmlGui provides what I want and does not depend on what I don't want.


Diffs
-

  CMakeLists.txt e2de5b0 
  src/CMakeLists.txt 58f0c7a 
  src/config-xmlgui.h.cmake 07c882f 
  src/kactioncollection.cpp 9c45725 
  src/kkeysequencewidget.cpp b2e2b6a 
  src/kshortcuteditwidget.cpp 670d031 
  src/kshortcutseditor.cpp 99dfb3d 
  src/kshortcutseditoritem.cpp 461a90c 
  src/kxmlguifactory.cpp 6848610 

Diff: https://git.reviewboard.kde.org/r/126895/diff/


Testing
---

Compiled with and without dependency. Tested Kleopatra against it.
Not yet tested on Windows, will do so in the next days.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-02-01 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---

(Updated Feb. 1, 2016, 10:53 a.m.)


Review request for KDE Frameworks.


Changes
---

Optional dependency is now implemented as a build option.


Repository: kxmlgui


Description
---

This is part of a three patch series that aims to allow a "leightweight" build 
of KXmlGui without DBus and KService dependencies. I've added the patches to: 
https://phabricator.kde.org/T1390 I'm not sure if I can create reviews that 
depend on changes from another review, I'll try and if it does not work I'll 
open one after another.

Global shortcuts are a nice optional feature to have. But as they are not 
strictly neccessary for the core functionality of KXmlGui, as I see it, and 
pull in an extra dependency to DBus and need runtime support on the target 
platform they should be optional.

This (and the other changes) add lots of unloved ifdefs, I could understand if 
thats disliked. But let me explain the background of this change:

I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
This is nice. Frameworks are awesome, I can just pick what I need and don't 
have dependencies to lots of things that are actually not needed.
Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to do.
I want:
- configureable "KDE Style" GUI
- configurable Shortcuts
- KDE Standardactions (e.g. Help / WhatsThis)
- kbugreport
- KDE Integration in an KDE Environment

But I don't want:
- Global Shortcuts (we don't have kded so this won't work for us anyway)
- DBus (our dbus is directory scoped and there are no other applications using 
dbus installed by us)
- KService dependency (System configuration has been troublesome in the past on 
Windows and is not neccessary if we provide just a single installation)

So these Patches are my way out of this Problem. Without the optional packages 
KXmlGui provides what I want and does not depend on what I don't want.


Diffs (updated)
-

  CMakeLists.txt e2de5b0 
  src/CMakeLists.txt 58f0c7a 
  src/config-xmlgui.h.cmake 07c882f 
  src/kactioncollection.cpp 9c45725 
  src/kkeysequencewidget.cpp b2e2b6a 
  src/kshortcuteditwidget.cpp 670d031 
  src/kshortcutseditor.cpp 99dfb3d 
  src/kshortcutseditoritem.cpp 461a90c 
  src/kxmlguifactory.cpp 6848610 

Diff: https://git.reviewboard.kde.org/r/126895/diff/


Testing
---

Compiled with and without dependency. Tested Kleopatra against it.
Not yet tested on Windows, will do so in the next days.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-29 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-29 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-29 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-28 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-28 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-28 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---

(Updated Jan. 28, 2016, 1:29 p.m.)


Review request for KDE Frameworks.


Changes
---

Only make GlobalAccel optional for non UNIX builds.


Repository: kxmlgui


Description
---

This is part of a three patch series that aims to allow a "leightweight" build 
of KXmlGui without DBus and KService dependencies. I've added the patches to: 
https://phabricator.kde.org/T1390 I'm not sure if I can create reviews that 
depend on changes from another review, I'll try and if it does not work I'll 
open one after another.

Global shortcuts are a nice optional feature to have. But as they are not 
strictly neccessary for the core functionality of KXmlGui, as I see it, and 
pull in an extra dependency to DBus and need runtime support on the target 
platform they should be optional.

This (and the other changes) add lots of unloved ifdefs, I could understand if 
thats disliked. But let me explain the background of this change:

I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
This is nice. Frameworks are awesome, I can just pick what I need and don't 
have dependencies to lots of things that are actually not needed.
Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to do.
I want:
- configureable "KDE Style" GUI
- configurable Shortcuts
- KDE Standardactions (e.g. Help / WhatsThis)
- kbugreport
- KDE Integration in an KDE Environment

But I don't want:
- Global Shortcuts (we don't have kded so this won't work for us anyway)
- DBus (our dbus is directory scoped and there are no other applications using 
dbus installed by us)
- KService dependency (System configuration has been troublesome in the past on 
Windows and is not neccessary if we provide just a single installation)

So these Patches are my way out of this Problem. Without the optional packages 
KXmlGui provides what I want and does not depend on what I don't want.


Diffs (updated)
-

  CMakeLists.txt 9d79619 
  src/CMakeLists.txt 58f0c7a 
  src/config-xmlgui.h.cmake 07c882f 
  src/kactioncollection.cpp 9c45725 
  src/kkeysequencewidget.cpp b2e2b6a 
  src/kshortcuteditwidget.cpp 670d031 
  src/kshortcutseditor.cpp 99dfb3d 
  src/kshortcutseditoritem.cpp 461a90c 
  src/kxmlguifactory.cpp 2767e69 

Diff: https://git.reviewboard.kde.org/r/126895/diff/


Testing
---

Compiled with and without dependency. Tested Kleopatra against it.
Not yet tested on Windows, will do so in the next days.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-28 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-28 Thread Andre Heinecke 
Hi,

On Wednesday 27 January 2016 21:28:36 Andreas Hartmetz wrote:
> On Mittwoch, 27. Januar 2016 17:21:33 CET Boudewijn Rempt wrote:
> [snip]
> 
> > whether kglobalshortcuts is functional or not is besides the point:
> > the point is that whether it works or not it doesn't add any
> > functionality to the average application. Global shortcuts are useful
> > only for a very limited set of applications, so it should always have
> > been an optional dependency.
> 
> Here is something that is never beside the point:
> maintenance burden and continuous-integration-ability.
> ifdefs are somewhat bad for maintainability and really, really bad for a
> continuous integration systems's ability to detect relevant build
> breakage. I am repeating Martin's argument here with different words.

To repeat our argument (yay) we feel that we need to have the KXmlGui library 
as one of the core libraries for "KDE ishness" not to always depend on 
KGlobalAccel on all platforms as other Platforms have different concepts for 
Global shortcuts and they don't make sense for our users that we see.

Wrt maintenance burden / CI effort. Please you can say you only maintain and 
Test the recommended usage. Our alternative is that we have to Patch it out 
then we have to maintain the patches and basically a fork.

Also this is really a very simple patch. It's not much different behavior it 
just does not allow you to configure Global Shortcuts through KxmlGui.

> The most maintainable way to make a feature optional is to disable it at
> runtime. 

I disagree with that. Runtime dependencies are more likely to cause bugs as a 
developer can not easily see / know how a function behaves when writing code.

Runtime dependencies also don't make sense for single Application deployments 
as we control all dependencies. The way it was in the past users had a Global 
Shortcuts configuration entry through KXmlGui which was always dysfunctional 
because we did not ship the necessary runtime components. 

And KGlobalAccel is not the only thing. I don't want to see spellchecking 
entires either that won't work because we have not installed a spellchecking 
libary or dictionaries. Etc.

> Only when this severely hurts performance or a feature plain
> won't build on a certain platform should it be disabled via ifdefs, and
> in the latter case, maybe it can be put into its own class that gets a
> real and a dummy implementation.

I dislike the dummy implementation. This makes code harder to understand and 
is more effort to maintain then simple harsh ifdefs.

It's also not a pattern already established for optional library depdenencies. 
It's established in the form of different implementations which might be 
dummies in a single library for different platforms. But to have dummy classes 
for optional dependencies is something different and afaik not established in 
KDE.

> My argument is first and foremost but for putting the knife where the
> least amount of stuff needs to be cut,

I think that XMLGui is the right place for this. XMLGui is a useful library 
without Global Shortcuts. It's very little code that needs GlobalAccel and it 
was easy to cut it out. There were not even any header / API changes 
neccessary for this.

> even if that results in shipping
> an unnecessary (small!) module.

I fail to see how this would be advantageous at all. Having code in a library 
that allows it to be dysfunctional is wrong. And I would not propose making 
such a change in GlobalAccel. Why should anyone would want to waste resources 
for something that does not add anything at all.

Shipping a library means that we have to include it in our build system, we 
have to update it regularly, we have to fix build errors for our platform, we 
have to ship the license, we have to include the source code in our source 
distribution etc. 

> Maybe there is a better solution, though.
> How about a dummy KGlobalShortcuts implementation in KXmlGui? There may
> be a few places where ifdefs are still required (e.g. completely hiding
> - and I don't mean removing - inert UI), but the vast majority of things
> in KGlobalShortcuts can be faked very easily by doing nothing at all.
> Most code paths don't need to be removed if there is simply no way to
> trigger them.

See above. A dummy library would imho be a more invasive change and harder to 
maintain then the ifdefs.

> The thing to be faked is a system that has no global shortcuts and where
> setting them somehow always fails. Maybe pretend to applications that it
> doesn't fail, shouldn't really matter.

Why would you want to do that? The only thing it adds is confusion for 
developers and users imho.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevatio

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-27 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-27 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
>     Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.
> 
> Andre Heinecke wrote:
> For me the build problem with KGlobalAccel is the build dependency to 
> DBus. BC drop in with No ops would help (in which case the configuration 
> entries should be completly hidden in the gui). But would a KGlobalAccel 
> without DBus / No-Ops be easier to maintain?
> 
> And the best thing for me is that If I don't want some features to be 
> able not to build them at all instead of a replacement library. And a 
> KGlobalAccel "Dummy" as part of KXmlGui also appears wrong to me.
> 
> Also my other two patches make DBus and KTextWidgets op

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-27 Thread Andre Heinecke 


> On Jan. 27, 2016, 7:02 a.m., Martin Gräßlin wrote:
> > Just in case that there is misunderstanding going on:
> > 
> > > Global Shortcuts (we don't have kded so this won't work for us anyway)
> > 
> > Global shortcut handling does not depend on kded!
> > 
> > Also I want to point out to 
> > http://commits.kde.org/kglobalaccel/40d047f013dc6f0e2f78066184a51a8c6e22eccd
> >  which was especially written for the behavior in xmlgui. As long as you 
> > don't configure a shortcut on a QAction it won't actually start the runtime 
> > part.
> > 
> > If the motivation is to ensure you don't need it on Krita on non-Linux: 
> > just don't ship the binary. You don't need it.

Yes misunderstanding on my side which component handles globalshortcuts at 
runtime. I only knew that they never were available in Gpg4win / Kleopatra as 
we didn't ship lots of runtime dependencies.

But with Frameworks I want to clean up the build dependencies, too. In KDE4 we 
had so many dependencies that we were unable to manage them as part of the 
Gpg4win build system and had to use Emerge on Windows to prepare binary 
packages of Kleopatra. This made Kleopatra maintenance and updates really hard 
and made it nearly impossible for a third party to rebuild everything from 
source. (example: kdelibs neeeded phonon, phonon on windows needed the vlc 
backend so we had a build dependency against vlc (and it's dependencies) even 
though Kleopatra does not play a single sound and hat no runtime support for 
any of this)


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/#review91635
---


On Jan. 27, 2016, 8:53 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126895/
> ---
> 
> (Updated Jan. 27, 2016, 8:53 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> This is part of a three patch series that aims to allow a "leightweight" 
> build of KXmlGui without DBus and KService dependencies. I've added the 
> patches to: https://phabricator.kde.org/T1390 I'm not sure if I can create 
> reviews that depend on changes from another review, I'll try and if it does 
> not work I'll open one after another.
> 
> Global shortcuts are a nice optional feature to have. But as they are not 
> strictly neccessary for the core functionality of KXmlGui, as I see it, and 
> pull in an extra dependency to DBus and need runtime support on the target 
> platform they should be optional.
> 
> This (and the other changes) add lots of unloved ifdefs, I could understand 
> if thats disliked. But let me explain the background of this change:
> 
> I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
> This is nice. Frameworks are awesome, I can just pick what I need and don't 
> have dependencies to lots of things that are actually not needed.
> Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to 
> do.
> I want:
> - configureable "KDE Style" GUI
> - configurable Shortcuts
> - KDE Standardactions (e.g. Help / WhatsThis)
> - kbugreport
> - KDE Integration in an KDE Environment
> 
> But I don't want:
> - Global Shortcuts (we don't have kded so this won't work for us anyway)
> - DBus (our dbus is directory scoped and there are no other applications 
> using dbus installed by us)
> - KService dependency (System configuration has been troublesome in the past 
> on Windows and is not neccessary if we provide just a single installation)
> 
> So these Patches are my way out of this Problem. Without the optional 
> packages KXmlGui provides what I want and does not depend on what I don't 
> want.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 9d79619 
>   src/CMakeLists.txt 58f0c7a 
>   src/config-xmlgui.h.cmake 07c882f 
>   src/kactioncollection.cpp 9c45725 
>   src/kkeysequencewidget.cpp b2e2b6a 
>   src/kshortcuteditwidget.cpp 670d031 
>   src/kshortcutseditor.cpp 99dfb3d 
>   src/kshortcutseditoritem.cpp 461a90c 
>   src/kxmlguifactory.cpp 2767e69 
> 
> Diff: https://git.reviewboard.kde.org/r/126895/diff/
> 
> 
> Testing
> ---
> 
> Compiled with and without dependency. Tested Kleopatra against it.
> Not yet tested on Windows, will do so in the next days.
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-27 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---

(Updated Jan. 27, 2016, 8:53 a.m.)


Review request for KDE Frameworks.


Changes
---

Changed package properties type from optional to recommended


Repository: kxmlgui


Description
---

This is part of a three patch series that aims to allow a "leightweight" build 
of KXmlGui without DBus and KService dependencies. I've added the patches to: 
https://phabricator.kde.org/T1390 I'm not sure if I can create reviews that 
depend on changes from another review, I'll try and if it does not work I'll 
open one after another.

Global shortcuts are a nice optional feature to have. But as they are not 
strictly neccessary for the core functionality of KXmlGui, as I see it, and 
pull in an extra dependency to DBus and need runtime support on the target 
platform they should be optional.

This (and the other changes) add lots of unloved ifdefs, I could understand if 
thats disliked. But let me explain the background of this change:

I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
This is nice. Frameworks are awesome, I can just pick what I need and don't 
have dependencies to lots of things that are actually not needed.
Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to do.
I want:
- configureable "KDE Style" GUI
- configurable Shortcuts
- KDE Standardactions (e.g. Help / WhatsThis)
- kbugreport
- KDE Integration in an KDE Environment

But I don't want:
- Global Shortcuts (we don't have kded so this won't work for us anyway)
- DBus (our dbus is directory scoped and there are no other applications using 
dbus installed by us)
- KService dependency (System configuration has been troublesome in the past on 
Windows and is not neccessary if we provide just a single installation)

So these Patches are my way out of this Problem. Without the optional packages 
KXmlGui provides what I want and does not depend on what I don't want.


Diffs (updated)
-

  CMakeLists.txt 9d79619 
  src/CMakeLists.txt 58f0c7a 
  src/config-xmlgui.h.cmake 07c882f 
  src/kactioncollection.cpp 9c45725 
  src/kkeysequencewidget.cpp b2e2b6a 
  src/kshortcuteditwidget.cpp 670d031 
  src/kshortcutseditor.cpp 99dfb3d 
  src/kshortcutseditoritem.cpp 461a90c 
  src/kxmlguifactory.cpp 2767e69 

Diff: https://git.reviewboard.kde.org/r/126895/diff/


Testing
---

Compiled with and without dependency. Tested Kleopatra against it.
Not yet tested on Windows, will do so in the next days.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-27 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.
> 
> Andre Heinecke wrote:
> Hi,
> 
> Abstracting it out would also be quite invasive imho. And from my 
> experience abstraced (optional) features are even harder to maintain then 
> ifdefs where you can easily see the codepath taken when something is not 
> available. While side effects through abstraction are harder to see when 
> hacking on code.
> 
> As for the other point:
> - GlobalAccel means that you basically need to have a keylogger on your 
> platform. I don't want that. There are system ways on Windows to create 
> global shortcuts already. Not as fine grained as KDE Actions but you could 
> use them to do command line calls.
> - I don't really see this as a Windows only thing. KXmlGui provides very 
> useful features even without Global Shortcuts. And as for making KGlobalAccel 
> just dumb on Windows. While I think this would generally be a good idea I 
> expect that others (from Kde-Windows) who provide several KDE applications 
> and stuff like Systemsettings on Windows would disagree.
> 
> We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
> available? This could avoid lots of ifdefs. But this would add a bit 
> maintenance cost when new API is used. While the IFDEFS make it quite 
> transparent to hackers that if you do thomething with GlobalAccel "please 
> guard it".
> 
> Aleix Pol Gonzalez wrote:
> @boud, yes, I also thought about your RR, in fact I looked it up but 
> couldn't find it.
> 
> Ok, maybe it's actually the way to make xmlgui viable to deploy.
> 
> Take this as a +1 by me.
> 
> Martin Gräßlin wrote:
> Could we maybe continue the route I went with making sure that 
> kglobalaccel doesn't start? I'm quite concerned about the ifdefs. If there 
> are still situations where kglobalacceld is started without being needed, 
> let's fix that. Let's make it a proper runtime thing instead of an ifdef 
> messery nobody will check.
> 
> I'm quite concerned about making the change optional as that's a route to 
> breakage with distros and as the maintainer of kglobalaccel I'm not looking 
> forward to those bug reports.
> 
> Boudewijn Rempt wrote:
> Well, part of the point, for me at least, is not having the dependency at 
> all. Any extra library, especially one that adds no functionality but is just 
> present,  is a burden just like #idefs are a burden.
> 
> Martin Gräßlin wrote:
> What can we do to make the burden not so hard on your side without adding 
> the ifdefs? KGlobalaccel is basically a tier 1 - the higher number is due to 
> the runtime part. Would it help to make the runtime part optional? Would it 
> help to have a BC drop in replacement which just no-ops?
> 
> By doing the change as suggested here new burden is created and moved to 
> the shoulders of others. E.g. all Linux distributions which now have to be 
> more careful with packaging. So we need to find the right balance.
> 
> Boudewijn Rempt wrote:
> Well, for me personally it's water under the bridge. On the other hand, I 
> don't think that it's a burden for distributions: distributions always 
> install every dependency, even if it's optional. That is the big problem that 
> has led over the years to people complaining that Krita needed Marble, for 
> instance.

For me the build problem with KGlobalAccel is the build dependency to DBus. BC 
drop in with No ops would help (in which case the configuration entries should 
be completly hidden in the gui). But would a KGlobalAccel without DBus / No-Ops 
be easier to maintain?

And the best thing for me is that If I don't want some features to be able not 
to build them at all instead of a replacement library. And a KGlobalAccel 
"Dummy" as part of KXmlGui also appears wrong to me.

Also my other two patches make DBus and KTextWidgets optional. For these I 
definetly think that Ifdefs are the right way to go

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-26 Thread Andre Heinecke 
Hi,

On Tuesday 26 January 2016 20:47:34 Boudewijn Rempt wrote:
> On Tue, 26 Jan 2016, Andre Heinecke wrote:
> > On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote:
> >> Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-)
> In the end, I decided to fork, instead of maintaining patches. That allowed
> us to hack the app shortcut system, too. For other frameworks, I do
> maintain patches.

In my experience in KDE-Windows I call maintaining patches in the long term a 
fork. KDE-Windows has lots of examples of this. :-)


Can you point me to your Forks / Patches? I don't know how to find them. I 
don't see a branch in emerge or something.
You've probably already solved some other things I'm facing currently. :-)


I think that we should try to push the KDE Community in a way that we don't 
need to fork / patch anymore for our needs. In my understanding the Frameworks 
effort was specifically done to make it easier just to grab some parts of KDE 
Libraries one might find useful without having to include the monolithic 
"kdelibs" overhead / dependencies. And if we beneficiaries of such an effort 
now 
end up forking things, the whole effort could be called a failure :-/

> > Let's see if my patches fare better. ConfigWidgets and IconThemes i find
> > ok. :-)
> Well, I didn't need those either. Because Krita has so many icons, some
> Windows tools like sandboxie and some virus scanners complain, which meant
> I basically _had_ to pack all icons in qrc files.

So far we had not problems with that. We always have problems with "Virus 
scanners" but this is (i think) mostly because we contain lots of crypto 
algorithms that are also used by CryptoLocker Viruses.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-26 Thread Andre Heinecke 
Hi,

On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote:
> Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-)

Uh, damn, I missed this :-(

I guess the intention is the same. KXmlGui is pretty important to have a "KDE 
Application" but it pulls in so much dependencies that it's imho a bit against 
the Frameworks Idea.

And the demand for this should be obvious if two maintainers of large KDE-
Windows deployments independently write such Patches ;-) I would go so far as 
basically forking it (maintaining patches as part of gpg4win) to avoid the 
DBus / KService dependency.

Let's see if my patches fare better. ConfigWidgets and IconThemes i find ok. :-)

Regards,
Andre

P.S.
I have not figured out how to create reviewrequests that depend on a revision 
under review so you have to look at the phabricator link for the other 
(similar) patches.

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-26 Thread Andre Heinecke 


> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote:
> > Hi,
> > I'm a bit afraid of all these ifndef. Do you think it would make sense to 
> > abstract out the KGlobalAccel usage?
> > 
> > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) 
> > on Windows?
> 
> Boudewijn Rempt wrote:
> I would say: most applications do not need global accelerators, so making 
> kglobalaccel functional on windows is not really relevant, you wouldn't want 
> that dependency anyway because it doesn't add functionality. And building a 
> library and including it is always a burden, so I would say it's much better 
> to make it optional.

Hi,

Abstracting it out would also be quite invasive imho. And from my experience 
abstraced (optional) features are even harder to maintain then ifdefs where you 
can easily see the codepath taken when something is not available. While side 
effects through abstraction are harder to see when hacking on code.

As for the other point:
- GlobalAccel means that you basically need to have a keylogger on your 
platform. I don't want that. There are system ways on Windows to create global 
shortcuts already. Not as fine grained as KDE Actions but you could use them to 
do command line calls.
- I don't really see this as a Windows only thing. KXmlGui provides very useful 
features even without Global Shortcuts. And as for making KGlobalAccel just 
dumb on Windows. While I think this would generally be a good idea I expect 
that others (from Kde-Windows) who provide several KDE applications and stuff 
like Systemsettings on Windows would disagree.

We could add a dummy class in KXmlGui thats used if KGlobalAccel is not 
available? This could avoid lots of ifdefs. But this would add a bit 
maintenance cost when new API is used. While the IFDEFS make it quite 
transparent to hackers that if you do thomething with GlobalAccel "please guard 
it".


- Andre


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/#review91623
---


On Jan. 26, 2016, 6:25 p.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126895/
> ---
> 
> (Updated Jan. 26, 2016, 6:25 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> This is part of a three patch series that aims to allow a "leightweight" 
> build of KXmlGui without DBus and KService dependencies. I've added the 
> patches to: https://phabricator.kde.org/T1390 I'm not sure if I can create 
> reviews that depend on changes from another review, I'll try and if it does 
> not work I'll open one after another.
> 
> Global shortcuts are a nice optional feature to have. But as they are not 
> strictly neccessary for the core functionality of KXmlGui, as I see it, and 
> pull in an extra dependency to DBus and need runtime support on the target 
> platform they should be optional.
> 
> This (and the other changes) add lots of unloved ifdefs, I could understand 
> if thats disliked. But let me explain the background of this change:
> 
> I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
> This is nice. Frameworks are awesome, I can just pick what I need and don't 
> have dependencies to lots of things that are actually not needed.
> Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to 
> do.
> I want:
> - configureable "KDE Style" GUI
> - configurable Shortcuts
> - KDE Standardactions (e.g. Help / WhatsThis)
> - kbugreport
> - KDE Integration in an KDE Environment
> 
> But I don't want:
> - Global Shortcuts (we don't have kded so this won't work for us anyway)
> - DBus (our dbus is directory scoped and there are no other applications 
> using dbus installed by us)
> - KService dependency (System configuration has been troublesome in the past 
> on Windows and is not neccessary if we provide just a single installation)
> 
> So these Patches are my way out of this Problem. Without the optional 
> packages KXmlGui provides what I want and does not depend on what I don't 
> want.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 9d79619 
>   src/CMakeLists.txt 58f0c7a 
>   src/config-xmlgui.h.cmake 07c882f 
>   src/kactioncollection.cpp 9c45725 
>   src/kkeysequencewidget.cpp b2e2b6a 
>   src/kshortcuteditwidget.cpp 670d

Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

2016-01-26 Thread Andre Heinecke 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126895/
---

Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

This is part of a three patch series that aims to allow a "leightweight" build 
of KXmlGui without DBus and KService dependencies. I've added the patches to: 
https://phabricator.kde.org/T1390 I'm not sure if I can create reviews that 
depend on changes from another review, I'll try and if it does not work I'll 
open one after another.

Global shortcuts are a nice optional feature to have. But as they are not 
strictly neccessary for the core functionality of KXmlGui, as I see it, and 
pull in an extra dependency to DBus and need runtime support on the target 
platform they should be optional.

This (and the other changes) add lots of unloved ifdefs, I could understand if 
thats disliked. But let me explain the background of this change:

I'm currently updating Kleopatra in Gpg4win to a KDE Frameworks based build. 
This is nice. Frameworks are awesome, I can just pick what I need and don't 
have dependencies to lots of things that are actually not needed.
Then comes KXmlGui, adds 20 Framework dependencies, and I don't know what to do.
I want:
- configureable "KDE Style" GUI
- configurable Shortcuts
- KDE Standardactions (e.g. Help / WhatsThis)
- kbugreport
- KDE Integration in an KDE Environment

But I don't want:
- Global Shortcuts (we don't have kded so this won't work for us anyway)
- DBus (our dbus is directory scoped and there are no other applications using 
dbus installed by us)
- KService dependency (System configuration has been troublesome in the past on 
Windows and is not neccessary if we provide just a single installation)

So these Patches are my way out of this Problem. Without the optional packages 
KXmlGui provides what I want and does not depend on what I don't want.


Diffs
-

  CMakeLists.txt 9d79619 
  src/CMakeLists.txt 58f0c7a 
  src/config-xmlgui.h.cmake 07c882f 
  src/kactioncollection.cpp 9c45725 
  src/kkeysequencewidget.cpp b2e2b6a 
  src/kshortcuteditwidget.cpp 670d031 
  src/kshortcutseditor.cpp 99dfb3d 
  src/kshortcutseditoritem.cpp 461a90c 
  src/kxmlguifactory.cpp 2767e69 

Diff: https://git.reviewboard.kde.org/r/126895/diff/


Testing
---

Compiled with and without dependency. Tested Kleopatra against it.
Not yet tested on Windows, will do so in the next days.


Thanks,

Andre Heinecke

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [Kde-pim] [kf5-]gpgmepp

2015-11-24 Thread Andre Heinecke 
Hi,

On Tuesday 24 November 2015 10:27:08 René J.  V. Bertin wrote:
> Andre Heinecke wrote:
> > We won't get there before 15.12 though, probably start of 2016.
> 
> Fine with me, but pray tell, are we going to see each and every point
> release from 15.08.04 onwards until then? ;)

Afaik it will just be part of the normal releases. I'm not sure if there will 
be a new point release if the Version is unchanged or no changes are made in 
the library but I guess so. I don't think It's necessary to make a special 
case out of gpgmepp for the release team. Is this a problem for you?

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [kf5-]gpgmepp

2015-11-24 Thread Andre Heinecke 
Hi,

On Tuesday 24 November 2015 08:57:26 Daniel Vrátil wrote:
> On Monday, November 23, 2015 1:09:25 PM CET René J.V. Bertin wrote:
> > Hi,
> > 
> > Quick question: gpgmepp is a dependency for kwallet, albeit an optional
> > one
> > (still not without importance I guess). Why is it part of "applications"
> > and not of "frameworks"?
> 
> It was split from kdepimlibs, and we are somewhat slow at pushing stuff from
> PIM to Frameworks. Additionally there's a hope that we could upstream it to
> GpgME - they are interested in maintaining the C++ bindings, so that would
> mean even less work for us - for that reason gpgmepp was not pushed to
> Frameworks.
> 
> Andre is the current maintainer of GpgME++, he might new what the current
> situation is.

Yes, Werner Koch the GpgME / GnuPG maintainer agreed that we should make 
gpgmepp the official C++ bindings for GpgME and maintain them as part of gpgme. 
(which is stated in the gpgme++ repo as the long term plan anyway).
The plan is to move the code in gpgme, get a release out that installs gpgme++ 
under a slightly different name or version and after that take out gpgme++ from 
the KDE releases / retire the repo.

We won't get there before 15.12 though, probably start of 2016.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: From kdelibs4 to KDE frameworks... how to make KDE more cross platform...

2012-02-13 Thread Andre Heinecke 
Hi,
Am Samstag, 11. Februar 2012, 20:00:01 schrieb Alexander Neundorf:
> Hi,
> While there are Windows and also OSX builds of KDE4, they are not really
> successful.
> I mean, it's not like everybody is running amarok today under Windows, or
> kate, or kdevelop, or digikam, kmail, etc.
> Some applications decided to go Qt-only for their Windows versions, e.g.
> Marble.
> 
> At FOSDEM I talked with Pau, and he said one thing that scares Windows users
> are (beside the huge downloads tdue to the many dependencies) that running
> a KDE application needs several helper processes running:
> 1. DBUS
> 2. kdeinit
> 3. klauncher
> 4. kded
> 5. kuiserver
> 
> So, can we cut down this number ?
> 
> Pau had the idea to write a fake libdbus for Windows, which internally
> doesn't talk to a dbus daemon, but which uses the Windows messaging
> service. On Linux DBUS is no problem. On Mac ? I don't know. Probably
> better than under Windows.
The perception that dbus is a problem on Windows is outdated. Dbus was a huge 
problem on windows but currently the situation is pretty good, we reall have 
no known issues with it. We can run multiple instances with different 
applications, it can do multiuser and it''s very stable and reliable for our 
platform.

I think dbus can and needs to stay.
> 
> kdeinit... can we make this optional ? It also sucks from the buildsystem
> POV. I remember we discussed this at the Desktop Summit... Would we have
> the same gains if we would simply build executables which export symbols,
> and if kdeinit is there, it runs those executables by dlopening them and
> running that symbol ? Would that have the same effect as loading KLMs ?
> Do I remember correctly that this is not (yet ?) supported on all
> distros/architectures ? Would that be a problem ? Or would this simply
> increase the pressure to add support for this everywhere ?
Signed i really would love to get rid of it.

> klauncher... this is quite central. I guess there is not much what could be
> done...
> 
> kded... for what things is this needed when running only a single
> application ?
Well kded handles some generic "kde" maintanence and watch stuff. For example 
it monitors if the windows registry entry for the timezone changes to notify 
kde applications. It also handles ssl certificate warnings and i think some 
more stuff.
For a single application you could probably better handle all this in process. 
But the better approach would probably be to just use those parts of KDE if 
you need them. (Amarok probably does not care mutch about timezones ;) )
> 
> kuiserver... if there are out-of-process kioslaves, I guess then there has
> to be an out-of-process kuiserver.
> 
> 
> Or, should we for Windows and OSX simply forget the KDE "desktop" and just
> concentrate on KDE applications ?
> E.g. ignore that we save resources by centralizing and sharing stuff like
> kioslaves among multiple applications ? Try to do more things in-process,
> maybe in threads ?
In my personal opinion as one of the KDE-Windows guys, yes. On my windows 
desktop i am running three different KDE's (Kontact / Amarok okular and the 
other stuff / Gpg4win ) Ok I'm a developer but if we want to have nice 
packages of okular and amarok as standalone "Apps" this will happen more and 
more. And just reducing stuff to "what the app needs" will really help there.
> It is cool to be able to replace the Windows shell... but does it make sense
> ? For applications it is IMO a feasible goal to be used by normal users
> under Windows, but replacing the Windows shell will stay only something for
> geeks I think.
Agreed.
> To make it short, now that we are going towards KDE frameworks, we should
> make sure that if there is something we can do to improve our situation on
> non KDE desktops, especially on non-UNIX, we should do that now or at least
> make sure that necessary changes can be done later on during the KDE
> frameworks compatiblity period without breaking compatiblity.
Yes framework has great possibilties for us from a point of packaging single 
applications. But speaking for the Windows developers, splitting up kdelibs 
and the general frameworks effort will make life easier for us without it 
beeing platform specific.
But I agree with you that we should try to get more involved with frameworks, 
we really don't have a strategy there or someone who we can point to as our 
"Frameworks guy" (Well when in doubt Patrick is always the guy for everything) 
;) .

There is definitly need for a discussion about "frameworks from a cross 
platform point of view"


Regards, and thanks for starting this discussion
Andre
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel