Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 10:45 a.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.
> 
> Luigi Toscano wrote:
> Afaik frameworkintegration is supposed to be an extension of the internal 
> Qt world and it has already been the case (I asked the same question few 
> Akademys ago). If you want to use QPA, you need to go down in the stack.
> 
> Martin Gräßlin wrote:
> yeah frameworkintegration is bound to use private API. So not really a 
> problem in this special case.
> 
> AFAIK some distros have adjusted the packaging to force a recompile for 
> new Qt releases.
> 
> Boudhayan Gupta wrote:
> Ah, that makes sense. Okay, I'm dropping this issue.
> 
> René J.V. Bertin wrote:
> Whew - Hacking is so much more fun if you can do it there where you're 
> not supposed to go, rather than to avoid exactly that ;)
> However, it might be possible to replace the direct call of the private 
> function by a call through a function pointer to `createPlatformTheme` 
> obtained through a dynamic resolver. Any idea if that is bound to fail 
> through a Qt function because it'd detect a request for a private API?
> 
> In any case, you (Boudhayan) are right that this modified framework might 
> end up being used also in *standalone* AppBundle builds rather than only in 
> builds using shared resources (in which applications are also built as app 
> bundles!). At least I hope it will, for the very reason I've been pushing the 
> patch. But I think you're wrong to assume that using private APIs is a 
> problem there. If anything it should be (much) less the case, because 
> standalone app bundles form a much more protected environment. They're not 
> meant to be upgraded internally, except maybe by some special mechanism 
> controlled by the developer(s) in charge. Updates to Qt without an 
> accompanying forced rebuild ("revbump" in MacPorts speak) to 
> frameworkintegration are much more likely to occur in a shared environment.
> 
> Boudhayan Gupta wrote:
> There's no reason to go through a dynamic function resolver if the rest 
> of FWI uses private APIs happily. Luigi says, "frameworkintegration is 
> supposed to be an extension of the internal Qt world" - in that case it makes 
> perfect sense to make use of private APIs to get your job done.
> 
> As for the AppBundles point - I'm thinking if it's possible Qt is 
> installed from e.g. the SDKs provided by qt.io and standalone AppBundles end 
> up depending on that. If not, using private APIs in standalone AppBundles 
> makes no difference - you won't upgrade Qt without upgrading the entire 
> AppBundle.

Dynamic resolution appears out of the question anyway, because the 
createPlatformTheme function is not a static member function. There's a `static 
QCocoaIntegration *instance()` (`_ZN17QCocoaIntegration8instanceEv`), though, 
which should return `QGuiApplicationPrivate::platform_integration`. Regardless 
of whether it's acceptable to use a private API here, there is still the 
question of handling a conflict/mismatch situation in a sensible way, one in 
which it's apparent immediately what went wrong.
But maybe there's an easier way to do that, simply by comparing a hard-coded Qt 
version with the runtime version.

Standalone app bundles are by definition not dependent on anything but system 
libraries, that's the whole idea behind them. When signed (e.g. because shipped 
through the App Store) you can also not modify them because if you do they 
won't launch. Of course you can build partially standalone app bundles, but I 
think that most devs will either aim for truly standalone products, or else 
product that share as much as possible (in which case Qt + KF5 frameworks could 
be built as a composite framework bundle).


- René J.V.

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 10:45 a.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.
> 
> Luigi Toscano wrote:
> Afaik frameworkintegration is supposed to be an extension of the internal 
> Qt world and it has already been the case (I asked the same question few 
> Akademys ago). If you want to use QPA, you need to go down in the stack.
> 
> Martin Gräßlin wrote:
> yeah frameworkintegration is bound to use private API. So not really a 
> problem in this special case.
> 
> AFAIK some distros have adjusted the packaging to force a recompile for 
> new Qt releases.
> 
> Boudhayan Gupta wrote:
> Ah, that makes sense. Okay, I'm dropping this issue.

Whew - Hacking is so much more fun if you can do it there where you're not 
supposed to go, rather than to avoid exactly that ;)
However, it might be possible to replace the direct call of the private 
function by a call through a function pointer to `createPlatformTheme` obtained 
through a dynamic resolver. Any idea if that is bound to fail through a Qt 
function because it'd detect a request for a private API?

In any case, you (Boudhayan) are right that this modified framework might end 
up being used also in *standalone* AppBundle builds rather than only in builds 
using shared resources (in which applications are also built as app bundles!). 
At least I hope it will, for the very reason I've been pushing the patch. But I 
think you're wrong to assume that using private APIs is a problem there. If 
anything it should be (much) less the case, because standalone app bundles form 
a much more protected environment. They're not meant to be upgraded internally, 
except maybe by some special mechanism controlled by the developer(s) in 
charge. Updates to Qt without an accompanying forced rebuild ("revbump" in 
MacPorts speak) to frameworkintegration are much more likely to occur in a 
shared environment.


- René J.V.


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Boudhayan Gupta]

> On Dec. 2, 2015, 3:15 p.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.
> 
> Luigi Toscano wrote:
> Afaik frameworkintegration is supposed to be an extension of the internal 
> Qt world and it has already been the case (I asked the same question few 
> Akademys ago). If you want to use QPA, you need to go down in the stack.
> 
> Martin Gräßlin wrote:
> yeah frameworkintegration is bound to use private API. So not really a 
> problem in this special case.
> 
> AFAIK some distros have adjusted the packaging to force a recompile for 
> new Qt releases.
> 
> Boudhayan Gupta wrote:
> Ah, that makes sense. Okay, I'm dropping this issue.
> 
> René J.V. Bertin wrote:
> Whew - Hacking is so much more fun if you can do it there where you're 
> not supposed to go, rather than to avoid exactly that ;)
> However, it might be possible to replace the direct call of the private 
> function by a call through a function pointer to `createPlatformTheme` 
> obtained through a dynamic resolver. Any idea if that is bound to fail 
> through a Qt function because it'd detect a request for a private API?
> 
> In any case, you (Boudhayan) are right that this modified framework might 
> end up being used also in *standalone* AppBundle builds rather than only in 
> builds using shared resources (in which applications are also built as app 
> bundles!). At least I hope it will, for the very reason I've been pushing the 
> patch. But I think you're wrong to assume that using private APIs is a 
> problem there. If anything it should be (much) less the case, because 
> standalone app bundles form a much more protected environment. They're not 
> meant to be upgraded internally, except maybe by some special mechanism 
> controlled by the developer(s) in charge. Updates to Qt without an 
> accompanying forced rebuild ("revbump" in MacPorts speak) to 
> frameworkintegration are much more likely to occur in a shared environment.

There's no reason to go through a dynamic function resolver if the rest of FWI 
uses private APIs happily. Luigi says, "frameworkintegration is supposed to be 
an extension of the internal Qt world" - in that case it makes perfect sense to 
make use of private APIs to get your job done.

As for the AppBundles point - I'm thinking if it's possible Qt is installed 
from e.g. the SDKs provided by qt.io and standalone AppBundles end up depending 
on that. If not, using private APIs in standalone AppBundles makes no 
difference - you won't upgrade Qt without upgrading the entire AppBundle.


- Boudhayan


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


On Dec. 2, 2015, 1:59 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 2, 2015, 1:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 1, 2015, 9:34 p.m., René J.V. Bertin wrote:
> > src/platformtheme/kdemactheme.mm, lines 53-87
> > 
> >
> > I thought it would be best to use a native dialog here to show a 
> > warning dialog, but it turns out there is already a native event filter in 
> > place that causes a conflict and a crash.
> > I'll have to replace this with a QMessageBox.

QMessageBox isn't possible either because we don't have a QApplication instance 
at this point.
It *should* be possible to use a native dialog as shown above, but then I'd 
need to find a way to deactivate the nativeEventFilter, and reactivate it after 
the dialog has been closed.


- René J.V.


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs rather than the ones from the 
> KdePlatformPlugin.
> 
> In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
> line with platform guidelines, and ensure that the autotests are not built as 
> app bundles.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 7c2129c 
>   src/kstyle/CMakeLists.txt bc26667 
>   src/kstyle/kstyle.mm PRE-CREATION 
>   src/platformtheme/CMakeLists.txt 23f590e 
>   src/platformtheme/kdemactheme.h PRE-CREATION 
>   src/platformtheme/kdemactheme.mm PRE-CREATION 
>   src/platformtheme/khintssettingsmac.h PRE-CREATION 
>   src/platformtheme/khintssettingsmac.mm PRE-CREATION 
>   src/platformtheme/main_mac.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126198/diff/
> 
> 
> 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 8:46 a.m., Martin Gräßlin wrote:
> > Overall I think this is now too much code duplication. With this appraoch 
> > you don't get bug fixes from the base code. I recommed to rather go for 
> > inheritance to have the actual code which can be shared still together.

Yes, I was aware of that; it was part of what I had in mind when I mentioned 
the maintenance burden being on KDE-Mac. 
I'll see what kind of difference inheritance can make here. I've been going 
over khintsettingsmac.mm because of a crash in there when testing without a 
kdeglobals file present. I'd left some look-and-feel remnants, and I think 
`KHintsSettings::readConfigValue()` will probably want to check if 
`mDefaultLnfConfig` isn't NULL before using it. 
Anyway, my impression is that even inheritance this class will be overriding 
(and thus duplicating) the brunt of the code; should I try it anyway?


> On Dec. 2, 2015, 8:46 a.m., Martin Gräßlin wrote:
> > src/platformtheme/CMakeLists.txt, lines 22-46
> > 
> >
> > please change this part to only contain differences. Otherwise it 
> > becomes difficult to maintain.
> > 
> > Like
> > 
> > set(platformtheme_SRCS ...)
> > if (APPLE)
> > set(platformtheme_SRCS ${platformtheme_SRCS} foo.mm)
> > endif()
> > 
> > 
> > Ideally I also don't want the generic part in the else branch. This 
> > should be more a feature based approach. What I don't want is that we 
> > generate a setup where it goes if(APPLE) else if (WINDOWS) else if 
> > (ANDROID)... You get what I mean ;-)

Erm, yes. Not sure why I didn't do this in the first place, maybe as a 
subconscious preparation for a possible need to fork and roll a related 
framework not intended to be Plasma-specific ;)


- René J.V.


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Martin Gräßlin]

> On Dec. 2, 2015, 8:38 a.m., Martin Gräßlin wrote:
> > Just wondering: if your main aim is to change default settings, why don't 
> > follow what linux distros do? That is ship some default configuration 
> > interface. For inspiration check e.g. kubuntu-default-settings.
> 
> René J.V. Bertin wrote:
> If I understand you correctly, you're suggesting I write a set of default 
> configuration values that could go into a look-and-feel package (?) I 
> stripped support for those in an effort to be PC because they're expected in 
> a folder called `plasma`.
> 
> It does look like this idea could remove the need for a Mac-specific 
> KHintsSettings class.
> 
> One thing I don't understand here: precedence between the package 
> configured in kdeglobals (`LookAndFeelPackage`) which is stored in 
> `mDefaultLnfConfig` and the hardcoded `defaultLookAndFeelPackage` package. 
> The latter is stored in `mLnfConfig` if different from the user-selected 
> package, but then `readConfigValue()` gives precedence to `mLnfConfig` if 
> it's set. That looks as if the effective roles are reversed.
> 
> René J.V. Bertin wrote:
> Too fast again :-/
> 
> I see that my suggestion below to check `mDefaultLnfConfig` before 
> accessing it is moot, but shouldn't `mLnfConfig` be initialised to 0 if 
> `looknfeel == defaultLookAndFeelPackage`?

> If I understand you correctly, you're suggesting I write a set of default 
> configuration values that could go into a look-and-feel package 

kconfig files. You just install a more global config file with your default 
values. Best check with some distros on how to do that. (I'm from the opposite 
department, telling distros when they broke it :-P )


- Martin


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 8:38 a.m., Martin Gräßlin wrote:
> > Just wondering: if your main aim is to change default settings, why don't 
> > follow what linux distros do? That is ship some default configuration 
> > interface. For inspiration check e.g. kubuntu-default-settings.
> 
> René J.V. Bertin wrote:
> If I understand you correctly, you're suggesting I write a set of default 
> configuration values that could go into a look-and-feel package (?) I 
> stripped support for those in an effort to be PC because they're expected in 
> a folder called `plasma`.
> 
> It does look like this idea could remove the need for a Mac-specific 
> KHintsSettings class.
> 
> One thing I don't understand here: precedence between the package 
> configured in kdeglobals (`LookAndFeelPackage`) which is stored in 
> `mDefaultLnfConfig` and the hardcoded `defaultLookAndFeelPackage` package. 
> The latter is stored in `mLnfConfig` if different from the user-selected 
> package, but then `readConfigValue()` gives precedence to `mLnfConfig` if 
> it's set. That looks as if the effective roles are reversed.

Too fast again :-/

I see that my suggestion below to check `mDefaultLnfConfig` before accessing it 
is moot, but shouldn't `mLnfConfig` be initialised to 0 if `looknfeel == 
defaultLookAndFeelPackage`?


- René J.V.


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs rather than the ones from the 
> KdePlatformPlugin.
> 
> In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
> line with platform 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 8:38 a.m., Martin Gräßlin wrote:
> > Just wondering: if your main aim is to change default settings, why don't 
> > follow what linux distros do? That is ship some default configuration 
> > interface. For inspiration check e.g. kubuntu-default-settings.

If I understand you correctly, you're suggesting I write a set of default 
configuration values that could go into a look-and-feel package (?) I stripped 
support for those in an effort to be PC because they're expected in a folder 
called `plasma`.

It does look like this idea could remove the need for a Mac-specific 
KHintsSettings class.

One thing I don't understand here: precedence between the package configured in 
kdeglobals (`LookAndFeelPackage`) which is stored in `mDefaultLnfConfig` and 
the hardcoded `defaultLookAndFeelPackage` package. The latter is stored in 
`mLnfConfig` if different from the user-selected package, but then 
`readConfigValue()` gives precedence to `mLnfConfig` if it's set. That looks as 
if the effective roles are reversed.


- René J.V.


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs rather than the ones from the 
> KdePlatformPlugin.
> 
> In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
> line with platform guidelines, and ensure that the autotests are not built as 
> app bundles.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 7c2129c 
>   src/kstyle/CMakeLists.txt bc26667 
>   src/kstyle/kstyle.mm PRE-CREATION 
>   src/platformtheme/CMakeLists.txt 23f590e 
>   

Review Request 126222: Fix rating widget flickering when selecting rating with mouse

[Xuetian Weng]

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

Review request for KDE Frameworks and David Faure.


Repository: kwidgetsaddons


Description
---

mousePressed and mouseMoved seems to contains some hack code. I don't know what 
these hacks are originally for, but it seems that they are not valid anymore 
and causes problem.

Currently, whenever a mouse move happens, the rating value cycles between 0, 1, 
2. This change drops all hack code.


Diffs
-

  src/kratingwidget.cpp d0d2903 

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


Testing
---

No flickering anymore when selecting rating.
Tested with following case, all cases are able to select all possible rating 
value.
setMaxRating(2) setHalfStepsEnabled(false)
setMaxRating(1) setHalfStepsEnabled(false)
setMaxRating(1) setHalfStepsEnabled(true)
setMaxRating(5) setHalfStepsEnabled(true)


Thanks,

Xuetian Weng

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

Re: Review Request 126222: Fix rating widget flickering when selecting rating with mouse

[Lamarque Souza]

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


That code was added to fix this bug 
https://bugs.kde.org/show_bug.cgi?id=171343#c6

- Lamarque Souza


On Dec. 2, 2015, 4:34 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126222/
> ---
> 
> (Updated Dec. 2, 2015, 4:34 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> mousePressed and mouseMoved seems to contains some hack code. I don't know 
> what these hacks are originally for, but it seems that they are not valid 
> anymore and causes problem.
> 
> Currently, whenever a mouse move happens, the rating value cycles between 0, 
> 1, 2. This change drops all hack code.
> 
> 
> Diffs
> -
> 
>   src/kratingwidget.cpp d0d2903 
> 
> Diff: https://git.reviewboard.kde.org/r/126222/diff/
> 
> 
> Testing
> ---
> 
> No flickering anymore when selecting rating.
> Tested with following case, all cases are able to select all possible rating 
> value.
> setMaxRating(2) setHalfStepsEnabled(false)
> setMaxRating(1) setHalfStepsEnabled(false)
> setMaxRating(1) setHalfStepsEnabled(true)
> setMaxRating(5) setHalfStepsEnabled(true)
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Updating techbase wiki page according to KF5 policies

[Alex Merry]

On 2015-12-02 08:09, David Faure wrote:

On Tuesday 01 December 2015 22:36:52 Alex Merry wrote:

On 2015-12-01 15:34, Martin Walch wrote:
> On Saturday, November 14, 2015 06:08:55 PM Alex Merry wrote:
>> On 2015-11-14 01:21, Martin Walch wrote:
>> > Alright, so I have created a stub at
>> >
>> > https://techbase.kde.org/Policies/Frameworks_Coding_Style
>> >
>> > ...
>> >
>> > Qt includes
>> > * For Qt #includes omit the module name and only use the class name.
>>
>> These are all still applicable.
>
> Does the same pattern apply to Frameworks includes?
> For example:
>
> KFileItem instead of KIOCore/KFileItem
> and
> KIO/HostInfo instead of KIOCore/KIO/HostInfo
>
> and of course not something like kfileitem.h or kio/hostinfo.h

Yes, although good luck trying to explain that, given the 
inconsistency

between  and 


This is not inconsistent at all. The first one is about the class 
KIO::HostInfo,

the second one is about the class KFileItem.
The header file is consistent with the class that it defines.


True, that's a reasonable way to explain it. I hadn't though of that 
(that's what happens when I write emails after I should be in bed).


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

Re: Review Request 124905: Win: Hide console window for binaries in LIBEXEC

[Kevin Funk]

> On Aug. 27, 2015, 9:57 p.m., Patrick Spendrin wrote:
> > Wait, Wait, Wait.
> > 1) The difference between console apps and GUI apps is that console apps 
> > actually have stdin, stdout and stderr streams. So using or not using a 
> > console app actually depends on if you need to have these streams!
> > 2) In kde4 (as in standard cmake) the default when you use add_executable 
> > is a console application, and if you add WIN32 you'll get a GUI 
> > application. In kf5 it was decided that it makes much more sense to mark 
> > non-gui applications explicitly, similar to how it is done in qmake (CONFIG 
> > += CONSOLE); this is done by the set_target_properties or the ecm macro.
> > About your problem of console windows: there is a different solution for 
> > that (it depends on the way the executables are run in QProcess), but I 
> > would need to look into the KDE4 code which starts kdeinit4.exe. kdeinit4 
> > *is* a console app.

@Patrick: So what's the proper solution? 

I'd really like to get this fixed. It's a big show-stopper on Windows.


- Kevin


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


On Aug. 27, 2015, 7:31 a.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124905/
> ---
> 
> (Updated Aug. 27, 2015, 7:31 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn 
> Rempt.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Win: Hide console window for binaries in LIBEXEC
> 
> 
> Diffs
> -
> 
>   src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc 
>   src/ioslaves/http/kcookiejar/CMakeLists.txt 
> 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 
>   src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 
>   src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e 
>   src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc 
> 
> Diff: https://git.reviewboard.kde.org/r/124905/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

[René J . V . Bertin]

> On Dec. 2, 2015, 8:51 a.m., David Faure wrote:
> > Please kind in mind that kded must be able to pop up dialogs, though.
> > (cookie dialog, SSL cert messagebox + dialog, etc. etc.).
> > 
> > If making it an "agent" doesn't prevent it from showing GUI elements now 
> > and then, then no problem.

With the earlier approach of setting `LSUIElement` that is guaranteed to be the 
case.

I just checked; launching Qt's Assistant with 
`QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM=1` all that changes is that 
the application remains in the background; it can be brought into the 
foreground, and it retains its presence in the Dock and app switcher.

IOW, I'm not really sure I understand why kded5 doesn't retain that presence 
with `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` set. It's possible that 
all the env. variable does is postpone the actions that lead to that presence. 
If that's true than we'd have to come back to the more appropriate previous 
revision of this patch.

OTOH: the only dialogs I have seen under KDE4 that are related to kded (unknown 
cert) were posted when kded4 was *not* running. Ditto for cookie related 
things. Under what circumstances is kded supposed to present a GUI?


- René J.V.


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


On Nov. 25, 2015, 7:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126170/
> ---
> 
> (Updated Nov. 25, 2015, 7:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kded
> 
> 
> Description
> ---
> 
> There should be no reason to build `kded5` as an app bundle on OS X, and with 
> recent feedback in mind I postulated that marking it "nongui" 
> (`ecm_mark_nongui_application`) would be acceptable on other platforms too.
> 
> Additionally, `kded5` doesn't have any more reason to appear in the Dock or 
> app switcher, on OS X, so I have added the code to make it an agent.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 4b9a5ff 
>   src/CMakeLists.txt 5e95df8 
>   src/kded.cpp 6929d7d 
> 
> Diff: https://git.reviewboard.kde.org/r/126170/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and FWs 5.16.0 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

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

(Updated Dec. 2, 2015, 10:38 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
Zimmerman.


Changes
---

This revision is a probably heavy-handed attempt at implementing Martin's 
suggestion to re-use as much code as possible using inheritance. There's less 
code that can be reused than I'd have liked, and I have a strong impression 
that my implementation actually does quite a few things twice. Meaning once in 
the parent class and once in my own class, despite probably overly liberal use 
of `virtual` keywords. Then again it seems hard to avoid this given that the 
parent KdePlatformTheme class has KHintsSettings and KFontsSettings instances, 
and my KdeMacTheme has KHintsSettingsMac and KFontsSettingsMac instances.
Clear this isn't yet my strongest subject yet, so I hope I haven't made a 
complete mess of this :-/

I've made the private members protected, in order to be able to inherit them, 
and I've introduce a `KdePlatformTheme::fontType()` method so that it becomes 
possible to have a central `QPlatformTheme::Font -> 
KFontSettingsData::FontType` translation, and then do a platform-specific 
lookup in the dedicated `m_fontsData` array. Maybe that `fontType()` method 
should be in `KFontDataSettings`?

New in this revision is also `KFontDataSettingsMac`, which exists in order to 
obtain the default fonts from the system (though the sizes are hardcoded, 
currently). The current algorithm isn't very satisfactory, as it turns out to 
be a more or less known Qt issue that it doesn't provide this information 
reliably on OS X. Surprise, surprise :) I'll have to look if this information 
can be obtained through Cocoa.

The reason to do this dynamically (and leave the default colour palette to 
whatever Qt sets it to, for now) instead of using a predefined config file is 
that this information can change between OS versions. OS X 10.11 introduced a 
new system font (or 2), and the default colours aren't set in stone either (and 
users can chose the `Graphite` or default "Aqua" theme, as well as the more 
recent "Dark mode").


Repository: frameworkintegration


Description
---

The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to Qt5; 
all that is required is to include the `qgenericunixservices` and 
`qgenericunixthemes` components in the build, and to append `"kde"` to the list 
returned by `QCocoaIntegration::themeNames()` for instance under the condition 
that `KDE_SESSION_VERSION` is set to a suitable value in the environment.

This will allow KF5 and Qt5 applications to use the theme selected through KDE 
if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, which 
seems like a sufficiently specific set of conditions that is easy to avoid by 
users who prefer to use the Mac native theme.

While requestion the KDE theme is also possible through `-style kde` or `env 
QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be the 
only way to get the full theme, including the font and colour selection. In my 
opinion it is above all the font customisation which is a very welcome feature 
for Qt/Mac; by default Qt applications use the default system font (Lucida 
Grande 13pt or even 14pt) throughout. This is a good UI font, but not at that 
size (and most "native" OS X applications indeed use a range of smaller sizes, 
depending on role.

It does have introduce a number of regressions, which the current patch aims to 
address. The most visible and problematic of these regressions is the loss of 
the Mac-style menu bar and thus of all menu items (actions).

The fix is straightforward : on OS X (and similarly affected platforms?), an 
instance of the native Cocoa platform theme is created through the private API, 
and used as a fallback rather than immediately falling back to the default 
implementations from `QPlatformTheme`. In addition, methods missing from (not 
overridden by) `KdePlatformTheme` are provided on OS X and call the 
corresponding methods from the native theme. It is this change which restores 
the menubar and even the Dock menu functionality.
One minor regression remains but should be easy to fix (elsewhere?): the 
Preferences menu loses its keyboard shortcut (Command-,).

Given the fallback nature of the native platform instance I have preferred to 
print a warning rather than using something like `qFatal`, above all because 
the message printed by qFatal tends to get lost on OS X. I can replace my use 
of `qWarning` with a dialog giving the choice between continuing or exiting the 
application - code that would be called in the menu methods because only there 
is it certain that the application actually needs a menubar.

In line with experience and feedback from the 

Re: Purpose as a KDE Framework

[Mark Gaiser]

On Tue, Dec 1, 2015 at 3:01 PM, Aleix Pol  wrote:

> Hi,
> I've been working on Purpose since some months now, with the intention
> of becoming a framework some day. Some information about it can be
> read here:
>
> https://projects.kde.org/projects/playground/libs/purpose/repository/revisions/master/entry/README.md
>
> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
> plus the plugins. Plugins raise the tier to 3 because of KIO which is
> used by some plugins.
>
> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
> KDevelop for patch sharing. I'd like to see it used in other cases
> than sharing as well as in other applications, but here's where we are
> at the moment. I think it's something to build upon.
>
> Any thoughts?
>
> Aleix
>

Hi Aleix,

I'm trying to understand what Purpose is doing exactly.
I've read the readme file, but i still can't quite figure out what it's
doing or where i might be able to use it.

Could you give a short summary with a clear example where to use it? That
would help me :)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

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

(Updated Dec. 2, 2015, 10:42 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
Zimmerman.


Changes
---

apologies, files were missing from the previous patch.


Repository: frameworkintegration


Description
---

The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to Qt5; 
all that is required is to include the `qgenericunixservices` and 
`qgenericunixthemes` components in the build, and to append `"kde"` to the list 
returned by `QCocoaIntegration::themeNames()` for instance under the condition 
that `KDE_SESSION_VERSION` is set to a suitable value in the environment.

This will allow KF5 and Qt5 applications to use the theme selected through KDE 
if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, which 
seems like a sufficiently specific set of conditions that is easy to avoid by 
users who prefer to use the Mac native theme.

While requestion the KDE theme is also possible through `-style kde` or `env 
QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be the 
only way to get the full theme, including the font and colour selection. In my 
opinion it is above all the font customisation which is a very welcome feature 
for Qt/Mac; by default Qt applications use the default system font (Lucida 
Grande 13pt or even 14pt) throughout. This is a good UI font, but not at that 
size (and most "native" OS X applications indeed use a range of smaller sizes, 
depending on role.

It does have introduce a number of regressions, which the current patch aims to 
address. The most visible and problematic of these regressions is the loss of 
the Mac-style menu bar and thus of all menu items (actions).

The fix is straightforward : on OS X (and similarly affected platforms?), an 
instance of the native Cocoa platform theme is created through the private API, 
and used as a fallback rather than immediately falling back to the default 
implementations from `QPlatformTheme`. In addition, methods missing from (not 
overridden by) `KdePlatformTheme` are provided on OS X and call the 
corresponding methods from the native theme. It is this change which restores 
the menubar and even the Dock menu functionality.
One minor regression remains but should be easy to fix (elsewhere?): the 
Preferences menu loses its keyboard shortcut (Command-,).

Given the fallback nature of the native platform instance I have preferred to 
print a warning rather than using something like `qFatal`, above all because 
the message printed by qFatal tends to get lost on OS X. I can replace my use 
of `qWarning` with a dialog giving the choice between continuing or exiting the 
application - code that would be called in the menu methods because only there 
is it certain that the application actually needs a menubar.

In line with experience and feedback from the KDE(4)-Mac community I have 
decided to force the use of native dialogs rather than the ones from the 
KdePlatformPlugin.

In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
line with platform guidelines, and ensure that the autotests are not built as 
app bundles.


Diffs (updated)
-

  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/CMakeLists.txt 23f590e 
  src/kstyle/kstyle.mm PRE-CREATION 
  src/kstyle/CMakeLists.txt bc26667 
  autotests/CMakeLists.txt 7c2129c 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettingsmac.h PRE-CREATION 
  src/platformtheme/khintssettingsmac.mm PRE-CREATION 
  src/platformtheme/main_mac.cpp PRE-CREATION 

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


Testing
---

On Mac OS X with Qt 5.5.1, KF5 frameworks 5.16.0 and QtCurve git/head.

I have not verified to what extent my use of a private `QGuiApplication` API 
links builds to a specific Qt version (I consider that nothing shocking and a 
minor price to pay).
>>> Do I need to add some glue to the CMake file so that it will warn if the 
>>> private headerfiles are not available? Apparently no changes were required 
>>> to find them.


File Attachments


purely native OS X theme
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/11/30/650d0da7-52b3-40d1-a1f9-cb610494cf77__Screen_Shot_2015-11-30_at_15.42.31.png
native theme but with `-style kde`
  

Re: Review Request 126222: Fix rating widget flickering when selecting rating with mouse

[Xuetian Weng]

> On Dec. 2, 2015, 4:45 p.m., Lamarque Souza wrote:
> > That code was added to fix this bug 
> > https://bugs.kde.org/show_bug.cgi?id=171343#c6

Emm.. interesting feature. But code inside mouseMoveEvent looks fishy, and this 
feature shouldn't be used when halfStepsEnabled is true. I'll try to keep this 
feature then.


- Xuetian


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


On Dec. 2, 2015, 4:34 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126222/
> ---
> 
> (Updated Dec. 2, 2015, 4:34 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> mousePressed and mouseMoved seems to contains some hack code. I don't know 
> what these hacks are originally for, but it seems that they are not valid 
> anymore and causes problem.
> 
> Currently, whenever a mouse move happens, the rating value cycles between 0, 
> 1, 2. This change drops all hack code.
> 
> 
> Diffs
> -
> 
>   src/kratingwidget.cpp d0d2903 
> 
> Diff: https://git.reviewboard.kde.org/r/126222/diff/
> 
> 
> Testing
> ---
> 
> No flickering anymore when selecting rating.
> Tested with following case, all cases are able to select all possible rating 
> value.
> setMaxRating(2) setHalfStepsEnabled(false)
> setMaxRating(1) setHalfStepsEnabled(false)
> setMaxRating(1) setHalfStepsEnabled(true)
> setMaxRating(5) setHalfStepsEnabled(true)
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

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

Re: Review Request 126189: Support https and other URL schemas for "home page" property in KAboutData constructor.

[Michael Pyne]

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

(Updated Dec. 3, 2015, 12:38 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 9e5f731c8f63d239172f76d826973042e7920dee by Michael Pyne 
to branch master.


Bugs: 355508
https://bugs.kde.org/show_bug.cgi?id=355508


Repository: kcoreaddons


Description
---

This commit permits URLs such as "https://www.foo.org; (i.e. with non-http 
schemas), which bug 355508 points out is something we don't currently support, 
and expands the test suite to ensure http and https URLs give the same behavior 
when deriving desktop file names and organization domains.

The existing code seems to operate the stripping the first URL host component 
(e.g. www.foo.org -> foo.org) for the purposes of generating an organization 
domain or desktop file name. I'm not sure if that was intentional or not, but I 
found it easier to just limit to two components instead (e.g. 
www.product.foo.org -> foo.org). Everything else should be pretty 
straightforward for review I think... much of the code change is simply because 
I tried to fix by making the current code scheme-independent instead of just 
adding a '|| scheme == "https"'.

I also modified the API docs to reflect the change. I will add the appropriate 
@since based on when I get a Ship It! ;)


Diffs
-

  src/lib/kaboutdata.h e9fc56b 
  src/lib/kaboutdata.cpp de19e6f 
  autotests/kaboutdatatest.cpp 96b3a13 

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


Testing
---

All tests pass in kaboutdatatest, including the extra test cases added to test 
https:// URLs specifically.

I also had hacked in some qDebug()s and ran with several KDE apps, all of which 
generated reasonable organization domains.


Thanks,

Michael Pyne

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

Re: Review Request 126222: Fix rating widget flickering when selecting rating with mouse

[Xuetian Weng]

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

(Updated Dec. 2, 2015, 11:37 p.m.)


Review request for KDE Frameworks and David Faure.


Repository: kwidgetsaddons


Description (updated)
---

Refactor the rating calculation:
1. Disable feature introduced in bug 171343 when halfSteps is enabled.
2. Merge the two pieces of code, and try to make it clearer and simpler.
3. make hover 0 star also show visual effect.


Diffs (updated)
-

  src/kratingwidget.cpp d0d2903 

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


Testing (updated)
---

Current rating is 0, hover on the 1st star, 1 star lights up, click on 1st 
star, rating becomes 2.

Current rating is 2. hover on the 1st star, half star lights up, click on 1st 
star, rating becomes 1.

Current rating is 1/2. move mouse to the left most edge, star's color becomes 
lighter. Click and rating becomes 0.


Thanks,

Xuetian Weng

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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Boudhayan Gupta]

> On Dec. 2, 2015, 3:15 p.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.
> 
> Luigi Toscano wrote:
> Afaik frameworkintegration is supposed to be an extension of the internal 
> Qt world and it has already been the case (I asked the same question few 
> Akademys ago). If you want to use QPA, you need to go down in the stack.
> 
> Martin Gräßlin wrote:
> yeah frameworkintegration is bound to use private API. So not really a 
> problem in this special case.
> 
> AFAIK some distros have adjusted the packaging to force a recompile for 
> new Qt releases.

Ah, that makes sense. Okay, I'm dropping this issue.


- Boudhayan


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


On Dec. 2, 2015, 1:59 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 2, 2015, 1:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Boudhayan Gupta]

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



src/platformtheme/kdemactheme.mm (line 39)


This makes me very nervous.

Using private APIs is almost always a guarantee the application won't 
preserve binary compatibility even across point releases (eg Qt 5.5.0 - 5.5.1), 
let alone across major releases.

What makes it even more dangerous is that this file won't be built only on 
MacPorts/Fink but also by people making normal AppBundle releases - where you 
have no control over what versions of dependencies are being used.

Please try to find a public API alternative, even if it ends up being a 
giant hack. I once found a very elegant private API solution to making a 
QQuickWidget emit a release event on the mouse cursor, but just because of the 
whole binary compat problem (some Linux distros don't even ship apps depending 
on private headers) I had to create a dummy item inside the QtQuick code and 
interact with it to get the cursor released. Giant hack, but at least no 
private API usage.

Private API is **private** for a reason.


- Boudhayan Gupta


On Dec. 2, 2015, 1:59 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 2, 2015, 1:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs rather than the ones from the 
> KdePlatformPlugin.
> 
> In addition I set the fallback value for `ShowIconsOnPushButtons` to false in 
> line with platform guidelines, and ensure that the autotests are not built as 
> app bundles.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 7c2129c 
>   src/kstyle/CMakeLists.txt bc26667 
>   src/kstyle/kstyle.mm PRE-CREATION 
>   

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Luigi Toscano]

> On Dic. 2, 2015, 10:45 a.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.

Afaik frameworkintegration is supposed to be an extension of the internal Qt 
world and it has already been the case (I asked the same question few Akademys 
ago). If you want to use QPA, you need to go down in the stack.


- Luigi


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


On Dic. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dic. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called in the menu methods because only 
> there is it certain that the application actually needs a menubar.
> 
> In line with experience and feedback from the KDE(4)-Mac community I have 
> decided to force the use of native dialogs 

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[Martin Gräßlin]

> On Dec. 2, 2015, 10:45 a.m., Boudhayan Gupta wrote:
> > src/platformtheme/kdemactheme.mm, line 39
> > 
> >
> > This makes me very nervous.
> > 
> > Using private APIs is almost always a guarantee the application won't 
> > preserve binary compatibility even across point releases (eg Qt 5.5.0 - 
> > 5.5.1), let alone across major releases.
> > 
> > What makes it even more dangerous is that this file won't be built only 
> > on MacPorts/Fink but also by people making normal AppBundle releases - 
> > where you have no control over what versions of dependencies are being used.
> > 
> > Please try to find a public API alternative, even if it ends up being a 
> > giant hack. I once found a very elegant private API solution to making a 
> > QQuickWidget emit a release event on the mouse cursor, but just because of 
> > the whole binary compat problem (some Linux distros don't even ship apps 
> > depending on private headers) I had to create a dummy item inside the 
> > QtQuick code and interact with it to get the cursor released. Giant hack, 
> > but at least no private API usage.
> > 
> > Private API is **private** for a reason.
> 
> Luigi Toscano wrote:
> Afaik frameworkintegration is supposed to be an extension of the internal 
> Qt world and it has already been the case (I asked the same question few 
> Akademys ago). If you want to use QPA, you need to go down in the stack.

yeah frameworkintegration is bound to use private API. So not really a problem 
in this special case.

AFAIK some distros have adjusted the packaging to force a recompile for new Qt 
releases.


- Martin


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


On Dec. 1, 2015, 9:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 1, 2015, 9:29 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> Preferences menu loses its keyboard shortcut (Command-,).
> 
> Given the fallback nature of the native platform instance I have preferred to 
> print a warning rather than using something like `qFatal`, above all because 
> the message printed by qFatal tends to get lost on OS X. I can replace my use 
> of `qWarning` with a dialog giving the choice between continuing or exiting 
> the application - code that would be called 

Re: Updating techbase wiki page according to KF5 policies

[David Faure]

On Tuesday 01 December 2015 22:36:52 Alex Merry wrote:
> On 2015-12-01 15:34, Martin Walch wrote:
> > On Saturday, November 14, 2015 06:08:55 PM Alex Merry wrote:
> >> On 2015-11-14 01:21, Martin Walch wrote:
> >> > Alright, so I have created a stub at
> >> >
> >> > https://techbase.kde.org/Policies/Frameworks_Coding_Style
> >> >
> >> > ...
> >> >
> >> > Qt includes
> >> > * For Qt #includes omit the module name and only use the class name.
> >> 
> >> These are all still applicable.
> > 
> > Does the same pattern apply to Frameworks includes?
> > For example:
> > 
> > KFileItem instead of KIOCore/KFileItem
> > and
> > KIO/HostInfo instead of KIOCore/KIO/HostInfo
> > 
> > and of course not something like kfileitem.h or kio/hostinfo.h
> 
> Yes, although good luck trying to explain that, given the inconsistency 
> between  and 

This is not inconsistent at all. The first one is about the class KIO::HostInfo,
the second one is about the class KFileItem.
The header file is consistent with the class that it defines.

>  is only 
> possible by fluke, really, as a side effect of where we install the 
> version headers.

Well it's the same as , i.e. an include that starts
with the module name. But for the same reasons as in Qt, this is not 
recommended.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

[René J . V . Bertin]

> On Dec. 2, 2015, 8:38 a.m., Martin Gräßlin wrote:
> > Just wondering: if your main aim is to change default settings, why don't 
> > follow what linux distros do? That is ship some default configuration 
> > interface. For inspiration check e.g. kubuntu-default-settings.
> 
> René J.V. Bertin wrote:
> If I understand you correctly, you're suggesting I write a set of default 
> configuration values that could go into a look-and-feel package (?) I 
> stripped support for those in an effort to be PC because they're expected in 
> a folder called `plasma`.
> 
> It does look like this idea could remove the need for a Mac-specific 
> KHintsSettings class.
> 
> One thing I don't understand here: precedence between the package 
> configured in kdeglobals (`LookAndFeelPackage`) which is stored in 
> `mDefaultLnfConfig` and the hardcoded `defaultLookAndFeelPackage` package. 
> The latter is stored in `mLnfConfig` if different from the user-selected 
> package, but then `readConfigValue()` gives precedence to `mLnfConfig` if 
> it's set. That looks as if the effective roles are reversed.
> 
> René J.V. Bertin wrote:
> Too fast again :-/
> 
> I see that my suggestion below to check `mDefaultLnfConfig` before 
> accessing it is moot, but shouldn't `mLnfConfig` be initialised to 0 if 
> `looknfeel == defaultLookAndFeelPackage`?
> 
> Martin Gräßlin wrote:
> > If I understand you correctly, you're suggesting I write a set of 
> default configuration values that could go into a look-and-feel package 
> 
> kconfig files. You just install a more global config file with your 
> default values. Best check with some distros on how to do that. (I'm from the 
> opposite department, telling distros when they broke it :-P )

Ah, ok. For now I've been focussing on your other suggestion, using inheritance.
But in a sense I'd prefer using default values determined at runtime for the 
"perfect" native look; either using Qt calls as I've done in my latest attempt, 
or using calls into whatever native API is available for that purpose. That's 
why I've been using ObjC++ after all :)


- René J.V.


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


On Dec. 2, 2015, 10:38 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126198/
> ---
> 
> (Updated Dec. 2, 2015, 10:38 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Valorie 
> Zimmerman.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to 
> Qt5; all that is required is to include the `qgenericunixservices` and 
> `qgenericunixthemes` components in the build, and to append `"kde"` to the 
> list returned by `QCocoaIntegration::themeNames()` for instance under the 
> condition that `KDE_SESSION_VERSION` is set to a suitable value in the 
> environment.
> 
> This will allow KF5 and Qt5 applications to use the theme selected through 
> KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, 
> which seems like a sufficiently specific set of conditions that is easy to 
> avoid by users who prefer to use the Mac native theme.
> 
> While requestion the KDE theme is also possible through `-style kde` or `env 
> QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be 
> the only way to get the full theme, including the font and colour selection. 
> In my opinion it is above all the font customisation which is a very welcome 
> feature for Qt/Mac; by default Qt applications use the default system font 
> (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not 
> at that size (and most "native" OS X applications indeed use a range of 
> smaller sizes, depending on role.
> 
> It does have introduce a number of regressions, which the current patch aims 
> to address. The most visible and problematic of these regressions is the loss 
> of the Mac-style menu bar and thus of all menu items (actions).
> 
> The fix is straightforward : on OS X (and similarly affected platforms?), an 
> instance of the native Cocoa platform theme is created through the private 
> API, and used as a fallback rather than immediately falling back to the 
> default implementations from `QPlatformTheme`. In addition, methods missing 
> from (not overridden by) `KdePlatformTheme` are provided on OS X and call the 
> corresponding methods from the native theme. It is this change which restores 
> the menubar and even the Dock menu functionality.
> One minor regression remains but should be easy to fix (elsewhere?): the 
> 

Review Request 126226: kdetemplate_add_app_templates installs previews

[Sebastian Kügler]

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

Review request for KDE Frameworks and Marco Martin.


Repository: extra-cmake-modules


Description
---

kapptemplate can't deal with templats without previews, so make sure we install 
the preview image.

Without this patch, the installed templates show up broken in kapptemplate. 
With it, they work as expected.

I'm assuming here that the preview has the baseName + .png, otherwise we'd have 
to read Icon field from the .kdevtemplate file, but that seems way too much 
hassle. The error message resulting from a wrong file name will show the 
expected filename, so it doesn't exactly hide the error.


Diffs
-

  kde-modules/KDETemplateMacro.cmake 796c3f1 

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


Testing
---

Installed templates/ from plasma-framework, this patch makes them work in 
kapptemplate.


Thanks,

Sebastian Kügler

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