date:20151216


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


I just want to say thanks for keeping at this - I feel kinda bad about the 
sheer number of changes I'm throwing at you! If you want to make me do some of 
the work, you can create a feature branch and point me at it, but I'm hoping 
this review is setting you up for an easy ride if you want to contribute 
something else to e-c-m in the future.

- Alex Merry


On Dec. 16, 2015, 12:25 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 16, 2015, 12:25 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDEPackageAppTemplates.cmake PRE-CREATION 
>   tests/CMakeLists.txt 1a66f56 
>   tests/KDEPackageAppTemplatesTest/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/Messages.sh PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/README PRE-CREATION 
>   
> tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/images/pairs.svgz
>  PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/ui/main.qml 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/metadata.desktop 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.kdevtemplate 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.png PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/run_test.cmake.config PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global



On Dec. 16, 2015, 7:14 p.m., Marco Martin wrote:
> > You might want to generate the documentation and look at it (you need the 
> > Sphinx documentation tool installed, then you just build 
> > extra-cmake-modules, and look in docs/html in the build directory).

In particular, you'll need to add a link file in docs/kde-module.


- Alex


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


On Dec. 16, 2015, 12:25 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 16, 2015, 12:25 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDEPackageAppTemplates.cmake PRE-CREATION 
>   tests/CMakeLists.txt 1a66f56 
>   tests/KDEPackageAppTemplatesTest/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/Messages.sh PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/README PRE-CREATION 
>   
> tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/images/pairs.svgz
>  PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/ui/main.qml 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/metadata.desktop 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.kdevtemplate 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.png PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/run_test.cmake.config PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global


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



kde-modules/KDEPackageAppTemplates.cmake (line 10)


Frameworks has a capital F.



kde-modules/KDEPackageAppTemplates.cmake (line 14)


Signature is still wrong.



kde-modules/KDEPackageAppTemplates.cmake (lines 16 - 37)


None of this should be indented.

Beware of how Sphinx formats your list of placeholders, though. Consider 
doing the list in the same way as KDEInstallDirs.cmake lists its variables.



kde-modules/KDEPackageAppTemplates.cmake (line 20)


"as if it was", instead of "as it was"?



kde-modules/KDEPackageAppTemplates.cmake (line 22)


missing closing parenthesis )?


You might want to generate the documentation and look at it (you need the 
Sphinx documentation tool installed, then you just build extra-cmake-modules, 
and look in docs/html in the build directory).

- Alex Merry


On Dec. 16, 2015, 12:25 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 16, 2015, 12:25 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDEPackageAppTemplates.cmake PRE-CREATION 
>   tests/CMakeLists.txt 1a66f56 
>   tests/KDEPackageAppTemplatesTest/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/Messages.sh PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/README PRE-CREATION 
>   
> tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/images/pairs.svgz
>  PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/ui/main.qml 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/metadata.desktop 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.kdevtemplate 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.png PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/run_test.cmake.config PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: Review Request 126185: Make the KAppTemplate CMake module global



> On Dec. 12, 2015, 3:40 p.m., Alex Merry wrote:
> > Ooh, also, please write a unit test. I can help with that if you find the 
> > idea of writing a CMake-based unit test daunting, but you can look in the 
> > tests directory for inspiration.
> 
> Marco Martin wrote:
> I'm not sure what the test should do...
> perhaps having in the repo a tarball and a source template, make it 
> generate and then compare the files?
> 
> Alex Merry wrote:
> Yes, that would work. Or you could have a source template, and check the 
> installed file can be extracted and check the extracted contents. Don't 
> forget to make sure that files you think should be excluded are in fact 
> omitted.
> 
> Marco Martin wrote:
> if i try to use kde_add_app_templates from a run_test.cmake i get the 
> message KDETemplateGenerator.cmake:97 (add_custom_target):
>   Command add_custom_target() is not scriptable
>   any idea what it could be?

Ah, you'll need to do a project-style test. See ECMPoQmToolsTest, or 
ECMInstallIconsTest. The idea is you create a CMakeLists.txt file as though it 
were a project using this module, and make, say, a check_tree.cmake script to 
check that the right things were installed in the right places. Lines 124-131 
of tests/CMakeLists.txt are what run ECMInstallIconsTest.


- Alex


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


On Dec. 16, 2015, 12:25 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 16, 2015, 12:25 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDEPackageAppTemplates.cmake PRE-CREATION 
>   tests/CMakeLists.txt 1a66f56 
>   tests/KDEPackageAppTemplatesTest/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/CMakeLists.txt PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/Messages.sh PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/README PRE-CREATION 
>   
> tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/images/pairs.svgz
>  PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/ui/main.qml 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/metadata.desktop 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.kdevtemplate 
> PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.png PRE-CREATION 
>   tests/KDEPackageAppTemplatesTest/run_test.cmake.config PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

2015-12-16 Thread Martin Klapetek



> 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?
> 
> René J.V. Bertin wrote:
> 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.)

I think a shorter version of this^ should be in the code instead of that 
comment ;)


- Martin


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


On Dec. 16, 2015, 10:24 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. 16, 2015, 10:24 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 .
> 
> 
> 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/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

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: Review Request 126330: use generate_export_header


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

(Updated Dec. 16, 2015, 11:35 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit cb8b690b571a35fc9431c8c16ad165dde747878b by Patrick R. 
Spendrin to branch master.


Repository: kdeclarative


Description
---

The old file, which seems to be a leftover was still used, even though
generate_export_header was present.


Diffs
-

  src/calendarevents/CMakeLists.txt 6c2aae34556136b70c0f092fc921745d6e313eda 
  src/calendarevents/calendarevents_export.h 
a4c6f87e62c02a4ed34d0ebff00e0a729357952f 

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


Testing
---

Windows.


Thanks,

Patrick Spendrin

___
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 126185: Make the KAppTemplate CMake module global

2015-12-16 Thread Marco Martin



> On Dec. 12, 2015, 3:40 p.m., Alex Merry wrote:
> > Ooh, also, please write a unit test. I can help with that if you find the 
> > idea of writing a CMake-based unit test daunting, but you can look in the 
> > tests directory for inspiration.
> 
> Marco Martin wrote:
> I'm not sure what the test should do...
> perhaps having in the repo a tarball and a source template, make it 
> generate and then compare the files?
> 
> Alex Merry wrote:
> Yes, that would work. Or you could have a source template, and check the 
> installed file can be extracted and check the extracted contents. Don't 
> forget to make sure that files you think should be excluded are in fact 
> omitted.

if i try to use kde_add_app_templates from a run_test.cmake i get the message 
KDETemplateGenerator.cmake:97 (add_custom_target):
  Command add_custom_target() is not scriptable
  any idea what it could be?


- Marco


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


On Dec. 15, 2015, 10:38 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126185/
> ---
> 
> (Updated Dec. 15, 2015, 10:38 a.m.)
> 
> 
> Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
> and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> templates are very useful as teaching tool in order to make
> a minimal application that uses a certain framework.
> templates in the KAppTemplate repository will always get forgotten
> (plus kapptemplate is not really necessary as they work in kdevelop as well)
> An ideal situation would be frameworks having templates in their own repos
> with templates of barebone apps using the main framework features.
> In order to do that, the cmake stuff needed in order to correctly install
> a template needs to be ported to a place avaiable to all frameworks
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEInstallDirs.cmake b7cd34d 
>   kde-modules/KDETemplateGenerator.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126185/diff/
> 
> 
> Testing
> ---
> 
> done some templates installed by plasma-framework
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
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 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: Review Request 126185: Make the KAppTemplate CMake module global

2015-12-16 Thread Marco Martin


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

(Updated Dec. 16, 2015, 12:25 p.m.)


Review request for Build System, KDE Frameworks, Plasma, Aleix Pol Gonzalez, 
and Simon Wächter.


Changes
---

rename done, stuck on the failing test


Repository: extra-cmake-modules


Description
---

templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks


Diffs (updated)
-

  kde-modules/KDEInstallDirs.cmake b7cd34d 
  kde-modules/KDEPackageAppTemplates.cmake PRE-CREATION 
  tests/CMakeLists.txt 1a66f56 
  tests/KDEPackageAppTemplatesTest/CMakeLists.txt PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/CMakeLists.txt PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/Messages.sh PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/README PRE-CREATION 
  
tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/images/pairs.svgz
 PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/contents/ui/main.qml 
PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/package/metadata.desktop 
PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.kdevtemplate 
PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/qml-plasmoid/qml-plasmoid.png PRE-CREATION 
  tests/KDEPackageAppTemplatesTest/run_test.cmake.config PRE-CREATION 

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


Testing
---

done some templates installed by plasma-framework


Thanks,

Marco Martin

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

Review Request 126384: better description of qmlmodule cmake module

2015-12-16 Thread Jonathan Riddell


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

Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: purpose


Description
---

don't say it's failed as a description, just say what it's looking for.  
currently it says it's failed even when it's found what it needs


Diffs
-

  src/plugins/cmake/FindQMLModule.cmake 63c3542 

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


Testing
---

run it with and without qmlplugindump installed, it now no longer says it's 
failed even when it hasn't


Thanks,

Jonathan Riddell

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

Review Request 126385: PartManager: stop tracking a widget even if it is no longer a top level window

2015-12-16 Thread Jonathan Marten


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

Review request for KDE Frameworks.


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


Repository: kparts


Description
---

This appears to be the cause of a crash when exiting System Settings.  More 
information in the bug report, but basically what happens is that the manager 
keeps track of widgets that it is managing in d->m_managedTopLevelWidgets.  If 
a widget is a top level widget when it is added, but is no longer top level 
when it is destroyed, it is not removed from the list which results in an 
access-to-deleted-object in the destructor.

This change unconditionally removes the widget even if it is no longer top 
level.  Removing the widget from the list has no ill effects, the list is only 
actually used in Partmanager::eventFilter() which will never get an event for a 
deleted widget anyway.

Aside:  The problematic 'foreach (const QWidget *w, 
d->m_managedTopLevelWidgets)' loop in PartManager::PartManager() is really 
superfluous, since all signal connections to 'this' are removed on destruction 
anyway.


Diffs
-

  src/partmanager.cpp 81bf73f 

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


Testing
---

Built KParts with this change, and also systemsettings5 with the associated 
change (see associated review).  Observed no crash when exiting the 
application.  Also checked correct operation of Konqueror and Kate.


Thanks,

Jonathan Marten

___
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: about ki18n/locales: installing only a subset?

2015-12-16 Thread Luigi Toscano

On Wednesday 16 of December 2015 14:44:54 René J.V. Bertin wrote:
> 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?).

That ship already sailed, there is now a link to the online version if you 
don't have KDocTools (I still there is value in offline documentation, but... 
patches welcome).
I'm not sure that specific format is the solution.

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

Re: Review Request 126384: better description of qmlmodule cmake module

2015-12-16 Thread Jonathan Riddell


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

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


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Changes
---

Submitted with commit 166ea0ed7877c47aa89eed03d00f5d1ed15424a6 by Jonathan 
Riddell to branch master.


Repository: purpose


Description
---

don't say it's failed as a description, just say what it's looking for.  
currently it says it's failed even when it's found what it needs


Diffs
-

  src/plugins/cmake/FindQMLModule.cmake 63c3542 

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


Testing
---

run it with and without qmlplugindump installed, it now no longer says it's 
failed even when it hasn't


Thanks,

Jonathan Riddell

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

Re: Review Request 126384: better description of qmlmodule cmake module

2015-12-16 Thread Aleix Pol Gonzalez


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

Ship it!


Ship It!

- Aleix Pol Gonzalez


On Dec. 16, 2015, 1:43 p.m., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126384/
> ---
> 
> (Updated Dec. 16, 2015, 1:43 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: purpose
> 
> 
> Description
> ---
> 
> don't say it's failed as a description, just say what it's looking for.  
> currently it says it's failed even when it's found what it needs
> 
> 
> Diffs
> -
> 
>   src/plugins/cmake/FindQMLModule.cmake 63c3542 
> 
> Diff: https://git.reviewboard.kde.org/r/126384/diff/
> 
> 
> Testing
> ---
> 
> run it with and without qmlplugindump installed, it now no longer says it's 
> failed even when it hasn't
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

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

Draft split for qpt plugin from frameworkintegration

2015-12-16 Thread Martin Graesslin

Hi all,

following up on [1] I have prepared a split of frameworkintegration to move 
the QPT plugin into a dedicated repository. You can find it in [2]. Please have 
a look at the split repo to verify that it looks fine. If everything is OK, 
I'll request a new repo from sysadmins.

Some general notes
* new repo name: plasma-integration
* new plugin name: PlasmaDesktopPlatformTheme
* new src folder name: src/plasma-desktop-platformtheme

Explaining the name changes:
The plugin is renamed to not conflict on install with the existing plugin from 
frameworkintegration and also incorporating future changes Marco pointed out: 
we need a different QPT plugin for mobile.

How to remove the plugin from frameworkintegration:
After the split we cannot remove it from frameworkintegration yet as that 
would break setups on the next framework release. Given that I plan to only 
phase it out: Introduce a cmake option to build and install it, which defaults 
to true till at least Plasma 5.6 is released. Afterward swapping the default 
to false, with a big fat warning and keeping it like that for at least half a 
year. Then remove it. We don't provide any guarantees for it, so we can remove 
it, but I want to keep the impact small.

Cheers
Martin

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
029234.html
[2] kde:scratch/graesslin/platform-integration (https://quickgit.kde.org/?
p=scratch%2Fgraesslin%2Fplasma-integration.git )

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

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

2015-12-16 Thread Sebastian Kügler


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


Looks fine to me, but I'll let Martin decide, since he maintains knotifications.

- Sebastian Kügler


On Dec. 15, 2015, 7: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, 7: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: about ki18n/locales: installing only a subset?

2015-12-16 Thread Chusslove Illich

> [: René J.V. Bertin :]
> 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 [...] something that has absolutely no use for the vast
> majority of users.

It has a use in every situation where multiple-language users work in a
centrally administered network. Like in... an office. My personal experience
in this regard is that whenever I sat at some machine of that type, I get
translated all software *but* the KDE software. And the unacceptable
overhead in that case is asking IT to do something about it.

> [...] but it'll end up amounting to a significant disk overhead (the one
> that comes with lots of small files) [...]

I don't think the disk overhead is significant. There are no loud complains
about other Gettext-using software, which normally comes with all
translations. To put it in perspective, a single contemporary high-budget
game will occupy much more disk blocks than all Gettext translations on the
system combined.

Furthermore, if one thinks of stripping the translation files from release
packages, or fetching them manually from the repo, that will not work
properly. There will be versioning mismatches, and some files will be
omitted, as PO files are not the only translation-related files. So this
should be done only with a much stronger reason than disk usage.

-- 
Chusslove Illich (Часлав Илић)


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

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

On Wednesday 16 December 2015 11:20:38 René J.V. Bertin wrote:
> On Wednesday December 16 2015 09:03:53 David Faure wrote:
> 
> > Yep, remove them if you don't want them, but then your users are going to 
> > complain, unless you provide them separately.
> 
> I think I implied in my original message that I consider providing them 
> separately the ideal solution ;)
> Sadly such an approach is far from trivial to implement (all the more with 
> MacPorts) if the source files are scattered over individual packages instead 
> of being available as complete bundles like they used to be. Or am I missing 
> something?

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

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

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

Re: Review Request 126330: use generate_export_header

2015-12-16 Thread Martin Klapetek


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

Ship it!


Ship It!

- Martin Klapetek


On Dec. 16, 2015, 9:18 a.m., Patrick Spendrin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126330/
> ---
> 
> (Updated Dec. 16, 2015, 9:18 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> The old file, which seems to be a leftover was still used, even though
> generate_export_header was present.
> 
> 
> Diffs
> -
> 
>   src/calendarevents/CMakeLists.txt 6c2aae34556136b70c0f092fc921745d6e313eda 
>   src/calendarevents/calendarevents_export.h 
> a4c6f87e62c02a4ed34d0ebff00e0a729357952f 
> 
> Diff: https://git.reviewboard.kde.org/r/126330/diff/
> 
> 
> Testing
> ---
> 
> Windows.
> 
> 
> Thanks,
> 
> Patrick Spendrin
> 
>

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

2015-12-16 Thread Martin Klapetek


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


Can you please add a screenshot of how such menu looks like on OS X?


src/kstatusnotifieritem.cpp (line 710)


Why is it reasonable if the platform guidelines speak against it?


- Martin Klapetek


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

2015-12-16 Thread šumski

On Wednesday 16 of December 2015 09:08:03 David Faure wrote:
> Fixed, it was an oversight when converting the lib into a KF5 framework.

But this is a BiC change...


Cheers,
Hrvoje

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

Re: Review Request 126325: kwidgetsaddons: Do not use QStringLiteral with multi strings


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

(Updated Dec. 16, 2015, 8:27 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Feck.


Changes
---

Submitted with commit 71dd42f902c8fa09f6eca5e762c2e46a45161767 by Patrick R. 
Spendrin on behalf of Patrick Spendrin to branch master.


Repository: kwidgetsaddons


Description
---

Strings that are separated into multiple parts don't work on Windows
together with QStringLiteral as the first string is interpreted as a
wide (16bit) string, and the second one as a narrow (8bit) string.
Replacing with QString::fromLatin1 is the easiest solution keeping
the code layout the same, joining the strings would work too though.


Diffs
-

  src/kmessagewidget.cpp b8070880dc2e7e9fd8c6c9be7f0087d4da83b413 
  tests/kmessageboxtest.cpp 73e5f7acf297eb9fb39bbcaf03f79ff9e17e29ac 

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


Testing
---

Windows.


Thanks,

Patrick Spendrin

___
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 Tuesday 15 December 2015 11:19:29 René J.V. Bertin wrote:
> 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...

Yep, remove them if you don't want them, but then your users are going to 
complain, unless you provide them separately.

The overhead is minimal and allows for modularity.

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

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

Re: Review Request 126325: kwidgetsaddons: Do not use QStringLiteral with multi strings


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

Ship it!


Ship It!

- David Faure


On Dec. 13, 2015, 10:38 p.m., Patrick Spendrin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126325/
> ---
> 
> (Updated Dec. 13, 2015, 10:38 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string.
> Replacing with QString::fromLatin1 is the easiest solution keeping
> the code layout the same, joining the strings would work too though.
> 
> 
> Diffs
> -
> 
>   src/kmessagewidget.cpp b8070880dc2e7e9fd8c6c9be7f0087d4da83b413 
>   tests/kmessageboxtest.cpp 73e5f7acf297eb9fb39bbcaf03f79ff9e17e29ac 
> 
> Diff: https://git.reviewboard.kde.org/r/126325/diff/
> 
> 
> Testing
> ---
> 
> Windows.
> 
> 
> Thanks,
> 
> Patrick Spendrin
> 
>

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

Re: Review Request 126330: use Qt defines for portability


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


I vote for generate_export_header.

- David Faure


On Dec. 12, 2015, 11:12 p.m., Patrick Spendrin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126330/
> ---
> 
> (Updated Dec. 12, 2015, 11:12 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> far better solution would be to use generate_export_header, if you prefer
> that, please let me know.
> 
> 
> Diffs
> -
> 
>   src/calendarevents/calendarevents_export.h 
> a4c6f87e62c02a4ed34d0ebff00e0a729357952f 
> 
> Diff: https://git.reviewboard.kde.org/r/126330/diff/
> 
> 
> Testing
> ---
> 
> Windows.
> 
> 
> Thanks,
> 
> Patrick Spendrin
> 
>

___
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

Fixed, it was an oversight when converting the lib into a KF5 framework.

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

Not exactly, there's also 

../bluez-qt/CMakeLists.txt:27:SOVERSION 6
../kactivities/CMakeLists.txt:129:  SOVERSION 1
../modemmanager-qt/CMakeLists.txt:40:SOVERSION 6)
../networkmanager-qt/CMakeLists.txt:40:SOVERSION 6)

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

Doesn't matter, it had a different library name (no KF5 in the name).

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

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

Re: Review Request 126326: kdbusaddons: Do not use QStringLiteral with multi strings


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

Ship it!


Ship It!

- David Faure


On Dec. 12, 2015, 10:58 p.m., Patrick Spendrin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126326/
> ---
> 
> (Updated Dec. 12, 2015, 10:58 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdbusaddons
> 
> 
> Description
> ---
> 
> Strings that are separated into multiple parts don't work on Windows
> together with QStringLiteral as the first string is interpreted as a
> wide (16bit) string, and the second one as a narrow (8bit) string.
> Replacing with QString::fromLatin1 is the easiest solution keeping
> the code layout the same, joining the strings would work too though.
> 
> 
> Diffs
> -
> 
>   src/kdbusservice.cpp d17bfd2b971d462cc9ddea37624f1e71c7d0f16e 
> 
> Diff: https://git.reviewboard.kde.org/r/126326/diff/
> 
> 
> Testing
> ---
> 
> Windows.
> 
> 
> Thanks,
> 
> Patrick Spendrin
> 
>

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

Re: Review Request 126330: use Qt defines for portability


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

(Updated Dez. 16, 2015, 8:17 vorm.)


Review request for KDE Frameworks.


Changes
---

I oversaw that the generate_export_header was already present, it just wasn't 
used.


Repository: kdeclarative


Description
---

far better solution would be to use generate_export_header, if you prefer
that, please let me know.


Diffs (updated)
-

  src/calendarevents/CMakeLists.txt 6c2aae34556136b70c0f092fc921745d6e313eda 
  src/calendarevents/calendarevents_export.h 
a4c6f87e62c02a4ed34d0ebff00e0a729357952f 

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


Testing
---

Windows.


Thanks,

Patrick Spendrin

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

Re: Review Request 126339: remove kdewin dependency


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

(Updated Dec. 16, 2015, 8:06 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.


Changes
---

Submitted with commit 8c26b8cda03327ec5d49203cd4144d3e35debaf9 by Patrick 
Spendrin to branch master.


Repository: khtml


Description
---

This removes the direct kdewin dependency by replacing problematic
function calls (uname, snprintf) with their Qt counterparts.
Some leftover unix header includes removed too.


Diffs
-

  CMakeLists.txt 51fe02a01c8166046d1c6085ec4a5b6e617e1fea 
  src/ecma/kjs_binding.cpp 5e122f0f0d70e6734565e7ab205d14a92c79d287 
  src/ecma/kjs_navigator.cpp 2f7be8d11e5af84e08ac640ccbc97f70aeac8abd 
  src/ecma/kjs_proxy.h 24abd1e1bac0932f8829f02185953142c74aadc8 
  src/ecma/kjs_proxy.cpp 20430f48fce986ca654c49c5771ad839845f11ab 
  src/khtml_pagecache.cpp 8e1841f6b0e816dfd8faa76f2191b269c4716011 
  src/khtml_part.cpp adbcd800a526e9f8fd92a553e62ee64791872938 
  src/kmultipart/kmultipart.cpp 1ad3bbb9b6d6a022799d5ef85f426fc9f911d45b 

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


Testing
---

Windows, Linux compiles.


Thanks,

Patrick Spendrin

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

Re: Review Request 126330: use generate_export_header


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

(Updated Dez. 16, 2015, 8:18 vorm.)


Review request for KDE Frameworks.


Summary (updated)
-

use generate_export_header


Repository: kdeclarative


Description (updated)
---

The old file, which seems to be a leftover was still used, even though
generate_export_header was present.


Diffs
-

  src/calendarevents/CMakeLists.txt 6c2aae34556136b70c0f092fc921745d6e313eda 
  src/calendarevents/calendarevents_export.h 
a4c6f87e62c02a4ed34d0ebff00e0a729357952f 

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


Testing
---

Windows.


Thanks,

Patrick Spendrin

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

Re: Review Request 126326: kdbusaddons: Do not use QStringLiteral with multi strings


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

(Updated Dec. 16, 2015, 8:21 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 11ef653e0393b2890e932d6ced4d5ef4d1781e93 by Patrick R. 
Spendrin to branch master.


Repository: kdbusaddons


Description
---

Strings that are separated into multiple parts don't work on Windows
together with QStringLiteral as the first string is interpreted as a
wide (16bit) string, and the second one as a narrow (8bit) string.
Replacing with QString::fromLatin1 is the easiest solution keeping
the code layout the same, joining the strings would work too though.


Diffs
-

  src/kdbusservice.cpp d17bfd2b971d462cc9ddea37624f1e71c7d0f16e 

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


Testing
---

Windows.


Thanks,

Patrick Spendrin

___
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 09:03:53 David Faure wrote:

> Yep, remove them if you don't want them, but then your users are going to 
> complain, unless you provide them separately.

I think I implied in my original message that I consider providing them 
separately the ideal solution ;)
Sadly such an approach is far from trivial to implement (all the more with 
MacPorts) if the source files are scattered over individual packages instead of 
being available as complete bundles like they used to be. Or am I missing 
something?

> The overhead is minimal and allows for modularity.

Overhead in terms of bytes, sure. Overhead in terms of the number of blocks 
used for those small files is a different thing. A matter of principle I 
consider more important than, say, strict adherence to code formatting.
It's a gripe I also have with Apple - but at least there one can understand it 
from a vendor who also sells disks and laptops with non replaceable disks 
(despite choice during the initial OS install all updates and downloads contain 
all supported languages - minus en_GB... - and Xcode contains several gigabytes 
of SDKs many will never use).

Again, for the vast majority of users, the vast majority of included languages 
ranges from moderate to utterly exotic, and if I weren't sticking to cheap, big 
spinning storage myself I'd be really annoyed to be obliged to waste precious 
SDD blocks.

Cheers,
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?

2015-12-16 Thread Jonathan Riddell

On Wed, Dec 16, 2015 at 11:20:38AM +0100, René J.V. Bertin wrote:
> On Wednesday December 16 2015 09:03:53 David Faure wrote:
> 
> > Yep, remove them if you don't want them, but then your users are going to 
> > complain, unless you provide them separately.
> 
> I think I implied in my original message that I consider providing them 
> separately the ideal solution ;)
> Sadly such an approach is far from trivial to implement (all the more with 
> MacPorts) if the source files are scattered over individual packages instead 
> of being available as complete bundles like they used to be. Or am I missing 
> something?

Many distros successfully make language packs by extracting the .po
files from the software they ship.  It's not possible to do this at
the KDE level because KDE isn't a monolithic software project any
more.

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