from:"René J . V . Bertin"

On Sunday December 06 2015 14:51:40 David Faure wrote:

> Here is an easy way to test this: do the same change for kiod in kio (it's 
> like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.

Regardless of what I try (even with the non-agent'ised, non-nongui version), I 
only get this:

CD kio/build/tests listjobtest.app/Contents/MacOS/listjobtest 
"ftp://t...@upload.kde.org;
Starting listJob for the URL: QUrl("ftp://t...@upload.kde.org;)
Runtime: 291 milliseconds.
Press Enter to quit.

kiod5 is started, but doesn't post a dialog. Doesn't raise/return an error 
either.
If there a debug category to activate in order to get more output I haven't 
found it.

R.
___
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


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


So with the current implementation that uses inheritance, there are 2 classes 
that have a `delayedDBusConnects` method which uses 
`QDBusConnection::sessionBus().connect()` to register things on the DBus. Both 
invoke that method explicitly from their ctor, and in general, with the 
inheritance/overriding going on I think I might be over-initialising certain 
things. I have modified the 2 `loadSettings` methods so that they only create 
new instances when `m_fontsData==0` (initialised in the respective ctors), so 
that should limit the redundancy.

Still I wonder if this isn't going to lead to DBus name conflicts (if the DBus 
connect method doesn't disconnect/reconnect)?

I also wonder if the crash-on-exit I just discovered in `kdebugdialog5` (but 
not in what few example KF5 applications I have at the moment) is related:

```
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.qt-project.QtDBus   0x00010355f9b6 QHashNode::~QHashNode() + 166 (qgenericatomic.h:90)
1   org.qt-project.QtCore   0x0001045b89b9 
QHashData::free_helper(void (*)(QHashData::Node*)) + 73 (qhash.cpp:405)
2   org.qt-project.QtDBus   0x0001035531a8 
QDBusConnectionPrivate::~QDBusConnectionPrivate() + 712 (qhash.h:342)
3   org.qt-project.QtDBus   0x0001035535ce 
QDBusConnectionPrivate::~QDBusConnectionPrivate() + 14 
(qdbusintegrator.cpp:1035)
4   org.qt-project.QtDBus   0x00010354baf8 (anonymous 
namespace)::Q_QGS__q_sessionBus::innerFunction()::Cleanup::~Cleanup() + 152 
(qdbusconnection.cpp:1079)
5   libsystem_c.dylib   0x7fff89e5d7a1 __cxa_finalize + 177
```

When I add some trace statements at relevant locations, I see this on the 
calling terminal:
```
> kdebugdialog5
QCoreApplication::arguments: Please instantiate the QApplication object first
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
KdePlatformTheme::KdePlatformTheme() 0x7fe420e0e2b0
KdePlatformTheme::loadSettings() 0x7fe420e0e2b0
KFontSettingsData::KFontSettingsData() KFontSettingsData(0x7fe420e15bc0)
KHintsSettings::KHintsSettings() KHintsSettings(0x7fe420e15690)
KdeMacTheme::KdeMacTheme() 0x7fe420e0e2b0
KdeMacTheme::loadSettings() 0x7fe420e0e2b0
KFontSettingsData::KFontSettingsData() KFontSettingsData(0x7fe420c94dc0)
KFontSettingsDataMac::KFontSettingsDataMac() 
KFontSettingsDataMac(0x7fe420c94dc0)
KHintsSettings::KHintsSettings() KHintsSettings(0x7fe420e2f110)
KHintsSettingsMac::KHintsSettingsMac() KHintsSettingsMac(0x7fe420e2f110)
KdeMacTheme::createPlatformSystemTrayIcon() 0x7fe420e0e2b0
KFontSettingsData::delayedDBusConnects() KFontSettingsData(0x7fe420e15bc0)
KFontSettingsData::delayedDBusConnects() KFontSettingsDataMac(0x7fe420c94dc0)
KFontSettingsDataMac::delayedDBusConnects() KFontSettingsDataMac(0x7fe420c94dc0)
KdeMacTheme::~KdeMacTheme() 0x7fe420e0e2b0
KdePlatformTheme::~KdePlatformTheme() 0x7fe420e0e2b0
KFontSettingsData::~KFontSettingsData() KFontSettingsData(0x7fe420e15bc0)
KHintsSettings::~KHintsSettings() KHintsSettings(0x7fe420e15690)
Segmentation fault
Exit 139
```

the non-crashes don't call `KdeMacTheme::createPlatformSystemTrayIcon()`, so 
even if `kdebugdialog5` doesn't actually put up a systray icon/menu there must 
be some relation between that call and the crash.
I'd hope this is just a bug in `kdebugdialog5`, but it doesn't express itself 
when I don't use the KdePlatformTheme (`KdeMacTheme`)...

- René J.V. Bertin


On Dec. 4, 2015, 7:01 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. 4, 2015, 7:01 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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme



> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.h, lines 41-54
> > 
> >
> > why did you add the virtual? The methods are marked as Q_DECL_OVERRIDE 
> > which implies they are virtual
> 
> René J.V. Bertin wrote:
> Q_DECL_OVERRIDE indeed appears to resolve to `override` even with clang; 
> what about when it doesn't? Not supposed to happen and thus not to worry 
> about any issues that might cause?
> 
> For now I've left the virtual keywords on definitions that lack 
> Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead?
> 
> Martin Gräßlin wrote:
> > what about when it doesn't?
> 
> It doesn't matter. override triggers a compile error if the base method 
> is not defined as virtual. By reimplementing in a subclass without virtual 
> you're not going to turn it non-virtual. We only used to add virtual in 
> derived classed to increase readability, to indicate that it overrides a base 
> method. Now we have language support for that.
> 
> > For now I've left the virtual keywords on definitions that lack 
> Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead?
> 
> Don't change if it's not needed. If the method is virtual in the base 
> class then don't add virtual.
> 
> René J.V. Bertin wrote:
> Ok. Even the dtors? I thought it was good practice to make those virtual 
> almost always?
> 
> Martin Gräßlin wrote:
> with dtors it makes in-deed sense to mark them as virtual. At least I 
> follow that practice to have them always virtual even if I use override for 
> everything else. But of course such a change should be a dedicated 
> coding-style commit not touching anything else.

As it stands, only KFontSettings has a non-virtual dtor.


- René J.V.


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


On Dec. 4, 2015, 7:01 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. 4, 2015, 7:01 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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme


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

(Updated Dec. 7, 2015, 5:43 p.m.)


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


Changes
---

revision with some (temporary!) debug trace outputs to go with 
https://git.reviewboard.kde.org/r/126198/#review89105


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/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/CMakeLists.txt 23f590e 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettings.cpp 8adf6c5 
  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 126241: [OS X] adapting KStyle (WIP)



> On Dec. 7, 2015, 4:29 p.m., Hugo Pereira Da Costa wrote:
> > I honestly have some doubt on the approach (but no counter proposal either)
> > Basically the file kstyle.mm is a *copy* of the .cpp file, with a couple of 
> > lines changed. (which I had to track down by 
> > - downloading the patch
> > - making an explicit diff of the two files
> > (which makes reviewing quite difficult/useless)
> > 
> > The mm file has the name, but different extension, and is compiled only for 
> > OSX
> > That means that any future fix (by me, or others) applied to one on a 
> > different platform will either
> > - not be ported to the other platform
> > - be ported blindly without testing (I don't even know how to compile mm on 
> > my linux box)
> > Is this really what we want to do ? 
> > 
> > Of course one could also add a common parent class to both the linux and 
> > osx implementation, that makes 99% of the job (some KStyleBase class), 
> > but then, wont that break binary compatibility badly for all widget styles 
> > that inherits these ? (oxygen, breeze)
> > 
> > Finally, the changes applied here only work for kstyle derived styles 
> > (oxygen, breeze), and not the QStyle based one. (QtCurve ?)
> > 
> > ... not convinced. (but not strong objection either)

I agree with most points, and am myself not sure where I (we) could go with a 
Mac-specific `KStyle`. Moving the OS X-specific code to a separate file was 
initially meant to be sure that the maintenance burden of code that was maybe 
not really intended to be used on that platform would be completely the 
responsibility of those who'd be using it. With `KStyle`, that's really a 
braindead approach, so I have indeed made a todo note to use inheritance here 
too.
Using a common base class is a nice idea, probably more elegant than overriding 
(as I've been doing with the platform plugin, and which *may* be causing me 
some issues). I guess you're right it might break binary compatibility, but 
aren't the dependents you cite supposed to be tight to a given 
`frameworkintegration` version already?

That final point converges with Christoph's conclusion. I *am* also working on 
a modified version of the KdePlatformPlugin 
(https://git.reviewboard.kde.org/r/126198). If it's indeed not possible (as 
someone else suggested!) to create a QStyle plugin that modifies fonts and/or 
colours, then a platform theme would be the way to go.


- René J.V.


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


On Dec. 4, 2015, 1:27 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126241/
> ---
> 
> (Updated Dec. 4, 2015, 1:27 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and Hugo Pereira 
> Da Costa.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> This is a split-off from RR https://git.reviewboard.kde.org/r/126198/, as 
> suggested there.
> 
> The proposed change (which is a work in progress) contains a few 
> modifications mirroring those proposed for the KdePlatformTheme plugin, 
> aiming to adapt the library to Mac OS X.
> 
> These modifications should probably be implemented by subclassing KStyle 
> rather than duplicating all code.
> 
> I have been focussing on the platform theme modifications, without really 
> looking into the extent to which KStyle is used or potentially useful on OS 
> X. A separate RR should support discussion about that more easily.
> 
> Would it for instance be possible to use KStyle to create a Qt *style* plugin 
> that does nothing more than extending the native theme/style with support for 
> KDE's font roles/types, colour palettes and icon themes? This could be 
> preferable for users or developers who are not interested in providing a 
> consistent cross-platform look (which presumable requires a platform *theme*) 
> and/or who do not want to depend on a theme that makes explicit use of a 
> private Qt API (cf. `KdeMacTheme` in the RR above).
> 
> 
> Diffs
> -
> 
>   src/kstyle/CMakeLists.txt bc26667 
>   src/kstyle/kstyle.mm PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126241/diff/
> 
> 
> Testing
> ---
> 
> Builds on OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 ; "source" 
> modifications are tested in the platform theme.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

kdelibs4support forces "icons in buttons"?

2015-12-08 Thread René J . V . Bertin

Hi,

I have the strong impression that applications using the kdelibs4support fw are 
forced to show icons in buttons, regardless of the corresponding setting (which 
is respected elsewhere).
For some reason it does not happen when I use the native platform plugin on OS 
X, but if the frameworkintegration platform plugin were responsible I'd expect 
icons to appear on buttons in all applications, including those not using 
kdelibs4support.

What's going on here? As far as I can see kdelibs4support does indeed support 
the key from kdeglobals; maybe the return value from the functions reading the 
key value is not used?

R.
___
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)



> 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)



> 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)



> 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)



> 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)



> 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)



> 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 
>

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

2015-11-29 Thread René J . V . Bertin



On Nov. 25, 2015, 6:18 p.m., René J.V. Bertin wrote:
> > See qtbase/src/plugins/platforms/cocoa/qcocoaintegration.mm and 
> > qcocoahelpers.mm
> 
> René J.V. Bertin wrote:
> Isn't copy/paste a great tool? :)
> 
> Anyway, `qt_mac_transformProccessToForegroundApplication` only reads the 
> `LSUIElement` key to determine whether an application is allowed to be 
> transformed to a foreground application, and I don't see any evidence that it 
> is published. It appears to be intended to be called by default, unless the 
> env. variable `QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM` is set. Which 
> is a bit surprising, but doing a `putenv` of that variable at the start of 
> `kdemain` indeed does appear to have the desired effect.

ping?


- René J.V.


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


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

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

2015-11-29 Thread René J . V . Bertin


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

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


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
-

  src/platformtheme/khintssettings.cpp 8adf6c5 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/kstyle/kstyle.cpp 6ba5d51 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  autotests/CMakeLists.txt 7c2129c 

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.


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: setting default widgetStyle (and ColorScheme)

2015-11-30 Thread René J . V . Bertin

Martin Graesslin wrote:

> That is in deed a better approach. I'm still questioning whether it's the 
> right thing to do on OSX, but that would then be up to the OSX developers to 
> decide on. 

I'll handle that tomorrow.

> But if the platformtheme plugin does get moved to Plasma I would say that it 
> doesn't belong there as I think Plasma should only care about targeting X11 
> and Wayland. That's something the Plasma team needs to decide on, though. At 

I don't remember the details, but I recall a discussion (probably on KDE-Mac) a 
while ago about components from KDE4 that make perfect sense on OS X (in a 
packaging approach like MacPorts') were moved to Plasma, and how that could 
lead 
to problems.

>> "Never say never" mean anything to you?
> 
> Sure! It's not possible to exchange the Quartz compositor. This means: never.
> Sorry to say, but I have been in the WM business a few years now and I know
> what's possible and what isn't ;-)

However Apple calls their displaying technology nowadays, the window server and 
any related underlying technologies are indeed conceived to be impossible to 
take over or replace, once launched. It is however possible to log into OS X in 
console mode, and from there you can launch (or ought to be able, I never 
tried) 
anything else that takes over whatever handles the user interface. This is more 
or less what the defunct PureDarwin and OpenDarwin projects did, or aimed to do.

OS X doesn't have a window manager, it has a window server that does a lot more 
than managing windows in X11 style. There is no dissociation between display 
server, window manager, and the various layers in between, except to some 
extent 
in the names of the SDKs involved.

R.

___
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)

2015-12-01 Thread René J . V . Bertin

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

A couple of things I jotted down today, probably open doors but nonetheless 
maybe something to consider and take into account for those who have little or 
no first-hand experience with Qt on OS X or even MS Windows.

On Linux and other Unices that aren't OS X/iOS, there is no native platform SDK 
that provides predefined generic (and less generic) buttons, menus and whatever 
widgets. If we ignore Wayland, there was only X11, which simply provides 
windows, undecorated and empty bits of screen space that aren't even 
necessarily rectangular. What you do with those windows is completely up to 
you. And that's exactly what Qt did when they designed the Fusion theme that 
was introduced in Qt5.
Qt applications that are started on a Linux system and that don't have access 
to anything else, will by default use the QGenericUnixTheme, combined with 
Fusion. Given that this was designed from scratch, it is not surprising that 
its use gives interfaces designed with the generic Qt toolbox a pretty damn 
good look, leading to interfaces that are perfectly workable and maybe even 
enjoyable to use. They even don't look too much out of place on other 
platforms, because that was another design criterium from what I understand.

OS X and MS Windows on the other hand do provide their own SDKs with predefined 
generic (and less generic) buttons, menus and whatever widgets. Cross-platform 
middlewares like Qt can indeed be expected to use those SDKs as the basis for 
their platform implementation (which doesn't mean they should be forbidden from 
also providing a true cross-platform-coherent look). But such a middleware can 
only guarantee to provide generic controls that map to the generic native 
widgets, or else at most a smallest common denominator collection of more 
specialised widgets that exist in the SDKs of all supported platforms.
As a result, interfaces built with only that cross-platform toolbox will look 
more or less good depending on how well generic design principles that come 
with using Qt map to the underlying toolkits --- and influenced by Tufte as I 
am, I firmly believe that this can and will have implications for interface 
usability.

To borrow a metaphor and proverb: a generic, "bare-bones" Qt interface using 
the OS X native theme will look like it's wearing the emperor's clothes, but 
clearly wasn't designed for wearing those clothes. The extent to which this is 
the case varies from application to application, but you can (and likely will) 
end up with cases where the native theme makes an application look more out of 
place than a theme like Fusion (if it could be used in its full form).

This was particularly visible in KDE4 applications using the native "macintosh" 
theme/style (enough examples of kate and kcalc, among others, have been 
posted). It looks like the underlying code hasn't that much evolved since Qt 
4.8.7, so I'm expecting certain issues we identified in KDE4 apps to exist 
under KF5 too. (Indeed, the font issue with the tab selector widget looks very 
familiar.)

- René J.V. Bertin

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

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

2015-12-01 Thread René J . V . Bertin

---
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.

Changes
---

This is the promised new revision, which introduces Mac-specific files, with
Mac-specific KdeMacTheme and KHintSettingsMac classes. I stripped them of
everything I saw that was either irrelevant or unsupported.

I'm not so sure what to make of the other components; I don't see anything
Plasma-specific in InfoPage, the KMessageBox seems just as useful on OS X as
everywhere else; the same could probably be said about KF5Style if I understand
its mission correctly.

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)
-

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/

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 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)

2015-12-01 Thread René J . V . Bertin


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



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.


- René J.V. Bertin


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/
> 
> 
> 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

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

> 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)


---
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: Review Request 126198: [OS X] adaptations for the KdePlatformTheme (and autotests)


---
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: KTabBar/QTabBar and documentMode

Jaroslaw Staniek wrote:

> Hi, that's one of my hints from 2010
> https://blogs.kde.org/2010/09/29/elegance-4-tab-bar-uncluttered :)

But that's for a different purpose, removing distracting visual clutter rather 
than ensuring that the tabs themselves remain useful.

After looking into the issue a bit more I've learned that the OS X native tab 
widget does allow to turn off text truncation, but that option isn't exported 
by 
Qt. In fact, I cannot even seem to find what native class is being used: there 
are no occurrences of the NSTab* classes I expected to find in the source.

> Definitely apps could be reviewed re the clutter even on Linux, KDE HIG can
> help too. I am not sure if automatic solutions are possible for the KF
> level.

No, neither am I, there's only so much one can do automatically with a widget. 
Ultimately it remains the task of the application/interface designer to use the 
provided building blocks to come up with something truly appropriate ... and 
overly intelligent widgets can shoot themselves in the foot by not being able 
to 
do exactly what they were told to do.

I think you can compare it to a monitor with "intelligent" dynamic 
contrast/colour control. Impossible to do any form of colour tuning on those 
when the feature cannot be turned off. (Similarly it took me a while to realise 
I had to turn off my DSLR's dynamic contrast feature if I wanted to do HDR 
myself :))

R.

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

Review Request 126239: make autotests nongui executables


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

Review request for KDE Frameworks.


Repository: frameworkintegration


Description
---

Autotests should be nongui executables, at least on OS X where they would 
otherwise be built as app bundles (meaning ctest called through `make test` 
won't find them).

Split off from RR https://git.reviewboard.kde.org/r/126198/ as suggested.


Diffs
-

  autotests/CMakeLists.txt 7c2129c 

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


Testing
---

On OS X 10.9 with Qt 5.5.1 and frameworks 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

Review Request 126241: [OS X] adapting KStyle (WIP)


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

Review request for KDE Software on Mac OS X, KDE Frameworks and Hugo Pereira Da 
Costa.


Repository: frameworkintegration


Description
---

This is a split-off from RR https://git.reviewboard.kde.org/r/126198/, as 
suggested there.

The proposed change (which is a work in progress) contains a few modifications 
mirroring those proposed for the KdePlatformTheme plugin, aiming to adapt the 
library to Mac OS X.

These modifications should probably be implemented by subclassing KStyle rather 
than duplicating all code.

I have been focussing on the platform theme modifications, without really 
looking into the extent to which KStyle is used or potentially useful on OS X. 
A separate RR should support discussion about that more easily.

Would it for instance be possible to use KStyle to create a Qt *style* plugin 
that does nothing more than extending the native theme/style with support for 
KDE's font roles/types, colour palettes and icon themes? This could be 
preferable for users or developers who are not interested in providing a 
consistent cross-platform look (which presumable requires a platform *theme*) 
and/or who do not want to depend on a theme that makes explicit use of a 
private Qt API (cf. `KdeMacTheme` in the RR above).


Diffs
-

  src/kstyle/CMakeLists.txt bc26667 
  src/kstyle/kstyle.mm PRE-CREATION 

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


Testing
---

Builds on OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 ; "source" 
modifications are tested in the platform theme.


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


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

(Updated Dec. 4, 2015, 2:05 p.m.)


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


Changes
---

This takes Martin's feedback into account, and drops the autotest and KStyle 
parts.

I will only have the chance to test-build this (long story...) later this 
afternoon, apologies for any syntax errors that got through.


Summary (updated)
-

[OS X] adaptations for the KdePlatformTheme


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/CMakeLists.txt 23f590e 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  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

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



> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > Please include Hugo for a review on the KStyle changes.
> > 
> > I'd suggest to split the review into three parts: one about the adjusted 
> > test (ecm_foo) - that's a no brainer and doesn't need further discussion. 
> > One about the KStyle change and one about the platform theme change. These 
> > are independent libraries so a split review makes it easier IMHO.

split-offs created; I found only 1 Hugo in the list of known people, whom I 
included on the new KStyle RR.


> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/CMakeLists.txt, lines 67-69
> > 
> >
> > don't make thie an elsif, just an if. It's not an elseif condition

In practice it is, I think it has more or less been decided to assume `APPLE` 
means "no X11". Qt's XCB QPA can currently still be built on OS X (and is 
almost completely functional) but there's no guarantee how long that will still 
be possible.

Which should suit some of you, as full-blown X11 support would definitely give 
sense to supporting full-blown Plasma sessions (in so-called rooted mode of the 
XQuartz server). :P


> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.h, lines 41-54
> > 
> >
> > why did you add the virtual? The methods are marked as Q_DECL_OVERRIDE 
> > which implies they are virtual

Q_DECL_OVERRIDE indeed appears to resolve to `override` even with clang; what 
about when it doesn't? Not supposed to happen and thus not to worry about any 
issues that might cause?

For now I've left the virtual keywords on definitions that lack 
Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead?


> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.h, lines 56-61
> > 
> >
> > there is no such thing as a protected variable (see e.g. 
> > https://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables
> >  ). If you need to access the variables, please add protected accessor and 
> > setter methods

That article suggests protected member variables do exist but should be 
avoided. Is that what you meant?

The only one I actually used was mKdeGlobals from the fontsettings class


> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/main_mac.cpp, line 45
> > 
> >
> > why does the mac platform want to setupXcbFlush?

If it won't ever be signalled "from outside" then no, there's no need to 
provide the slot at all. (There was a question about this on line 44 ;))

I take it the moc include is still required because the class derives QObject?


- René J.V.


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


On Dec. 3, 2015, 10:51 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. 3, 2015, 10:51 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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme



> On Dec. 4, 2015, 8:26 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.h, lines 41-54
> > 
> >
> > why did you add the virtual? The methods are marked as Q_DECL_OVERRIDE 
> > which implies they are virtual
> 
> René J.V. Bertin wrote:
> Q_DECL_OVERRIDE indeed appears to resolve to `override` even with clang; 
> what about when it doesn't? Not supposed to happen and thus not to worry 
> about any issues that might cause?
> 
> For now I've left the virtual keywords on definitions that lack 
> Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead?
> 
> Martin Gräßlin wrote:
> > what about when it doesn't?
> 
> It doesn't matter. override triggers a compile error if the base method 
> is not defined as virtual. By reimplementing in a subclass without virtual 
> you're not going to turn it non-virtual. We only used to add virtual in 
> derived classed to increase readability, to indicate that it overrides a base 
> method. Now we have language support for that.
> 
> > For now I've left the virtual keywords on definitions that lack 
> Q_DECL_OVERRIDE; should I use Q_DECL_OVERRIDE instead?
> 
> Don't change if it's not needed. If the method is virtual in the base 
> class then don't add virtual.

Ok. Even the dtors? I thought it was good practice to make those virtual almost 
always?


- René J.V.


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


On Dec. 4, 2015, 2:05 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. 4, 2015, 2:05 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 
>

Re: Review Request 126239: make autotests nongui executables


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

(Updated Dec. 4, 2015, 4:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 4037bdc070a98c06f125da636655e4735259a060 by René J.V. 
Bertin to branch master.


Repository: frameworkintegration


Description
---

Autotests should be nongui executables, at least on OS X where they would 
otherwise be built as app bundles (meaning ctest called through `make test` 
won't find them).

Split off from RR https://git.reviewboard.kde.org/r/126198/ as suggested.


Diffs
-

  autotests/CMakeLists.txt 7c2129c 

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


Testing
---

On OS X 10.9 with Qt 5.5.1 and frameworks 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 126170: [OS X] make kded5 an agent, and build it as a regular application instead of an app bundle

2015-12-06 Thread René J . V . Bertin

On Sunday December 06 2015 14:51:40 David Faure wrote:

> Here is an easy way to test this: do the same change for kiod in kio (it's 
> like a mini kded) and then
> cd kio/tests ; ./listjobtest ftp://t...@upload.kde.org
> should bring up a password dialog.

OK, hope to get around to doing that tomorrow.

> 
> Except that with Qt 5.6 from git here (from some time ago) it asserts in DBus 
> (looking into that now)... but hopefully you have Qt 5.5 ?

Yes.
Is that assert platform-specific? There has been a recent change that 
apparently removed DBus access from the OS X platform plugin, I hope that's not 
related? (I can dig out the code review ticket if you missed it.)

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

Re: kpty/utempter

2015-12-06 Thread René J . V . Bertin

On Sunday December 06 2015 21:52:21 David Faure wrote:

> > Question is, how useful is this in KPty?
> 
> `utempter is a privileged helper program that writes utmp/wtmp entries for 
> unprivileged programs.`

I can read, you know ;)

> 
> Does utmp or wtmp exist on OSX?
> Hmm, yes, but deprecated -- 
> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/utmp.5.html
> So probably not worth it.

There's utmpx nowadays, which isn't marked as deprecated, and is backwards 
compatible with utmp:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/utmpx.5.html

Question is, what are we missing out on without it? Is this what kdesu is based 
on, for instance?

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

[OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

Hi,

Several classes exist that have the possibility to create widgets or windows 
from a Qt WId, and those are used (exclusively? mostly?) by certain helper 
agents like the kwalletd to display dialogs parented by a window from the 
application that sent the request that justified posting the dialog in question.

This procedure works fine on X11 where there is a single server that provides 
and controls the basic UI elements (windows) and where a WId is (presumable) 
something that translates to an X11 window reference. On OS X (and MS 
Windows?), a WId is in fact cast from a pointer to an instance of a native 
widget class (QNSView, QNSWindow; QCocoaView in Qt4), and using these from a 
different process can evidently lead to a SIGSEGV.

Yet applications like kwalletd are not out of place on platforms that are not 
X11 ... and I understand from Martin that the same or a highly comparable 
situation exists with Wayland.

I'd like to start a discussion on how this can be dealt with. Qt does not keep 
track of who "owns" each existing WId (not on OS X at least), but until now 
QWidget::find(WId) has always returned NULL for me when given an invalid WId 
(including those owned by another process).

A function like createWIdDialog (in KWidgetsAddons) already detects this, and 
can be adapted to handle this situation differently where required (it 
currently calls setMainWindow() when QWidget::find returned NULL and the WId 
isn't NULL itself). For a KMessageBox it would then make sense on OS X to call 
a platform function to ensure that the dialog is posted in front; i.o.w. in 
front of all windows rather than where the owning application decided to place 
the window (WId). (Not doing anything of the sort would mean the dialog opens 
in the "layer" of the background application, i.e. somewhere behind most or all 
other open windows).

I'm working on an OS X plugin for KWindowSystem, so a priori I should be able 
to provide an appropriate activateWindow implementation.
I'd appreciate suggestions what classes that allow to create instances from 
WIds should provide this "in your face" approach if the target WId comes from 
another process.

KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT use 
the plugin architecture currently, but simply assumes that QWindow::fromWinId() 
will always work (and never crash). For the time being it will thus require 
ifdefs. Beyond that, exactly how should I adapt it? Never do anything on OS X 
(the solution used currently in KDELibs4/MacPorts)? Or check the result from 
QWidget::find() and only do its job when that function returns a valid pointer 
(which could actually be the general approach if that find() function isn't 
expensive on platforms where calling it is redundant).

Beyond that I suppose that setMainWindow() is *not* the place to push the new 
window to the foreground so that it doesn't get overlooked - or is it?
In other words, what exactly is the role of KWindowSystem's main window?

Thanks,
René

PS: I did indeed write a native, "Keychain backend" (SecKeyChain) for KWallet4, 
but after having used and polished that backed for over a year I think it is 
not feasible to provide a satisfactory implementation that maps enough of the 
KWallet feature set to the much more restricted SecKeyChain API. Applications 
depending on KWallet (and their users) are better off with an adapted kwalletd 
that functions correctly, IMHO.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

On Wednesday December 09 2015 13:51:47 Martin Graesslin wrote:

> > KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT
> > use the plugin architecture currently, but simply assumes that
> > QWindow::fromWinId() will always work (and never crash).
> 
> oh that explains a lot... Like why couldn't I find it in my Wayland backend, 
> why do random applications crash on Wayland...

You actually missed this? :)

> nah, won't help. Well would help for OSX, but not for Linux/Wayland. I think 
> we need to move it to plugin architecture, too.

I agree. When I said "for the time being" that was also because I have been 
developing my MacPorts build/packaging scripts at the same time as installing 
(bootstrapping) KF5, and even the current KWindowSystem git/head refuses to 
build against 5.16.0 (and I'd just as well have only a single set of build 
directories). Oh well...

Is Wayland detection purely a runtime thing?

> > Beyond that I suppose that setMainWindow() is *not* the place to push the
> > new window to the foreground so that it doesn't get overlooked - or is it?
> > In other words, what exactly is the role of KWindowSystem's main window?
> 
> It's an X11 thing (like most KWindowSystem methods) for parent-child 
> relationship. It's not about raising windows, etc. That's up to the windowing 
> system.

That confirms my impression about setMainWindow(). As to the "up to the 
windowing system" bit, that's a lot less simple.
From what I understand, the purpose of using a WId from another application is 
to ensure that the newly created window/dialog displays alongside the windows 
of that application (above them if the window manager is set to stack new 
windows that way). On OS X, windows are always opened in front of the other 
windows of the same application (unless the application instructs differently). 
Assuming that that owning application is frontmost (the one being used 
interactively) when the dialog is created, that should be a sufficient way to 
ensure that the dialog is seen by the user, without forcing it to the front or 
even setting a WM hint.

In practice it doesn't always work that way; even on X11 things like wallet 
password requests tend to "pop down" somewhere behind a random amount of other 
windows. That happens often enough that I patched the akonadi mail transport 
agent so that it handles wallet unlock timeouts more intelligently.
On OS X it would be systematic, which was among the reasons I made a Keychain 
backend for KWallet; at least the native API puts password unlock requests up 
right in your face. Annoying at times, but appropriately so IMHO.

This is why I asked if there are classes where it would make sense to force a 
window to the foreground if it cannot be opened alongside (= just above) the 
windows of the application that's responsible for that new window's creation. 
KMessageBox seems like a justifiable candidate to me.

Note: if an application posts an alert on OS X it will depend on certain things 
if that alert is posted in front of everything else (alert type among others). 
I'm not sure I really know the rules but it's a fact that every so often you'll 
happen upon an alert that got posted somewhere behind other things (or on a 
different "Space", virtual desktop) ... or you are alerted by another signal 
that draws your attention to some background app that requires it. Typically 
that will be a bouncing Dock icon ... and evidently that's not possible in a 
background app ("agent") that doesn't have Dock presence.

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

Re: Scope of framework integration plugin?

2015-12-05 Thread René J . V . Bertin

Boudewijn Rempt wrote:

From what I recall from KDE4, there was at least a KDE -> X resources path in 
systemsettings

> without any kde integration available, and I noticed that Qt 5.6 doesn't seem
> to pick up the Gnome font hinting settings.

Re-reading this I'd say there must be a default setting in Qt if it doesn't 
respect the X resource values on your Gnome-only system. I take it you checked 
if Qt-only applications have the same behaviour?

What Freetype and Fontconfig versions does that OpenSuse Leap system have? I 
seem to recall mention of things not getting picked up with the latest version 
of Bohoomil's infinality-ultimate project, which could be related (it's based 
on 
very recent Freetype and Fontconfig versions).

R.

>> That mostly comes from X resources.
>> 
>> can you run:
>> xrdb -q | grep  Xft
>> 
>> on both?
> 
> I have finally had a chance to sit down at the computer at home:
> 
> On the opensuse leap gnome-only system:
> 
> boud@linux-jw8m:~> xrdb -q | grep -i xft
> Xft.dpi:96
> Xft.antialias:  1
> Xft.hinting:0
> Xft.hintstyle:  hintnone
> Xft.rgba:   rgb
> 
> On the kde plasma 5 system:
> 
> 
> Xft.dpi:120
> Xft.antialias:  1
> Xft.hinting:0
> Xft.hintstyle:  hintnone
> Xft.rgba:   none
> 
>> 
>> startkde has a bunch of scripts to set these from your kde settings, but it's
>> somewhat archaic so I can see why Gnome might have ported away.

___
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



> On Dec. 4, 2015, 2:40 p.m., Martin Gräßlin wrote:
> >

No, those we shouldn't need anymore as the toplevel CMake file will reject Qt 
versions earlier than 5.3.0 .

Should I clean up all occurrences from platformtheme, even where they have 
nothing to do with the Mac version?


- René J.V.


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


On Dec. 4, 2015, 7:01 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. 4, 2015, 7:01 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
> -
> 
>   src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
>   src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
>   src/platformtheme/kdemactheme.h PRE-CREATION 
>   src/platformtheme/kdemactheme.mm PRE-CREATION 
>   src/platformtheme/kdeplatformtheme.h 97d09df 
>   src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
>   src/platformtheme/kfontsettingsdata.h 4b92c7d 
>   src/platformtheme/CMakeLists.txt 23f590e 
>   src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
>   src/platformtheme/khintssettings.h ec064d3 
>   src/platformtheme/khintssettings.cpp 8adf6c5 
>   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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme


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

(Updated Dec. 4, 2015, 7:01 p.m.)


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


Changes
---

This takes the open issues into account, and also restores settings in the 
khintssettingsmac ctor that got lost when I added the `m_hints.clear()` command 
a rev. or 2 back. I also made the KHintsSettings member variables private 
again; I missed those earlier today.


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/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/CMakeLists.txt 23f590e 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettings.cpp 8adf6c5 
  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

KTabBar/QTabBar and documentMode

2015-12-03 Thread René J . V . Bertin

Hi,

I've been looking into ways to configure (improve) the look and feel using the 
native platform theme on OS X, and was reminded quite quickly about one of the 
nuisances that can arise with the default look of the native widget used by 
QTabBar. It's easy to reach the number of open tabs where the underlying system 
starts truncating text, replacing it with an ellipsis. Adding a close button 
doesn't help of course; this affected the tabbed document editor from 
KDevelop4, for instance.

What I had not realised was that QTabBar provides a documentMode exactly for 
this reason/application, which switches the widget to a mode more appropriate 
for multi-tab document views, on OS X. I see that Kate4 used to set that mode 
(makes you wonder why KDevelop4 didn't benefit from that), but the mode switch 
has disappeared from the current Kate code.
The only mention of the mode I've seen to date in KF5 frameworks code is in a 
comment (!) in kdelibs4support (src/kdeui/k4style.cpp).

I'm a bit early in asking this in that I haven't yet been able to test neither 
Kate nor KDevelop, but is there an "official" or consensual opinion about this 
(e.g. applications should call QTabBar::setDocumentMode themselves when 
appropriate ... and can be patched if they don't)?

R.
___
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)

2015-12-03 Thread René J . V . Bertin


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

(Updated Dec. 3, 2015, 10:51 p.m.)


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


Changes
---

A slightly polished version. New here is support for the fact that OS X will 
use a bold `MessageBoxFont` by default (bold version of the system 
font/`GeneralFont`). This is now supported through a new cache entry 
corresponding to the bold `GeneralFont`. If however the user configured a 
different `GeneralFont`, this choice will be respected, but this font will 
still be made bold.

Interestingly, the `MessageBoxFont` is one of the fonts that OS X allows/ed to 
be configured (through a utility like `TinkerTool` that exposed preferences not 
otherwise exposed).


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)
-

  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/kdeplatformtheme.h 97d09df 
  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

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



> 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 126291: initial implementation of a platform plugin for OS X (WIP)


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

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


Repository: kwindowsystem


Description
---

KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
"backport" of the modified KDE4 KWindowSystem implementation that has been used 
in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.

I have made some initial steps to remove deprecated Carbon API calls, but this 
is clearly a work in progress.

Open questions include
- is there any justification to run an event handler (or Cocoa observer) to 
keep track of running applications, possibly even listing all their open 
windows?
- is there any use for the Qt event listener framework (cf. the NETEventFilter 
in the X11 plugin)? I haven't yet had time to try to figure out what this 
"could be good for", and am very open to suggestions in this departments.
- one application for such an event filter would be a listener that catches the 
opening and closing of all windows by the running process, and keeps track of 
their `WId`s. A new method could then be added (to `KWindowInfo`?) to 
distinguish `WId`s created by the running application from "foreign" ones 
(useful also on Wayland and MS Windows).

`KWindowSystem::setMainWindow` should become a front for payload provided by 
the plugins. I'll leave that to the regular/official maintainer(s) of this 
framework.

This code could probably do with *lots* of comments; I'll try to add them as 
questions about this or that bit of code arise.


Diffs
-

  src/platforms/osx/plugin.cpp PRE-CREATION 
  src/platforms/osx/plugin.h PRE-CREATION 
  src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION 
  src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION 
  src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION 
  src/platforms/osx/kwindowsystem.cpp 2fcec18 
  src/platforms/osx/kwindowinfo_mac_p.h 26ff790 
  src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION 
  src/platforms/osx/kwindowinfo.mm PRE-CREATION 
  src/platforms/osx/cocoa.json PRE-CREATION 
  src/platforms/osx/kwindowinfo.cpp 328d6a9 
  src/kwindowsystem.cpp 9ef273f 
  src/platforms/osx/CMakeLists.txt 4fc3347 

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


Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 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: [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

Kai Uwe Broulik wrote:

> ‎> On OS X (and MS Windows?),
> 
> And Wayland, so it affects Linux, too.

Yes, I learned that while composing my message (cf. the subject).

FWIW, I just provided an initial/WIP implementation of a KWindowSystem plugin 
for OS X: https://git.reviewboard.kde.org/r/126291/

R.

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

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.
> 
> René J.V. Bertin wrote:
> 1: why should one care? It is said nowhere that the setting defined as 
> "show icons on buttons" in `systemsettings(5)` applies only to dialogs. 
> Rather, the tooltip says "when this is enabled, KDE applications will show 
> icons alongside [sic!] some important buttons".
> In other words, when "this" is *not* enabled, there should be no icons, 
> period.
> I have found no sign in the code that the ShowIconsOnPushButtons hint is 
> to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed 
> carries the suggestion in its name but I would not be surprised if Qt really 
> thinks of it in a more general sense. Probably also because the notion of 
> what a dialog is has become a lot vaguer.
> 
> And that also happens to be what Qt does; buttons show their icons on 
> Linux (and other Unix variants?) but on OS X or MS Windows displaying of 
> those icons is deactivated unless you use a style that enables it. In fact, 
> the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except 
> in the generic Unix theme (= it does work globally like 
> `AA_DontShowIconsInMenus` everywhere else).
> 
> 2: a user who indicates s/he doesn't want to see icons will get an empty 
> button. That's also what can happen with QPushButton, and app developers have 
> to take this into consideration. Cf. toolbars (and Qt's position on the use 
> of "texted separators").
> I don't think I've ever come across a standard button showing only an 
> icon, except possibly the arrow button next to the progress indicators in 
> KMail and KDevelop.
> 
> As to fixing it here: as it turns out, "here" is the main source for 
> annoying icons rearing their silly heads on buttons on my screen ;) and it 
> was also something of a challenge to understand why they kept appearing 
> despite the fact that all code appeared to return the value of 
> `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all 
> applications are going to stop using it anytime soon.
> 
> I looked into fixing the issue in KDialogButtonBox but saw that it does 
> nothing to override the `ShowIconsOnPushButtons` setting. The only way to 
> respect the setting through that class (or a modern equivalent) would be to 
> set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another 
> regression: changes in this setting are supposed to be reflected by running 
> applications without requiring a restart (or a recreation of dialogs). If it 
> were just me I'd decree that buttons can have either text or an icon, but 
> right now we have to make do with this mixed situation.
> 
> I don't mind making this an OS X (and MS Windows) specific modification, 
> of course, but on those platforms
> 
> Thomas Lübking wrote:
> > 1: why should one care?
> 
> Because, as explained, that is what the hint says. Nothing else.
> 
> > I have found no sign in the code that the ShowIconsOnPushButtons hint 
> is to be used only for dialogs
> 
> No, but it's been used to feed SH_DialogButtonBox_ButtonsHaveIcons *AND* 
> KPushButton.
> ShowIconsOnPushButtons implied SH_DialogButtonBox_ButtonsHaveIcons but 
> NOT vv.
> 
> The approach is wrong, since you're abusing the hint for generalisation.
> 
> > but on OS X or MS Windows
> 
> ... Qt uses native elements which might simply globally downforce the 
> pushbutton icon nonsense (as could any style - I was more than once close to 
> doing that in virtuality)
> Eg. Breeze might do that on favor of the HIG, but that's not relevant 
> here.
> 
> Downforcing in KPushButton means to

system tray test?

Hi,

Does KF5 provide any classes above Qt's for putting up and controlling an icon 
(with/out menu) in the "system tray"?
If so, is there a simple test app I can try?

Reason I'm asking: kwalletmanager5 isn't showing a systray interface like 
kwalletmanager(4) does. Not on OS X (where Qt5's systray does work), and on 
Linux under a KDE4 desktop I'm not sure what I'm getting.

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

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing


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

(Updated Dec. 11, 2015, 1:42 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, and Hugo 
Pereira Da Costa.


Changes
---

This adds the changes to KDialogButtonBox that seem required to respect 
`SH_DialogButtonBox_ButtonsHaveIcons` regardless of `ShowIconsOnPushButtons` (= 
if the former could be independent of the latter e.g. when using a style that 
does not use the latter to determine the value of the former).

What is the point in allowing `KDialogButtonBox::addButton` to create a button 
that is not added because of an invalid role? It seems that button wouldn't 
appear (or in an unexpected place), and be leaked?


Repository: kdelibs4support


Description
---

KF5 applications have long had a habit of drawing icons on buttons even when 
this feature was turned off in the user's setting. This was mostly noticeable 
in applications built on kdelibs4support.

It seems that the actual culprit is in Qt's QPushButton implementation 
(https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the 
null icon) in the option instance, before handing off control to the painter.


Diffs (updated)
-

  src/kdeui/kpushbutton.cpp 98534fa 
  src/kdeui/kdialogbuttonbox.cpp 0f6649b 

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


Testing
---

On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .

I have not yet verified if there are other classes where this modification 
would be relevant too.


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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing


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

(Updated Dec. 11, 2015, 1:59 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, and Hugo 
Pereira Da Costa.


Changes
---

This patch for KDialogButtonBox actually builds.


Repository: kdelibs4support


Description
---

KF5 applications have long had a habit of drawing icons on buttons even when 
this feature was turned off in the user's setting. This was mostly noticeable 
in applications built on kdelibs4support.

It seems that the actual culprit is in Qt's QPushButton implementation 
(https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the 
null icon) in the option instance, before handing off control to the painter.


Diffs (updated)
-

  src/kdeui/kdialogbuttonbox.cpp 0f6649b 
  src/kdeui/kpushbutton.cpp 98534fa 

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


Testing
---

On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .

I have not yet verified if there are other classes where this modification 
would be relevant too.


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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.
> 
> René J.V. Bertin wrote:
> 1: why should one care? It is said nowhere that the setting defined as 
> "show icons on buttons" in `systemsettings(5)` applies only to dialogs. 
> Rather, the tooltip says "when this is enabled, KDE applications will show 
> icons alongside [sic!] some important buttons".
> In other words, when "this" is *not* enabled, there should be no icons, 
> period.
> I have found no sign in the code that the ShowIconsOnPushButtons hint is 
> to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed 
> carries the suggestion in its name but I would not be surprised if Qt really 
> thinks of it in a more general sense. Probably also because the notion of 
> what a dialog is has become a lot vaguer.
> 
> And that also happens to be what Qt does; buttons show their icons on 
> Linux (and other Unix variants?) but on OS X or MS Windows displaying of 
> those icons is deactivated unless you use a style that enables it. In fact, 
> the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except 
> in the generic Unix theme (= it does work globally like 
> `AA_DontShowIconsInMenus` everywhere else).
> 
> 2: a user who indicates s/he doesn't want to see icons will get an empty 
> button. That's also what can happen with QPushButton, and app developers have 
> to take this into consideration. Cf. toolbars (and Qt's position on the use 
> of "texted separators").
> I don't think I've ever come across a standard button showing only an 
> icon, except possibly the arrow button next to the progress indicators in 
> KMail and KDevelop.
> 
> As to fixing it here: as it turns out, "here" is the main source for 
> annoying icons rearing their silly heads on buttons on my screen ;) and it 
> was also something of a challenge to understand why they kept appearing 
> despite the fact that all code appeared to return the value of 
> `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all 
> applications are going to stop using it anytime soon.
> 
> I looked into fixing the issue in KDialogButtonBox but saw that it does 
> nothing to override the `ShowIconsOnPushButtons` setting. The only way to 
> respect the setting through that class (or a modern equivalent) would be to 
> set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another 
> regression: changes in this setting are supposed to be reflected by running 
> applications without requiring a restart (or a recreation of dialogs). If it 
> were just me I'd decree that buttons can have either text or an icon, but 
> right now we have to make do with this mixed situation.
> 
> I don't mind making this an OS X (and MS Windows) specific modification, 
> of course, but on those platforms
> 
> Thomas Lübking wrote:
> > 1: why should one care?
> 
> Because, as explained, that is what the hint says. Nothing else.
> 
> > I have found no sign in the code that the ShowIconsOnPushButtons hint 
> is to be used only for dialogs
> 
> No, but it's been used to feed SH_DialogButtonBox_ButtonsHaveIcons *AND* 
> KPushButton.
> ShowIconsOnPushButtons implied SH_DialogButtonBox_ButtonsHaveIcons but 
> NOT vv.
> 
> The approach is wrong, since you're abusing the hint for generalisation.
> 
> > but on OS X or MS Windows
> 
> ... Qt uses native elements which might simply globally downforce the 
> pushbutton icon nonsense (as could any style - I was more than once close to 
> doing that in virtuality)
> Eg. Breeze might do that on favor of the HIG, but that's not relevant 
> here.
> 
> Downforcing in KPushButton means to

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.
> 
> René J.V. Bertin wrote:
> 1: why should one care? It is said nowhere that the setting defined as 
> "show icons on buttons" in `systemsettings(5)` applies only to dialogs. 
> Rather, the tooltip says "when this is enabled, KDE applications will show 
> icons alongside [sic!] some important buttons".
> In other words, when "this" is *not* enabled, there should be no icons, 
> period.
> I have found no sign in the code that the ShowIconsOnPushButtons hint is 
> to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed 
> carries the suggestion in its name but I would not be surprised if Qt really 
> thinks of it in a more general sense. Probably also because the notion of 
> what a dialog is has become a lot vaguer.
> 
> And that also happens to be what Qt does; buttons show their icons on 
> Linux (and other Unix variants?) but on OS X or MS Windows displaying of 
> those icons is deactivated unless you use a style that enables it. In fact, 
> the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except 
> in the generic Unix theme (= it does work globally like 
> `AA_DontShowIconsInMenus` everywhere else).
> 
> 2: a user who indicates s/he doesn't want to see icons will get an empty 
> button. That's also what can happen with QPushButton, and app developers have 
> to take this into consideration. Cf. toolbars (and Qt's position on the use 
> of "texted separators").
> I don't think I've ever come across a standard button showing only an 
> icon, except possibly the arrow button next to the progress indicators in 
> KMail and KDevelop.
> 
> As to fixing it here: as it turns out, "here" is the main source for 
> annoying icons rearing their silly heads on buttons on my screen ;) and it 
> was also something of a challenge to understand why they kept appearing 
> despite the fact that all code appeared to return the value of 
> `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all 
> applications are going to stop using it anytime soon.
> 
> I looked into fixing the issue in KDialogButtonBox but saw that it does 
> nothing to override the `ShowIconsOnPushButtons` setting. The only way to 
> respect the setting through that class (or a modern equivalent) would be to 
> set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another 
> regression: changes in this setting are supposed to be reflected by running 
> applications without requiring a restart (or a recreation of dialogs). If it 
> were just me I'd decree that buttons can have either text or an icon, but 
> right now we have to make do with this mixed situation.
> 
> I don't mind making this an OS X (and MS Windows) specific modification, 
> of course, but on those platforms
> 
> Thomas Lübking wrote:
> > 1: why should one care?
> 
> Because, as explained, that is what the hint says. Nothing else.
> 
> > I have found no sign in the code that the ShowIconsOnPushButtons hint 
> is to be used only for dialogs
> 
> No, but it's been used to feed SH_DialogButtonBox_ButtonsHaveIcons *AND* 
> KPushButton.
> ShowIconsOnPushButtons implied SH_DialogButtonBox_ButtonsHaveIcons but 
> NOT vv.
> 
> The approach is wrong, since you're abusing the hint for generalisation.
> 
> > but on OS X or MS Windows
> 
> ... Qt uses native elements which might simply globally downforce the 
> pushbutton icon nonsense (as could any style - I was more than once close to 
> doing that in virtuality)
> Eg. Breeze might do that on favor of the HIG, but that's not relevant 
> here.
> 
> Downforcing in KPushButton means to

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.
> 
> René J.V. Bertin wrote:
> 1: why should one care? It is said nowhere that the setting defined as 
> "show icons on buttons" in `systemsettings(5)` applies only to dialogs. 
> Rather, the tooltip says "when this is enabled, KDE applications will show 
> icons alongside [sic!] some important buttons".
> In other words, when "this" is *not* enabled, there should be no icons, 
> period.
> I have found no sign in the code that the ShowIconsOnPushButtons hint is 
> to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed 
> carries the suggestion in its name but I would not be surprised if Qt really 
> thinks of it in a more general sense. Probably also because the notion of 
> what a dialog is has become a lot vaguer.
> 
> And that also happens to be what Qt does; buttons show their icons on 
> Linux (and other Unix variants?) but on OS X or MS Windows displaying of 
> those icons is deactivated unless you use a style that enables it. In fact, 
> the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except 
> in the generic Unix theme (= it does work globally like 
> `AA_DontShowIconsInMenus` everywhere else).
> 
> 2: a user who indicates s/he doesn't want to see icons will get an empty 
> button. That's also what can happen with QPushButton, and app developers have 
> to take this into consideration. Cf. toolbars (and Qt's position on the use 
> of "texted separators").
> I don't think I've ever come across a standard button showing only an 
> icon, except possibly the arrow button next to the progress indicators in 
> KMail and KDevelop.
> 
> As to fixing it here: as it turns out, "here" is the main source for 
> annoying icons rearing their silly heads on buttons on my screen ;) and it 
> was also something of a challenge to understand why they kept appearing 
> despite the fact that all code appeared to return the value of 
> `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all 
> applications are going to stop using it anytime soon.
> 
> I looked into fixing the issue in KDialogButtonBox but saw that it does 
> nothing to override the `ShowIconsOnPushButtons` setting. The only way to 
> respect the setting through that class (or a modern equivalent) would be to 
> set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another 
> regression: changes in this setting are supposed to be reflected by running 
> applications without requiring a restart (or a recreation of dialogs). If it 
> were just me I'd decree that buttons can have either text or an icon, but 
> right now we have to make do with this mixed situation.
> 
> I don't mind making this an OS X (and MS Windows) specific modification, 
> of course, but on those platforms
> 
> Thomas Lübking wrote:
> > 1: why should one care?
> 
> Because, as explained, that is what the hint says. Nothing else.
> 
> > I have found no sign in the code that the ShowIconsOnPushButtons hint 
> is to be used only for dialogs
> 
> No, but it's been used to feed SH_DialogButtonBox_ButtonsHaveIcons *AND* 
> KPushButton.
> ShowIconsOnPushButtons implied SH_DialogButtonBox_ButtonsHaveIcons but 
> NOT vv.
> 
> The approach is wrong, since you're abusing the hint for generalisation.
> 
> > but on OS X or MS Windows
> 
> ... Qt uses native elements which might simply globally downforce the 
> pushbutton icon nonsense (as could any style - I was more than once close to 
> doing that in virtuality)
> Eg. Breeze might do that on favor of the HIG, but that's not relevant 
> here.
> 
> Downforcing in KPushButton means to

Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing


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

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


Repository: kdelibs4support


Description
---

KF5 applications have long had a habit of drawing icons on buttons even when 
this feature was turned off in the user's setting. This was mostly noticeable 
in applications built on kdelibs4support.

It seems that the actual culprit is in Qt's QPushButton implementation 
(https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the 
null icon) in the option instance, before handing off control to the painter.


Diffs
-

  src/kdeui/kpushbutton.cpp 98534fa 

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


Testing
---

On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .

I have not yet verified if there are other classes where this modification 
would be relevant too.


Thanks,

René J.V. Bertin

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

Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana


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

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


Repository: kdelibs4support


Description
---

This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and 
demangling support on OS X, FreeBSD and Solaris/OpenIndiana.
The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/

It seems that change was never incorporated because of a single open issue for 
which I never found the time (also given that it seemed a bit overkill).

My PC-BSD and Indiana VMs are no longer operational; it seems highly likely 
that the current code still works but if further testing or polishing is 
required I'll rather remove the specific parts than bring the VMs online again.


Diffs
-

  src/kdecore/kdebug.cpp 6f04dce 

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


Testing
---

On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with gcc 
and clang, PC-BSD with clang and on Open Indiana. 

The KDE4 RR raises some doubts concerning checking for only an OS and not 
compilers (in demangling). I think there is no reason for such doubts: 
compilers are obliged to co-exist and be compatible nowadays, at least on 
individual OS families (each platform will have its own default/dominant 
compiler that is used to build the system libraries). In practice it turns out 
that gcc and clang use the same C++ mangling scheme. The only difference is in 
the way `backtrace_symbols()` formats the stack, and that indeed appears to 
defined the OS rather than by the compiler used.
(Then again I'm willing to stand corrected by someone who has a Linux system 
built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :))


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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing


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

(Updated Dec. 11, 2015, 5:26 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, Hugo 
Pereira Da Costa, and Yichao Yu.


Changes
---

Thomas, what exactly did you mean with "QDialogButtonBox::addButton should do 
correctly"? Looking at Qt's code again, I can confirm that 
QDB::addButton(StandardButton) is the only one invoking the private 
createButton method which in turn sets an icon if ButtonsHaveIcons is true. The 
other QDB::addButton methods simply call the private addButton method which 
will do a layout step by default, but I don't see where an icon would be added.

Should I understand that `style->standardIcon()` is invoked during drawing as a 
function of button's role?

I cannot find evidence of that in QtCurve. But if that is the case nonetheless, 
why are we patching KDialogButtonBox again? And how do you explain that 
removing the icon after a button is created has the effect it has (when the 
style will continue to see the button role)?


Repository: kdelibs4support


Description
---

KF5 applications have long had a habit of drawing icons on buttons even when 
this feature was turned off in the user's setting. This was mostly noticeable 
in applications built on kdelibs4support.

It seems that the actual culprit is in Qt's QPushButton implementation 
(https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the 
null icon) in the option instance, before handing off control to the painter.


Diffs (updated)
-

  src/kdeui/kdialogbuttonbox.cpp 0f6649b 
  src/kdeui/kpushbutton.cpp 98534fa 

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


Testing
---

On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .

I have not yet verified if there are other classes where this modification 
would be relevant too.


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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 61
> > 
> >
> > unrelated and it won't leak, since the cleanup is done by the 
> > parent/child relation ("this" passed to KPushButton)

Maybe it won't leak, but the question remains why what buttons with an invalid 
role are good for.


- René J.V.


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


On Dec. 11, 2015, 3:03 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126308/
> ---
> 
> (Updated Dec. 11, 2015, 3:03 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, Hugo 
> Pereira Da Costa, and Yichao Yu.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> KF5 applications have long had a habit of drawing icons on buttons even when 
> this feature was turned off in the user's setting. This was mostly noticeable 
> in applications built on kdelibs4support.
> 
> It seems that the actual culprit is in Qt's QPushButton implementation 
> (https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
> around it in `KPushButton::paintEvent`, by removing the icon (forcing it to 
> the null icon) in the option instance, before handing off control to the 
> painter.
> 
> 
> Diffs
> -
> 
>   src/kdeui/kdialogbuttonbox.cpp 0f6649b 
>   src/kdeui/kpushbutton.cpp 98534fa 
> 
> Diff: https://git.reviewboard.kde.org/r/126308/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .
> 
> I have not yet verified if there are other classes where this modification 
> would be relevant too.
> 
> 
> 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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 36
> > 
> >
> > unrelated and not required

Not required indeed, but related in the sense that it removes any ambiguity on 
what method is being called ;)

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 39
> > 
> >
> > QDialogButtonBox::addButton should do correctly anyway, so please don't 
> > workaround things that are not broken.

No, I've looked at Qt 5.5.1 . The only QDialogButtonBox::addButton that "does 
correctly" is the one that takes a StandardButton. I haven't had time to test 
this (will need to rebuild QtBase first) but I'm pretty sure that that method 
creates a button with an icon with its sequence

```
QPushButton *button = new QPushButton(text, this);
d->addButton(button, role);
```

My approach here is to avoid adding an icon if ButtonsHaveIcons is false, or 
remove the icon if one was already added. That's what QDB does with its 
::addButton(StandardButton btn) method (calling a private createButton() 
method). Any other approach is useless without a style supporting and enforcing 
ButtonsHaveIcons, but which such a style KDialogButtonBox doesn't need to be 
fixed in the first place...

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 57
> > 
> >
> > you can completely spare this, there's no reason to manipulate a copy 
> > of the GuiItem, just burns CPU

In that case I'll have to remove the `const` from guiitem, meaning a change to 
the API.

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 70
> > 
> >
> > Setting the icon is sufficient, please do not mess around with other 
> > attributes.

Are you sure? setIcon() doesn't call setIconSize() nor does it reset any size 
information already present. Is it a good idea to replace an icon and leaving 
the size information from the previous icon)? NB: should the icon from the 
KGuiItem override the role's standard icon or should it be the other way round 
(provided icon as a default when the role doesn't provide an icon, for 
instance)?

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 75
> > 
> >
> > this is really the only thing you should need to do here.

Cf. the previous comment about icon priority: this method can provide 2 icons 
that the button will have to chose from.

And I think that it's probably a good idea to set the icon size to 0 when the 
intent is to remove the icon completely.

> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kpushbutton.cpp, line 257
> > 
> >
> > still wrong and again, please don't mess with the icon size - you're 
> > just tempting DIV zero segfaults.

what?? Code that doesn't check integer div 0 should be encouraged to crash. A 
different bug than the one we're addressing here, but not one I have any 
patience with/for.

I could use QSize() instead of QSize(0,0); the former would mean 
iconSize.isValid() will return false while with the latter it'll return true. 
But note that functions like QPushButton::sizeHint() do not check isValid. A 
bit of a conundrum.
Am I right that a button that never had an icon will have `iconSize() == 
QSize()` ?

- René J.V.

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

On Dec. 11, 2015, 3:03 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126308/
> ---
> 
> (Updated Dec. 11, 2015, 3:03 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, Hugo 
> Pereira Da Costa, and Yichao Yu.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> KF5 applications have long had a habit of drawing icons on buttons even when 
> this feature was turned off in the user's setting. This was mostly noticeable 
> in applications built on kdelibs4support.
> 
> It seems that the actual culprit is in Qt's QPushButton implementation 
> (https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
> around it in `KPushButton::paintEvent`, by removing the icon

kwidgetsaddons on OS X: menus become menu items

Hi,

After building kate I'm seeing repeating messages like the ones below on the 
calling terminal, using either Kate or KWrite. This also happens with 
Christoph's bundle(d) build. (I've patched my Qt build to be more informative 
though).

void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu item 
"Clipboard " is already in menu "Edit" , remove it from the other menu 
first before inserting into "Untitled"
void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu item 
"" is already in menu "" , remove it from the other menu first before 
inserting into "Untitled"
virtual void QCocoaMenu::removeMenuItem(QPlatformMenuItem *) Item "Clipboard 
" to remove does not belong to this menu "Untitled"
virtual void QCocoaMenu::removeMenuItem(QPlatformMenuItem *) Item "" 
to remove does not belong to this menu "Untitled"
void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu item 
"Clipboard " is already in menu "Edit" , remove it from the other menu 
first before inserting into "Untitled"
void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu item 
"" is already in menu "" , remove it from the other menu first before 
inserting into "Untitled"
void QCocoaMenu::insertNative(QCocoaMenuItem *, QCocoaMenuItem *) Menu item 
"Clipboard " is already in menu "Edit" after item "" , remove it from 
the other menu first before inserting into "Edit"
virtual void QCocoaMenu::removeMenuItem(QPlatformMenuItem *) Item "Clipboard 
" to remove does not belong to this menu "Untitled"
virtual void QCocoaMenu::removeMenuItem(QPlatformMenuItem *) Item "" 
to remove does not belong to this menu "Untitled"

From what I've been able to gather, this means that the 2 menus in question get 
added to another menu (the Edit menu for "Clipboard History") rather than 
becoming a (toplevel) menu of their own.
Evidently it is too late to figure out why this happens at the time the warning 
is printed.

Qt has long had a "feature" in its menu item handling on OS X where it would 
guess the menuRole from the action text. That feature is intended to let 
certain QActions become "menu items" in the menu that's supposed to hold them 
on OS X, without requiring any action from the developer. So a QAction called 
Preferences, Settings or matching a few other patterns will go into the 
"Application menu" rather than into the menu the application is expecting, and 
be called Preferences.
There is only 1 way around this: call setMenuRole(QAction::NoRole) on each 
QAction before it can be added to a menu, or use the intended MenuRole for 
QActions. 

Either way, I have been trying set QAction::NoRole in a number of places that 
seemed relevant (up to the KActionMenu ctors), to no avail. The "Clipboard 
History" menu is present in the Edit menu where it is actually not out of place 
(and is functional), but the Bookmarks menu is nowhere to be found.

I could use a hand with this. If no better solution can be found I'd prefer 
deactivating the corresponding features (on OS X) rather than getting this 
terminal pollution and possible application instability (I've already seen 
cases where the menus wouldn't open).

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

Re: kwidgetsaddons on OS X: menus become menu items

On Friday December 11 2015 23:55:35 René J.V. Bertin wrote:

KActionMenu being derived from QWidgetAction I wonder if the following blurb 
from the QWidgetAction documentation is relevant here:

OS X: If you add a widget to a menu in the application's menu bar on OS X, the 
widget will be added and it will function but with some limitations:

The widget is reparented away from the QMenu to the native menu view. If you 
show the menu in some other place (e.g. as a popup menu), the widget will not 
be there.


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

lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib

Out of curiosity: is it intended that KFileMetaData sets the library 
compatibility version to 3, leading to

/opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so
/opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so.3
/opt/local/lib/x86_64-linux-gnu/libKF5FileMetaData.so.5.17.0

and on OS X

%> otool -L /opt/local/lib/libKF5FileMetaData.3.dylib
/opt/local/lib/libKF5FileMetaData.3.dylib:
/opt/local/lib/libKF5FileMetaData.3.dylib (compatibility version 3.0.0, 
current version 5.17.0)
/opt/local/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, current 
version 5.17.0)

/opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore 
(compatibility version 5.5.0, current version 5.5.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)

for packaging purposes it would be preferable if all libraries (symlinks) that 
are recorded in dependents' dependency lists are of the form libKF5*.5.dylib or 
libKF5*.so.5 (KFileMetadata is the only deviant one).

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

Re: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib

On Tuesday December 15 2015 18:55:52 René J.V. Bertin wrote:
> for packaging purposes it would be preferable if all libraries (symlinks) 
> that are recorded in dependents' dependency lists are of the form 
> libKF5*.5.dylib or libKF5*.so.5 (KFileMetadata is the only deviant one).

PS : KDE4's kfilemetadata has a compatibility/so version 4 ...

R.

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

Re: system tray test?

René J. V. Bertin wrote:

> Sebastian Kügler wrote:
>> Seems to make sense to me. Could you file a review request for this?
> 
> Ok, will put that on my todo list :)

https://git.reviewboard.kde.org/r/126369/

:)

R.

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

Re: Review Request 126369: [OS X] adaptation(s) to platform limitations (WIP)

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

(Updated Dec. 16, 2015, 10:24 p.m.)

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

Changes
---

A few screenshots, as requested.

Repository: knotifications

Description
---

OS X has a number of limitations in features used by KNotifications, notably
concerning the status notifier item (aka system tray icon).

This RR will likely evolve to address multiple limitations (at least also the
NeedsAttention state); at the moment it only proposes an emulation of
`QMenu::addSection`.

`QMenu::addSection` works by adding a QAction with a "texted separator" at the
insertion location. Texted separators do not exist in menu items in the OS X
"global" menubar (they become regular separators), and Qt will not provide a
platform-specific implementation. Loss of the section title text is maybe not
always an issue, but I think it is in the system tray menu. I therefore propose
to emulate `QMenu::addSection` by replacing the texted separator with an
inactive (disabled) menu item that shows the text, followed by a standard
separator. Menus in the notification area are much less subject to interface
guidelines, so the presence of an item icon is acceptable and IMO useful for
the `titleAction`.

Testing the NeedsAttention state with the tests/kstatusnotifieritemtest
application leads to disappearance of the menubar icon, i.e. the access to the
notifier menu becomes invisible rather than blinking (which is what I get on
Linux using the same packaging). Adding a few qDebug statements shows that the
`attentionIcon` is empty.
I'd appreciate a crash course how this feature is supposed to work, so I can
see if an OS X implementation might be feasible.

Diffs
-

src/kstatusnotifieritem.cpp f9bf460

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

Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.17.0 .

File Attachments (updated)

the systray icon & menu created by kstatusnotifieritemtest . This application
has no icon to show.

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/286037ae-07b3-454a-a226-1748854493a1__kstatusnotifieritemtest-systray.png
The systray icon and menu created by the KDE4 kwalletmanager (code has an
equivalent patch)

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/4fc9d4e4-1537-478c-9196-94cbc17b6b7c__kwalletmanager-systray.png
An Apple systray icon+menu that shows icons (which cannot be hidden)

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fc48a963-2e18-4396-bd38-062d41688118__Apple-systray-menu-with-icons.png

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 126369: [OS X] adaptation(s) to platform limitations (WIP)

> On Dec. 16, 2015, 5:40 p.m., Martin Klapetek wrote:
> > src/kstatusnotifieritem.cpp, line 710
> > 
> >
> > Why is it reasonable if the platform guidelines speak against it?

The platform guidelines apply to regular application menus and displaying an 
icon that corresponds to the item action; but even there they are guidelines. 
They shouldn't be mistaken for hard rules.
Menus in the notification area often show other kinds of widgets, use different 
font/weights or even provide a window that contains a view on a website. 
There's a utility that shows the mobile version of one's FB or G+ account - and 
that little gimmick is available through the App Store. Meaning Apple vetted 
it; they in fact show icons themselves in the input selection menu.

The reason why I find it useful to show the `app->windowIcon()` here is because 
often the systray icon and menu are the only interface an application provides. 
It is thus good to show the information the user is used to seeing when 
identifying applications; Finder, Dock and App Switcher all show the 
application icon plus the application name.

Any other items in the systray menu ought to be subject to the ShowIconsInMenus 
preference which is supposed to be false by default. (With "ought to be" I mean 
that I don't see anything in the code suggesting they'll behave otherwise.)

- René J.V.

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

On Dec. 15, 2015, 8:44 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126369/
> ---
> 
> (Updated Dec. 15, 2015, 8:44 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> OS X has a number of limitations in features used by KNotifications, notably 
> concerning the status notifier item (aka system tray icon).
> 
> This RR will likely evolve to address multiple limitations (at least also the 
> NeedsAttention state); at the moment it only proposes an emulation of 
> `QMenu::addSection`.
> 
> `QMenu::addSection` works by adding a QAction with a "texted separator" at 
> the insertion location. Texted separators do not exist in menu items in the 
> OS X "global" menubar (they become regular separators), and Qt will not 
> provide a platform-specific implementation. Loss of the section title text is 
> maybe not always an issue, but I think it is in the system tray menu. I 
> therefore propose to emulate `QMenu::addSection` by replacing the texted 
> separator with an inactive (disabled) menu item that shows the text, followed 
> by a standard separator. Menus in the notification area are much less subject 
> to interface guidelines, so the presence of an item icon is acceptable and 
> IMO useful for the `titleAction`.
> 
> Testing the NeedsAttention state with the tests/kstatusnotifieritemtest 
> application leads to disappearance of the menubar icon, i.e. the access to 
> the notifier menu becomes invisible rather than blinking (which is what I get 
> on Linux using the same packaging). Adding a few qDebug statements shows that 
> the `attentionIcon` is empty.
> I'd appreciate a crash course how this feature is supposed to work, so I can 
> see if an OS X implementation might be feasible.
> 
> 
> Diffs
> -
> 
>   src/kstatusnotifieritem.cpp f9bf460 
> 
> Diff: https://git.reviewboard.kde.org/r/126369/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.17.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: lib/x86_64-linux-gnu/libKF5FileMetaData.so | lib/libKF5FileMetaData.3.dylib

šumski wrote:

>> Fixed, it was an oversight when converting the lib into a KF5 framework.
> 
> But this is a BiC change...

Yes, bug fixes can do that ;)

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

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.
> 
> René J.V. Bertin wrote:
> 1: why should one care? It is said nowhere that the setting defined as 
> "show icons on buttons" in `systemsettings(5)` applies only to dialogs. 
> Rather, the tooltip says "when this is enabled, KDE applications will show 
> icons alongside [sic!] some important buttons".
> In other words, when "this" is *not* enabled, there should be no icons, 
> period.
> I have found no sign in the code that the ShowIconsOnPushButtons hint is 
> to be used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed 
> carries the suggestion in its name but I would not be surprised if Qt really 
> thinks of it in a more general sense. Probably also because the notion of 
> what a dialog is has become a lot vaguer.
> 
> And that also happens to be what Qt does; buttons show their icons on 
> Linux (and other Unix variants?) but on OS X or MS Windows displaying of 
> those icons is deactivated unless you use a style that enables it. In fact, 
> the default setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except 
> in the generic Unix theme (= it does work globally like 
> `AA_DontShowIconsInMenus` everywhere else).
> 
> 2: a user who indicates s/he doesn't want to see icons will get an empty 
> button. That's also what can happen with QPushButton, and app developers have 
> to take this into consideration. Cf. toolbars (and Qt's position on the use 
> of "texted separators").
> I don't think I've ever come across a standard button showing only an 
> icon, except possibly the arrow button next to the progress indicators in 
> KMail and KDevelop.
> 
> As to fixing it here: as it turns out, "here" is the main source for 
> annoying icons rearing their silly heads on buttons on my screen ;) and it 
> was also something of a challenge to understand why they kept appearing 
> despite the fact that all code appeared to return the value of 
> `ShowIconsOnPushButtons`. Deprecated or not, it doesn't look like all 
> applications are going to stop using it anytime soon.
> 
> I looked into fixing the issue in KDialogButtonBox but saw that it does 
> nothing to override the `ShowIconsOnPushButtons` setting. The only way to 
> respect the setting through that class (or a modern equivalent) would be to 
> set an empty icon if `ShowIconsOnPushButtons=false`. That introduces another 
> regression: changes in this setting are supposed to be reflected by running 
> applications without requiring a restart (or a recreation of dialogs). If it 
> were just me I'd decree that buttons can have either text or an icon, but 
> right now we have to make do with this mixed situation.
> 
> I don't mind making this an OS X (and MS Windows) specific modification, 
> of course, but on those platforms
> 
> Thomas Lübking wrote:
> > 1: why should one care?
> 
> Because, as explained, that is what the hint says. Nothing else.
> 
> > I have found no sign in the code that the ShowIconsOnPushButtons hint 
> is to be used only for dialogs
> 
> No, but it's been used to feed SH_DialogButtonBox_ButtonsHaveIcons *AND* 
> KPushButton.
> ShowIconsOnPushButtons implied SH_DialogButtonBox_ButtonsHaveIcons but 
> NOT vv.
> 
> The approach is wrong, since you're abusing the hint for generalisation.
> 
> > but on OS X or MS Windows
> 
> ... Qt uses native elements which might simply globally downforce the 
> pushbutton icon nonsense (as could any style - I was more than once close to 
> doing that in virtuality)
> Eg. Breeze might do that on favor of the HIG, but that's not relevant 
> here.
> 
> Downforcing in KPushButton means to

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)



> On Dec. 14, 2015, 7:53 a.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > this introduces a QtWidgets dependency and thus changes the integration 
> > level of the framework. I highly recommend to not go this way.
> > 
> > Looking at the code there is no reason for this. The usage of 
> > QDesktopWidget is not needed as QScreen provides the same. Similar one 
> > doesn't need the QWidget usage as QWindow is already there.
> 
> René J.V. Bertin wrote:
> I'm all for reducing the number of dependencies, but haven't found 
> another way to get at QWidget::saveGeometry and QWidget::restoreGeometry.
> You're probably much more familiar with what those functions really save 
> and restore, and thus to what extent they're essentially convenience 
> functions here for something I could just as well access via 
> QWindow::geometry or QWindow::frameGeometry. I'd have to figure out on my end 
> which of the two I'd need to use because that'd be specific to OS X (knowing 
> there is no QWindow::setFrameGeometry). I won't be able to test that on MS 
> Windows though.
> 
> What integration level are you invoking? This dependency doesn't make 
> kconfig a Tier 2 framework, does it? Is it so bad to add a dependency on 
> Qt5Widgets to something that already depends on Qt5Gui?
> 
> A more fundamental question would be why this is in KConfig. One could 
> argue that window size (and position) are not application configuration 
> parameters when they're saved automatically; they're a reflection of 
> application interface state (@). Maybe a subtle difference (and maybe a 
> debate that was already held a long time ago), but doesn't this rather (or 
> better) belong in KWindowSystem?
> 
> @) Off-topic, but like other state variables saved automatically it might 
> even be wise to save them in a separate file so it's easier to reset state 
> without doing a full "factory reset".
> 
> Boudhayan Gupta wrote:
> In Qt5, a dependency on QtWidgets is the difference between having to use 
> a QGuiApplication (without) and QApplication (with). QtWidgets is a 20MB or 
> so dependency, so in terms of library load times at runtime the difference is 
> somewhat significant.

I'm sensitive to that kind of argument. Interesting btw; my OS X QtWidgets 
library is 8.6Mb (which should include debug info), but on Linux using the same 
script for installing Qt it is 97Mb (!). So there is indeed some reason to 
introduce the extra dependency only on platforms where it's needed, if it's 
needed.

But (something I cannot NOT ask in this context) : just how many applications 
are there that present a user interface without any need for QtWidgets in any 
of their dependencies?


- René J.V.


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


On Dec. 13, 2015, 2:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 13, 2015, 2:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e.

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme



> On Dec. 14, 2015, 7:56 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.cpp, line 45
> > 
> >
> > this looks like a not needed debug statement, same in dtor and 
> > loadSettings and KFontSettings

Evidently, sorry for that; they'll be gone in the next revision.

You're right: I added those statements chasing a bug that turned up to be 
upstream.


- René J.V.


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


On Dec. 12, 2015, 7:08 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. 12, 2015, 7:08 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
> -
> 
>   src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
>   src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
>   src/platformtheme/CMakeLists.txt 23f590e 
>   src/platformtheme/kdemactheme.h PRE-CREATION 
>   src/platformtheme/kdemactheme.mm PRE-CREATION 
>   src/platformtheme/kdeplatformtheme.h 97d09df 
>   src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
>   src/platformtheme/kfontsettingsdata.h 4b92c7d 
>   src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
>   src/platformtheme/khintssettings.h ec064d3 
>   src/platformtheme/khintssettings.cpp 8adf6c5 
>   src/platformtheme/khintssettingsmac.h PRE-CREATION 
>   src/platformtheme/khintssettingsmac.mm PRE-CREATION 
>   src/platformtheme/main_mac.cpp PRE-CREATION 
> 
> Diff:

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)


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

(Updated Dec. 14, 2015, 5:04 p.m.)


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


Changes
---

Version taking the various issues into account.
I've reimplemented the (IMHO) relevant bits of QWidget::saveGeometry and 
QWidget::restoreGeometry as a class, in hope it might be reusable.

This works to satisfaction on OS X, and hopefully will do so on MS Windows too.

Restoring window size *and* position without a dedicated function that handles 
both aspects is often tricky (and platform dependent). QWidget::restoreGeometry 
is much more complex and it is well possible that is better capable to handle 
all possible interactions between size and position. I suppose time will tell.


Repository: kconfig


Description
---

In KDElibs4, the KMainWindow::saveWindowSize() and 
KMainWindow::restoreWindowSize() function saved and restored not only the size 
but also the position (i.e. the geometry) of windows, using 
QWidget::saveGeometry and QWidget::restoreGeometry.

2 main reasons for this (according to the comments):
- Under X11 restoring the position is tricky
- X11 has a window manager which might be considered responsible for that 
functionality (and I suppose most modern WMs have the feature enabled by 
default?)

Both arguments are moot on MS Windows and OS X, and on both platforms users 
expect to see window positions restored as well as window size. On OS X there 
is also little choice in the matter: most applications offer the geometry 
restore without asking (IIRC it is the same on MS Windows).

I would thus like to propose to port the platform-specific code that existed 
for MS Windows (and for OS X as a MacPorts patch that apparently was never 
submitted upstreams). I realise that this violates the message conveyed by the 
function names but I would like to think that this is a case where function is 
more important.

You may also notice that the Mac version does not store resolution-specific 
settings. This happens to work best on OS X, where multi-screen support has 
been present since the early nineties, and where window geometry is restored 
regardless of the screen resolution (i.e. connect a different external screen 
with a different resolution, and windows will reopen as they were on that 
screen, not with some default geometry).
I required I can update the comments in the header to reflect this subtlety.

Note that for optimal functionality a companion patch to `KMainWindow::event` 
is required:
```
--- a/src/kmainwindow.cpp
+++ b/src/kmainwindow.cpp
@@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
 {
 K_D(KMainWindow);
 switch (ev->type()) {
-#ifdef Q_OS_WIN
+#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
 case QEvent::Move:
 #endif
 case QEvent::Resize:
```

This ensures that the window geometry save is performed also after a move (to 
update the position) without requiring a dummy resizing operation.
Do I need to create a separate RR for this change or is it small enough that I 
can push it if and when this RR is accepted?


Diffs (updated)
-

  src/gui/kwindowconfig.h 48a8f3c 
  src/gui/kwindowconfig.cpp d2f355c 

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


Testing
---

On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 5.5.1 
and frameworks 5.16.0 (and Kate as a test application).
I presume that the MS Windows code has been tested sufficiently in KDELibs4; I 
have only adapted it to Qt5 and tested if it builds.


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 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)



> On Dec. 14, 2015, 12:47 p.m., Marco Martin wrote:
> > src/gui/CMakeLists.txt, line 22
> > 
> >
> > we really can't add a dependency to QWidgets here.
> > depending on qwidgets will make many potential interested project not 
> > able to use it
> 
> Alex Richardson wrote:
> Also shouldn't all that information be available using QScreen/QWindow? 
> It doesn't seem to save much: 
> http://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwidget.cpp.html#_ZNK7QWidget12saveGeometryEv

Are you more or less inviting me to "clone" QWidget::saveGeometry? It *does* do 
more than simply saving frame position and window size (I have a working 
prototype that saves and restores just that, but I guess you'd want me to 
include maximised state and what else?)


- René J.V.


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


On Dec. 13, 2015, 2:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 13, 2015, 2:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that 
> I can push it if and when this RR is accepted?
> 
> 
> Diffs
> -
> 
>   src/gui/CMakeLists.txt 9663e09 
>   src/gui/kwindowconfig.h 48a8f3c 
>   src/gui/kwindowconfig.cpp d2f355c 
> 
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 
> 5.5.1 and frameworks 5.16.0 (and Kate as a test application).
> I presume that the MS Windows code has been tested sufficiently in KDELibs4; 
> I have only adapted it to Qt5 and tested if it builds.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

about ki18n/locales: installing only a subset?

Hi,

The KDE4 approach to internationalisation (sic :)) had the huge advantage that 
it was rather trivial to provide installer packages for individual languages so 
users could install only those few languages they would actually use.
It seems that with KF5 we have gotten back in the situation where you get every 
possible language installed. Now that may be nice for the occasional office 
prank, but it'll end up amounting to a significant disk overhead (the one that 
comes with lots of small files) for something that has absolutely no use for 
the vast majority of users.

Is there some central mechanism to control which languages are installed? 
Looking at KF5I18NMacros it would seem that there's only an external "central 
mechanism"; binning the unwanted files before building...

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

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> >

For the record: I've raised a few interrogations that are preventing me from 
following up and addressing the open issues raised by Thomas.


- René J.V.


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


On Dec. 11, 2015, 5:26 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126308/
> ---
> 
> (Updated Dec. 11, 2015, 5:26 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, Hugo 
> Pereira Da Costa, and Yichao Yu.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> KF5 applications have long had a habit of drawing icons on buttons even when 
> this feature was turned off in the user's setting. This was mostly noticeable 
> in applications built on kdelibs4support.
> 
> It seems that the actual culprit is in Qt's QPushButton implementation 
> (https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
> around it in `KPushButton::paintEvent`, by removing the icon (forcing it to 
> the null icon) in the option instance, before handing off control to the 
> painter.
> 
> 
> Diffs
> -
> 
>   src/kdeui/kdialogbuttonbox.cpp 0f6649b 
>   src/kdeui/kpushbutton.cpp 98534fa 
> 
> Diff: https://git.reviewboard.kde.org/r/126308/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .
> 
> I have not yet verified if there are other classes where this modification 
> would be relevant too.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

"Buttons have icons", round N+1

Hi,

There has been some discussion around one of my RRs concerning how to respect 
KDE's ShowIconsOnPushButtons and Qt's SH_DialogButtonBox_ButtonsHaveIcons style 
hint.

The ultimate way would be in the style that does the actual drawing, but that 
is probably not the one with the smallest overhead.

Until now this discussion focussed on kdelibs4support, but I just learned that 
e.g. KMessageBox can also show buttons that have icons despite 
ShowIconsOnPushButtons being false. This happens for instance in the dialog 
Kate puts up when asked to close a file with unsaved changes.

The dialog in question is a KMessageBox with a few KStandardGuiItems.
In a comparable situation, Qt's own code simply doesn't add the standard icons 
to the buttons being created, when SH_DialogButtonBox_ButtonsHaveIcons is false.

KMessageBox isn't a QDialogButtonBox, but shouldn't it do the same? Would it be 
acceptable to remove the icon in the appropriate KStandardGuiItem methods, or 
even in KGuiItem, when SH_DialogButtonBox_ButtonsHaveIcons is false, or 
(rather) when ShowIconsOnPushButtons is false?

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

Re: "Buttons have icons", round N+1

On Sunday December 13 2015 17:14:17 Thomas Lübking wrote:

> I object the overhead concern. The global solution is easily applied by the 
> style (the icon isn't loaded from disk or rendered until you/the style 
> requires a pixmap from painting - until then there's just a string that hints 
> which icon to use)

Maybe, but the style will have to query the hint every time, whereas querying 
the style before (not) adding the icon is an overhead that happens only when a 
button is created. Whether that's a measurable overhead is another thing, of 
course.

> 
> So this is as well orthogonal to the general Pushbutton 
> icon/ShowIconsOnPushButtons question (but simply a bug that needs to be fixed)

Not exactly orthogonal according how I understand the definition of that term. 
You claimed that ShowIconsOnPushButtons is supposed to apply to all buttons 
(and that's the interpretation I'd prefer). In that case, it should override 
Qt's SH_DialogButtonBox_ButtonsHaveIcons when that variable is true. Otherwise 
you end up in a situation where a style can override ShowIconsOnPushButtons 
(which is the "interface" users have to toggle icons in buttons).

Actually, I think a KDE style can query KDE's own ShowIconsOnPushButtons, and 
skip drawing icons an all buttons when that setting is off. That's the idea 
behind the setting, after all -- and given how the setting is exposed (in 
systemsettings), that is definitely the interpretation users will give it.

> It might seem reasonable to query the parent widget of the button in KGuiItem 
> to catch a variety of occasions at once (though this doesn't guarantee 
> anything, parent and style would have to be tracked to make this "perfect" or 
> QPushButton would check its parent widget on painting and conditionally omit 
> the icon when it's a buttonbox and the style doesn't want icons there)

I don't follow this. If respecting the hint (or hints) via KGuiItem is 
reasonable, let's begin by drawing up a list of all situations where a KGuiItem 
should NOT omit the icon despite either of the related hints being false.

I continue to think that there is nothing inherently wrong with KDE giving a 
broader application to a Qt parameter for KDE purposes, as long as it's 
documented somewhere.

You'll also have to consider the fact (IMHO) that every now and then someone 
will create something that is essentially a QDialogButtonBox but that doesn't 
use that class. Sure, just blindly applying the rules you can reject any bug 
reports about how those buttons fail to respect user choice in the matter as 
"works as intended/expected". And that's where ShowIconsOnPushButtons comes in 
again...

In short, is there any reason why KDE would use the 
SH_DialogButtonBox_ButtonsHaveIcons hint, if that hint reflects 
ShowIconsOnButtons?

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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)


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

(Updated Dec. 13, 2015, 2:54 p.m.)


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


Changes
---

A minor change that supports the QPA-dependency of the contents of 
QWidget.saveGeometry(). A small nod to the fact that Qt (still) supports 
multiple QPA plugins on OS X.


Repository: kconfig


Description
---

In KDElibs4, the KMainWindow::saveWindowSize() and 
KMainWindow::restoreWindowSize() function saved and restored not only the size 
but also the position (i.e. the geometry) of windows, using 
QWidget::saveGeometry and QWidget::restoreGeometry.

2 main reasons for this (according to the comments):
- Under X11 restoring the position is tricky
- X11 has a window manager which might be considered responsible for that 
functionality (and I suppose most modern WMs have the feature enabled by 
default?)

Both arguments are moot on MS Windows and OS X, and on both platforms users 
expect to see window positions restored as well as window size. On OS X there 
is also little choice in the matter: most applications offer the geometry 
restore without asking (IIRC it is the same on MS Windows).

I would thus like to propose to port the platform-specific code that existed 
for MS Windows (and for OS X as a MacPorts patch that apparently was never 
submitted upstreams). I realise that this violates the message conveyed by the 
function names but I would like to think that this is a case where function is 
more important.

You may also notice that the Mac version does not store resolution-specific 
settings. This happens to work best on OS X, where multi-screen support has 
been present since the early nineties, and where window geometry is restored 
regardless of the screen resolution (i.e. connect a different external screen 
with a different resolution, and windows will reopen as they were on that 
screen, not with some default geometry).
I required I can update the comments in the header to reflect this subtlety.

Note that for optimal functionality a companion patch to `KMainWindow::event` 
is required:
```
--- a/src/kmainwindow.cpp
+++ b/src/kmainwindow.cpp
@@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
 {
 K_D(KMainWindow);
 switch (ev->type()) {
-#ifdef Q_OS_WIN
+#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
 case QEvent::Move:
 #endif
 case QEvent::Resize:
```

This ensures that the window geometry save is performed also after a move (to 
update the position) without requiring a dummy resizing operation.
Do I need to create a separate RR for this change or is it small enough that I 
can push it if and when this RR is accepted?


Diffs (updated)
-

  src/gui/CMakeLists.txt 9663e09 
  src/gui/kwindowconfig.h 48a8f3c 
  src/gui/kwindowconfig.cpp d2f355c 

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


Testing
---

On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 5.5.1 
and frameworks 5.16.0 (and Kate as a test application).
I presume that the MS Windows code has been tested sufficiently in KDELibs4; I 
have only adapted it to Qt5 and tested if it builds.


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 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 39
> > 
> >
> > QDialogButtonBox::addButton should do correctly anyway, so please don't 
> > workaround things that are not broken.
> 
> René J.V. Bertin wrote:
> No, I've looked at Qt 5.5.1 . The only QDialogButtonBox::addButton that 
> "does correctly" is the one that takes a StandardButton. I haven't had time 
> to test this (will need to rebuild QtBase first) but I'm pretty sure that 
> that method creates a button with an icon with its sequence
> 
> ```
> QPushButton *button = new QPushButton(text, this);
> d->addButton(button, role);
> ```
> 
> My approach here is to avoid adding an icon if ButtonsHaveIcons is false, 
> or remove the icon if one was already added. That's what QDB does with its 
> ::addButton(StandardButton btn) method (calling a private createButton() 
> method). Any other approach is useless without a style supporting and 
> enforcing ButtonsHaveIcons, but which such a style KDialogButtonBox doesn't 
> need to be fixed in the first place...
> 
> Thomas Lübking wrote:
> ::addButton(text, role) creates "new QPushButton(text, this)" - those 
> should seriously not have any icons.
> 
> > whith such a style KDialogButtonBox doesn't need to be fixed in the 
> first place
> 
> If it's broken, it needs to be fixed - you cannot bail out with "the 
> style is correcting that for us" (I've been fixing far too many kdelibs/qtgui 
> bugs in the style ;-)

> ::addButton(text, role) creates "new QPushButton(text, this)" - those should 
> seriously not have any icons.

Agreed, they shouldn't *show* any if the user doesn't want to see them. AFAIC 
they can have a whole bunch of icons as long as they're not displayed. 

This argument is a bit useless as long as we don't know if an interface should 
stop showing icons the moment the user unticks the corresponding setting in 
systemsettings (and start showing them again when the setting is ticked). If 
it's ok to tell the user that "the new setting will only be respected after an 
application restart", then fine, let's simply not add icons when they're not 
wanted. In all those countless places where the setting will have to be applied.

But didn't you point out yourself that the style is in the best position to 
avoid drawing any unwanted icons?


> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 57
> > 
> >
> > you can completely spare this, there's no reason to manipulate a copy 
> > of the GuiItem, just burns CPU
> 
> René J.V. Bertin wrote:
> In that case I'll have to remove the `const` from guiitem, meaning a 
> change to the API.
> 
> Thomas Lübking wrote:
> No, you do not touch the KGuiItem that comes (it's not yours!) and it's 
> pointless to create a copy, strip the icon from that, assign it to the button 
> (and maybe even strip the icon from the button) - you just apply the GuiItem 
> that enters and strip the icon from the button. The interim (deep) GuiItem 
> copy is just detour in the path to remove the icon from the button.

I must be getting on with other real-life stuff now; I agree with not touching 
the incoming item of course. I'll see if there isn't a way to avoid adding the 
unwanted icon at all, to avoid the icon deep copy as well (probably the most 
expensive part of a GuiItem deep copy, no?)


> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 61
> > 
> >
> > unrelated and it won't leak, since the cleanup is done by the 
> > parent/child relation ("this" passed to KPushButton)
> 
> René J.V. Bertin wrote:
> Maybe it won't leak, but the question remains why what buttons with an 
> invalid role are good for.
> 
> Thomas Lübking wrote:
> Did you see such role being used? It would be a client code bug (the 
> symbol is juts for completeness sake, so that you can eg. assign it to a 
> role, pipe that to some transformation functions, check whether it's still 
> invalid and then react to that)

No, I haven't seen such a role (and client code bug, agreed on that). I did see 
however that there is no trivial way to check for it; you apparently have to 
look at the role before adding the button, or else query the KDialogButtonBox 
if it owns the button (if that's even possible).


> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 70
> > 
> >
> > Setting the icon is sufficient, please do not mess around with other 
> > attributes.
> 
> René J.V. Bertin wrote:
> Are you sure? setIcon() doesn't call

Re: kwidgetsaddons on OS X: menus become menu items

2015-12-12 Thread René J . V . Bertin

René J.V. Bertin wrote:

> The widget is reparented away from the QMenu to the native menu view. If you
> show the menu in some other place (e.g. as a popup menu), the widget will not
> be there.

Actually I think this part *is* related: I noticed that the Bookmarks menu is 
supposed to appear also in the context menu of the main editor view.

R.

___
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

2015-12-12 Thread René J . V . Bertin



> On Dec. 7, 2015, 5:41 p.m., René J.V. Bertin wrote:
> > So with the current implementation that uses inheritance, there are 2 
> > classes that have a `delayedDBusConnects` method which uses 
> > `QDBusConnection::sessionBus().connect()` to register things on the DBus. 
> > Both invoke that method explicitly from their ctor, and in general, with 
> > the inheritance/overriding going on I think I might be over-initialising 
> > certain things. I have modified the 2 `loadSettings` methods so that they 
> > only create new instances when `m_fontsData==0` (initialised in the 
> > respective ctors), so that should limit the redundancy.
> > 
> > Still I wonder if this isn't going to lead to DBus name conflicts (if the 
> > DBus connect method doesn't disconnect/reconnect)?
> > 
> > I also wonder if the crash-on-exit I just discovered in `kdebugdialog5` 
> > (but not in what few example KF5 applications I have at the moment) is 
> > related:
> > 
> > ```
> > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> > 0   org.qt-project.QtDBus   0x00010355f9b6 QHashNode > QDBusConnectionPrivate::SignalHook>::~QHashNode() + 166 
> > (qgenericatomic.h:90)
> > 1   org.qt-project.QtCore   0x0001045b89b9 
> > QHashData::free_helper(void (*)(QHashData::Node*)) + 73 (qhash.cpp:405)
> > 2   org.qt-project.QtDBus   0x0001035531a8 
> > QDBusConnectionPrivate::~QDBusConnectionPrivate() + 712 (qhash.h:342)
> > 3   org.qt-project.QtDBus   0x0001035535ce 
> > QDBusConnectionPrivate::~QDBusConnectionPrivate() + 14 
> > (qdbusintegrator.cpp:1035)
> > 4   org.qt-project.QtDBus   0x00010354baf8 (anonymous 
> > namespace)::Q_QGS__q_sessionBus::innerFunction()::Cleanup::~Cleanup() + 152 
> > (qdbusconnection.cpp:1079)
> > 5   libsystem_c.dylib   0x7fff89e5d7a1 __cxa_finalize + 177
> > ```
> > 
> > When I add some trace statements at relevant locations, I see this on the 
> > calling terminal:
> > ```
> > > kdebugdialog5
> > QCoreApplication::arguments: Please instantiate the QApplication object 
> > first
> > QDBusConnection: session D-Bus connection created before QCoreApplication. 
> > Application may misbehave.
> > KdePlatformTheme::KdePlatformTheme() 0x7fe420e0e2b0
> > KdePlatformTheme::loadSettings() 0x7fe420e0e2b0
> > KFontSettingsData::KFontSettingsData() KFontSettingsData(0x7fe420e15bc0)
> > KHintsSettings::KHintsSettings() KHintsSettings(0x7fe420e15690)
> > KdeMacTheme::KdeMacTheme() 0x7fe420e0e2b0
> > KdeMacTheme::loadSettings() 0x7fe420e0e2b0
> > KFontSettingsData::KFontSettingsData() KFontSettingsData(0x7fe420c94dc0)
> > KFontSettingsDataMac::KFontSettingsDataMac() 
> > KFontSettingsDataMac(0x7fe420c94dc0)
> > KHintsSettings::KHintsSettings() KHintsSettings(0x7fe420e2f110)
> > KHintsSettingsMac::KHintsSettingsMac() KHintsSettingsMac(0x7fe420e2f110)
> > KdeMacTheme::createPlatformSystemTrayIcon() 0x7fe420e0e2b0
> > KFontSettingsData::delayedDBusConnects() KFontSettingsData(0x7fe420e15bc0)
> > KFontSettingsData::delayedDBusConnects() 
> > KFontSettingsDataMac(0x7fe420c94dc0)
> > KFontSettingsDataMac::delayedDBusConnects() 
> > KFontSettingsDataMac(0x7fe420c94dc0)
> > KdeMacTheme::~KdeMacTheme() 0x7fe420e0e2b0
> > KdePlatformTheme::~KdePlatformTheme() 0x7fe420e0e2b0
> > KFontSettingsData::~KFontSettingsData() KFontSettingsData(0x7fe420e15bc0)
> > KHintsSettings::~KHintsSettings() KHintsSettings(0x7fe420e15690)
> > Segmentation fault
> > Exit 139
> > ```
> > 
> > the non-crashes don't call `KdeMacTheme::createPlatformSystemTrayIcon()`, 
> > so even if `kdebugdialog5` doesn't actually put up a systray icon/menu 
> > there must be some relation between that call and the crash.
> > I'd hope this is just a bug in `kdebugdialog5`, but it doesn't express 
> > itself when I don't use the KdePlatformTheme (`KdeMacTheme`)...

That crash turns out completely unrelated, but caused by the fact Qt still 
unloads plugins at exit. An upstream patch is being evaluated that stops that 
from happening, and after applying it I no longer see any crashing.


- René J.V.


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


On Dec. 7, 2015, 5:43 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. 7, 2015, 5:43 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 
>

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

2015-12-12 Thread René J . V . Bertin


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

(Updated Dec. 12, 2015, 7:08 p.m.)


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


Changes
---

I've finally gotten around to building Kate, and wanted to show some 
comparisons, alas not completely working to my advantage.


For some reason, Christoph Cullman's own standalone app bundle build puts up an 
interface that has less glitches than the purely native interface I get when I 
deactivate (move aside) the frameworkintegration port with its KdeMacTheme 
plugin. The glitches I see with my own build are very much like what we used to 
see in KDE4/MacPorts. MacPorts never patched Qt's Mac platform theme, and Qt4 
had no QStandardPaths that we could (had to) patch. So what I'm seeing in my 
kate5 build is unlikely to be a direct result of using XDG compliant paths on 
OS X. Maybe the fact that those XDG compliant paths do contain all kinds of 
stuff that's not present in the standalone app bundle has something to do with 
it.
BTW, note that my build is an app bundle too, except that it contains only the 
strictly necessary files (executable, info dict and app icon).
Sadly for me, using the macintosh style with the KdeMacTheme plugin does not 
fix all the glitches though it does make the interface look less 
overdimensioned.

I hesitated to add a snap of kate running under X11 (with the macintosh style) 
but didn't to avoid confusion. However, it could have served to underline one 
tidbit that I didn't know myself until very recently:

> QWidgets (and QML) don't use native UI views. They draw everything themself. 
> The drawing is done in the style.

In other words, there is no native NSButton "behind" a QPushButton, no NSTabBar 
behind a QTabBar, etc. The mac style undoubtedly uses APIs that exist only on 
OS X to draw "everything", but it'll happily draw onto an X11 window (and 
create an almost identical result). This probably explains in part why we're 
seeing the glitches we're seeing, but as far as I'm concerned it also gives the 
native style less of a "it's native and thus better" status.


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

kdebugdialog5 crashing on exit (FYI)

Hi,

I mentioned having crashes on exit with kdebugdialog5 a couple of days ago, 
deep 
in Qt territory. At first I thought the culprit was my implementation of a 
"KdeMacPlatformTheme" that inherits from the regular KdePlatformTheme.

Then I noticed that kdebugdialog5 also crashes on exit on Linux, when the 
KdePlatformTheme isn't present but the app is started with --fullmode (and does 
the same on OS X with the native platform theme).

Thiago Macieira referred me to a proposed change to refrain from unloading 
plugins (https://codereview.qt-project.org/#/c/140750/) and I can report that 
applying the patch indeed solves the issue for me (on OS X).

R.

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

Re: Review Request 126369: [OS X] adaptation(s) to platform limitations (WIP)


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


Well, it isn't exactly easy, but I remembered that KMail can badge the system 
tray icon with the number of read messages. Adapted to KNotifications (no extra 
dependencies except for Qt5::MacExtras for the -optional?- app icon badging) 
that gives 

``` C++
void KStatusNotifierItemPrivate::syncLegacySystemTrayIcon()
{
if (status == KStatusNotifierItem::NeedsAttention) {
#ifdef Q_OS_OSX
QtMac::setBadgeLabelText(QStringLiteral("!"));
if (attentionIconName.isNull() && attentionIcon.isNull()) {
// code adapted from kmail's KMSystemTray::updateCount()
int overlaySize = 22;
QIcon attnIcon = qApp->windowIcon();
if (!attnIcon.availableSizes().isEmpty()) {
overlaySize = attnIcon.availableSizes().at(0).width();
}
QFont labelFont = 
QFontDatabase::systemFont(QFontDatabase::GeneralFont);
labelFont.setBold(true);
QFontMetrics qfm(labelFont);
float attnHeight = overlaySize * 0.667;
if (qfm.height() > attnHeight) {
float labelSize = attnHeight;
labelFont.setPointSizeF(labelSize);
}
// Paint the label in a pixmap
QPixmap overlayPixmap(overlaySize, overlaySize);
overlayPixmap.fill(Qt::transparent);

QPainter p();
p.setFont(labelFont);
p.setBrush(Qt::NoBrush);
// this sort of badge/label is red on OS X
p.setPen(QColor(224,0,0));
p.setOpacity(1.0);
// use U+2022, the Unicode bullet
p.drawText(overlayPixmap.rect(), Qt::AlignRight|Qt::AlignTop, 
QStringLiteral("•"));
p.end();

QPixmap iconPixmap = attnIcon.pixmap(overlaySize, overlaySize);
QPainter pp();
pp.drawPixmap(0, 0, overlayPixmap);
pp.end();
systemTrayIcon->setIcon(iconPixmap);
} else
#endif
{
if (!movieName.isNull()) {
if (!movie) {
movie = new QMovie(movieName);
}
systemTrayIcon->setMovie(movie);
} else if (!attentionIconName.isNull()) {
systemTrayIcon->setIcon(QIcon::fromTheme(attentionIconName));
} else {
systemTrayIcon->setIcon(attentionIcon);
}
}
} else {
if (!iconName.isNull()) {
systemTrayIcon->setIcon(QIcon::fromTheme(iconName));
} else {
systemTrayIcon->setIcon(icon);
}
#ifdef Q_OS_OSX
QtMac::setBadgeLabelText(QString());
#endif
}

systemTrayIcon->setToolTip(toolTipTitle);
}
```

- René J.V. Bertin


On Dec. 17, 2015, 12:40 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126369/
> ---
> 
> (Updated Dec. 17, 2015, 12:40 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> OS X has a number of limitations in features used by KNotifications, notably 
> concerning the status notifier item (aka system tray icon).
> 
> This RR will likely evolve to address multiple limitations (at least also the 
> NeedsAttention state); at the moment it only proposes an emulation of 
> `QMenu::addSection`.
> 
> `QMenu::addSection` works by adding a QAction with a "texted separator" at 
> the insertion location. Texted separators do not exist in menu items in the 
> OS X "global" menubar (they become regular separators), and Qt will not 
> provide a platform-specific implementation. Loss of the section title text is 
> maybe not always an issue, but I think it is in the system tray menu. I 
> therefore propose to emulate `QMenu::addSection` by replacing the texted 
> separator with an inactive (disabled) menu item that shows the text, followed 
> by a standard separator. Menus in the notification area are much less subject 
> to interface guidelines, so the presence of an item icon is acceptable and 
> IMO useful for the `titleAction`.
> 
> Testing the NeedsAttention state with the tests/kstatusnotifieritemtest 
> application leads to disappearance of the menubar icon, i.e. the access to 
> the notifier menu becomes invisible rather than blinking (which is what I get 
> on Linux using the same packaging). Adding a few qDebug statements shows that 
> the `attentionIcon` is empty.
> I'd appreciate a crash course how this feature is supposed to work, so I can 
> see if an OS X implementation might be feasible.
> 
> 
> Diffs
>

Re: Review Request 126369: [OS X] adaptation(s) to platform limitations (WIP)

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

(Updated Dec. 17, 2015, 3 p.m.)

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

Changes
---

preview of the effects of the code snippet from my previous post.

I just realised that OS X also provides a completely different mechanism that
could be used for a status notifier, albeit *only in "foreground" applications*
(i.e. with full GUI presence). It's possible to add a menu to the Dock icon,
and Qt provides a hook for that. The NeedsAttention state can then be achieved
by the native mechanism that lets the Dock icon bounce (would require using
ObjC though). Theoretically it's possible to change the dock icon at runtime
but I see no real need for that. I'll have a look how well the "systray" menu
works under a Dock icon.

Repository: knotifications

Description
---

OS X has a number of limitations in features used by KNotifications, notably
concerning the status notifier item (aka system tray icon).

This RR will likely evolve to address multiple limitations (at least also the
NeedsAttention state); at the moment it only proposes an emulation of
`QMenu::addSection`.

Diffs
-

src/kstatusnotifieritem.cpp f9bf460

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

Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.17.0 .

File Attachments (updated)

the systray icon & menu created by kstatusnotifieritemtest . This application
has no icon to show.

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/4fc9d4e4-1537-478c-9196-94cbc17b6b7c__kwalletmanager-systray.png
An Apple systray icon+menu that shows icons (which cannot be hidden)

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fc48a963-2e18-4396-bd38-062d41688118__Apple-systray-menu-with-icons.png
kstatusnotifieritemtest with added appIcon

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/17/e896e90d-f0a8-43f7-9199-847572832df7__kstatusnotifieritemtest-with-appIcon.png
kstatusnotifieritemtest-with-appIcon+attention.png

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/17/f41081db-8e09-4ea2-95c1-f507c62109d4__kstatusnotifieritemtest-with-appIconattention.png

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 126369: [OS X] adaptation(s) to platform limitations (WIP)

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

(Updated Dec. 17, 2015, 5:26 p.m.)

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

Changes
---

I've been working on this some more.

In addition to badging the systray icon with a NeedsAttention label, I've also
- worked around the absence of tool tip subtitles
- worked around notification messages getting lost. Since OS X 10.8,
QSystemTrayIcon::showMessage() hooks into the native notification centre, which
behaves a lot like how notifications work on a Linux/KDE(4) desktop. On earlier
OS X versions Growl is used directly.
Messages relayed through the DBus get lost. Is that because Growl is supposed
to handle them, and I don't have that utility installed? If so, I'd suggest
dropping the indirection through DBus, on OS X.

Repository: knotifications

Description
---

OS X has a number of limitations in features used by KNotifications, notably
concerning the status notifier item (aka system tray icon).

This RR will likely evolve to address multiple limitations (at least also the
NeedsAttention state); at the moment it only proposes an emulation of
`QMenu::addSection`.

Diffs (updated)
-

CMakeLists.txt 6d09051
src/CMakeLists.txt 7eb3125
src/kstatusnotifieritem.cpp f9bf460
tests/kstatusnotifieritemtest.cpp 973fc85

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

Testing
---

On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.17.0 .

File Attachments

the systray icon & menu created by kstatusnotifieritemtest . This application
has no icon to show.

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/4fc9d4e4-1537-478c-9196-94cbc17b6b7c__kwalletmanager-systray.png
An Apple systray icon+menu that shows icons (which cannot be hidden)

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/16/fc48a963-2e18-4396-bd38-062d41688118__Apple-systray-menu-with-icons.png
kstatusnotifieritemtest with added appIcon

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/17/e896e90d-f0a8-43f7-9199-847572832df7__kstatusnotifieritemtest-with-appIcon.png
kstatusnotifieritemtest-with-appIcon+attention.png

https://git.reviewboard.kde.org/media/uploaded/files/2015/12/17/f41081db-8e09-4ea2-95c1-f507c62109d4__kstatusnotifieritemtest-with-appIconattention.png

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


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

(Updated Dec. 17, 2015, 7:40 p.m.)


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


Changes
---

this removes the qDebug() statements, and a few cleanups.

Can I presume that the `QDBusConnection::sessionBus.connect()` call 
`re`connects if a previous connection was already made with identical arguments 
except for sender and/or receiver?


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/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/CMakeLists.txt 23f590e 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettings.cpp 8adf6c5 
  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

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)



> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.

I was afraid someone was going to say that, which is why I tried to argue that 
it's highly unexpected from a user viewpoint that only window size is saved and 
not position. How often would it happen that a developer is "highly surprised" 
in a *negative* way that window size AND position are restored on a platform 
where this is the default behaviour?

I have nothing against introducing a pair of new methods, but how is that 
supposed to be done in transparent fashion? I do have a lot against a need to 
change all dependent software to call those methods (maintenance burden and all 
that).

Counter proposal: replace save/restoreWindowSize with 
save/restoreWindowGeometry everywhere, with a platform-specific interpretation 
of what exactly geometry encompasses. Much less surprise there, just a bit more 
need to read the documentation. Are these functions ever called intentionally 
outside of what I suppose is a more or less automatic feature that takes care 
of restoring window, erm, layout (saving is clearly automatic).


- René J.V.


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


On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 5:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that 
> I can push it if and when this RR is accepted?
> 
> 
> Diffs
> -
> 
>   src/gui/kwindowconfig.h 48a8f3c 
>   src/gui/kwindowconfig.cpp d2f355c 
> 
> Diff: https://git.reviewboard.kde.org/r/126324/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6 through 10.9 with various KDElibs4 versions and now with Qt 
> 5.5.1 and frameworks 5.16.0 (and Kate as a test application).
> I presume that the MS Windows code has been tested sufficiently in KDELibs4; 
> I have only adapted it

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)



> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).

Just to be clear: if I am going to introduce restore/saveWindowGeometry methods 
they'll replace the WindowSize variants on OS X or at least those will then use 
a different KConfig key to avoid conflicts. 
I'd also be dropping the MS Windows part of the patch (as this is not a 
decision I want to make for a platform I don't use).

But please consider this: that KConfig key has been called `geometry` for a 
long time. Where exactly is the surprise, that restore/saveWindowSize never did 
what the key they operate with suggests, or that they have always been using an 
inaptly named key? For me the answer is straightforward and based on what users 
will expect...


- René J.V.


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


On Dec. 14, 2015, 5:04 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 14, 2015, 5:04 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing



> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> >
> 
> René J.V. Bertin wrote:
> For the record: I've raised a few interrogations that are preventing me 
> from following up and addressing the open issues raised by Thomas.

I'm stepping out, patching icons out of buttons elsewhere but in the style no 
longer has any urgency for me. 

A final word of advice: try to get the Qt devs to indicate what they really 
intend with `SH_DialogButtonBox_ButtonsHaveIcons` : the end result on the 
screen (i.e. ButtonsShowIcons) or the result at the code/data level (i.e. 
ButtonsHaveIconMemberVariablesThatAreNotNull). If the former, there's no bug to 
patch (except in the style).


> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 39
> > 
> >
> > QDialogButtonBox::addButton should do correctly anyway, so please don't 
> > workaround things that are not broken.
> 
> René J.V. Bertin wrote:
> No, I've looked at Qt 5.5.1 . The only QDialogButtonBox::addButton that 
> "does correctly" is the one that takes a StandardButton. I haven't had time 
> to test this (will need to rebuild QtBase first) but I'm pretty sure that 
> that method creates a button with an icon with its sequence
> 
> ```
> QPushButton *button = new QPushButton(text, this);
> d->addButton(button, role);
> ```
> 
> My approach here is to avoid adding an icon if ButtonsHaveIcons is false, 
> or remove the icon if one was already added. That's what QDB does with its 
> ::addButton(StandardButton btn) method (calling a private createButton() 
> method). Any other approach is useless without a style supporting and 
> enforcing ButtonsHaveIcons, but which such a style KDialogButtonBox doesn't 
> need to be fixed in the first place...
> 
> Thomas Lübking wrote:
> ::addButton(text, role) creates "new QPushButton(text, this)" - those 
> should seriously not have any icons.
> 
> > whith such a style KDialogButtonBox doesn't need to be fixed in the 
> first place
> 
> If it's broken, it needs to be fixed - you cannot bail out with "the 
> style is correcting that for us" (I've been fixing far too many kdelibs/qtgui 
> bugs in the style ;-)
> 
> René J.V. Bertin wrote:
> > ::addButton(text, role) creates "new QPushButton(text, this)" - those 
> should seriously not have any icons.
> 
> Agreed, they shouldn't *show* any if the user doesn't want to see them. 
> AFAIC they can have a whole bunch of icons as long as they're not displayed. 
> 
> This argument is a bit useless as long as we don't know if an interface 
> should stop showing icons the moment the user unticks the corresponding 
> setting in systemsettings (and start showing them again when the setting is 
> ticked). If it's ok to tell the user that "the new setting will only be 
> respected after an application restart", then fine, let's simply not add 
> icons when they're not wanted. In all those countless places where the 
> setting will have to be applied.
> 
> But didn't you point out yourself that the style is in the best position 
> to avoid drawing any unwanted icons?
> 
> Thomas Lübking wrote:
> If you create a PushButton with this constructor, the button has at this 
> point no icon assigned. This has absolutely nothing to do with some setting 
> or the display of anything - where should the button have obtained an icon? 
> None is set here in the first place. QPushButton::icon().isNull()

Yes, apparently my assumption was wrong. It beats me where that icon gets set 
then, and how it'll be possible ultimately to prevent one from getting set. I'm 
going to hand this one back to you - I've solved my personal icon gripe in the 
style I use so as far as I'm concerned there is no longer a bug here O:-)


> On Dec. 11, 2015, 2:55 p.m., Thomas Lübking wrote:
> > src/kdeui/kdialogbuttonbox.cpp, line 70
> > 
> >
> > Setting the icon is sufficient, please do not mess around with other 
> > attributes.
> 
> René J.V. Bertin wrote:
> Are you sure? setIcon() doesn't call setIconSize() nor does it reset any 
> size information already present. Is it a good idea to replace an icon and 
> leaving the size information from the previous icon)? NB: should the icon 
> from the KGuiItem override the role's standard icon or should it be the other 
> way round (provided icon as a default when the role doesn't provide an icon, 
> for instance)?
> 
> Thomas Lübking wrote:
> setIcon *shall* not setIconSize, the two values are completely 
> orhtogonal. Dropping the size information will just get you into trouble when 
> you should require it again.
> If eg. a style would reserve icon space of iconSize despite there 
> actually is no icon to paint, the style is simply broken.
> 
> The icon size refers

Re: Review Request 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)

> On Dec. 17, 2015, 5:16 p.m., Martin Gräßlin wrote:
> > src/gui/kwindowconfig.h, lines 38-39
> > 
> >
> > That doesn't match the method name. It's saveWindowSize, not 
> > saveWindowGeometry. It's highly unexpected that saveWindowSize saves the 
> > position.
> > 
> > If you want that: please introduce a new saveWindowGeometry method.
> 
> René J.V. Bertin wrote:
> I was afraid someone was going to say that, which is why I tried to argue 
> that it's highly unexpected from a user viewpoint that only window size is 
> saved and not position. How often would it happen that a developer is "highly 
> surprised" in a *negative* way that window size AND position are restored on 
> a platform where this is the default behaviour?
> 
> I have nothing against introducing a pair of new methods, but how is that 
> supposed to be done in transparent fashion? I do have a lot against a need to 
> change all dependent software to call those methods (maintenance burden and 
> all that).
> 
> Counter proposal: replace save/restoreWindowSize with 
> save/restoreWindowGeometry everywhere, with a platform-specific 
> interpretation of what exactly geometry encompasses. Much less surprise 
> there, just a bit more need to read the documentation. Are these functions 
> ever called intentionally outside of what I suppose is a more or less 
> automatic feature that takes care of restoring window, erm, layout (saving is 
> clearly automatic).
> 
> René J.V. Bertin wrote:
> Just to be clear: if I am going to introduce restore/saveWindowGeometry 
> methods they'll replace the WindowSize variants on OS X or at least those 
> will then use a different KConfig key to avoid conflicts. 
> I'd also be dropping the MS Windows part of the patch (as this is not a 
> decision I want to make for a platform I don't use).
> 
> But please consider this: that KConfig key has been called `geometry` for 
> a long time. Where exactly is the surprise, that restore/saveWindowSize never 
> did what the key they operate with suggests, or that they have always been 
> using an inaptly named key? For me the answer is straightforward and based on 
> what users will expect...
> 
> Martin Gräßlin wrote:
> I leave it to the maintainers. On API I maintain I would say no to 
> something changing the semantics like that.

As I just wrote in reply to a message from Valorie, I have absolutely no issue 
with maintaining methods for saving and restoring only window size, for code 
that somehow requires that. I'd guess that such code would probably enforce the 
intended window position itself *after* restoring window size (because that 
operation *can* affect window position), but in the end that's (indeed) up to 
the code's developers to decide.

IOW, I'm perfectly willing to discuss a better solution in which the burden to 
ensure that window save/restore works as "natively" as possible on each 
platform is shared. The best way to do that is of course to have a single pair 
of methods that have platform-specific implementations.

As far as I'm concerned such a solution might even be prepared completely in 
KConfig/gui before changes are made everywhere else to deploy that new 
solution. In that case I would for instance run temporary local (MacPorts) 
patches that replace saveWindowSize/restoreWindowSize with wrappers for 
saveWindowGeometry/restoreWindowGeometry.

Side-observation: OS X (Cocoa) provides a `[NSWindow setFrameAutosaveName:]` 
method, i.e. it avoids reference to specifics like size or geometry completely.

That method also provides another thought that could be taken into 
consideration if it is decided to evolve this part of the frameworks, something 
I'd be interested in collaborating on. Currently, there is no support for 
saving and restoring multiple windows per application. That may be more or less 
sufficient when applications always follow a MDI approach, but even if they do 
that still doesn't make them applications that are active only in a single 
instance. Example: KDevelop. One might expect that opening a given, 
pre-existing session (collection of open projects) restores the main window 
geometry (size and/or position) that used previously for that session, rather 
than the geometry used by whatever KDevelop session was run last. On OS X that 
would be done with something like `[NSWindow setFrameautosaveName:[window 
representedFile]]`, where `[NSWindow representedFile]` corresponds to 
`QWindow::filePath` (but AFAICS those are not coupled in Qt5).

I already had a quick look, but realised I don't know if the KConfig mechanism 
has facilities to handle cleanup of stale/obsolete key/value entries.

- René J.V.

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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme



> On Dec. 18, 2015, 8:11 a.m., Martin Gräßlin wrote:
> > I still want to see other OSX devs comment on that this is really the 
> > wanted approach. Also I need to point out that the split out of QPT to 
> > plasma-integration is prepared. I suggest to introduce a comparable 
> > osx-integration repository.

I have nothing against that, if done centrally. It could host/provide other 
things to, if set up appropriately. Maybe a better name would be inspired on 
Qt's MacExtras, X11Extras etc. (though arguably those are about improving 
integration).

KDE-Mac is CC'ed on each and every OS X related RR I file; from what I hear 
through the KDE-Mac ML their silence indicates general approval. You are of 
course not expected to take my word on this, but I do understand you have had 
some feedback from some of them concerning my contributions. And I think that 
includes the reality that I am currently basically the only active "OS X dev".

I'm aware that I'm in an uncomfortable position, working alone for and in name 
of a community the extent of which I don't even know. It's something that makes 
me wonder regularly why I'm doing it at all. I suppose that creating an 
osx-integration framework will make the lack of opinions from other "OSX devs" 
a bit more our internal affair rather than something affecting all of KF5?


> On Dec. 18, 2015, 8:11 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.cpp, lines 45-46
> > 
> >
> > Q_NULLPTR

I recall a relatively recent discussion on a Qt mailing list; IIUC Qt now 
advises to use `0` and not Q_NULLPTR anymore. It certainly makes the code more 
compact and (thus) readable; is there a reason KF5 sticks to Q_NULLPTR?


- René J.V.


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


On Dec. 17, 2015, 7:40 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. 17, 2015, 7:40 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

Re: about ki18n/locales: installing only a subset?

On Friday December 18 2015 10:53:35 Chusslove Illich wrote:

>I'm not talking about offices requiring it. I'm talking about coming to a
>random office in the world and finding my language already available,
>without trifling anyone about it.

Out of curiosity: do you expect to use your language when communicating with 
people instead of computers, in any random office in the world? ;)

>> You haven't read (or understood) my argument, which is about how blocks
>> are used, not how many.
>
>I read it, but apparently I didn't understand it. Would you explain it
>further, or point me to an explanation?

In traditional disk/file system technology, files use an integer number of 
blocks, and blocks aren't shared among files. I am not aware that has changed 
with SSDs, but block sizes have increased. They used to be 512 bytes, which is 
a size that is small enough that the actual on-disk size for each file will 
never be more than 511 bytes larger than necessary. With 4096 byte blocks that 
potential waste grows to 4095 bytes, about 8x more.
Disclaimer: this is what *I* understand of the underlying functioning. I am not 
always right in my understanding of things.

As I said, I don't want to make a huge point of this. I'm perfectly aware that 
we're not in a situation like the last time I cleaned unwanted languages 
(.lproj directories) from OS X and freed up hundreds of Mbs from my boot 
partition. And in that case we were talking about absolute disk space waste :)

R
___
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



> On Dec. 18, 2015, 8:11 a.m., Martin Gräßlin wrote:
> > src/platformtheme/kdeplatformtheme.cpp, lines 45-46
> > 
> >
> > Q_NULLPTR
> 
> René J.V. Bertin wrote:
> I recall a relatively recent discussion on a Qt mailing list; IIUC Qt now 
> advises to use `0` and not Q_NULLPTR anymore. It certainly makes the code 
> more compact and (thus) readable; is there a reason KF5 sticks to Q_NULLPTR?
> 
> Aleix Pol Gonzalez wrote:
> I don't see where you got that impression:
> 
> http://lists.qt-project.org/pipermail/development/2015-December/024040.html

Is that your idea of *relatively* recent? :) I was thinking of a discussion a 
bit longer ago (but frankly, don't ask me to dig it up, I doubt I'd be able to).

I haven't read the full thread above, in fact I stopped reading at 
```
Arguments against:
- it's uglier than "0", and more to type
```

because that sums up exactly how I think about the question. But in the end I 
only care that there are no chances of 32bit/64bit conflicts (I had some of 
those in code of my own, which led me to be almost religious about using NULL 
for pointers).

I do have a bit of an issue with using a *Q_* prefix, as it suggests a 
Qt-specific type that should only be used in calls to Qt functions...


- René J.V.


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


On Dec. 17, 2015, 7:40 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. 17, 2015, 7:40 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 
>

Re: about ki18n/locales: installing only a subset?

On Wednesday December 16 2015 14:18:33 Jaroslaw Staniek wrote:
> How about bundling the files in qrc containers, one per language to address
> the issue of many tiny files?

Agreed (and a priori already raised in a previous message).

> That reminds me similar case of icon files.

Indeed. And the docbooks/documentation (which could presumably be converted to 
Qt's compiled format?).

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

Re: about ki18n/locales: installing only a subset?

On Wednesday December 16 2015 11:48:58 David Faure wrote:

> They are copied into the frameworks at release time. So you can also grab 
> them from
> svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5 directly (warning, this is huge)

Ah, good! Svn is a bit of a hog indeed, but IIRC it does make it easier to grab 
only a subset (supposing the repository is organised by language and not by 
package).

> See release-tools/update_l10n.sh for the script I use to fetch only the 
> frameworks translations
> in all languages (rather than all translations and all docbooks for all apps 
> in all languages)

What I forgot to raise earlier was a more general question. If interface 
translation is handled through a dedicated framework, wouldn't it be possible 
to install the translation files in a well-optimised container? Even with a 
single container per framework/application/whatever you'd still ought to get 
significantly more efficient disk usage. Not just re: file size in bytes vs. 
blocks but I think also on modern COW filesystems like ZFS and btrfs (and 
filesystem level compression should perform better too).

As I said, this is something about which *I* tend to be principled :)

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

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 11:11 p.m., Thomas Lübking wrote:
> > 1. What tells you that this is a dialog buttonbox pushbutton?
> > 2. What happens if the button has no text?
> > 
> > 
> > The bug is in QDialogButtonBox (or rather the K variant, 
> > QDialogButtonBoxPrivate::createButton() seems to incorporate the hint 
> > correctly)
> > 
> > 
> > [KDE] has "ShowIconsOnPushButtons=false" in kdeglobals which was 
> > interpreted by KPushButton _and_ kstyle for the hint, but the hint only 
> > covers Q'DialogButtonBox'es - there's simply no global rule for this like 
> > AA_DontShowIconsInMenus
> > 
> > => KDialogButtonBox shall respect the hint for its buttons (there're two 
> > special creation routines).
> > 
> > For the rest, the platform plugin ideally picks the kdeglobals setting and 
> > exports it to the application object (dyn property?) where the style can 
> > pick it and incorporate it into its calculations (ie. if no icons are 
> > wanted and there's text or arrow, omit the icon in size calculation and 
> > painting)
> > 
> > "Fixing" that in deprecated KPushButton doesn't really fix anything. We'll 
> > face the mix we had, just that users of QPushButton were far less prone to 
> > pass them an icon in pre-KF5 times.
> > 
> > Please also attach Hugo Pereira Da Costa.

1: why should one care? It is said nowhere that the setting defined as "show 
icons on buttons" in `systemsettings(5)` applies only to dialogs. Rather, the 
tooltip says "when this is enabled, KDE applications will show icons alongside 
[sic!] some important buttons".
In other words, when "this" is *not* enabled, there should be no icons, period.
I have found no sign in the code that the ShowIconsOnPushButtons hint is to be 
used only for dialogs; `SH_DialogButtonBox_ButtonsHaveIcons` indeed carries the 
suggestion in its name but I would not be surprised if Qt really thinks of it 
in a more general sense. Probably also because the notion of what a dialog is 
has become a lot vaguer.

And that also happens to be what Qt does; buttons show their icons on Linux 
(and other Unix variants?) but on OS X or MS Windows displaying of those icons 
is deactivated unless you use a style that enables it. In fact, the default 
setting for `SH_DialogButtonBox_ButtonsHaveIcons` is false except in the 
generic Unix theme (= it does work globally like `AA_DontShowIconsInMenus` 
everywhere else).

2: a user who indicates s/he doesn't want to see icons will get an empty 
button. That's also what can happen with QPushButton, and app developers have 
to take this into consideration. Cf. toolbars (and Qt's position on the use of 
"texted separators").
I don't think I've ever come across a standard button showing only an icon, 
except possibly the arrow button next to the progress indicators in KMail and 
KDevelop.

As to fixing it here: as it turns out, "here" is the main source for annoying 
icons rearing their silly heads on buttons on my screen ;) and it was also 
something of a challenge to understand why they kept appearing despite the fact 
that all code appeared to return the value of `ShowIconsOnPushButtons`. 
Deprecated or not, it doesn't look like all applications are going to stop 
using it anytime soon.

I looked into fixing the issue in KDialogButtonBox but saw that it does nothing 
to override the `ShowIconsOnPushButtons` setting. The only way to respect the 
setting through that class (or a modern equivalent) would be to set an empty 
icon if `ShowIconsOnPushButtons=false`. That introduces another regression: 
changes in this setting are supposed to be reflected by running applications 
without requiring a restart (or a recreation of dialogs). If it were just me 
I'd decree that buttons can have either text or an icon, but right now we have 
to make do with this mixed situation.

I don't mind making this an OS X (and MS Windows) specific modification, of 
course, but on those platforms

- René J.V.

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

On Dec. 10, 2015, 11:12 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126308/
> ---
> 
> (Updated Dec. 10, 2015, 11:12 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, and Hugo 
> Pereira Da Costa.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> KF5 applications have long had a habit of drawing icons on buttons even when 
> this feature was turned off in the user's setting. This was mostly noticeable 
> in applications built on kdelibs4support.
> 
> It seems that the actual culprit is in Qt's QPushButton implementation 
>

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing


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

(Updated Dec. 10, 2015, 11:54 p.m.)


Review request for KDE Software on Mac OS X, KDE Frameworks, Qt KDE, and Hugo 
Pereira Da Costa.


Changes
---

Easy enough to avoid empty buttons!


Repository: kdelibs4support


Description
---

KF5 applications have long had a habit of drawing icons on buttons even when 
this feature was turned off in the user's setting. This was mostly noticeable 
in applications built on kdelibs4support.

It seems that the actual culprit is in Qt's QPushButton implementation 
(https://bugreports.qt.io/browse/QTBUG-49887), but it is possible to work 
around it in `KPushButton::paintEvent`, by removing the icon (forcing it to the 
null icon) in the option instance, before handing off control to the painter.


Diffs (updated)
-

  src/kdeui/kpushbutton.cpp 98534fa 

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


Testing
---

On Kubuntu 14.04 and OS X 10.9.5 with Qt 5.5.1 and KF5 frameworks 5.16.0 .

I have not yet verified if there are other classes where this modification 
would be relevant too.


Thanks,

René J.V. Bertin

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

Review Request 126304: (re)enable building with -DQTC_QT5_ENABLE_KDE


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

Review request for KDE Frameworks, Qt KDE and Yichao Yu.


Repository: qtcurve


Description
---

As the title says, this restores the definition of QTC_QT5_ENABLE_KDE in the 
CMake file when a KF5 build is done, and introduces the changes required for 
that build to succeed.

Except for removing references to the m_componentData member (already removed 
from the class; deprecated type) I have not made any other changes to the code.


Diffs
-

  qt5/CMakeLists.txt 837d9c2 
  qt5/style/CMakeLists.txt 7f65f8c 
  qt5/style/qtcurve.cpp febcfcf 
  qt5/style/qtcurve_api.cpp 87a927f 
  qt5/style/qtcurve_p.h bfc7502 
  qt5/style/qtcurve_primitive.cpp b5a3204 

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


Testing
---

On KUbuntu 14.04 and Mac OS X 10.9.5, both with Qt 5.5.1 and KF5 Frameworks 
5.16.0 installed under /opt/local


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 126324: [MSWin/OS X] save and restore window geometry instead of only size (WIP/Suggestion)



> On Dec. 14, 2015, 7:53 a.m., Martin Gräßlin wrote:
> > src/gui/CMakeLists.txt, line 2
> > 
> >
> > this introduces a QtWidgets dependency and thus changes the integration 
> > level of the framework. I highly recommend to not go this way.
> > 
> > Looking at the code there is no reason for this. The usage of 
> > QDesktopWidget is not needed as QScreen provides the same. Similar one 
> > doesn't need the QWidget usage as QWindow is already there.

I'm all for reducing the number of dependencies, but haven't found another way 
to get at QWidget::saveGeometry and QWidget::restoreGeometry.
You're probably much more familiar with what those functions really save and 
restore, and thus to what extent they're essentially convenience functions here 
for something I could just as well access via QWindow::geometry or 
QWindow::frameGeometry. I'd have to figure out on my end which of the two I'd 
need to use because that'd be specific to OS X (knowing there is no 
QWindow::setFrameGeometry). I won't be able to test that on MS Windows though.

What integration level are you invoking? This dependency doesn't make kconfig a 
Tier 2 framework, does it? Is it so bad to add a dependency on Qt5Widgets to 
something that already depends on Qt5Gui?

A more fundamental question would be why this is in KConfig. One could argue 
that window size (and position) are not application configuration parameters 
when they're saved automatically; they're a reflection of application interface 
state (@). Maybe a subtle difference (and maybe a debate that was already held 
a long time ago), but doesn't this rather (or better) belong in KWindowSystem?

@) Off-topic, but like other state variables saved automatically it might even 
be wise to save them in a separate file so it's easier to reset state without 
doing a full "factory reset".


- René J.V.


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


On Dec. 13, 2015, 2:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126324/
> ---
> 
> (Updated Dec. 13, 2015, 2:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> In KDElibs4, the KMainWindow::saveWindowSize() and 
> KMainWindow::restoreWindowSize() function saved and restored not only the 
> size but also the position (i.e. the geometry) of windows, using 
> QWidget::saveGeometry and QWidget::restoreGeometry.
> 
> 2 main reasons for this (according to the comments):
> - Under X11 restoring the position is tricky
> - X11 has a window manager which might be considered responsible for that 
> functionality (and I suppose most modern WMs have the feature enabled by 
> default?)
> 
> Both arguments are moot on MS Windows and OS X, and on both platforms users 
> expect to see window positions restored as well as window size. On OS X there 
> is also little choice in the matter: most applications offer the geometry 
> restore without asking (IIRC it is the same on MS Windows).
> 
> I would thus like to propose to port the platform-specific code that existed 
> for MS Windows (and for OS X as a MacPorts patch that apparently was never 
> submitted upstreams). I realise that this violates the message conveyed by 
> the function names but I would like to think that this is a case where 
> function is more important.
> 
> You may also notice that the Mac version does not store resolution-specific 
> settings. This happens to work best on OS X, where multi-screen support has 
> been present since the early nineties, and where window geometry is restored 
> regardless of the screen resolution (i.e. connect a different external screen 
> with a different resolution, and windows will reopen as they were on that 
> screen, not with some default geometry).
> I required I can update the comments in the header to reflect this subtlety.
> 
> Note that for optimal functionality a companion patch to `KMainWindow::event` 
> is required:
> ```
> --- a/src/kmainwindow.cpp
> +++ b/src/kmainwindow.cpp
> @@ -772,7 +772,7 @@ bool KMainWindow::event(QEvent *ev)
>  {
>  K_D(KMainWindow);
>  switch (ev->type()) {
> -#ifdef Q_OS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_OS_OSX)
>  case QEvent::Move:
>  #endif
>  case QEvent::Resize:
> ```
> 
> This ensures that the window geometry save is performed also after a move (to 
> update the position) without requiring a dummy resizing operation.
> Do I need to create a separate RR for this change or is it small enough that 
> I can push it if

Re: system tray test?