date:20151214

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

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



> 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 126295: Fix wrong button in KUrlNavigator issue caused by 9dbe36f734b5b839b2a6a934fad29d639e954498

2015-12-14 Thread Xuetian Weng


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

(Updated Dec. 14, 2015, 11:31 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure and Emmanuel Pescosta.


Changes
---

Submitted with commit d34b37b6831429f7a48edec7de77cb88524b3784 by Weng Xuetian 
to branch master.


Repository: kio


Description
---

9dbe36f734b5b839b2a6a934fad29d639e954498 breaks some assumption on startIndex. 
The argument index passed to buttonUrl is based number of '/'in full url. 
Because of that, url like "sftp://a...@b.com/a/b; is now shown as 
"sftp:a...@b.com" / "b" / "b" in dolphin url bar.

This patch changes all relevant code that calls buttonUrl() to use url.path() 
instead of url.toDisplayString() to count the number of "/".


Diffs
-

  src/filewidgets/kurlnavigator.cpp 848e98b 

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


Testing
---

Remote url -> ok
Local url -> ok
Remote url in places and try browse some sub folder -> ok
Local url in places and try browse some sub folder -> ok


Thanks,

Xuetian Weng

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

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

2015-12-14 Thread Boudhayan Gupta



> On Dec. 14, 2015, 12:23 p.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".

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.


- Boudhayan


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


On Dec. 13, 2015, 7:24 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, 7:24 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
>

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

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



> 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 126312: Add xcb variant for static KStartupInfo::sendFoo methods

2015-12-14 Thread Martin Gräßlin


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

(Updated Dec. 14, 2015, 9:55 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 60d4037f34b67570205d3aaaec349c3ae61f6aa2 by Martin 
Gräßlin to branch master.


Repository: kwindowsystem


Description
---

Adds for each of sendStartup, sendChange, sendFinish an xcb variant
and deprecates the XLib variant. In addition the static variants which
are not windowing system specific delegate to the new xcb variant to
share more code paths.


Diffs
-

  src/kstartupinfo.h dfcd42797d887ca6d43161f8c3b767ad436e5116 
  src/kstartupinfo.cpp a97b8b5416ca67a083960a76093933fb098327a5 

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


Testing
---

autotest still passes


Thanks,

Martin Gräßlin

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

Jenkins-kde-ci: kwindowsystem master kf5-qt5 » Linux,NoX11,gcc - Build # 51 - Fixed!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/51/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 10:03:21 +
Build duration: 1 min 28 sec

CHANGE SET
Revision 879c6f30947c05cac72b05315a614b04a309b08b by Martin Gräßlin: (Fix build 
without xcb)
  change: edit src/kstartupinfo.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

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

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 46 - Failure!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/46/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 09:55:46 +
Build duration: 1 min 3 sec

CHANGE SET
Revision 60d4037f34b67570205d3aaaec349c3ae61f6aa2 by Martin Gräßlin: (Add xcb 
variant for static KStartupInfo::sendFoo methods)
  change: edit src/kstartupinfo.h
  change: edit src/kstartupinfo.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126320: Read KPluginMetada's property X-Plasma-ComponentTypes as a stringlist

2015-12-14 Thread Alex Richardson


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

Ship it!



src/plasma/scripting/scriptengine.cpp (line 89)


readStringList() is static so KPluginMetaData:: is probably the better way 
to call it


- Alex Richardson


On Dec. 11, 2015, 6:48 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126320/
> ---
> 
> (Updated Dec. 11, 2015, 6:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Alex Richardson.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> plasma-scriptengine.desktop defines the property "X-Plasma-ComponentTypes"
> as Type=QStringList. When reading it using KPluginMetaData::value(..) it
> expects a QString back. This used to work but regressed in kcoreaddons in
> commit cfd18cf09b559a050fd6a2680ad4e71eeb950383. Now I'm not sure if calling
> KPluginMetaData::value(..) on a property that is known to be a stringlist
> should actually return a QString (Alex?), but making it read the property
> as a stringlist works and is correct and also fixes Plasma startup for me.
> 
> 
> Diffs
> -
> 
>   src/plasma/scripting/scriptengine.cpp 1b132de 
> 
> Diff: https://git.reviewboard.kde.org/r/126320/diff/
> 
> 
> Testing
> ---
> 
> Plasma would get stuck on startup, now I can run Plasma again.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
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

2015-12-14 Thread Patrick Spendrin


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

(Updated Dez. 14, 2015, 10:37 vorm.)


Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.


Changes
---

there actually is a qsysinfo.h, not sure why I didn't find it in the first 
place.


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

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

2015-12-14 Thread Boudhayan Gupta



> On Dec. 14, 2015, 12:23 p.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.
> 
> René J.V. Bertin wrote:
> 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?

The idea is that you can write OpenGL apps without introducing the QtWidgets 
dependency, by using Qt's event loop and drawing on a QWindow. The KDE 
Frameworks follow this philosophy - because they're supposed to be used 
independently of KDE, the frameworks strive to minimise their dependency 
footprint.


- Boudhayan


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


On Dec. 13, 2015, 7:24 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, 7:24 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

Jenkins-kde-ci: kwindowsystem master kf5-qt5 » Linux,NoX11,gcc - Build # 50 - Failure!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/50/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 09:55:46 +
Build duration: 1 min 6 sec

CHANGE SET
Revision 60d4037f34b67570205d3aaaec349c3ae61f6aa2 by Martin Gräßlin: (Add xcb 
variant for static KStartupInfo::sendFoo methods)
  change: edit src/kstartupinfo.cpp
  change: edit src/kstartupinfo.h
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kwindowsystem master kf5-qt5 » Linux,NoX11,gcc - Build # 51 - Fixed!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/51/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 10:03:21 +
Build duration: 1 min 28 sec

CHANGE SET
Revision 879c6f30947c05cac72b05315a614b04a309b08b by Martin Gräßlin: (Fix build 
without xcb)
  change: edit src/kstartupinfo.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

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

Review Request 126343: KPluginMetaData: Add fields used by KAboutData and introduce conversion function

2015-12-14 Thread Alex Richardson


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

Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

Add KPluginMetaData::translators() and KAboutPerson::fromJson()

Plugins could have a list of translators in KDE4 through KAboutData so
this commit restores this for KF5. As a side effect of now having
authors() and translators() returning a list of KAboutPerson I also
added KAboutPerson::fromJSON() as publc function but I can make that
internal API instead if it's preferred.

--- 

Add KPluginMetaData::copyrightText(), extraInformation() and otherContributors()

Now KPluginMetaData has well defined keys for all the information used
by KAboutData. This means we can easily create KAboutData objects from
a KPluginMetaData object e.g. for use in an KAboutApplicationDialog.
For example Okular uses this to display information about generator that
is being used for the current document.

---

Add KAboutData::fromPluginMetaData(const KPluginMetaData )

This is useful e.g. to create an KAboutApplicationDialog for plugins


Diffs
-

  autotests/kpluginmetadatatest.cpp 25c8b8d5351eb5c5c784d528f9e90dfc8ea77982 
  src/lib/kaboutdata.h 0dbd7a0ce7ec9220614c5f824a0f379ea5f45559 
  src/lib/kaboutdata.cpp 5d9a55ea027fc1b8fb6e6394d72cf48f142bb664 
  src/lib/plugin/kpluginmetadata.h a91b94ad404b6839aa3b8d13b8da19f407708c1b 
  src/lib/plugin/kpluginmetadata.cpp 36743600788693b6449d065f0448e3195445772e 

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


Testing
---

Tests pass, used by KAboutApplicationDialog in okular: 
https://git.reviewboard.kde.org/r/126193/


Thanks,

Alex Richardson

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

Re: Review Request 126320: Read KPluginMetada's property X-Plasma-ComponentTypes as a stringlist

2015-12-14 Thread Marco Martin


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

Ship it!


Ship It!

- Marco Martin


On Dec. 11, 2015, 6:48 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126320/
> ---
> 
> (Updated Dec. 11, 2015, 6:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Alex Richardson.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> plasma-scriptengine.desktop defines the property "X-Plasma-ComponentTypes"
> as Type=QStringList. When reading it using KPluginMetaData::value(..) it
> expects a QString back. This used to work but regressed in kcoreaddons in
> commit cfd18cf09b559a050fd6a2680ad4e71eeb950383. Now I'm not sure if calling
> KPluginMetaData::value(..) on a property that is known to be a stringlist
> should actually return a QString (Alex?), but making it read the property
> as a stringlist works and is correct and also fixes Plasma startup for me.
> 
> 
> Diffs
> -
> 
>   src/plasma/scripting/scriptengine.cpp 1b132de 
> 
> Diff: https://git.reviewboard.kde.org/r/126320/diff/
> 
> 
> Testing
> ---
> 
> Plasma would get stuck on startup, now I can run Plasma again.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126329: kio: Do not use QStringLiteral with multi strings

2015-12-14 Thread Patrick Spendrin


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

(Updated Dec. 14, 2015, 9:43 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

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


Repository: kio


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 does work too though.


Diffs
-

  autotests/dataprotocoltest.cpp 9fe238fdbb0e9682141772d423a64edd5621921b 
  src/core/ksambashare.cpp a3f84ac3971141e687d9ab17e0131a66db34ed5a 
  src/filewidgets/kfileplacesmodel.cpp b409c1b1617f97f3cdbc79a2c76110a5f9449398 
  src/ioslaves/help/kio_help.cpp cb27a77b22fe378a126d985621985265edb93767 
  src/widgets/kpropertiesdialog.cpp 0ff506273a10dba238fefc5c552c71434681285e 

Diff: https://git.reviewboard.kde.org/r/126329/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

2015-12-14 Thread Alex Richardson


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

Ship it!


Looks good to me

- Alex Richardson


On Dec. 14, 2015, 10:37 a.m., Patrick Spendrin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126339/
> ---
> 
> (Updated Dec. 14, 2015, 10:37 a.m.)
> 
> 
> Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.
> 
> 
> 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: kdeinit freezes on Wayland in OOM protection

2015-12-14 Thread Martin Graesslin

On Friday, November 27, 2015 1:05:26 PM CET Michael Pyne wrote:
> On Thu, November 26, 2015 13:16:04 Martin Graesslin wrote:
> > we are facing a problem during the startup of Plasma on Wayland. If OOM
> > protection is enabled for kdeinit and we already have a running X server,
> > kdeinit freezes dead.
> > 
> > I'm sorry for having ignored the issue for too long and had just disabled
> > OOM protection on my system, so I never hit it. Now I enabled it again to
> > get the problem. On my system I have now two frozen kdeinit processes:
> > 
> > martin1960  1956  0 77832 26448   1 13:05 ?00:00:00
> > /opt/kf5/bin/ kdeinit5 --oom-pipe 4 --kded +kcminit_startup
> > martin1961  1960  0 77832  2816   3 13:05 ?00:00:00
> > /opt/kf5/bin/ kdeinit5 --oom-pipe 4 --kded +kcminit_startup
> > 
> > One has the following stacktrace:
> > It's frozen in this line of code:
> > sigsuspend();   // wait for the signal to come
> > 
> > The other one has the following stacktrace:
> > which is:
> > d.n = read(d.fd[0], , 1);
> > 
> > Given that it looks to me like these two processes dead-lock. I do not
> > understand why, why it only happens on Wayland, why the fact that an X
> > server must already be running is relevant and what the OOM protection has
> > to do with it.
> 
> I don't have the answer but I can help explain the deadlock better I think.

thanks for your input. It helped me understanding quite a bit.

Some more testing results:
Weston+Xwayland: doesn't show the problem
Weston without Xwayland (and DISPLAY=$WAYLAND_DISPLAY): doesn't show the 
problem.

What I absolutely do not understand how KWin could influence it. From all the 
backtraces I see it always freezes before interacting with the windowing 
system.

Any more ideas to test and investigate, highly appreciated. I got a rather 
high number of complaints due to that problem and it's a showstopper and I'm 
lost with it.

Cheers
Martin

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: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

2015-12-14 Thread Martin Graesslin

On Monday, December 14, 2015 2:40:16 PM CET Mark Gaiser wrote:
> On Mon, Dec 14, 2015 at 1:37 PM, Marco Martin  wrote:
> > On Thursday 10 December 2015, Mark Gaiser wrote:
> > > It's not just a barrier in my head. It's a waste of resources if one
> > > package that doesn't need a dozen dependencies, pulls it in because
> > 
> > someone
> > 
> > > decided it doesn't matter for the resources. If you don't use it, don't
> > > install it.
> > > But that's my opinion. You know i'm all about optimization (more so then
> > > other people) so i can understand if you don't share this opinion.
> > 
> > It's really asking the wrong question: it's really a matter of wether or
> > not
> > the Plasma desktop QPT (that's what it is even right now, even if it isn't
> > in
> > the workspace/ repositories yet) makes sense used on different platforms
> > (and
> > would still not be forbidden doing so, the cost of it would still be quite
> > negligible)
> > but it's not really what you want on Windows
> > nor what you want in OSX
> > nor what you want in GNOME
> > or XFCE
> > and yeah, probably not even in LXQt
> > even in Plasma Mobile, we'll need a different QPT
> 
> Please!
> Stop assuming things i never said!
> 
> For the full fledged desktop environments (windows, mac, plasma, gnome,
> xfce, etc...) you are all completely right.
> And that wasn't the point i was trying to make at all.
> 
> The point i was trying to make is where a user - for whatever reason -
> decides to use a light weight desktop (say openbox, or say a tilling window
> manager, think along THOSE lines) there a user might very well prefer the
> dialogs that frameworks can provide if the QPT is installed over the stock
> Qt dialogs. LXQt is doubtful since it is somewhere in the middle.
> 
> That is the point i'm trying to make over and over again.
> 
> Now some seem to think that's the wrong thing to do since every "desktop
> environment" (say i3 tilling wm, just for fun and to prevent further
> assumptions of gnome...) needs to implement their own QPA to get the
> framework fancy dialogs. That's fine if you think that. It's an RFC! Those
> opinions should be shared since it's the intention of an RFC to get the
> opinion of others. I think one QPA with just the framework goodness should
> exists (and does exist right now) that should be usable on every wm (yes,
> say i3 again) if the user decides to do that.

you really think that those "lightweight" i3 users use anything from KDE? We 
are the bloatware kings in their eyes. And no, this practically is just a non 
existing case. Please see for example popcon:

* https://qa.debian.org/popcon.php?package=plasma-workspace
* https://qa.debian.org/popcon.php?package=frameworkintegration
* https://qa.debian.org/popcon.php?package=i3-wm
* https://qa.debian.org/popcon.php?package=openbox

If we assume that the users of frameworkintegration without plasma-workspace 
are those i3 users than we have 60 users for that.

Btw. to me there is no difference between a full fledged desktop environment 
and an i3 session. The users use it like a desktop environment, it should be 
treated like one. If i3 wants to use the QPT, they need to provide one and I 
highly recommend to do it, because KWin is not a tiling WM. This has influence 
on how our dialogs look like.

Cheers
Martin

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

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


---
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 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Artur Puzio



> On Gru 14, 2015, 8:10 po południu, Sergio Martins wrote:
> > src/klocalizedstring.cpp, line 389
> > 
> >
> > this will break the build with MSVC, it doesn't support QStringLiteral 
> > with multi-line literals.
> > 
> > (hint:
> > export 
> > CLAZY_EXTRA_OPTIONS="qstring-uneeded-heap-allocations-msvc-compat"
> > )
> 
> Nick Shaforostoff wrote:
> why QString is used for debug output in the first place?
> there is operator<<(const char * s) for latin1 text, which is the case
> (i.e. no non-latin symbols are used in the literals)
> 
> using strings for debugging output is suboptimal

look at line 487:
```
qWarning() << QStringLiteral(
 "Plural argument to message {%1} not supplied 
before conversion.")
 .arg(shortenMessage(QString::fromUtf8(text)));
```
Some of QString-s can by changed to const char *, but in other places they are 
required.


- Artur


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


On Gru 14, 2015, 7:46 po południu, Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126350/
> ---
> 
> (Updated Gru 14, 2015, 7:46 po południu)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
> [-Wclazy-rule-of-three]`
> Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
> Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
> [-Wclazy-variant-sanitizer]`
> Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
> Fixed `warning: Pass small and trivially-copyable type by value (const class 
> QChar &) [-Wclazy-foreach]`
> Fixed `warning: QString::fromLatin1() being passed a literal 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(const char*) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(QLatin1String) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 7711e9b 
>   src/klocalizedcontext.cpp 3bc42dd 
>   src/common_helpers.cpp dad7f84 
>   src/klocalizedstring.cpp 69950d2 
>   src/ktranscript.cpp 04dda66 
>   src/kuitmarkup.h d110ca3 
>   src/kuitmarkup.cpp 02b891a 
> 
> Diff: https://git.reviewboard.kde.org/r/126350/diff/
> 
> 
> Testing
> ---
> 
> Automated tests 1,3 and 4 passing.
> Test 2 fails on my system both: after changes and before.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: kdeinit freezes on Wayland in OOM protection

2015-12-14 Thread Martin Gräßlin

Am 2015-12-15 03:20, schrieb Michael Pyne:

On Mon, December 14, 2015 16:07:38 Martin Graesslin wrote:

On Friday, November 27, 2015 1:05:26 PM CET Michael Pyne wrote:
> On Thu, November 26, 2015 13:16:04 Martin Graesslin wrote:
> > we are facing a problem during the startup of Plasma on Wayland. If OOM
> > protection is enabled for kdeinit and we already have a running X
> > server,
> > kdeinit freezes dead.
> >
> > I'm sorry for having ignored the issue for too long and had just
> > disabled
> > OOM protection on my system, so I never hit it. Now I enabled it again
> > to
> > get the problem. On my system I have now two frozen kdeinit processes:
> >
> > martin1960  1956  0 77832 26448   1 13:05 ?00:00:00
> > /opt/kf5/bin/ kdeinit5 --oom-pipe 4 --kded +kcminit_startup
> > martin1961  1960  0 77832  2816   3 13:05 ?00:00:00
> > /opt/kf5/bin/ kdeinit5 --oom-pipe 4 --kded +kcminit_startup
> >
> > One has the following stacktrace:
> > It's frozen in this line of code:
> > sigsuspend();   // wait for the signal to come
> >
> > The other one has the following stacktrace:
> > which is:
> > d.n = read(d.fd[0], , 1);
> >
> > Given that it looks to me like these two processes dead-lock. I do not
> > understand why, why it only happens on Wayland, why the fact that an X
> > server must already be running is relevant and what the OOM protection
> > has
> > to do with it.
>
> I don't have the answer but I can help explain the deadlock better I
> think.

thanks for your input. It helped me understanding quite a bit.

Some more testing results:
Weston+Xwayland: doesn't show the problem
Weston without Xwayland (and DISPLAY=$WAYLAND_DISPLAY): doesn't show 
the

problem.

What I absolutely do not understand how KWin could influence it. From 
all

the backtraces I see it always freezes before interacting with the
windowing system.

Any more ideas to test and investigate, highly appreciated. I got a 
rather
high number of complaints due to that problem and it's a showstopper 
and I'm

lost with it.

Did you add an error check around the set_protection call in 
start_kdeinit.c

and see if that call is failing? (i.e. does "kill(pid, SIGUSR1)" ever
execute?).

yep I added it, but I'm not sure whether it changed anything. When I 
gdb'ed into the process it was hanging in the read in the for loop. So 
it might or might not have proceeded to the set_protection call.

If the kill() call *is* reached then perhaps SIGUSR1 is unintentionally 
masked
in the 'grandchild' process (the child of kdeinit about to be 
exec()'d).
Perhaps something in the wayland/kwin/weston/x11 library interaction 
blocks

SIGUSR1 from being received in that case?

Possible. I saw that weston has the following in the Xwayland process 
fork:

/* Ignore SIGUSR1 in the child, which will make the X
* server send SIGUSR1 to the parent (weston) when
* it's done with initialization.  During
* initialization the X server will round trip and
* block on the wayland compositor, so avoid making
* blocking requests (like xcb_connect_to_fd) until
* it's done with that. */
signal(SIGUSR1, SIG_IGN);

I think the easiest possible fix is to replace the sigsuspend call with 
a
sigtimedwait() call, constructed to wait for SIGUSR1 alone, but with a 
short
timeout. In the event the timeout is reached, continue with the exec() 
as
normal, possibly after leaving a noisy warning. It's probably a good 
idea to
do this anyway since library code shouldn't wait indefinitely just 
because OOM
is enabled, but you're the one best positioned to reproduce at this 
point :)

That is a good suggestion. I'll give it a try!

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

Re: Review Request 126343: KPluginMetaData: Add fields used by KAboutData and introduce conversion function

2015-12-14 Thread Sebastian Kügler


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


Looks good to me, though I wouldn't mind another reviewer. (If no one steps up 
within a week or so, please ship it.)


src/lib/kaboutdata.cpp (line 823)


Unrelated, but doesn't match what we define as "KDE" anymore.


- Sebastian Kügler


On Dec. 14, 2015, 11:45 a.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126343/
> ---
> 
> (Updated Dec. 14, 2015, 11:45 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Add KPluginMetaData::translators() and KAboutPerson::fromJson()
> 
> Plugins could have a list of translators in KDE4 through KAboutData so
> this commit restores this for KF5. As a side effect of now having
> authors() and translators() returning a list of KAboutPerson I also
> added KAboutPerson::fromJSON() as publc function but I can make that
> internal API instead if it's preferred.
> 
> --- 
> 
> Add KPluginMetaData::copyrightText(), extraInformation() and 
> otherContributors()
> 
> Now KPluginMetaData has well defined keys for all the information used
> by KAboutData. This means we can easily create KAboutData objects from
> a KPluginMetaData object e.g. for use in an KAboutApplicationDialog.
> For example Okular uses this to display information about generator that
> is being used for the current document.
> 
> ---
> 
> Add KAboutData::fromPluginMetaData(const KPluginMetaData )
> 
> This is useful e.g. to create an KAboutApplicationDialog for plugins
> 
> 
> Diffs
> -
> 
>   autotests/kpluginmetadatatest.cpp 25c8b8d5351eb5c5c784d528f9e90dfc8ea77982 
>   src/lib/kaboutdata.h 0dbd7a0ce7ec9220614c5f824a0f379ea5f45559 
>   src/lib/kaboutdata.cpp 5d9a55ea027fc1b8fb6e6394d72cf48f142bb664 
>   src/lib/plugin/kpluginmetadata.h a91b94ad404b6839aa3b8d13b8da19f407708c1b 
>   src/lib/plugin/kpluginmetadata.cpp 36743600788693b6449d065f0448e3195445772e 
> 
> Diff: https://git.reviewboard.kde.org/r/126343/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, used by KAboutApplicationDialog in okular: 
> https://git.reviewboard.kde.org/r/126193/
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

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

Re: Review Request 126320: Read KPluginMetada's property X-Plasma-ComponentTypes as a stringlist

2015-12-14 Thread Martin Klapetek


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

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


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma and Alex Richardson.


Changes
---

Submitted with commit 54602237fd018a7212cadea5210a1908584ee110 by Martin 
Klapetek to branch master.


Repository: plasma-framework


Description
---

plasma-scriptengine.desktop defines the property "X-Plasma-ComponentTypes"
as Type=QStringList. When reading it using KPluginMetaData::value(..) it
expects a QString back. This used to work but regressed in kcoreaddons in
commit cfd18cf09b559a050fd6a2680ad4e71eeb950383. Now I'm not sure if calling
KPluginMetaData::value(..) on a property that is known to be a stringlist
should actually return a QString (Alex?), but making it read the property
as a stringlist works and is correct and also fixes Plasma startup for me.


Diffs
-

  src/plasma/scripting/scriptengine.cpp 1b132de 

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


Testing
---

Plasma would get stuck on startup, now I can run Plasma again.


Thanks,

Martin Klapetek

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

Re: Review Request 126320: Read KPluginMetada's property X-Plasma-ComponentTypes as a stringlist

2015-12-14 Thread Martin Klapetek



> On Dec. 14, 2015, 11:36 a.m., Alex Richardson wrote:
> > src/plasma/scripting/scriptengine.cpp, line 67
> > 
> >
> > This should probably also be changed to QStringList?

Yes.


- Martin


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


On Dec. 11, 2015, 7:48 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126320/
> ---
> 
> (Updated Dec. 11, 2015, 7:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Alex Richardson.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> plasma-scriptengine.desktop defines the property "X-Plasma-ComponentTypes"
> as Type=QStringList. When reading it using KPluginMetaData::value(..) it
> expects a QString back. This used to work but regressed in kcoreaddons in
> commit cfd18cf09b559a050fd6a2680ad4e71eeb950383. Now I'm not sure if calling
> KPluginMetaData::value(..) on a property that is known to be a stringlist
> should actually return a QString (Alex?), but making it read the property
> as a stringlist works and is correct and also fixes Plasma startup for me.
> 
> 
> Diffs
> -
> 
>   src/plasma/scripting/scriptengine.cpp 1b132de 
> 
> Diff: https://git.reviewboard.kde.org/r/126320/diff/
> 
> 
> Testing
> ---
> 
> Plasma would get stuck on startup, now I can run Plasma again.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
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-14 Thread Martin Klapetek



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

FYI you can have function name printed by qDebug by default by setting your 
QT_MESSAGE_PATTERN. See http://woboq.com/blog/nice-debug-output-with-qt.html


- Martin


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

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

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



> 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

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

2015-12-14 Thread Boudhayan Gupta



> On Dec. 14, 2015, 5:17 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
> 
> René J.V. Bertin wrote:
> 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?)
> 
> Boudhayan Gupta wrote:
> Don't just lift code. See what it does and then implement it your own 
> way. Licensing between Qt and KDE are incompatible (quote: code may not be 
> copied from Qt into KDE Platform as Qt is LGPL 2.1 only which would prevent 
> it being used under LGPL 3 - from 
> https://techbase.kde.org/Policies/Licensing_Policy)

Actually, René, I think it would be prudent to at least try and push a patch 
upstream to Qt implementing the window geometry APIs on QWindow.


- Boudhayan


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


On Dec. 13, 2015, 7:24 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, 7:24 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,
> 
>

Re: Review Request 126343: KPluginMetaData: Add fields used by KAboutData and introduce conversion function

2015-12-14 Thread Kevin Funk


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


Just a few nitpicks. Rest looks good to me.


src/lib/kaboutdata.h (line 979)


Can't you move that into `KAboutData::Private`? What am I missing?

Polluting the public header otherwise.



src/lib/plugin/kpluginmetadata.h (line 72)


Duplicated documentation.

Just `\sa KAboutPerson::fromJSON`?


- Kevin Funk


On Dec. 14, 2015, 11:45 a.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126343/
> ---
> 
> (Updated Dec. 14, 2015, 11:45 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> Add KPluginMetaData::translators() and KAboutPerson::fromJson()
> 
> Plugins could have a list of translators in KDE4 through KAboutData so
> this commit restores this for KF5. As a side effect of now having
> authors() and translators() returning a list of KAboutPerson I also
> added KAboutPerson::fromJSON() as publc function but I can make that
> internal API instead if it's preferred.
> 
> --- 
> 
> Add KPluginMetaData::copyrightText(), extraInformation() and 
> otherContributors()
> 
> Now KPluginMetaData has well defined keys for all the information used
> by KAboutData. This means we can easily create KAboutData objects from
> a KPluginMetaData object e.g. for use in an KAboutApplicationDialog.
> For example Okular uses this to display information about generator that
> is being used for the current document.
> 
> ---
> 
> Add KAboutData::fromPluginMetaData(const KPluginMetaData )
> 
> This is useful e.g. to create an KAboutApplicationDialog for plugins
> 
> 
> Diffs
> -
> 
>   autotests/kpluginmetadatatest.cpp 25c8b8d5351eb5c5c784d528f9e90dfc8ea77982 
>   src/lib/kaboutdata.h 0dbd7a0ce7ec9220614c5f824a0f379ea5f45559 
>   src/lib/kaboutdata.cpp 5d9a55ea027fc1b8fb6e6394d72cf48f142bb664 
>   src/lib/plugin/kpluginmetadata.h a91b94ad404b6839aa3b8d13b8da19f407708c1b 
>   src/lib/plugin/kpluginmetadata.cpp 36743600788693b6449d065f0448e3195445772e 
> 
> Diff: https://git.reviewboard.kde.org/r/126343/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, used by KAboutApplicationDialog in okular: 
> https://git.reviewboard.kde.org/r/126193/
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

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

2015-12-14 Thread Boudhayan Gupta



> On Dec. 14, 2015, 5:17 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
> 
> René J.V. Bertin wrote:
> 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?)

Don't just lift code. See what it does and then implement it your own way. 
Licensing between Qt and KDE are incompatible (quote: code may not be copied 
from Qt into KDE Platform as Qt is LGPL 2.1 only which would prevent it being 
used under LGPL 3 - from https://techbase.kde.org/Policies/Licensing_Policy)


- Boudhayan


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


On Dec. 13, 2015, 7:24 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, 7:24 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

Re: RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

2015-12-14 Thread Mark Gaiser

On Mon, Dec 14, 2015 at 1:37 PM, Marco Martin  wrote:

> On Thursday 10 December 2015, Mark Gaiser wrote:
> > It's not just a barrier in my head. It's a waste of resources if one
> > package that doesn't need a dozen dependencies, pulls it in because
> someone
> > decided it doesn't matter for the resources. If you don't use it, don't
> > install it.
> > But that's my opinion. You know i'm all about optimization (more so then
> > other people) so i can understand if you don't share this opinion.
>
> It's really asking the wrong question: it's really a matter of wether or
> not
> the Plasma desktop QPT (that's what it is even right now, even if it isn't
> in
> the workspace/ repositories yet) makes sense used on different platforms
> (and
> would still not be forbidden doing so, the cost of it would still be quite
> negligible)
> but it's not really what you want on Windows
> nor what you want in OSX
> nor what you want in GNOME
> or XFCE
> and yeah, probably not even in LXQt
> even in Plasma Mobile, we'll need a different QPT
>

Please!
Stop assuming things i never said!

For the full fledged desktop environments (windows, mac, plasma, gnome,
xfce, etc...) you are all completely right.
And that wasn't the point i was trying to make at all.

The point i was trying to make is where a user - for whatever reason -
decides to use a light weight desktop (say openbox, or say a tilling window
manager, think along THOSE lines) there a user might very well prefer the
dialogs that frameworks can provide if the QPT is installed over the stock
Qt dialogs. LXQt is doubtful since it is somewhere in the middle.

That is the point i'm trying to make over and over again.

Now some seem to think that's the wrong thing to do since every "desktop
environment" (say i3 tilling wm, just for fun and to prevent further
assumptions of gnome...) needs to implement their own QPA to get the
framework fancy dialogs. That's fine if you think that. It's an RFC! Those
opinions should be shared since it's the intention of an RFC to get the
opinion of others. I think one QPA with just the framework goodness should
exists (and does exist right now) that should be usable on every wm (yes,
say i3 again) if the user decides to do that.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 126348: Make it possible to provide the metadata in json

2015-12-14 Thread Aleix Pol Gonzalez


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

Review request for KDE Frameworks and Plasma.


Repository: kpackage


Description
---

Due to KCoreAddons transition from using desktop files to json files, KPackage 
ended in a weird state where desktop files were allowed to use desktop files 
but not json.

This patch makes sure that manifest.json files are also acceptable.


Diffs
-

  autotests/querytest.cpp 0a2f11a 
  src/kpackage/package.cpp 8416054 
  src/kpackage/packageloader.cpp 1e1e382 
  src/kpackage/private/packagejobthread.cpp 444dacc 
  src/kpackage/private/packagejobthread_p.h 1babf0b 
  src/kpackage/private/packages.cpp 2f6bbcf 

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


Testing
---

Tests still pass (except for 
https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
 that is not passing in master).
Adds a test plugin with a json file in it.


Thanks,

Aleix Pol Gonzalez

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

Re: Purpose as a KDE Framework

2015-12-14 Thread Aleix Pol

On Mon, Dec 7, 2015 at 12:49 PM, Marco Martin  wrote:
> On Thursday 03 December 2015, Aleix Pol wrote:
>> > but i don't think scripted plugins can be added as an aftertought as the
>> > structure of the framework may be influenced by that (yeah, i know,
>> > dependencies, but my wet dream is to have those sharing scripts findable
>> > of ghns/kdelook and installable with kpackage)
>>
>> I'll give scripted plugins some thought.
>>
>
> my suggestion is to try that before making it a framework, in case
> incompatible changes would be needed

I introduced scripted plugins support in master and a Twitter plugin
implemented in nodejs.

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

Jenkins-kde-ci: kdeclarative master kf5-qt5 » Linux,gcc - Build # 65 - Still Failing!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdeclarative%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/65/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 14 Dec 2015 21:37:04 +
Build duration: 10 sec

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-14 Thread Sebastian Kügler


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



src/kpackage/package.cpp (line 447)


Please remove before committing



src/kpackage/private/packagejobthread.cpp (line 138)


So if this is going into KPluginMetaData, as Alex suggests, this part can 
be simplified



src/kpackage/private/packagejobthread.cpp (line 160)


Would it make sense to make this stringlist a static as to share the data?



src/kpackage/private/packagejobthread.cpp (line 183)


Why this change?



src/kpackage/private/packagejobthread.cpp (line 303)


Above, we're using QStringLiteral() for the desktop file names, please make 
it consistent in the code you change, and in new code. Right now, it's a bit of 
a hodge-podge of QL1S, QSL, and just plain chars.



src/kpackage/private/packagejobthread.cpp (line 312)


Not sure we should assert here, not loading a package is fine, and I'd 
rather not generate a crash (had to fix too many of these). Below, we're 
actually checking for valid metadata.

Can we make it a warning?



src/kpackage/private/packagejobthread_p.h (line 59)


We should be able to get rid of this one (and the additionally include in 
its user).



src/kpackage/private/packages.cpp (line 57)


Fix spelling of "Fuck" and make it a fatal error? ;)


- Sebastian Kügler


On Dec. 14, 2015, 5:11 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 14, 2015, 5:11 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 126339: remove kdewin dependency

2015-12-14 Thread Patrick Spendrin


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

Review request for KDE Frameworks, David Faure and Martin Tobias Holmedahl 
Sandsmark.


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

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



> 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

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 47 - Fixed!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/47/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 10:03:21 +
Build duration: 21 sec

CHANGE SET
Revision 879c6f30947c05cac72b05315a614b04a309b08b by Martin Gräßlin: (Fix build 
without xcb)
  change: edit src/kstartupinfo.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

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

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 47 - Fixed!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/47/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Mon, 14 Dec 2015 10:03:21 +
Build duration: 21 sec

CHANGE SET
Revision 879c6f30947c05cac72b05315a614b04a309b08b by Martin Gräßlin: (Fix build 
without xcb)
  change: edit src/kstartupinfo.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  

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

Re: Review Request 126320: Read KPluginMetada's property X-Plasma-ComponentTypes as a stringlist

2015-12-14 Thread Alex Richardson


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



src/plasma/scripting/scriptengine.cpp (line 67)


This should probably also be changed to QStringList?


- Alex Richardson


On Dec. 11, 2015, 6:48 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126320/
> ---
> 
> (Updated Dec. 11, 2015, 6:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Alex Richardson.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> plasma-scriptengine.desktop defines the property "X-Plasma-ComponentTypes"
> as Type=QStringList. When reading it using KPluginMetaData::value(..) it
> expects a QString back. This used to work but regressed in kcoreaddons in
> commit cfd18cf09b559a050fd6a2680ad4e71eeb950383. Now I'm not sure if calling
> KPluginMetaData::value(..) on a property that is known to be a stringlist
> should actually return a QString (Alex?), but making it read the property
> as a stringlist works and is correct and also fixes Plasma startup for me.
> 
> 
> Diffs
> -
> 
>   src/plasma/scripting/scriptengine.cpp 1b132de 
> 
> Diff: https://git.reviewboard.kde.org/r/126320/diff/
> 
> 
> Testing
> ---
> 
> Plasma would get stuck on startup, now I can run Plasma again.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Sergio Martins


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



src/klocalizedstring.cpp (line 389)


this will break the build with MSVC, it doesn't support QStringLiteral with 
multi-line literals.

(hint:
export CLAZY_EXTRA_OPTIONS="qstring-uneeded-heap-allocations-msvc-compat"
)


- Sergio Martins


On Dec. 14, 2015, 6:46 p.m., Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126350/
> ---
> 
> (Updated Dec. 14, 2015, 6:46 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
> [-Wclazy-rule-of-three]`
> Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
> Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
> [-Wclazy-variant-sanitizer]`
> Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
> Fixed `warning: Pass small and trivially-copyable type by value (const class 
> QChar &) [-Wclazy-foreach]`
> Fixed `warning: QString::fromLatin1() being passed a literal 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(const char*) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(QLatin1String) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 7711e9b 
>   src/klocalizedcontext.cpp 3bc42dd 
>   src/common_helpers.cpp dad7f84 
>   src/klocalizedstring.cpp 69950d2 
>   src/ktranscript.cpp 04dda66 
>   src/kuitmarkup.h d110ca3 
>   src/kuitmarkup.cpp 02b891a 
> 
> Diff: https://git.reviewboard.kde.org/r/126350/diff/
> 
> 
> Testing
> ---
> 
> Automated tests 1,3 and 4 passing.
> Test 2 fails on my system both: after changes and before.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Artur Puzio


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

(Updated Dec. 14, 2015, 7:37 p.m.)


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: ki18n


Description
---

Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
[-Wclazy-rule-of-three]`
Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
[-Wclazy-variant-sanitizer]`
Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
Fixed `warning: Pass small and trivially-copyable type by value (const class 
QChar &) [-Wclazy-foreach]`
Fixed `warning: QString::fromLatin1() being passed a literal 
[-Wclazy-qstring-uneeded-heap-allocations]`
Fixed `warning: QString(const char*) being called 
[-Wclazy-qstring-uneeded-heap-allocations]`
Fixed `warning: QString(QLatin1String) being called 
[-Wclazy-qstring-uneeded-heap-allocations]`


Diffs
-

  src/kcatalog.cpp 7711e9b 
  src/klocalizedcontext.cpp 3bc42dd 
  src/common_helpers.cpp dad7f84 
  src/klocalizedstring.cpp 69950d2 
  src/ktranscript.cpp 04dda66 
  src/kuitmarkup.h d110ca3 
  src/kuitmarkup.cpp 02b891a 

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


Testing
---

Automated tests 1,3 and 4 passing.
Test 2 fails on my system both: after changes and before.


Thanks,

Artur Puzio

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Aleix Pol Gonzalez



> On Dec. 14, 2015, 7:38 p.m., Aleix Pol Gonzalez wrote:
> > I ran the tests locally and I can confirm that clazy warnings are gone and 
> > all tests still pass.

+1, waiting for maintainer approval.


- Aleix


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


On Dec. 14, 2015, 7:37 p.m., Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126350/
> ---
> 
> (Updated Dec. 14, 2015, 7:37 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
> [-Wclazy-rule-of-three]`
> Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
> Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
> [-Wclazy-variant-sanitizer]`
> Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
> Fixed `warning: Pass small and trivially-copyable type by value (const class 
> QChar &) [-Wclazy-foreach]`
> Fixed `warning: QString::fromLatin1() being passed a literal 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(const char*) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(QLatin1String) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 7711e9b 
>   src/klocalizedcontext.cpp 3bc42dd 
>   src/common_helpers.cpp dad7f84 
>   src/klocalizedstring.cpp 69950d2 
>   src/ktranscript.cpp 04dda66 
>   src/kuitmarkup.h d110ca3 
>   src/kuitmarkup.cpp 02b891a 
> 
> Diff: https://git.reviewboard.kde.org/r/126350/diff/
> 
> 
> Testing
> ---
> 
> Automated tests 1,3 and 4 passing.
> Test 2 fails on my system both: after changes and before.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-14 Thread Alex Richardson


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


Can't really comment on KPackage internals, but looks good to me other than 
this one issue


src/kpackage/private/packagejobthread.cpp (line 143)


I think it would be better if this code was added to the KPluginMetaData 
ctor (in an `if (path.endswith(".json"))` branch.


- Alex Richardson


On Dec. 14, 2015, 5:11 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 14, 2015, 5:11 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Aleix Pol Gonzalez


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


I ran the tests locally and I can confirm that clazy warnings are gone and all 
tests still pass.

- Aleix Pol Gonzalez


On Dec. 14, 2015, 7:37 p.m., Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126350/
> ---
> 
> (Updated Dec. 14, 2015, 7:37 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
> [-Wclazy-rule-of-three]`
> Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
> Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
> [-Wclazy-variant-sanitizer]`
> Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
> Fixed `warning: Pass small and trivially-copyable type by value (const class 
> QChar &) [-Wclazy-foreach]`
> Fixed `warning: QString::fromLatin1() being passed a literal 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(const char*) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(QLatin1String) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 7711e9b 
>   src/klocalizedcontext.cpp 3bc42dd 
>   src/common_helpers.cpp dad7f84 
>   src/klocalizedstring.cpp 69950d2 
>   src/ktranscript.cpp 04dda66 
>   src/kuitmarkup.h d110ca3 
>   src/kuitmarkup.cpp 02b891a 
> 
> Diff: https://git.reviewboard.kde.org/r/126350/diff/
> 
> 
> Testing
> ---
> 
> Automated tests 1,3 and 4 passing.
> Test 2 fails on my system both: after changes and before.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Artur Puzio


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

(Updated Gru 14, 2015, 7:46 po południu)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: ki18n


Description
---

Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
[-Wclazy-rule-of-three]`
Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
[-Wclazy-variant-sanitizer]`
Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
Fixed `warning: Pass small and trivially-copyable type by value (const class 
QChar &) [-Wclazy-foreach]`
Fixed `warning: QString::fromLatin1() being passed a literal 
[-Wclazy-qstring-uneeded-heap-allocations]`
Fixed `warning: QString(const char*) being called 
[-Wclazy-qstring-uneeded-heap-allocations]`
Fixed `warning: QString(QLatin1String) being called 
[-Wclazy-qstring-uneeded-heap-allocations]`


Diffs
-

  src/kcatalog.cpp 7711e9b 
  src/klocalizedcontext.cpp 3bc42dd 
  src/common_helpers.cpp dad7f84 
  src/klocalizedstring.cpp 69950d2 
  src/ktranscript.cpp 04dda66 
  src/kuitmarkup.h d110ca3 
  src/kuitmarkup.cpp 02b891a 

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


Testing
---

Automated tests 1,3 and 4 passing.
Test 2 fails on my system both: after changes and before.


Thanks,

Artur Puzio

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

Re: Review Request 126312: Add xcb variant for static KStartupInfo::sendFoo methods

2015-12-14 Thread David Faure


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

Ship it!


Ship It!

- David Faure


On Dec. 14, 2015, 7:08 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126312/
> ---
> 
> (Updated Dec. 14, 2015, 7:08 a.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> Adds for each of sendStartup, sendChange, sendFinish an xcb variant
> and deprecates the XLib variant. In addition the static variants which
> are not windowing system specific delegate to the new xcb variant to
> share more code paths.
> 
> 
> Diffs
> -
> 
>   src/kstartupinfo.h dfcd42797d887ca6d43161f8c3b767ad436e5116 
>   src/kstartupinfo.cpp a97b8b5416ca67a083960a76093933fb098327a5 
> 
> Diff: https://git.reviewboard.kde.org/r/126312/diff/
> 
> 
> Testing
> ---
> 
> autotest still passes
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 126348: Make it possible to provide the metadata in json

2015-12-14 Thread Nick Shaforostoff


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



src/kpackage/private/packages.cpp (line 57)


something more meaningful?


- Nick Shaforostoff


On Dec. 14, 2015, 5:11 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126348/
> ---
> 
> (Updated Dec. 14, 2015, 5:11 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Due to KCoreAddons transition from using desktop files to json files, 
> KPackage ended in a weird state where desktop files were allowed to use 
> desktop files but not json.
> 
> This patch makes sure that manifest.json files are also acceptable.
> 
> 
> Diffs
> -
> 
>   autotests/querytest.cpp 0a2f11a 
>   src/kpackage/package.cpp 8416054 
>   src/kpackage/packageloader.cpp 1e1e382 
>   src/kpackage/private/packagejobthread.cpp 444dacc 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
>   src/kpackage/private/packages.cpp 2f6bbcf 
> 
> Diff: https://git.reviewboard.kde.org/r/126348/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass (except for 
> https://build.kde.org/job/kpackage%20master%20stable-kf5-qt5/37/PLATFORM=Linux,compiler=gcc/testReport/,
>  that is not passing in master).
> Adds a test plugin with a json file in it.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 126350: Fixed all Clazy level 1 and level 2 warnings

2015-12-14 Thread Nick Shaforostoff



> On Dec. 14, 2015, 7:10 p.m., Sergio Martins wrote:
> > src/klocalizedstring.cpp, line 389
> > 
> >
> > this will break the build with MSVC, it doesn't support QStringLiteral 
> > with multi-line literals.
> > 
> > (hint:
> > export 
> > CLAZY_EXTRA_OPTIONS="qstring-uneeded-heap-allocations-msvc-compat"
> > )

why QString is used for debug output in the first place?
there is operator<<(const char * s) for latin1 text, which is the case
(i.e. no non-latin symbols are used in the literals)

using strings for debugging output is suboptimal


- Nick


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


On Dec. 14, 2015, 6:46 p.m., Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126350/
> ---
> 
> (Updated Dec. 14, 2015, 6:46 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: ki18n
> 
> 
> Description
> ---
> 
> Fixed `warning: KuitSetup has dtor, copy-ctor but not copy-assignment 
> [-Wclazy-rule-of-three]`
> Fixed `warning: Reserve candidate [-Wclazy-reserve-candidates]`
> Fixed `warning: Use QVariant::toFoo() instead of QVariant::value() 
> [-Wclazy-variant-sanitizer]`
> Fixed `warning: Use midRef() instead [-Wclazy-qstring-ref]`
> Fixed `warning: Pass small and trivially-copyable type by value (const class 
> QChar &) [-Wclazy-foreach]`
> Fixed `warning: QString::fromLatin1() being passed a literal 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(const char*) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> Fixed `warning: QString(QLatin1String) being called 
> [-Wclazy-qstring-uneeded-heap-allocations]`
> 
> 
> Diffs
> -
> 
>   src/kcatalog.cpp 7711e9b 
>   src/klocalizedcontext.cpp 3bc42dd 
>   src/common_helpers.cpp dad7f84 
>   src/klocalizedstring.cpp 69950d2 
>   src/ktranscript.cpp 04dda66 
>   src/kuitmarkup.h d110ca3 
>   src/kuitmarkup.cpp 02b891a 
> 
> Diff: https://git.reviewboard.kde.org/r/126350/diff/
> 
> 
> Testing
> ---
> 
> Automated tests 1,3 and 4 passing.
> Test 2 fails on my system both: after changes and before.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: system tray test?

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

Sebastian Kügler wrote:

>> 
>> I'd suggest replacing the line above with a sequence "m->addAction, m-
>> 
>> >addSeparator" on OS X, or do you have other suggestions?
> 
> Seems to make sense to me. Could you file a review request for this?

Ok, will put that on my todo list :)

Cheers,
R.

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

Jenkins-kde-ci: kdeclarative master kf5-qt5 » Linux,gcc - Build # 64 - Failure!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdeclarative%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/64/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 14 Dec 2015 21:14:23 +
Build duration: 11 sec

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

Jenkins-kde-ci: kdeclarative master stable-kf5-qt5 » Linux,gcc - Build # 65 - Failure!

2015-12-14 Thread no-reply


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kdeclarative%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/65/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 14 Dec 2015 21:14:23 +
Build duration: 10 sec

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

Re: Review Request 126167: Expose QMimeType comment

2015-12-14 Thread Kai Uwe Broulik


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

(Updated Dec. 14, 2015, 9:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Changes
---

Submitted with commit aa412c02657828f68f2ac4a3a303853f255525a5 by Kai Uwe 
Broulik to branch master.


Repository: kdeclarative


Description
---

This allows to show the pretty name ("text file") rather than text/plain


Diffs
-

  src/qmlcontrols/kquickcontrolsaddons/mimedatabase.cpp 73b1d15 

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


Testing
---

Works


Thanks,

Kai Uwe Broulik

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

52 matches

Mail list logo