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

2015-12-07 Thread Martin Graesslin 
On Monday, December 7, 2015 3:54:31 PM CET Mark Gaiser wrote:
> While at it. Why does frameworkintegration force [1] specific fonts upon
> the user?
> 
> It's fine that apparently some folks prefer Oxygen fonts over all else, but
> i thoroughly dislike it.
> I always end up blacklisting it in my pacman manager (pacman, archlinux)
> since 99% of the time when i have font issues, it's because of that package
> being installed.

We cannot find a font which makes everybody happy. This is impossible, so 
please let's not derail the discussion.
> 
> Regarding your proposal. When running KDE apps on something other then
> Plasma, you would also want to have the frameworksintegration plugin to be
> loaded, right?

No. As I outlined, it would not get loaded as the required env variables are 
set by startkde. I doubt that GNOME is announcing the KDE_SESSION_VERSION env 
variable.

> Specially the platformtheme folder with the vastly improved dialogs over
> stock Qt. Remember, those improved dialogs have the power of KIO behind it
> instead of the default Qt support (only the local filesystem)

On other desktop environments it should pick the platform's native dialog. 
E.g. on GNOME we want to give users the GNOME's file dialog to have an 
integrated experience. Please don't start about GNOME's dialog being not that 
good as ours. That's not the point. We want GTK applications to pick our file 
dialog in Plasma and we want our application's to pick GNOME's file dialog in 
GNOME. Our subjective feeling of superior user experience is pointless if the 
user is used to the platform's file dialog.

> 
> I really see value in having that usable in - say - openbox or any other
> non plasma environment where people would want to open KDE applications
> that make use of framework libraries (like KIO).

which is still possible. They need to install the package and set the env 
variables. That's the same as right now: they need to install the package and 
set the env variables. It's not an automagically works anyway.

> 
> Isn't the only plasma specific part the KStyle folder?

No.

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 126241: [OS X] adapting KStyle (WIP)

2015-12-07 Thread Hugo Pereira Da Costa 

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


I honestly have some doubt on the approach (but no counter proposal either)
Basically the file kstyle.mm is a *copy* of the .cpp file, with a couple of 
lines changed. (which I had to track down by 
- downloading the patch
- making an explicit diff of the two files
(which makes reviewing quite difficult/useless)

The mm file has the name, but different extension, and is compiled only for OSX
That means that any future fix (by me, or others) applied to one on a different 
platform will either
- not be ported to the other platform
- be ported blindly without testing (I don't even know how to compile mm on my 
linux box)
Is this really what we want to do ? 

Of course one could also add a common parent class to both the linux and osx 
implementation, that makes 99% of the job (some KStyleBase class), 
but then, wont that break binary compatibility badly for all widget styles that 
inherits these ? (oxygen, breeze)

Finally, the changes applied here only work for kstyle derived styles (oxygen, 
breeze), and not the QStyle based one. (QtCurve ?)

... not convinced. (but not strong objection either)

- Hugo Pereira Da Costa


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

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

Re: Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process

2015-12-07 Thread Aleix Pol Gonzalez 

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

(Updated Dec. 7, 2015, 2:29 p.m.)


Review request for KDE Frameworks.


Changes
---

Another attempt, using Q_COREAPP_STARTUP_FUNCTION.


Repository: kio


Description
---

Prevents the UiDelegate and UiTracker to get initialized, because they'll try 
to create windows and dialogs when some things happen and these will 
immediately end in a crash.


Diffs (updated)
-

  src/widgets/kdynamicjobtracker.cpp 14924d5 

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


Testing
---

Ran the tests, my unit test doesn't crash anymore.


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

2015-12-07 Thread René J . V . Bertin 
On Sunday December 06 2015 14:51:40 David Faure wrote:

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

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

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

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

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

Re: KNotifications filters

2015-12-07 Thread Jeremy Whiting 
Yeah, that makes sense. Ok will do.

On Sun, Dec 6, 2015 at 3:37 AM, David Faure  wrote:
> On Thursday 24 September 2015 20:35:24 Jeremy Whiting wrote:
>>  If so I guess the logical place for it would be a TTS group in
>> kdeglobals, does that make sense?
>
> Stay away from kdeglobals :-)
> It forces every app to parse that stuff even if they don't need it.
>
> Framework-specific config can go into a framework-specific config file,
> it doesn't have to be kdeglobals.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: RFC: split platformtheme plugin from frameworkintegration and

2015-12-07 Thread Jonathan Riddell 
On Mon, Dec 07, 2015 at 03:54:31PM +0100, Mark Gaiser wrote:
> While at it. Why does frameworkintegration force [1] specific fonts upon the
> user?

For the same reason it sets an icon theme, to give Plasma desktops a consistent 
look and feel.  It switches to Noto in 5.5.

Jonathan
___
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-07 Thread Mark Gaiser 
On Mon, Dec 7, 2015 at 1:09 PM, Martin Graesslin  wrote:

> Hi all,
>
> based on the discussion in [1] I propose that we split out platformtheme
> plugin from frameworkintegration into a dedicated repository and move it to
> kde/workspace to be released together with Plasma 5.6.
>
> The main reasoning is that this plugin only gets loaded with env variables
> set
> in startkde anyway, which makes it a Plasma (Desktop) specific plugin. It's
> about integrating Qt application into Plasma and by that pretty useless for
> anything outside Plasma. Moving it to Plasma has in my opinion some
> advantages
> as we can better synchronize the release cycle and also allow us to depend
> on
> libraries provided by workspace [2].
>
> I'd like to get some feedback on the proposal and if this gets positive
> feedback, I'll look into performing the split.
>
> Best Regards
> Martin Gräßlin
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-November/
> 029022.html
> [2]  e.g. I need a dependency to KWayland, which is currently not yet
> possible
> due to KWayland not yet being moved to frameworks.
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
While at it. Why does frameworkintegration force [1] specific fonts upon
the user?

It's fine that apparently some folks prefer Oxygen fonts over all else, but
i thoroughly dislike it.
I always end up blacklisting it in my pacman manager (pacman, archlinux)
since 99% of the time when i have font issues, it's because of that package
being installed.

Imho, it's ok if Plasma "prefers" one font over another (which can be
Oxygen) but it should definitely not force it upon the user.


Regarding your proposal. When running KDE apps on something other then
Plasma, you would also want to have the frameworksintegration plugin to be
loaded, right?
Specially the platformtheme folder with the vastly improved dialogs over
stock Qt. Remember, those improved dialogs have the power of KIO behind it
instead of the default Qt support (only the local filesystem)

I really see value in having that usable in - say - openbox or any other
non plasma environment where people would want to open KDE applications
that make use of framework libraries (like KIO).

Isn't the only plasma specific part the KStyle folder?


[1]
https://quickgit.kde.org/?p=frameworkintegration.git=blob=75dc9b92578577c28288500795198027b4c725ad=fcb3f531ae7161f4ef0768a86db8ce98571f3118=CMakeLists.txt#l72
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126212: Do not crash if KDE platform integration is loaded but SNI is unavailable

2015-12-07 Thread Martin Klapetek 

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

Ship it!


Ship It!

- Martin Klapetek


On Dec. 1, 2015, 1:53 a.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126212/
> ---
> 
> (Updated Dec. 1, 2015, 1:53 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 350785
> https://bugs.kde.org/show_bug.cgi?id=350785
> 
> 
> Repository: knotifications
> 
> 
> Description
> ---
> 
> See bug 350785. The crash is quite nasty, makes dbus allocate all available 
> file descriptors plus hangs the application; worth preventing imo. Yes, the 
> setup leading to this issue is broken, but it's just an env var and it's hard 
> to track down.
> 
> 
> Diffs
> -
> 
>   src/kstatusnotifieritem.cpp c48f4d0 
> 
> Diff: https://git.reviewboard.kde.org/r/126212/diff/
> 
> 
> Testing
> ---
> 
> Now prints an error message instead of crashing.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

___
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-07 Thread René J . V . Bertin 

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


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

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

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

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

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

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

- René J.V. Bertin


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

Jenkins-kde-ci: kio master stable-kf5-qt5 » Linux,gcc - Build # 172 - Unstable!

2015-12-07 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/172/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 07 Dec 2015 13:33:18 +
Build duration: 12 min

CHANGE SET
Revision 4360986c56a39f46ebe6ee1973de54ab84c6bebe by David Faure: (Fix kiod 
asserting in QtDBus, with Qt 5.6.)
  change: edit src/kiod/kiod_main.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 46 test(s), Skipped: 0 test(s), Total: 
47 test(s)Failed: TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24908/50035 
(50%)CONDITIONAL 13464/20761 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7048/7264 
(97%)CONDITIONAL 3854/7069 (55%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7441/14021 
(53%)CONDITIONAL 3891/5395 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7590 
(30%)CONDITIONAL 915/1409 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 
284/412 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 35/35 (100%)CONDITIONAL 
43/52 (83%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 226/256 (88%)CONDITIONAL 
292/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2692/10636 
(25%)CONDITIONAL 1285/1880 (68%)___
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-07 Thread René J . V . Bertin 


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

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


- René J.V.


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


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

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

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

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

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


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


Changes
---

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


Repository: frameworkintegration


Description
---

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

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

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

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

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

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

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

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


Diffs (updated)
-

  src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/CMakeLists.txt 23f590e 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettings.cpp 8adf6c5 
  src/platformtheme/khintssettingsmac.h PRE-CREATION 
  src/platformtheme/khintssettingsmac.mm PRE-CREATION 
  src/platformtheme/main_mac.cpp PRE-CREATION 

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


Testing
---

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

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


File Attachments


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

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

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


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

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

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


- René J.V.


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


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

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

Re: Review Request 126212: Do not crash if KDE platform integration is loaded but SNI is unavailable

2015-12-07 Thread Sven Brauch 

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

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


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit b45544f3d4dd9cb1873b92a609f45a68f5f6e471 by Sven Brauch 
to branch master.


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


Repository: knotifications


Description
---

See bug 350785. The crash is quite nasty, makes dbus allocate all available 
file descriptors plus hangs the application; worth preventing imo. Yes, the 
setup leading to this issue is broken, but it's just an env var and it's hard 
to track down.


Diffs
-

  src/kstatusnotifieritem.cpp c48f4d0 

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


Testing
---

Now prints an error message instead of crashing.


Thanks,

Sven Brauch

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

Re: Review Request 125762: External extractor plugin support for KFileMetaData

2015-12-07 Thread Boudhayan Gupta 


> On Dec. 6, 2015, 5:32 p.m., Vishesh Handa wrote:
> > If you're planning on pushing this please push it to a testing branch. 
> > Untill we actually have some plugins using this we might not be sure of the 
> > API. My points below are quite negative and I was hoping on writing a more 
> > positive email about the different ways to go about this, but I seem to 
> > have been procrastinating and have not written it. Sorry.
> > 
> > My main objections with this -
> > 
> > 1. One cannot choose between external plugins. Since all of them are in 
> > 1-plugin (called ExternalPlugin), and all the mimtypes are just combined. 
> > This matters less in the case of Baloo, but when someone else wants to 
> > choose specific extractors. It's impossible.
> > 
> > 2. Extraction of plain text is simply not supported.
> > 
> > 3. No way to differentiate in the implementation of a plugin. We may get 
> > plugins for the same mimetype using different technologies, perhaps we need 
> > a way to identify which one to choose. Maybe this will never be a problem, 
> > but I'm skeptical.
> > 
> > 4. Contamination of the PATH, maybe we could put them in a different place 
> > which makes it obvious that users should never execute them.
> > 
> > 5. Getting the list of extractors now means running a possibly large number 
> > of executables with possibly bad implementations. They could just get 
> > stuck, and all other plugins will suffer. Perhaps the list of mimetypes 
> > supported could be in a desktop file?

I'm going to sit and think on this for a while.

I wanted to get a minimally invasive solution to the problem, but if you want 
it doen **right**, I'd have to think things through.

I don't think 3 will ever be a problem - I'm suggesting that people will 
install only one plugin per mimetype, if someone wants a plugin using different 
tech, they'll swap out the current plugin (by removing it from their system). 
For 4, we can put the somewhere in libexec. For 5, I don't want to use .desktop 
files. Maybe KPackage based solutions? Or even simpler, a bunch of json files 
in some subdir of /etc.


- Boudhayan


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


On Oct. 24, 2015, 5:49 p.m., Boudhayan Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125762/
> ---
> 
> (Updated Oct. 24, 2015, 5:49 p.m.)
> 
> 
> Review request for Baloo, KDE Frameworks, Pinak Ahuja, and Vishesh Handa.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> This patch introduces support for external metadata extractors in 
> KFileMetaData
> 
> The external extractors themselves can be written in any language, provided 
> that it can be executed as a standalone executable (compiled or script with a 
> hashbang), with command line arguments, and can output data to stdout.
> 
> The extractors are executed like so:
> 
> * `extractor --mimetypes` - outputs a list of mimetypes supported by the 
> extractor, one per line.
> * `extractor filename` - outputs a json document with the metadata. The keys 
> are such that they can be directly used with PropertyInfo::fromName().
> 
> At the KFileMetaData end, an additional internal plugin (ExternalExtractor) 
> is provided that forms a conduit between external extractors and the internal 
> API. This plugin looks for executables called 
> kfilemetadata_extractor_ in /usr/bin to find external extractors, 
> and executes them with the --mimetypes arg to find the list of mimetypes each 
> extractor supports. ExternalExtractor then claims to support all of these 
> mimetypes, and then delegates to the extractor executable when doing the 
> actual extraction.
> 
> 
> Diffs
> -
> 
>   README.md 19b1a26 
>   src/extractors/CMakeLists.txt 5dd223e 
>   src/extractors/externalextractor.h PRE-CREATION 
>   src/extractors/externalextractor.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125762/diff/
> 
> 
> Testing
> ---
> 
> Tested with the sample executable file extractor (as attched, written in 
> python) with the dump manual test in KFileMetaData. Works.
> 
> 
> File Attachments
> 
> 
> kfilemetadata_extractor_executable
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/23/146b657f-31d9-4117-a82f-ef966a6339d4__kfilemetadata_extractor_executable
> 
> 
> Thanks,
> 
> Boudhayan Gupta
> 
>

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

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

2015-12-07 Thread Martin Graesslin 
Hi all,

based on the discussion in [1] I propose that we split out platformtheme 
plugin from frameworkintegration into a dedicated repository and move it to 
kde/workspace to be released together with Plasma 5.6.

The main reasoning is that this plugin only gets loaded with env variables set 
in startkde anyway, which makes it a Plasma (Desktop) specific plugin. It's 
about integrating Qt application into Plasma and by that pretty useless for 
anything outside Plasma. Moving it to Plasma has in my opinion some advantages 
as we can better synchronize the release cycle and also allow us to depend on 
libraries provided by workspace [2].

I'd like to get some feedback on the proposal and if this gets positive 
feedback, I'll look into performing the split.

Best Regards
Martin Gräßlin

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-November/
029022.html
[2]  e.g. I need a dependency to KWayland, which is currently not yet possible 
due to KWayland not yet being moved to frameworks.

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

2015-12-07 Thread Martin Gräßlin 


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

with dtors it makes in-deed sense to mark them as virtual. At least I follow 
that practice to have them always virtual even if I use override for everything 
else. But of course such a change should be a dedicated coding-style commit not 
touching anything else.


- Martin


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


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

Re: Icons missing

2015-12-07 Thread Michael Palimaka 
On 06/12/15 23:56, Thorsten Zachmann wrote:
> Hello all,
> 
> I use a separate user for running calligra. I use ssh -X to login from my 
> normal desktop user to my kde running user. However when I start any
> kde application  I have no icons. With strace I can see it searches for icons 
> in the hicolor folder instead of breeze. 
> With the help of David Faure I found out the the icons are shown as expected 
> when I call
> 
> export KDE_FULL_SESSION=true
> 
> before starting the application.
> 
> I think using an application via ssh -X is used quite often and it should 
> work 
> out of the box with the need of setting any special export. Maybe you have an 
> idea on how the behaviour can be improved. 
> 
> Please CC me as I'm not subscribed to the list.
> 
> Thorsten Zachmann

This is a really nasty regression compared to KDE 4, and I'm surprised
we don't hear about it more often.

Unfortunately I don't have any solution to suggest.


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

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 181 - Fixed!

2015-12-07 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/181/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 07 Dec 2015 16:29:29 +
Build duration: 6 min 54 sec

CHANGE SET
Revision eb7d6cc1cf8632cdf977eeff5c4385bc810ec7ad by Marco Martin: (add a 
window-list icon, needed by plasma mobile)
  change: edit src/desktoptheme/breeze/icons/window.svgz


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3918/10042 
(39%)CONDITIONAL 1941/3082 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 549/564 
(97%)CONDITIONAL 344/618 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 362/2027 
(18%)CONDITIONAL 152/236 (64%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1589/3644 
(44%)CONDITIONAL 794/1220 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 942/1740 
(54%)CONDITIONAL 395/600 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/180 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 476/1774 
(27%)CONDITIONAL 256/408 (63%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 181 - Fixed!

2015-12-07 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/181/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 07 Dec 2015 16:29:29 +
Build duration: 6 min 54 sec

CHANGE SET
Revision eb7d6cc1cf8632cdf977eeff5c4385bc810ec7ad by Marco Martin: (add a 
window-list icon, needed by plasma mobile)
  change: edit src/desktoptheme/breeze/icons/window.svgz


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3918/10042 
(39%)CONDITIONAL 1941/3082 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 549/564 
(97%)CONDITIONAL 344/618 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 362/2027 
(18%)CONDITIONAL 152/236 (64%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1589/3644 
(44%)CONDITIONAL 794/1220 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 942/1740 
(54%)CONDITIONAL 395/600 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/180 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 476/1774 
(27%)CONDITIONAL 256/408 (63%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
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-07 Thread Aleix Pol 
On Mon, Dec 7, 2015 at 1:09 PM, Martin Graesslin  wrote:
> Hi all,
>
> based on the discussion in [1] I propose that we split out platformtheme
> plugin from frameworkintegration into a dedicated repository and move it to
> kde/workspace to be released together with Plasma 5.6.
>
> The main reasoning is that this plugin only gets loaded with env variables set
> in startkde anyway, which makes it a Plasma (Desktop) specific plugin. It's
> about integrating Qt application into Plasma and by that pretty useless for
> anything outside Plasma. Moving it to Plasma has in my opinion some advantages
> as we can better synchronize the release cycle and also allow us to depend on
> libraries provided by workspace [2].
>
> I'd like to get some feedback on the proposal and if this gets positive
> feedback, I'll look into performing the split.
>
> Best Regards
> Martin Gräßlin
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-November/
> 029022.html
> [2]  e.g. I need a dependency to KWayland, which is currently not yet possible
> due to KWayland not yet being moved to frameworks.

+1 I think it's a good idea.

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