Re: KDE Frameworks 5.29.0

[Martin Graesslin]

On Saturday, December 10, 2016 3:47:56 PM CET David Faure wrote:
> On samedi 10 décembre 2016 09:52:06 CET Martin Graesslin wrote:
> > On Thursday, December 8, 2016 9:32:13 AM CET David Faure wrote:
> > > On mercredi 7 décembre 2016 21:06:11 CET Kevin Funk wrote:
> > > > On Wednesday, 7 December 2016 20:10:40 CET Albert Astals Cid wrote:
> > > > > El dimecres, 7 de desembre de 2016, a les 10:08:18 CET, David Faure
> > > > > va
> > > > > 
> > > > > escriure:
> > > > > > On lundi 5 décembre 2016 18:40:46 CET Martin Gräßlin wrote:
> > > > > > > Am 2016-12-05 09:20, schrieb David Faure:
> > > > > > > > On dimanche 4 décembre 2016 23:42:44 CET šumski wrote:
> > > > > > > >> On nedjelja, 4. prosinca 2016. 00:37:52 CET David Faure 
wrote:
> > > > > > > >> > Dear packagers,
> > > > > > > >> > 
> > > > > > > >> > KDE Frameworks 5.29.0 has been uploaded to the usual place.
> > > > > > > >> > 
> > > > > > > >> > New framework: prison
> > > > > > > >> > 
> > > > > > > >> > Public release next Saturday.
> > > > > > > >> > 
> > > > > > > >> > Thanks for the packaging work!
> > > > > > > >> 
> > > > > > > >> kconfig (r129382) breaks compilation of kdevplatform:
> > > > > > > >> http://paste.opensuse.org/82016854
> > > > > > > > 
> > > > > > > > Indeed (but it's not the change from RR 129382, it's commit
> > > > > > > > cd4e650
> > > > > > > > from
> > > > > > > > https://phabricator.kde.org/D3386
> > > > > > > > 
> > > > > > > > Seems to come from Inherits=BaseClass while BaseClass doesn't
> > > > > > > > use
> > > > > > > > arg="true".
> > > > > > > > 
> > > > > > > > Here's a testcase for the kconfig unittests. Martin, can you
> > > > > > > > take
> > > > > > > > a
> > > > > > > > look?
> > > > > > > 
> > > > > > > The earliest I can have a look is probably on Friday, I'm sorry.
> > > > > > > 
> > > > > > > My suggestion is to revert my two commits and I'll redo for next
> > > > > > > frameworks.
> > > > > > 
> > > > > > OK, done. New git tag and tarball:
> > > > > > 
> > > > > > kconfig v5.29.0-rc2
> > > > > > 47f7e954a58ba5538d055e2f75e483cade48ee8a
> > > > > > d6c12e0908de1b91529de15e75a52c9974685c91b423d5b5abeb06f261d0fa47
> > > > > > sources/kconfig-5.29.0.tar.xz
> > > > > 
> > > > > Acoording to kfunk the thing that broke kdevplatform wasn't really
> > > > > kconfigs
> > > > > fault but a side effect of kdevplatform code not being very good.
> > > > 
> > > > Heya,
> > > > 
> > > > the patch restoring the kdevplatform build with KF5 5.29:
> > > >   https://cgit.kde.org/kdevplatform.git/commit/?
> > > > 
> > > > id=e84645d1694bdad7f179cd41babce723fe07aa63
> > > > 
> > > > The code in kdevplatform is a bit special, it's probably the only
> > > > place
> > > > in
> > > > whole KDE which broke due to the recent changes in kconfig. I don't
> > > > see
> > > > an
> > > > easy migration path, even if you introduce said change in a later
> > > > kconfig
> > > > release.
> > > > 
> > > > I don't mind if you leave kconfig as-is. But that's probably something
> > > > for
> > > > dfaure to decide.
> > > 
> > > Well, the change to kdevplatform isn't released yet, so kconfig 5.29-rc1
> > > would break compilation of the current kdevplatform releases.
> > > 
> > > Also, the fact that I'm able to write a kconfig unittest that doesn't
> > > compile tells me that something isn't right with these kconfig changes
> > > ---
> > > unless it can be proven that what I'm doing in that new test is not
> > > meaningful and is (now) forbidden, in which case it should

Stepping down as KGlobalAccel maintainer

[Martin Graesslin]

Hi frameworks developers,

I decided to step down as the maintainer of KGlobalAccel. I haven't done any 
work on KGlobalAccel this year and bug reports just linger. A big problem for 
me maintaining KGlobalAccel is that most work is needed in the X11 
implementation. As I no longer use X11 and cannot simulate it under Wayland I 
don't think I'm in any position to further maintain KGlobalAccel. Also this is 
something I don't expect to change in future. I don't see myself switching 
into an X11 session just to investigate a bug in KGlobalAccel.

I hope that we find an interested developer to take over the maintainership. 
Best would be someone with X11 knowledge.

Best Regards
Martin Gräßlin

Re: ATTN: latest changes in breeze-icons make packaging untenable

[Martin Graesslin]

On Tuesday, October 25, 2016 4:47:40 PM CEST Luca Beltrame wrote:
> Hello,
> 
> recent changes in breeze broke building in openSUSE's OBS: after a
> discussion on IRC, it turned out that there were incorrect symlinks.
> Adjustments were made in order to preserve space. However, while
> harmless at first (I didn't notice earlier, and CI was green) these
> changes *break* packaging for most systems.
> 
> The reason? Directories became symlinks, hence a package manager can't
> fix that, it will totally break when a package updates (because it will
> try to symlink something existent).
> 
> Therefore there is *no* way the current state of breeze-icons can be
> installed a the moment by any sane distribution. No problem for now,
> but Frameworks are monthly releases, so...
> 
> This needs to be fixed, even if at the cost of wasting space (but
> making packagers much happier).
> 
> If there's no consensus, I will revert these commits [1][2][3][4] in
> breeze-icons by Sunday morning.

+1 go for it. Sorry for the problems this caused to distros. As a reminder to 
our devs and designers: frameworks have a review policy. the commits mentioned 
by Luca have no Review hint. Please don't push without prior review - 
especially not if you change something like that. We could have get the 
expertise in during the review.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: KF5/Qt5 and multiple QPAs

[Martin Graesslin]

On Wednesday, September 21, 2016 10:14:33 PM CEST René J.V. Bertin wrote:
> Hi,
> 
> Am I correct that Qt now provides a Wayland QPA and that users on Linux can
> now decide, in principle "on the fly" which displaying protocol a newly
> started application is going to use, presumably with a platform-wide
> default either hardwired into Qt or defined in some settings file?

That's correct. This mail is written in a kmail on --platform xcb in a Wayland 
session.

> 
> If so, how does that work out with KF5 applications that get started by
> others? Say, a user with a Wayland-based desktop logs in over ssh+X11 and
> wants to run kate remotely with `kate -platform xcb`. A new session dbus
> will be started, and during Kate's start-up sequence kdeinit5 will start
> which will then start klauncher.
> 
> I just tried this on OS X (I have a working XCB QPA on my system, plus a
> patched dbus that works without launchd). kdeinit5 starts up fine because
> it's not a GUI app (I think), but klauncher is. It doesn't inherit the
> `-platform xcb` arguments, and thus fails because the Cocoa QPA only works
> locally.
> 
> Mostly asking out of curiosity, though I would of course appreciate it if on
> occasion I could use applications like Kate remotely.

That's something I have never tried and I think is a corner case. In case of 
starting a new dbus session it would be enough to just do an
export QT_QPA_PLATFORM=xcb

prior to starting any remote application. That will force all to use the xcb 
platform. Which is what you want in a remote situation.

But I need to remind that the x11 over the network is broken. It just doesn't 
work and I highly suggest to look into different solutions for this. If it 
breaks, it breaks and that's a good thing!

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: C++11 & friends

[Martin Graesslin]

On Sunday, September 11, 2016 3:21:21 AM CEST Dominik Haumann wrote:
> Hi all,
> 
> I just saw a commit by Volker turning nullptr into Q_NULLPTR with the
> comment that Visual Studio 2012 does not support nullptr.
> 
> While this change is trivial for obvious reasons, do we really need to do
> that?
> 
> I am raising this question especially since KTextEditor seems to use
> 'nullptr' in several locations now for several releases - and noone
> complained.

I have said so in the past and I will continue to say this: as long as we 
don't have a CI system which can verify the C++11 subset we are allowed to 
use, it's pointless to try to restrict the usage. We are humans and no 
compilers. Nobody can expect that we remember which calls are allowed and 
which not if we have C++14 compliant compilers.

To me the only relevant and allowed subset of C++ is the one which compiles on 
build.kde.org.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Failing unittests

[Martin Graesslin]

On Saturday, August 6, 2016 8:12:06 PM CEST David Faure wrote:
> Today is KF 5.25 tagging day, but the CI isn't green...
> kwayland: testWaylandFullscreenShell fails

Sorry about that. It's caused by a newer weston version [1] which got 
installed on Friday on build.kde.org. I just pushed a fix which QSKIPs if the 
old interface is not announced.

Cheers
Martin

[1] The Weston specific fullscreen shell extension got moved to Wayland 
Protocols and renamed to the conventions there.



signature.asc
Description: This is a digitally signed message part.

Re: Where to put kwayland integration plugins

[Martin Graesslin]

On Wednesday, July 6, 2016 12:16:09 AM CEST Albert Astals Cid wrote:
> El dissabte, 2 de juliol de 2016, a les 15:25:39 CEST, Martin Graesslin va
> 
> escriure:
> > On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote:
> > > On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote:
> > > > On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraess...@kde.org>
> > 
> > wrote:
> > > > > Hi framework-developers,
> > > > > 
> > > > > in Plasma we have a repository called kwayland-integration. It
> > > > > provides
> > > > > a
> > > > > plugin for:
> > > > > * KWindowSystem
> > > > > * KIdleTime
> > > > > 
> > > > > using the KWayland client API. Thus it makes these frameworks
> > > > > functional
> > > > > on
> > > > > windowing system Wayland.
> > > > > 
> > > > > I want to move the plugins into frameworks and are wondering how to
> > > > > do
> > > > > that
> > > > > and where to move them to.
> > > > > 
> > > > > I see the following options:
> > > > > 1. Integrate directly into kwindowsystem and kidletime
> > > > > 2. Merge them into frameworks-integration
> > > > > 3. Create a new framework kwayland-integration
> > > > > 4. create a new framework "kwindowsystem-wayland" and
> > > > > "kidletime-wayland"
> > > > > 
> > > > > Option 1 is I think an absolute no-no as it would turn kwindowsystem
> > > > > and
> > > > > kidletime from tier 1 to tier 2 and that would affect a huge amount
> > > > > of
> > > > > other frameworks. For everything which is not in tier 1, I think
> > > > > it's
> > > > > the
> > > > > way to go.
> > > > > 
> > > > > Option 2 is something I don't want to do as that would combine
> > > > > windowing
> > > > > system integration code with random other stuff and would result in
> > > > > weird
> > > > > dependencies. (To use KIdleTime on Wayland one needs X11 and
> > > > > Phonon?)
> > > > > 
> > > > > The same actually also applies to Option 3, though it is just two
> > > > > frameworks and all dependencies would be tier 1.
> > > > > 
> > > > > So personally I think option 3 or option 4 are the way to go.
> > > > > 
> > > > > What do you think? Better ideas?
> > > > 
> > > > I agree ideally it's 3 or 4. Where do you have it now? Are they
> > > > already separate repositories? If so, just moving them to frameworks
> > > > could make sense.
> > > > 
> > > > In Purpose I have a similar problem (and I know the discussion is also
> > > > relevant for other frameworks). We usually don't want plugins to raise
> > > > the tier of your base framework, but you still need them to be
> > > > distributed together and either way you need to make sure the plugins
> > > > will be available when the system is deployed (which is actually much
> > > > easier in option 1).
> > > 
> > > The alternative is to use option 1 with a cmake option to disable the
> > > kwayland-based plugin. This offers benefits because
> > > - on systems with wayland enabled, you are sure the plugin is present
> > > (no
> > > bug report like "idle detection doesn't work" (because of a missing
> > > package)) - on systems where dependencies should be kept to a minimum
> > > (e.g.
> > > an X11-based embedded system) one can easily compile without the
> > > kwayland
> > > dependency
> > > 
> > > Application developers using KIdleTime or KWindowSystem do expect it to
> > > work on all platforms where the application works, so surely a
> > > dependency
> > > on kwayland can't be a problem on wayland.
> > 
> > That's actually not the case. Both KIdleTime and KWindowSystem (runtime)
> > depend on additional Wayland protocols currently only provided in KWin/
> > Wayland. That means your KIdleTime based application won't work in e.g.
> > GNOME.
> > 
> > Given that the real world benefit of option 1 is not that large.
> 
> I'm confused by this, rsibreak uses "KIdleTime::instance()->idleTime()" when
> you say it won't work in GNOME, you mean "GNOME Wayland" or "any GNOME at
> all"?

GNOME Wayland.

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: Where to put kwayland integration plugins

[Martin Graesslin]

On Saturday, July 2, 2016 8:59:28 PM CEST you wrote:
> On samedi 2 juillet 2016 15:25:39 CEST Martin Graesslin wrote:
> > On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote:
> > > On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote:
> > > > On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraess...@kde.org>
> > 
> > wrote:
> > > > > Hi framework-developers,
> > > > > 
> > > > > in Plasma we have a repository called kwayland-integration. It
> > > > > provides
> > > > > a
> > > > > plugin for:
> > > > > * KWindowSystem
> > > > > * KIdleTime
> > > > > 
> > > > > using the KWayland client API. Thus it makes these frameworks
> > > > > functional
> > > > > on
> > > > > windowing system Wayland.
> > > > > 
> > > > > I want to move the plugins into frameworks and are wondering how to
> > > > > do
> > > > > that
> > > > > and where to move them to.
> > > > > 
> > > > > I see the following options:
> > > > > 1. Integrate directly into kwindowsystem and kidletime
> > > > > 2. Merge them into frameworks-integration
> > > > > 3. Create a new framework kwayland-integration
> > > > > 4. create a new framework "kwindowsystem-wayland" and
> > > > > "kidletime-wayland"
> > > > > 
> > > > > Option 1 is I think an absolute no-no as it would turn kwindowsystem
> > > > > and
> > > > > kidletime from tier 1 to tier 2 and that would affect a huge amount
> > > > > of
> > > > > other frameworks. For everything which is not in tier 1, I think
> > > > > it's
> > > > > the
> > > > > way to go.
> > > > > 
> > > > > Option 2 is something I don't want to do as that would combine
> > > > > windowing
> > > > > system integration code with random other stuff and would result in
> > > > > weird
> > > > > dependencies. (To use KIdleTime on Wayland one needs X11 and
> > > > > Phonon?)
> > > > > 
> > > > > The same actually also applies to Option 3, though it is just two
> > > > > frameworks and all dependencies would be tier 1.
> > > > > 
> > > > > So personally I think option 3 or option 4 are the way to go.
> > > > > 
> > > > > What do you think? Better ideas?
> > > > 
> > > > I agree ideally it's 3 or 4. Where do you have it now? Are they
> > > > already separate repositories? If so, just moving them to frameworks
> > > > could make sense.
> > > > 
> > > > In Purpose I have a similar problem (and I know the discussion is also
> > > > relevant for other frameworks). We usually don't want plugins to raise
> > > > the tier of your base framework, but you still need them to be
> > > > distributed together and either way you need to make sure the plugins
> > > > will be available when the system is deployed (which is actually much
> > > > easier in option 1).
> > > 
> > > The alternative is to use option 1 with a cmake option to disable the
> > > kwayland-based plugin. This offers benefits because
> > > - on systems with wayland enabled, you are sure the plugin is present
> > > (no
> > > bug report like "idle detection doesn't work" (because of a missing
> > > package)) - on systems where dependencies should be kept to a minimum
> > > (e.g.
> > > an X11-based embedded system) one can easily compile without the
> > > kwayland
> > > dependency
> > > 
> > > Application developers using KIdleTime or KWindowSystem do expect it to
> > > work on all platforms where the application works, so surely a
> > > dependency
> > > on kwayland can't be a problem on wayland.
> > 
> > That's actually not the case. Both KIdleTime and KWindowSystem (runtime)
> > depend on additional Wayland protocols currently only provided in KWin/
> > Wayland. That means your KIdleTime based application won't work in e.g.
> > GNOME.
> 
> OK so things are less interoperable than I thought
>   -- so much for "whatever the problem is, wayland will fix it!" ;-)

Only currently. I hope to see at least the idletime integration getting 
standardized.

> 
> However that only makes my last paragraph moot, not the rest of the
> argument, AFAICS.
> 
> In fact it even leads to another possible solution : if these plugins are
> only useful in Plasma5, then there's no problem with putting them into
> plasma- integration, is there?

Except that e.g. LXQt might use KWin and then they need it. But given that 
KWin is from Plasma one could argue that they should also use kwayland-
integration from Plasma.

Ok, I'll leave it as it is for now and will reevaluate the situation once we 
have the protocols standardized.

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: Where to put kwayland integration plugins

[Martin Graesslin]

On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote:
> On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote:
> > On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > > Hi framework-developers,
> > > 
> > > in Plasma we have a repository called kwayland-integration. It provides
> > > a
> > > plugin for:
> > > * KWindowSystem
> > > * KIdleTime
> > > 
> > > using the KWayland client API. Thus it makes these frameworks functional
> > > on
> > > windowing system Wayland.
> > > 
> > > I want to move the plugins into frameworks and are wondering how to do
> > > that
> > > and where to move them to.
> > > 
> > > I see the following options:
> > > 1. Integrate directly into kwindowsystem and kidletime
> > > 2. Merge them into frameworks-integration
> > > 3. Create a new framework kwayland-integration
> > > 4. create a new framework "kwindowsystem-wayland" and
> > > "kidletime-wayland"
> > > 
> > > Option 1 is I think an absolute no-no as it would turn kwindowsystem and
> > > kidletime from tier 1 to tier 2 and that would affect a huge amount of
> > > other frameworks. For everything which is not in tier 1, I think it's
> > > the
> > > way to go.
> > > 
> > > Option 2 is something I don't want to do as that would combine windowing
> > > system integration code with random other stuff and would result in
> > > weird
> > > dependencies. (To use KIdleTime on Wayland one needs X11 and Phonon?)
> > > 
> > > The same actually also applies to Option 3, though it is just two
> > > frameworks and all dependencies would be tier 1.
> > > 
> > > So personally I think option 3 or option 4 are the way to go.
> > > 
> > > What do you think? Better ideas?
> > 
> > I agree ideally it's 3 or 4. Where do you have it now? Are they
> > already separate repositories? If so, just moving them to frameworks
> > could make sense.
> > 
> > In Purpose I have a similar problem (and I know the discussion is also
> > relevant for other frameworks). We usually don't want plugins to raise
> > the tier of your base framework, but you still need them to be
> > distributed together and either way you need to make sure the plugins
> > will be available when the system is deployed (which is actually much
> > easier in option 1).
> 
> The alternative is to use option 1 with a cmake option to disable the
> kwayland-based plugin. This offers benefits because
> - on systems with wayland enabled, you are sure the plugin is present (no
> bug report like "idle detection doesn't work" (because of a missing
> package)) - on systems where dependencies should be kept to a minimum (e.g.
> an X11-based embedded system) one can easily compile without the kwayland
> dependency
> 
> Application developers using KIdleTime or KWindowSystem do expect it to work
> on all platforms where the application works, so surely a dependency on
> kwayland can't be a problem on wayland.

That's actually not the case. Both KIdleTime and KWindowSystem (runtime) 
depend on additional Wayland protocols currently only provided in KWin/
Wayland. That means your KIdleTime based application won't work in e.g. GNOME.

Given that the real world benefit of option 1 is not that large.

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: Replacing the "- name: All" platform wildcard

[Martin Graesslin]

On Wednesday, June 15, 2016 11:18:40 AM CEST Andreas Cord-Landwehr wrote:
> On Wednesday, June 15, 2016 11:01:14 AM CEST Martin Graesslin wrote:
> > On Wednesday, June 15, 2016 10:16:19 AM CEST Andreas Cord-Landwehr wrote:
> > > Hey all,
> > > 
> > > in preparation for getting information about Android as supported
> > > platform
> > > on api.kde.org, I would like to purge the "- name: All" platform
> > > wildcard
> > > 
> > > from all metainfo.yaml files and replace it by:
> > > - name: Linux
> > > - name: Windows
> > > - name: MacOSX
> > 
> > As you are preparing this for Android: is the name Linux correct, if yes
> > what is it supposed to tell us? That it works on GNU/Linux, but not on
> > Android/ Linux or that it works on Linux/X11, but not on Linux/Android?
> 
> Hi, sorry for the confusion. This is only a preparation step that does not
> change any logic in apidox, but just removes the All wildcard.
> In a second step, I want to add the Android information with "- name:
> Android" for the about 15 frameworks that already work with Android.
> The wildcard has to be removed first, since otherwise all frameworks would
> declare to support Android once the overview page says that we (partially)
> support Android.

there's no confusion. I did understand that. But as Android is clearly I'm 
questioning what Linux is supposed to tell us and whether it's better to 
directly change it with something which better expresses the Linux but not 
Android condition. After all it cannot be about the kernel.

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: Replacing the "- name: All" platform wildcard

[Martin Graesslin]

On Wednesday, June 15, 2016 10:16:19 AM CEST Andreas Cord-Landwehr wrote:
> Hey all,
> 
> in preparation for getting information about Android as supported platform
> on api.kde.org, I would like to purge the "- name: All" platform wildcard
> from all metainfo.yaml files and replace it by:
> - name: Linux
> - name: Windows
> - name: MacOSX

As you are preparing this for Android: is the name Linux correct, if yes what 
is it supposed to tell us? That it works on GNU/Linux, but not on Android/
Linux or that it works on Linux/X11, but not on Linux/Android?

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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Monday, June 6, 2016 1:29:51 PM CEST Jaroslaw Staniek wrote:
> On 6 June 2016 at 13:04, Martin Graesslin <mgraess...@kde.org> wrote:
> > On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> > > On 30 May 2016 at 17:11, Michael Pyne <mp...@kde.org> wrote:
> > > > On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote:
> > > > > On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote:
> > > > > > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote:
> > > > > > > All in all, If nobody just noted an issue with the licensing
> > 
> > above
> > 
> > > > maybe
> > > > 
> > > > > > > nobody tried to place/distribute a non-GPL software on top of
> > > > > > > Plasma?
> > > > > > > That
> > > > > > > would be the worst news of all to me.
> > > > > > > 
> > > > > > > Please speak up someone else because it's a matter of KDE, not
> > 
> > just
> > 
> > > > > > > a
> > > > > > > single desktop shell. Maybe some voting fits here.
> > > > > > 
> > > > > > I've only been able to keep track of the margins of the thread but
> > 
> > I
> > 
> > > > will
> > > > 
> > > > > > admit that it seems surprising that we would use code licensing as
> > 
> > a
> > 
> > > > means
> > > > 
> > > > > > to either enforce the exclusiveness of Plasma's artwork above and
> > > > 
> > > > beyond
> > > > 
> > > > > > the existing license for the artwork, or to prevent applications
> > > > 
> > > > running
> > > > 
> > > > > > on
> > > > > > KDE frameworks (but outside of Plasma) from supplying an
> > 
> > alternative
> > 
> > > > > > KDE-authored QStyle.
> > > > > 
> > > > > heh, that's certainly not the case here. This is not trying to force
> > 
> > our
> > 
> > > > > style to be only used in Plasma. That would be a ridiculous stance
> > 
> > from
> > 
> > > > my
> > > > 
> > > > > side.
> > > > > 
> > > > > I want to have my code stay GPL. I don't think that the breeze code
> > > > 
> > > > needs to
> > > > 
> > > > > be licenced in a way that it can be copied into 3rd party
> > 
> > applications.
> > 
> > > > > That's all. It has nothing to do with enforcing anything, it's just
> > > > > about
> > > > 
> > > > ​​
> > > > ​​
> > > > t
> > > > ​​
> > > > he
> > > > ​​
> > > > actual implementation should stay GPL in my opinion.
> > > > 
> > > > Alright, my apologies for misunderstanding and then misrepresenting
> > 
> > your
> > 
> > > > position. Certainly
> > > > ​​
> > > > code licensing is every developer's choice to make, and
> > > > I'm not sure of better ways than what you're doing to avoid
> > > > third-party
> > > > apps
> > > > from easily cloning the code behind the style (even if it means more
> > > > difficulty for non-GPL KDE apps outside of Plasma).
> > > 
> > > ​
> > > Please let me repeat​ (and cover this and any potential similar cases in
> > > the future): this blocking avoids *any* reuse for non-GPL code no matter
> > 
> > if
> > 
> > > via copying or linking (either via private APIs, eventually
> > > framework-ify
> > > that _if_ it pays off). It's hard to assume Martin did not
> > 
> > read/understand
> > 
> > > my explanation of the use cases and the technicals.
> > > 
> > > ​Since when LGPL (versus GPL) decrease code reuse?​ Conversely, GPL
> > > means
> > > less chance for collaborating on shared code.
> > 
> > If you really want to be able to reuse the code as one wishes it needs to
> > be
> > MIT/BSD licensed. Otherwise it's just working for your personal use case
> > that
> > your LGPL based application (or whatever) can use it.
> > 
> > Making the code LGPL won't fix the "problem" of not reusing the code. I'm
> > not
> > open to discuss changing the licence away from GPL due to

Re: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> On 30 May 2016 at 17:11, Michael Pyne <mp...@kde.org> wrote:
> > On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote:
> > > On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote:
> > > > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote:
> > > > > All in all, If nobody just noted an issue with the licensing above
> > 
> > maybe
> > 
> > > > > nobody tried to place/distribute a non-GPL software on top of
> > > > > Plasma?
> > > > > That
> > > > > would be the worst news of all to me.
> > > > > 
> > > > > Please speak up someone else because it's a matter of KDE, not just
> > > > > a
> > > > > single desktop shell. Maybe some voting fits here.
> > > > 
> > > > I've only been able to keep track of the margins of the thread but I
> > 
> > will
> > 
> > > > admit that it seems surprising that we would use code licensing as a
> > 
> > means
> > 
> > > > to either enforce the exclusiveness of Plasma's artwork above and
> > 
> > beyond
> > 
> > > > the existing license for the artwork, or to prevent applications
> > 
> > running
> > 
> > > > on
> > > > KDE frameworks (but outside of Plasma) from supplying an alternative
> > > > KDE-authored QStyle.
> > > 
> > > heh, that's certainly not the case here. This is not trying to force our
> > > style to be only used in Plasma. That would be a ridiculous stance from
> > 
> > my
> > 
> > > side.
> > > 
> > > I want to have my code stay GPL. I don't think that the breeze code
> > 
> > needs to
> > 
> > > be licenced in a way that it can be copied into 3rd party applications.
> > > That's all. It has nothing to do with enforcing anything, it's just
> > > about
> > 
> > ​​
> > ​​
> > t
> > ​​
> > he
> > ​​
> > actual implementation should stay GPL in my opinion.
> > 
> > Alright, my apologies for misunderstanding and then misrepresenting your
> > position. Certainly
> > ​​
> > code licensing is every developer's choice to make, and
> > I'm not sure of better ways than what you're doing to avoid third-party
> > apps
> > from easily cloning the code behind the style (even if it means more
> > difficulty for non-GPL KDE apps outside of Plasma).
> 
> ​
> Please let me repeat​ (and cover this and any potential similar cases in
> the future): this blocking avoids *any* reuse for non-GPL code no matter if
> via copying or linking (either via private APIs, eventually framework-ify
> that _if_ it pays off). It's hard to assume Martin did not read/understand
> my explanation of the use cases and the technicals.
> 
> ​Since when LGPL (versus GPL) decrease code reuse?​ Conversely, GPL means
> less chance for collaborating on shared code.

If you really want to be able to reuse the code as one wishes it needs to be 
MIT/BSD licensed. Otherwise it's just working for your personal use case that 
your LGPL based application (or whatever) can use it.

Making the code LGPL won't fix the "problem" of not reusing the code. I'm not 
open to discuss changing the licence away from GPL due to that. LGPL won't 
solve the problem and BSD style license I'm not comfortable with.

If the code were a library (which it isn't) LGPL could be an option. But it 
isn't and nobody wants to turn it into a library. It's a mood point.

Sorry to having to deny your relicence request. I want my code contributions 
to be GPL by default, LGPL is for me already a hard exception which must have 
strong understandable reasons (like a library one wants to use, which breeze 
isn't).

Btw. I'm very unhappy with the level of pressure you are exposing here by 
bringing it up again and again.

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: Where to put kwayland integration plugins

[Martin Graesslin]

On Monday, June 6, 2016 11:26:58 AM CEST Aleix Pol wrote:
> On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraess...@kde.org> wrote:
> > Hi framework-developers,
> > 
> > in Plasma we have a repository called kwayland-integration. It provides a
> > plugin for:
> > * KWindowSystem
> > * KIdleTime
> > 
> > using the KWayland client API. Thus it makes these frameworks functional
> > on
> > windowing system Wayland.
> > 
> > I want to move the plugins into frameworks and are wondering how to do
> > that
> > and where to move them to.
> > 
> > I see the following options:
> > 1. Integrate directly into kwindowsystem and kidletime
> > 2. Merge them into frameworks-integration
> > 3. Create a new framework kwayland-integration
> > 4. create a new framework "kwindowsystem-wayland" and "kidletime-wayland"
> > 
> > Option 1 is I think an absolute no-no as it would turn kwindowsystem and
> > kidletime from tier 1 to tier 2 and that would affect a huge amount of
> > other frameworks. For everything which is not in tier 1, I think it's the
> > way to go.
> > 
> > Option 2 is something I don't want to do as that would combine windowing
> > system integration code with random other stuff and would result in weird
> > dependencies. (To use KIdleTime on Wayland one needs X11 and Phonon?)
> > 
> > The same actually also applies to Option 3, though it is just two
> > frameworks and all dependencies would be tier 1.
> > 
> > So personally I think option 3 or option 4 are the way to go.
> > 
> > What do you think? Better ideas?
> 
> I agree ideally it's 3 or 4. Where do you have it now? Are they
> already separate repositories? If so, just moving them to frameworks
> could make sense.

they are currently part of plasma in a dedicated repository called "kwayland-
integration". Each of the two plugins is in a dedicated source directory, so 
both option 3 and 4 could be easily done.

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

Where to put kwayland integration plugins

[Martin Graesslin]

Hi framework-developers,

in Plasma we have a repository called kwayland-integration. It provides a 
plugin for:
* KWindowSystem
* KIdleTime

using the KWayland client API. Thus it makes these frameworks functional on 
windowing system Wayland.

I want to move the plugins into frameworks and are wondering how to do that 
and where to move them to.

I see the following options:
1. Integrate directly into kwindowsystem and kidletime
2. Merge them into frameworks-integration
3. Create a new framework kwayland-integration
4. create a new framework "kwindowsystem-wayland" and "kidletime-wayland"

Option 1 is I think an absolute no-no as it would turn kwindowsystem and 
kidletime from tier 1 to tier 2 and that would affect a huge amount of other 
frameworks. For everything which is not in tier 1, I think it's the way to go.

Option 2 is something I don't want to do as that would combine windowing 
system integration code with random other stuff and would result in weird 
dependencies. (To use KIdleTime on Wayland one needs X11 and Phonon?)

The same actually also applies to Option 3, though it is just two frameworks 
and all dependencies would be tier 1.

So personally I think option 3 or option 4 are the way to go.

What do you think? Better ideas?

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: QGlobalStatic and windowing specific calls in dtor

[Martin Graesslin]

On Monday, May 30, 2016 5:50:23 PM CEST Aleix Pol wrote:
> On Mon, May 30, 2016 at 4:25 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > Hi frameworks-dev,
> > 
> > I have a problem with my KWayland based plugin for KIdleTime. KIdleTime
> > uses a QGlobalStatic, so it gets destroyed at exit-time. At that point
> > the QGuiApplication and the qpa plugin does not exist any more, so any
> > windowing system specific calls will fail.
> > 
> > In the case of the KWayland based plugin, KWayland performs cleanup calls
> > which crash as the wayland connection got already destroyed. In principle
> > the same could also happen for the other plugins - they just don't
> > perform any cleanup and prefer to leak X resources.
> > 
> > So what's the best way to handle such a situation? How can I tear-down the
> > plugin in a clean way without crashing?
> 
> It should clean up when aboutToQuit is emitted.
> http://doc.qt.io/qt-5/qcoreapplication.html#aboutToQuit

Thanks, yes that should work. Though just when I wanted to reproduce the 
actual problem I failed to do so. /me is confused.

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: kwindowsystem crashes

[Martin Graesslin]

On Monday, May 30, 2016 11:36:54 AM CEST Kurt Hindenburg wrote:
> There are a number of lines that division by zero could happen in
> frameworks/kwindowsystem/src/platforms/xcb/kwindowsystem.cpp  if
> displayGeometry returns a 0 QRect.  I think that is what is happening with
> bug 349512.

urgh. That means that there are no QScreens with a size.

> 
> viewportToDesktop, viewportWindowToDesktop, desktopToViewport
> 
> I’m not clear on the best way to prevent this.  Forcing displayGeometry to
> never return a 0 QRect (which seem the best) or by checking all the
> locations of division by 0.

If the size is 0/0 then returning a false size looks incorrect to me. On the 
other hand it means that we are in an intermediate state - no screens is not a 
valid setup.

So my suggestion would be to change line 75 to only update the displayGeometry 
if region.boundingRect() is not empty.

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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote:
> On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote:
> > All in all, If nobody just noted an issue with the licensing above maybe
> > nobody tried to place/distribute a non-GPL software on top of Plasma? That
> > would be the worst news of all to me.
> > 
> > Please speak up someone else because it's a matter of KDE, not just a
> > single desktop shell. Maybe some voting fits here.
> 
> I've only been able to keep track of the margins of the thread but I will
> admit that it seems surprising that we would use code licensing as a means
> to either enforce the exclusiveness of Plasma's artwork above and beyond
> the existing license for the artwork, or to prevent applications running on
> KDE frameworks (but outside of Plasma) from supplying an alternative
> KDE-authored QStyle.

heh, that's certainly not the case here. This is not trying to force our style 
to be only used in Plasma. That would be a ridiculous stance from my side.

I want to have my code stay GPL. I don't think that the breeze code needs to 
be licenced in a way that it can be copied into 3rd party applications. That's 
all. It has nothing to do with enforcing anything, it's just about the actual 
implementation should stay GPL in my opinion.

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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
> So we, in KDE, lack LGPL style code for our de-facto official look and feel.

This is the crucial point. Breeze is not the de-facto official look and feel of 
KDE. It's the look and feel of Plasma. Applications shouldn't use it. 
Applications of course can use it as much as they want. Nobody is going to 
forbid it. But the fact that they use it, doesn't make it the de-facto official 
look and feel and doesn't mean that we have to licence the style as LGPL.

I stay where I am: I am not agreeing to having my code in Breeze (and Oxygen) 
being relicensed to LGPL. I don't see a need for it, I think GPL is the right 
choice for that code.

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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:
> On 17 May 2016 at 20:38, Martin Graesslin <mgraess...@kde.org> wrote:
> > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > > > If you show me why it needs to be a framework and I agree with it,
> > > > I might be willing to consider to allow to relicense the code I wrote
> > 
> > for
> > 
> > > > it.
> > > 
> > > There's no request to make it framework from me. LGPLing Breeze does not
> > > automatically add obligation to create and maintain a framweork.
> > 
> > Especially
> > 
> > > that there are not widely declared use cases. It's just a way to get the
> > > same what was legal in the times of Oxygen and KDElibs 4.
> > 
> > Yes exactly! If you would present me reasons why it should become a
> > framework
> > I might see a need for it to have it LGPL. That is something I currently
> > don't
> > see. Thus I don't see a reason to change it to LGPL.
> 
> But there's no rule in KDE that LGPL code needs to form frameworks.
> No need to switch the topic... Adding a framework is a lot of
> responsibility I am aware of and I don't request more work from others.
> We had an agreement within KDE organization that there's not even rule
> that​ KDE projects have to use C++ or Qt. People can implement things in
> HTML or C# or Java. Unless licenses stay against it but I see no reason why
> would be that.
> 
> > Similar I don't relicense KWin to LGPL, just because there might be a
> > reason
> > later on.  When we split out code from KWin to KWayland we did the
> > relicense
> > as needed.
> 
> ​You see​, authors have the benefit of re-licensing when _they_ need.
> I am not the author and have to face unusual extensive testing of my
> reasoning.

You are asking me as a copyright holder whether I agree to a relicense. You 
have to convince me. To me the default licence is GPLv3+. Everything else 
means an exception to my personal view. You have to provide really good 
reasons to make me agree that this is needed.

So far I have not seen them. It is more a wishy-washy about you want to use 
some code. That's not a reasoning. Explain why you need it and explain it that 
makes sense with our overall KDE vision about applications not being part of 
Plasma and depending on Plasma. Especially: how do you want to achieve it 
without making applications depend on Plasma, which is nothing we want. Copy 
code? No way, for that I'm not going to agree to relicense.

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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > If you show me why it needs to be a framework and I agree with it,
> > I might be willing to consider to allow to relicense the code I wrote for
> > it.
> 
> There's no request to make it framework from me. LGPLing Breeze does not
> automatically add obligation to create and maintain a framweork. Especially
> that there are not widely declared use cases. It's just a way to get the
> same what was legal in the times of Oxygen and KDElibs 4.

Yes exactly! If you would present me reasons why it should become a framework 
I might see a need for it to have it LGPL. That is something I currently don't 
see. Thus I don't see a reason to change it to LGPL.

Similar I don't relicense KWin to LGPL, just because there might be a reason 
later on.  When we split out code from KWin to KWayland we did the relicense 
as needed.

> ​Why on the icons and not on style?​ (See also below)
> I have apps/libs that hard-depend on breeze style. (not just the
> implementation, on the design)
> Example reason: because for my requirements it works better with the icons
> and for example Windows 95 or Windows 7 style does not. Or I hav code that
> does not link to QWidget and still needs to paint/print something that is
> desinged in Breeze style.

Are that made up examples? If you want to use a QStyle in an application not 
using QWidgets you have lost already.

> ​Bottom line, IIRC there are no KDE applications anymore. You can't predict
> what OS / UX the _Qt_ apps will be used on. So author of applications are
> perfectly free to target other OSes than just the Plasma-based ones.

We want KDE applications to integrate with the OSes style and not force the 
Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze 
style.

> 
> > > Icons are part of the KF5 product [1] which does not mean libraries
> > 
> > depend
> > 
> > > on them
> > > https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> > > (well I believe as a product they depend but that's out-of-the box level
> > > thinking not belonging here)
> > 
> > libraries do depend on icons. Otherwise there wouldn't be efforts on how
> > to
> > package all required icons in the case of Android.
> 
> Very good, so similarly, ​I am packaging the breeze style for desktop OSes
> that lack Breeze QStyle.​ And like on Android, for these OSes​ the style is
> defined/decided at the application's level. And I have chosen Breeze style
> and icons and using that assumption while developing custom widgets (a hell
> of work for even for one style when QStyle is a stalled API now).

So you are porting part of Plasma to other OSes. That's great! Though doesn't 
mean that Plasma should relicense code.

> 
> > > Do you then agree with relicensing after my explanations here and in the
> > > other email?
> > 
> > no, sorry, I still don't see why that would be needed.
> 
> ​Legal reason:​
> ​​I am distributing the Breeze QStyle for OSes without Plasma installed.​
> There is some LGPL code, it's the same purpose for LGPL as KF5 has, opening
> up for use by GPL-incompatible apps. But ​Breeze code ​can't be used as a
> part of it even by linking. Breeze is GPL unlike all the styles shipped
> with Qt (4 or 5) that are LGPL.

Huh? Oxygen is also GPL and I don't see how it matters how Qt publishes their 
styles.

> There's no even exception in Breeze style.
> Breeze can't be used even if people pay $$$ to KDE in such cases.
> It's closed for this usage paths. It's even close for GPL-incompatible open
> source projects but that's another matter; it's not possible to compile-in
> an GFDL resource into the app or Mozilla licensed one -- all this is
> incompatible with GPL.
> Hard to explain to developers that there are so many not obvious
> restrictions when they move from styles distributed with Qt5 to Breeze.

well yes, Plasma as a platform is GPL. If you want to derive your product from 
Plasma you need to follow Plasma's licensing.

> 
> Breeze can be semi-legally used with GPL-incompatible app on the user's
> machine when it is loaded as a plugin without user knowing what is
> happening.
> Semi-legally because such app can't become GPL at runtime. It's just happy
> user not knowing there's a conflict.

That's not semi-legally. That's fully legally and the idea behind the plugin. 
We as Plasma inject the plugin into the running application. If an application 
sets it to use the breeze style manually I consider this as derived work.

> 
> I am afraid this situation also extends so Plasma based OSes became
> generally non-accessible (depends on jurisdiction and IANAL) for non-FOSS
> world. In my opinion Breeze can't be set as default in non-GPL app now. And
> what we're protecting here - has to be decided.

That looks fine to me. Non-GPL apps should not define a hard dependency on 
Plasma.

> 
> 
> ​Technical reason:
> ​Assume a software architecture that displays a check box in an interactive
> document. Say, it's 

Re: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote:
> On 9 May 2016 at 07:53, Martin Graesslin <mgraess...@kde.org> wrote:
> > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> > > Hi,
> > > Is relicensing Breeze QStyle to LGPL from GPL for possible and
> > 
> > acceptable?
> > 
> > > I've found cases when bits of the code beyond QStyle/KStyle API need
> > > to be reused. One example is: custom widgets.
> > > If we're considering Breeze QStyle as implementation of certain
> > > artwork, and KDE artwork in general would be LGPL also for
> > > consistency.
> > > For example wallpapers, icons are LGPL.
> > > 
> > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> > > it's not clear in breeze.git. The same question here: can it be LGPL
> > > or BSD?
> > > 
> > > Bottom line is: if we want to popularise our frameworks in the outside
> > > world...
> > 
> > I fail to follow you why Breeze QStyle should be a framework. No framework
> > should depend on it, Breeze QStyle is a plugin and it's only getting
> > loaded by
> > either setting an env variable manually or using the Plasma QPT plugin
> > which
> > is not in Frameworks either.
> 
> ​Not only KF5 is LGPL. ​Also other libraries and also parts of individual
> apps.

And there are also libraries which are GPL. E.g. kwineffects or kscreenlocker 
library.

> BTW: The latter help to create frameworks in the future (picking GPL too
> early kills the idea).

No it doesn't. It just means that one needs to get everybody to agree on the 
relicense. If you show me why it needs to be a framework and I agree with it, 
I might be willing to consider to allow to relicense the code I wrote for it.

> 
> > Anyway on the question of whether to relicense to LGPL you should ask the
> > copyright holders and I doubt you found them here on frameworks-devel as
> > Breeze is not a framework. I'm one of the copyright holders and as I don't
> > understand why you want it relicensed I would not agree to it. I think GPL
> > is
> > the proper license for our workspace components.
> 
> I'd like more explanation to know if you disagree just for the sake...

of course not!

> Don't you agree with LGPL for breeze or oxygen icons?

We have applications which depend on breeze and oxygen icons. That's why we 
moved them to frameworks. Applications depend on it, LGPL is the proper 
license.

The style though is part of Plasma Workspace and as that should follow the 
licensing of Plasma components which is GPL.  This also applies to many 
libraries in Plasma.

> 
> Styles are in *the same* group. They make-our-user-experience.

They make up the user-experience of Plasma. Not of the applications.

> 
> Icons are part of the KF5 product [1] which does not mean libraries depend
> on them
> https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> (well I believe as a product they depend but that's out-of-the box level
> thinking not belonging here)

libraries do depend on icons. Otherwise there wouldn't be efforts on how to 
package all required icons in the case of Android.

> 
> Do you then agree with relicensing after my explanations here and in the
> other email?

no, sorry, I still don't see why that would be needed.

> 
> The request is about the freedom to use of the code from of the breeze
> style in LGPL code freely opening freedom for experimentation and progress.
> The design (by VDG) is free to use (LGPL I think), why wouldn't the
> implementation be free-to-link?

I repeat again: I object to a relicense of code I have written to GPL in the 
case of Breeze and Oxygen.

> 
> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
> clearly as these would be actually scripts and graphic/style files. Why
> would we have inferior situation just because we happen to use compilers?

I don't see what that has to do 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: dbus-less frameworks on osx

[Martin Graesslin]

On Wednesday, May 11, 2016 4:00:45 AM CEST Nick Shaforostoff wrote:
> hi all! I'm investigating possibility of getting some kde apps to build on
> osx with vanilla Qt without dbus.
> 
> would you accept patches that make that possible?
> 
> for example, i have just built kauth without dbus and i can prepare a review
> request with a (nice) patch for this

Having suggested this in the past: I think that's a good idea and I fully 
support 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: LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> Hi,
> Is relicensing Breeze QStyle to LGPL from GPL for possible and acceptable?
> I've found cases when bits of the code beyond QStyle/KStyle API need
> to be reused. One example is: custom widgets.
> If we're considering Breeze QStyle as implementation of certain
> artwork, and KDE artwork in general would be LGPL also for
> consistency.
> For example wallpapers, icons are LGPL.
> 
> Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> it's not clear in breeze.git. The same question here: can it be LGPL
> or BSD?
> 
> Bottom line is: if we want to popularise our frameworks in the outside
> world...

I fail to follow you why Breeze QStyle should be a framework. No framework 
should depend on it, Breeze QStyle is a plugin and it's only getting loaded by 
either setting an env variable manually or using the Plasma QPT plugin which 
is not in Frameworks either.

Anyway on the question of whether to relicense to LGPL you should ask the 
copyright holders and I doubt you found them here on frameworks-devel as 
Breeze is not a framework. I'm one of the copyright holders and as I don't 
understand why you want it relicensed I would not agree to it. I think GPL is 
the proper license for our workspace components.

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 for KWayland for inclusion in frameworks

[Martin Graesslin]

On Saturday, May 7, 2016 7:45:20 PM CEST Michael Pyne wrote:
> On Sat, May 7, 2016 13:50:05 David Faure wrote:
> > Hi guys,
> > 
> > Can you check the CI for KWayland? ASAN detects an invalid memory usage
> > in KWayland::Client::OutputDevice::Private::doneCallback() called after
> > KWayland::Client::OutputDevice::~OutputDevice().
> > 
> > https://build.kde.org/view/Frameworks%20kf5-qt5/job/kwayland%20master%20kf
> > 5->
> > qt5/28/PLATFORM=Linux,compiler=gcc/testReport/junit/%28root%29/TestSuite/
> > kwa yland_testWaylandOutputDevice/
> 
> I find that report kind of confusing. The line 323 of
> test_wayland_outputdevice.cpp is just a QSignalSpy constructor, it shouldn't
> involve destruction of an OutputDevice (what ASAN is warning about here). I
> wonder if it maybe has something to do with the modern signal/slot
> connection syntax in use?
> 
> For what it's worth there's a relevant Coverity entry (CID 1340943), noting
> that the TestWaylandOutputDevice class does not have an initializer for
> m_queue within the constructor (or in any of the other class members it
> looked at). But I don't see how that would be related either.

This test has been flaky for some time. A rerun normally succeeds (as it just 
did) and whenever I tried to reproduce locally I failed.

Sorry I have no idea (yet) about the test and so far just triggered rebuild 
whenever the test failed.

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 for KWayland for inclusion in frameworks

[Martin Graesslin]

Hi David,

did you forget to update the version number of KWayland to 5.22 or is 
something still missing in KWayland?

Cheers
Martin

On Sunday, April 17, 2016 10:42:08 AM CEST David Faure wrote:
> Hi Martin,
> 
> Very nice run down of the check list!
> 
> I approve the move of kwayland to frameworks, please proceed
> (preferrably earlier than in two weeks, since that would be close to release
> date).
> 
> Cheers,
> David.
> 
> On Friday 15 April 2016 10:08:57 Martin Graesslin wrote:
> > Hi frameworks-developers,
> > 
> > based on the thread "KWayland as framework" [1] I want to start the review
> > process for including KWayland into frameworks.
> > 
> > To make it easier I'm giving an overview:
> > Policies [2]:
> > * Tier 1/integration - dependencies on Qt::Gui (5.4) and Wayland (1.7)
> > * directory structure
> > 
> >  ** name of toplevel directory: kwayland
> >  ** README.md: check
> >  ** COPYING.LIB: check
> >  ** metadata.yaml: check
> >  ** docs subdirectory: no additional documentation
> >  ** src with dedicated subdirectories: check, there is src/client and src/
> > 
> > server
> > 
> >  ** examples subdirectory: no dedicated examples
> >  ** autotests subdirectory: check
> >  ** tests subdirectory: check
> >  ** cmake subdirectory: not needed
> > 
> > * automatic unit test: the current line coverage for client library is 86
> > %, the line coverage for server library is 80 %
> > * binary compatibility: KWayland has been ABI stable since it got added to
> > Plasma
> > * documentation: yes, the API is documented
> > * localization: not needed, no user visible strings
> > 
> > * buildsystem:
> >   ** KF5WaylandConfig.cmake is generated
> >   ** KF5WaylandConfigVersion.cmake is generated
> >   ** no other cmake files are installed
> >   ** library names are camel case: KF5WaylandServer and KF5WaylandClient
> >   ** dependencies to other frameworks: it's tier 1, doesn't apply
> > 
> > * commits are reviewed: yes, but KWayland is already using phabricator
> > * CI failures are treated as stop the line events: I like my view green
> > ;-)
> > 
> > * compiler requirements:
> >   ** gcc 4.5: I don't know, the minimum gcc version my distribution offers
> >   is
> > 
> > 4.7
> > 
> >   ** clang 3.1: I don't know, the minimum clang version my distribution
> >   offers> 
> > is 3.5
> > 
> >  **  VS2012: doesn't apply, it's Linux only [5]
> >  ** constraints for other C++11 features: it compiles on build.kde.org, so
> > 
> > should be fine
> > 
> > Guidelines [3]:
> > * Policies: see above
> > * translations: doesn't apply
> > * split repository: yes, all commits were extracted when creating the
> > project * astyle: the code follows the kdelibs coding style from the
> > start, didn't run astyle again
> > * Dependencies on deprecated API: none
> > * module in frameworks: not yet, currently still in Plasma [4]
> > * kde-build-metadata: not yet, currently still in Plasma [4]
> > * CI Jobs: currently still for Plasma [4]:
> > https://build.kde.org/job/kwayland %20master%20kf5-qt5/
> > * bugs.kde.org project: currently still in Plasma [4]
> > * reviewboard: yes
> > * README.md: yes
> > 
> > If you have any further questions regarding the move, please ask. If I
> > don't get any blocking feedback in the next two weeks, I'm going to
> > request the move and hope to get it into next frameworks release if that
> > works with David ;-)
> > 
> > Thanks,
> > Martin
> > 
> > [1]
> > https://mail.kde.org/pipermail/kde-frameworks-devel/2016-March/032116.htm
> > l [2] https://community.kde.org/Frameworks/Policies
> > [3] https://community.kde.org/Frameworks/CreationGuidelines
> > [4] I'll do those tasks if we get the green light for move to frameworks,
> > otherwise it'll stay in Plasma
> > [5] some code uses linux includes, to support other Unix-systems porting
> > is
> > needed



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: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

[Martin Graesslin]

On Saturday, April 23, 2016 10:35:22 AM CEST Martin Graesslin wrote:
> Could we disable that ASAN check please[1]? I have two of my projects
> failing due to the DBus problem and one further failing due to a similar
> problem in QQuickStyleItem [2]. It's nice that we find errors, but I rather
> not have my tests fail due to errors in Qt.

Just for the record: plasma-workspace is also failing due to that.

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: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

[Martin Graesslin]

On Monday, April 25, 2016 11:17:03 AM CEST Luigi Toscano wrote:
> On Monday 25 of April 2016 19:14:00 Ben Cooksley wrote:
> > On Mon, Apr 25, 2016 at 5:59 PM, Martin Graesslin <mgraess...@kde.org>
> 
> wrote:
> > > In summary: I don't want spend time to investigate false positives. If
> > > an
> > > option results in false positives, I think that we should disable it.
> > 
> > Understandable.
> > 
> > > Of course Qt should get those bugs fixed, but for that Qt should enable
> > > ASAN on their CI system. If we get libraries which are free of ASAN
> > > problems, then we can enable it on our side. But false positives are
> > > just
> > > bad.
> > 
> > Based on this i'm going to assume Qt is not ASAN compliant, and will
> > therefore be disabling ASAN for all KDE projects across the entire KDE
> > CI system in 24 hours unless nobody objects.
> 
> The best of both worlds would be leave it enabled, but weave the known
> faulty results until they are fixed. Notification emails would come only
> for new issues. This happens in OpenStack, for example, where otherwise the
> amount of failures from underlying components would block too many projects
> for too much time (a skiplist disables few tests annotated with
> decorators).

Unfortunately that's not a solution in the case of the problems here. E.g. all 
my KWin/Wayland tests fail when connecting to DBus, that happens directly in 
init. No test is executed. It's like not having any tests at all.

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: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

[Martin Graesslin]

On Monday, April 25, 2016 7:29:51 AM CEST Albert Astals Cid wrote:
> I object.
> a) I already told you, don't use something nobody else uses, use the
> separate reposb) Not going to happen, but why would it matter at all?
> 
> More reasons for it: c) ASAN does not check for things in the library being
> broken or not since it only works on code compiled with ASAN, so the
> crashes are not in the library, they are in your code (if they are because
> of the library being broken or not that's not important, *your* code is the
> one that is going to crash)

Please check the backtraces. It's in this cases NOT a bug in "my code", it's a 
wrong delete in Qt code, making my test fail. Yes it's a bug, yes my code 
exposes it, yes I don't care, because there is nothing we can do. It's a false 
positive from my point of view. And makes it difficult to get real test 
results. 
A false positive destroys the purpose of a CI system. If we cannot trust it, 
it gets ignored.

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: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

[Martin Graesslin]

On Saturday, April 23, 2016 8:48:17 PM CEST Ben Cooksley wrote:
> On Sat, Apr 23, 2016 at 8:35 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > On Saturday, April 23, 2016 1:09:00 PM CEST Ben Cooksley wrote:
> >> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil <dvra...@kde.org> wrote:
> >> > On Saturday, April 23, 2016 1:44:16 AM CEST Ben Cooksley wrote:
> >> >> On Fri, Apr 22, 2016 at 11:11 PM, David Faure <fa...@kde.org> wrote:
> >> >> > On Thursday 21 April 2016 14:57:52 no-re...@kde.org wrote:
> >> >> >> GENERAL INFO
> >> >> >> 
> >> >> >> BUILD UNSTABLE
> >> >> >> Build URL:
> >> >> >> https://build.kde.org/job/kdbusaddons%20master%20kf5-qt5/PLATFORM=L
> >> >> >> inu
> >> >> >> x,
> >> >> >> compiler=gcc/11/>
> >> >> > 
> >> >> > Wow, ASAN detected a real bug in Qt here.
> >> >> > 
> >> >> > Fixed in https://codereview.qt-project.org/156728
> >> >> 
> >> >> As this issue essentially breaks any test on the CI system that
> >> >> depends on Qt I suggest all developers affected by this indicate this
> >> >> on the relevant reviews.
> >> > 
> >> > Hey guys,
> >> 
> >> Hi David,
> >> 
> >> > any chance to get this patch into our Qt build on the CI since it has
> >> > been
> >> > integrated upstream now? As it affects all tests that interact with
> >> > DBus
> >> > it
> >> > would be nice to resolve this on the CI.
> >> 
> >> We'll need upstream to update qt5.git (I think that's still required
> >> for changes to fully flow through) I think.
> >> We could try to hack the patch in, but then we'll end up having to
> >> undo that in a few weeks time.
> > 
> > Could we disable that ASAN check please[1]? I have two of my projects
> > failing due to the DBus problem and one further failing due to a similar
> > problem in QQuickStyleItem [2]. It's nice that we find errors, but I
> > rather not have my tests fail due to errors in Qt.
> 
> That would just cover up the issue.

Yes it would and that's exactly what I want.

To me the CI is currently producing false positives. It started to break from 
one moment to the other. It costs time to look into why it started to fail. It 
means that till that problem is fixed in Qt I cannot trust the CI system. It 
results in nobody noticing real breakage, because the build is broken anyway.

Then there is the problem of responsibility: I look at the output, I have no 
idea why that thing is broken, I have no idea how to build a minimal example 
which would reproduce it, even less on how to fix it. That's just a really bad 
situation to have a CI which can be trusted.

In summary: I don't want spend time to investigate false positives. If an 
option results in false positives, I think that we should disable it.

Of course Qt should get those bugs fixed, but for that Qt should enable ASAN on 
their CI system. If we get libraries which are free of ASAN problems, then we 
can enable it on our side. But false positives are just bad.

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: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

[Martin Graesslin]

On Saturday, April 23, 2016 1:09:00 PM CEST Ben Cooksley wrote:
> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil  wrote:
> > On Saturday, April 23, 2016 1:44:16 AM CEST Ben Cooksley wrote:
> >> On Fri, Apr 22, 2016 at 11:11 PM, David Faure  wrote:
> >> > On Thursday 21 April 2016 14:57:52 no-re...@kde.org wrote:
> >> >> GENERAL INFO
> >> >> 
> >> >> BUILD UNSTABLE
> >> >> Build URL:
> >> >> https://build.kde.org/job/kdbusaddons%20master%20kf5-qt5/PLATFORM=Linu
> >> >> x,
> >> >> compiler=gcc/11/>
> >> > 
> >> > Wow, ASAN detected a real bug in Qt here.
> >> > 
> >> > Fixed in https://codereview.qt-project.org/156728
> >> 
> >> As this issue essentially breaks any test on the CI system that
> >> depends on Qt I suggest all developers affected by this indicate this
> >> on the relevant reviews.
> > 
> > Hey guys,
> 
> Hi David,
> 
> > any chance to get this patch into our Qt build on the CI since it has been
> > integrated upstream now? As it affects all tests that interact with DBus
> > it
> > would be nice to resolve this on the CI.
> 
> We'll need upstream to update qt5.git (I think that's still required
> for changes to fully flow through) I think.
> We could try to hack the patch in, but then we'll end up having to
> undo that in a few weeks time.

Could we disable that ASAN check please[1]? I have two of my projects failing 
due to the DBus problem and one further failing due to a similar problem in 
QQuickStyleItem [2]. It's nice that we find errors, but I rather not have my 
tests fail due to errors in Qt.

Cheers
Martin

[1] just export ASAN_OPTIONS=new_delete_type_mismatch=0
[2] https://build.kde.org/user/graesslin/my-views/view/mgraesslin
%20maintained/job/plasma-integration%20master%20kf5-qt5/
PLATFORM=Linux,compiler=gcc/lastCompletedBuild/testReport/%28root%29/
TestSuite/frameworkintegration_kfiledialogqml_unittest/


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 for KWayland for inclusion in frameworks

[Martin Graesslin]

On Friday, April 15, 2016 10:08:57 AM CEST Martin Graesslin wrote:
> Hi frameworks-developers,

short update

> * module in frameworks: not yet, currently still in Plasma [4]

done

> * kde-build-metadata: not yet, currently still in Plasma [4]

done

> * CI Jobs: currently still for Plasma [4]:
> https://build.kde.org/job/kwayland %20master%20kf5-qt5/

done

> * bugs.kde.org project: currently still in Plasma [4]

done

I think we have everything in place now.

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

Review Request for KWayland for inclusion in frameworks

[Martin Graesslin]

Hi frameworks-developers,

based on the thread "KWayland as framework" [1] I want to start the review 
process for including KWayland into frameworks.

To make it easier I'm giving an overview:
Policies [2]:
* Tier 1/integration - dependencies on Qt::Gui (5.4) and Wayland (1.7)
* directory structure
 ** name of toplevel directory: kwayland
 ** README.md: check
 ** COPYING.LIB: check
 ** metadata.yaml: check
 ** docs subdirectory: no additional documentation
 ** src with dedicated subdirectories: check, there is src/client and src/
server
 ** examples subdirectory: no dedicated examples
 ** autotests subdirectory: check
 ** tests subdirectory: check
 ** cmake subdirectory: not needed
* automatic unit test: the current line coverage for client library is 86 %, 
the line coverage for server library is 80 %
* binary compatibility: KWayland has been ABI stable since it got added to 
Plasma
* documentation: yes, the API is documented
* localization: not needed, no user visible strings
* buildsystem:
  ** KF5WaylandConfig.cmake is generated
  ** KF5WaylandConfigVersion.cmake is generated
  ** no other cmake files are installed
  ** library names are camel case: KF5WaylandServer and KF5WaylandClient
  ** dependencies to other frameworks: it's tier 1, doesn't apply
* commits are reviewed: yes, but KWayland is already using phabricator
* CI failures are treated as stop the line events: I like my view green ;-)
* compiler requirements:
  ** gcc 4.5: I don't know, the minimum gcc version my distribution offers is 
4.7
  ** clang 3.1: I don't know, the minimum clang version my distribution offers 
is 3.5
 **  VS2012: doesn't apply, it's Linux only [5]
 ** constraints for other C++11 features: it compiles on build.kde.org, so 
should be fine

Guidelines [3]:
* Policies: see above
* translations: doesn't apply
* split repository: yes, all commits were extracted when creating the project
* astyle: the code follows the kdelibs coding style from the start, didn't run 
astyle again
* Dependencies on deprecated API: none
* module in frameworks: not yet, currently still in Plasma [4]
* kde-build-metadata: not yet, currently still in Plasma [4]
* CI Jobs: currently still for Plasma [4]: https://build.kde.org/job/kwayland
%20master%20kf5-qt5/
* bugs.kde.org project: currently still in Plasma [4]
* reviewboard: yes
* README.md: yes

If you have any further questions regarding the move, please ask. If I don't 
get any blocking feedback in the next two weeks, I'm going to request the move 
and hope to get it into next frameworks release if that works with David ;-)

Thanks,
Martin

[1] https://mail.kde.org/pipermail/kde-frameworks-devel/2016-March/032116.html
[2] https://community.kde.org/Frameworks/Policies
[3] https://community.kde.org/Frameworks/CreationGuidelines
[4] I'll do those tasks if we get the green light for move to frameworks, 
otherwise it'll stay in Plasma
[5] some code uses linux includes, to support other Unix-systems porting is 
needed

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: Misbehavior when unloading KStyle

[Martin Graesslin]

On Wednesday, April 6, 2016 8:10:53 PM CEST Aleix Pol wrote:
> Hi,
> I've seen a couple of times such backtrace [1] which shows Qt waiting
> for something that never happens. An easy way to reproduce is to load
> konversation (or any application with KDBusService::Unique), hide it
> and run it again. The exit call will never be fulfilled in the second
> process.
> 
> Any idea of what could be the cause of this? Or why it's happening?

That looks like https://bugs.kde.org/show_bug.cgi?id=360593

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: kauth testing?

[Martin Graesslin]

On Sunday, April 3, 2016 9:29:55 AM CEST René J.V. Bertin wrote:
> Hi,
> 
> KAuth doesn't come with anything but a few unittests that do not appear to
> attempt an actual authentication. I build my K*5 stuff for installation
> into /opt/local, under OS X and under KUbuntu 14.04 (i.e. a KDE4 desktop).
> That excludes almost everything related to Plasma5 desktops and I only know
> of the kwallet kcm which is supposed to use KAuth to unlock the
> configuration settings ... something that as far as I understand the code
> was never implemented completely so I had to disable the feature with a
> patch in order to be able to use the kcm.
> 
> Now I installed smb4k git/master and see InvalidActionErrors each time I
> attempt to authenticate which of course raises the question if my KAuth
> build isn't broken.

did it build the mac or the fake backend?

> 
> Is there a simple test app I could download and use to test this?

Doesn't look like it, At least I didn't find any in the src repository.

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

[Martin Graesslin]

On Saturday, November 28, 2015 7:58:47 PM CET René J. V. Bertin wrote:
> Olivier Goffart wrote:
> > A pure KF5 appliation would anyway use the KDE platform theme plugin
> > provided by KDE Frameworks.  (in frameworkintegration)
> > (So in other words: that code should not be executed when kde frameworks
> > is
> > installed, in theory)
> 
> So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa).
> From the looks of it that one lacks support for theme plugins. Or rather,
> it doesn't return the appropriate thing(s) from
> QGuiApplicationPrivate::platform_integration->themeNames().
> 
> Now the question is, should KF5 applications be able to use the KDE platform
> theme plugin provided by kf5-frameworkintegration if that framework is
> installed?

In my opinion: no. I even think the frameworkintegration framework should get 
removed from frameworks and moved into Plasma Workspace. Because that's what 
it is about: integrating Qt applications into plasma.

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: Policy for Dependencies

[Martin Graesslin]

On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote:
> Hi,

thanks for raising this topic. I think it's very important that we have a 
general strategy for frameworks and not have thousands of micro-fixes in 
various frameworks.

> 1) "Normal" deployment like we do in on Linux => just installing it with all
> features if possible. 2) "Application Bundles/Installer" like we will have
> to do it on Win/Mac and 3rdparty Linux people will need to do.
> 
> I think the easiest solution is to make stuff optional. That will avoid ugly
> "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people to still
> build stuff with that deps on that operating systems if really wanted.

Given from the no-X11 fixes I think that we should avoid all if (WIN OR APPLE) 
as that:
a) is hard to maintain
b) doesn't scale
c) not testable for the devs working on Linux

Given that it should be feature based and we should make as much usage of the 
built in CMake features we have. I really like the approach we have now found 
for X11 on OSX: disable certain find modules at a global level.

I think that is something which could be applied for more things. Control 
through global ECM settings. This could if we don't want to have global 
changes also through convenient command switches:

e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE

which then implies e.g. no phonon and no dbus and ...

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: Jenkins and XDG_DATA_DIRS

[Martin Graesslin]

On Tuesday, March 22, 2016 6:46:50 PM CET Ben Cooksley wrote:
> On Mon, Mar 21, 2016 at 7:56 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > On Saturday, March 19, 2016 10:27:38 PM CET David Faure wrote:
> >> It appears that something regressed in the jenkins setup.
> >> 
> >> Almost all of the current failures in the "Frameworks kf5-qt5" group come
> >> from XDG_DATA_DIRS not being set up correctly anymore, I think.
> >> E.g. in
> >> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kio%20master%20kf5-qt
> >> 5/
> >> 269/PLATFORM=Linux,compiler=gcc/console * KUriFilterTest and others fail
> >> to
> >> see the servicetype "KUriFilter/Plugin" which kio installs itself
> >> 
> >> The kio job says
> >> 
> >> export
> >> XDG_DATA_DIRS="/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/
> >> kw
> >> idgetsaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt
> >> 5/f
> >> rameworks/kauth/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
> >> 5-qt
> >> 5/frameworks/sonnet/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g+
> >> +/kf
> >> 5-qt5/frameworks/knotifications/inst/usr/share:/srv/jenkins/install/ubun
> >> tu/x
> >> 86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/usr/share:/srv/jen
> >> kins
> >> /install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kdoctools/inst/usr/share:/
> >> srv/
> >> jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/ktextwidgets/inst/u
> >> sr/s
> >> hare:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kconfigwi
> >> dget
> >> s/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/framewor
> >> ks/k
> >> jobwidgets/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5
> >> /fra
> >> meworks/kcoreaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g+
> >> +/kf
> >> 5-qt5/frameworks/breeze-icons/inst/usr/share:/srv/jenkins/install/ubuntu
> >> /x86
> >> _64/g++/kf5-qt5/frameworks/kglobalaccel/inst/usr/share:/srv/jenkins/inst
> >> all/
> >> ubuntu/x86_64/g++/kf5-qt5/frameworks/kservice/inst/usr/share:/srv/jenkin
> >> s/in
> >> stall/ubuntu/x86_64/g++/kf5-qt5/frameworks/kwallet/inst/usr/share:/srv/j
> >> enki
> >> ns/install/ubuntu/x86_64/g++/kf5-qt5/kdesupport/phonon/phonon/inst/usr/s
> >> hare>> 
> >> :$XDG_DATA_DIRS:/usr/share:/usr/share"
> >> 
> >> This is missing the dir for kio itself.
> >> 
> >> Same kind of problem in kemoticonstest (which loads its own plugin),
> >> frameworkintegration (same).
> >> 
> >> Is this a voluntary change, as in, we should fix the tests to work
> >> without
> >> the need to make install first?
> > 
> > other frameworks affected by the CI-regression are:
> > * kwindowsystem
> > * kglobalaccel
> > 
> > both cannot find their own plugin so I assume it's the same problem. I
> > don't have the time to rework the tests to make them pass again, sorry
> > :-(
> From what i've been told, the necessary changes to the scripts should
> now have been made to correct this.
> A rebuild may be needed though.

I just run a build kwindowsystem and can confirm that it works again. It's back 
to green \o/

Thanks a lot

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: Jenkins and XDG_DATA_DIRS

[Martin Graesslin]

On Saturday, March 19, 2016 10:27:38 PM CET David Faure wrote:
> It appears that something regressed in the jenkins setup.
> 
> Almost all of the current failures in the "Frameworks kf5-qt5" group come
> from XDG_DATA_DIRS not being set up correctly anymore, I think.
> E.g. in
> https://build.kde.org/view/Frameworks%20kf5-qt5/job/kio%20master%20kf5-qt5/
> 269/PLATFORM=Linux,compiler=gcc/console * KUriFilterTest and others fail to
> see the servicetype "KUriFilter/Plugin" which kio installs itself
> 
> The kio job says
> 
> export
> XDG_DATA_DIRS="/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kw
> idgetsaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/f
> rameworks/kauth/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt
> 5/frameworks/sonnet/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
> 5-qt5/frameworks/knotifications/inst/usr/share:/srv/jenkins/install/ubuntu/x
> 86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/usr/share:/srv/jenkins
> /install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kdoctools/inst/usr/share:/srv/
> jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/ktextwidgets/inst/usr/s
> hare:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/kconfigwidget
> s/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/frameworks/k
> jobwidgets/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/fra
> meworks/kcoreaddons/inst/usr/share:/srv/jenkins/install/ubuntu/x86_64/g++/kf
> 5-qt5/frameworks/breeze-icons/inst/usr/share:/srv/jenkins/install/ubuntu/x86
> _64/g++/kf5-qt5/frameworks/kglobalaccel/inst/usr/share:/srv/jenkins/install/
> ubuntu/x86_64/g++/kf5-qt5/frameworks/kservice/inst/usr/share:/srv/jenkins/in
> stall/ubuntu/x86_64/g++/kf5-qt5/frameworks/kwallet/inst/usr/share:/srv/jenki
> ns/install/ubuntu/x86_64/g++/kf5-qt5/kdesupport/phonon/phonon/inst/usr/share
> :$XDG_DATA_DIRS:/usr/share:/usr/share"
> 
> This is missing the dir for kio itself.
> 
> Same kind of problem in kemoticonstest (which loads its own plugin),
> frameworkintegration (same).
> 
> Is this a voluntary change, as in, we should fix the tests to work without
> the need to make install first?

other frameworks affected by the CI-regression are:
* kwindowsystem
* kglobalaccel

both cannot find their own plugin so I assume it's the same problem. I don't 
have the time to rework the tests to make them pass again, sorry :-(

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

Raising Qt requirement to Qt 5.4

[Martin Graesslin]

Hi all,

with todays release of Qt 5.6 I suggest that we raise the minimum Qt version 
requirement to 5.4. This would mean the latest three releases are supported.

The important new features in Qt 5.4 in my opinion for frameworks development 
are:
* QSignalSpy(const QObject *object, PointerToMemberFunction signal)
* Q_LOGGING_CATEGORY(name, string, msgType)

Which are already used in many frameworks and currently ifdefed.

Opinions?

Best Regards
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: I'm missing the favicons interface

[Martin Graesslin]

On Friday, February 19, 2016 11:04:21 PM CET David Faure wrote:
> On Tuesday 16 February 2016 22:32:18 Robby Stephenson wrote:
> > On Tue, Feb 16, 2016 at 5:00 PM, David Faure  wrote:
> > > I'm curious though, what's the use case for a large favicon? In KDE4 the
> > > only
> > > time I see this is when using Alt+Tab and with konqueror windows open
> > > (and
> > > that
> > > looks a bit weird because other apps have a much bigger icon than
> > > konq's,
> > > but
> > > that's an unrelated issue I guess). I guess your app has another use for
> > > large
> > > icons with a favicon, I'm just curious what it is, and whether the
> > > text-html icon
> > > as the main icon is the best icon to have. This is an opportunity to
> > > rethink this
> > > if we want to ;)
> > 
> > Tellico searches a number of API end points, including some like SRU or
> > z39.50 that could be any server at all. Many are also http servers and
> > provide a favicon. In the configuration dialog for those sources, I chose
> > to put a 64x64 icon next to all the specific data options and the favicon
> > overlay fits the bill. I agree - it's an odd case, and as for whether
> > text/html is the best icon, well, probably better than any other option.
> 
> OK.
> 
> I experimented a little bit, and realized that there are a few issues
> even in kdelibs4 this isn't ideal, in Alt+Tab everything has much bigger
> icons than konqueror's favicon... so an icon engine (and returning
> a QIcon from the job) would be good, but a bit tricky for konqueror's code
> (which uses QString for this in many places).
> 
> This also makes me wonder if KWindowSystem::setIcons should
> still exist, it's limited to two icons sizes while QIcon can handle a lot
> more --- Martin?

well yeah the API in KWindowSytem is not optimal. It would be better to have a 
variant to pass a QIcon.

The underlying NETWinInfo class can set icons in any size, though.

The better question is whether QWindow::setIcon works as expected. If that's 
the case I'd suggest to deprecate KWindowSystem::setIcons in favor of 
QWindow::setIcon.

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: Proposal for moving KColorScheme from KConfigWidgets to KGuiAddons

[Martin Graesslin]

On Saturday, February 20, 2016 11:22:48 AM CET Andreas Cord-Landwehr wrote:
> Hi, I want to propose to move the KColorScheme class from the KConfigWidgets
> famework to the KGuiAddons framework.
> 
> Reasons:
> * that would reduce dependencies of KIconThemes and make it
>   - a Tier 2 framework (currently Tier 3) and
>   - make it easier to use KIconThemes on Android
> * KGuiAddons seems to be the much more logical place for this class in my
> opinion
> 
> My Questions:
> a) Are there other opinions about this move?
> b) What about KColorSchemeManager? I would propose to keep it at
> KConfigWidgets, though.

KColorSchemeManager is only in KConfigWidgets because KColorScheme is in 
KConfigWidgets. Thus I would suggest to move it as well if possible.

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: Solid/PowerManagement deprecation

[Martin Graesslin]

On Wednesday, February 10, 2016 3:55:51 PM CET Aleix Pol wrote:
> Hi,
> I've been looking in the last days what applications and uses make our
> software stick to KDELibs4Support.
> 
> My impression is that the big missing thing is Solid/PowerManagement.
> 
> Is anyone looking into the issue?

I replaced the usage in kscreenlocker (suspend/hibernate) with new written 
code which does nice async dbus. From the start I considered that this code 
could become the base for a new lib, so it has the right licence, etc. Commit 
is at:

http://commits.kde.org/kscreenlocker/a04768901ac13985dd673bbb45f2bf98d9a52903

But overall I don't know what is really needed from a PowerManagement API.

> Should we look into un-deprecating it?

given the very sync-dbus state of the API, I would not recommend to.

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: KActivitiesStats framework for review

[Martin Graesslin]

On Monday, February 1, 2016 9:59:17 AM CET Ivan Čukić wrote:
> Hi all,
> 
> There is a new framework-to-be under review. Until now, it was used in
> plasma (and shipped with plasma, although it was developed in
> kactivities repository - strange setup, but we somehow managed). To
> avoid collisions, it was previously known under the
> KActivitiesExperimentalStats name, and it exported symbols in
> KActivities::Experimental::Stats namespace.
> 
> The framework allows querying the statistics collected by the
> activities system in plasma. It depends only on Qt, KActivities and
> KConfig, so it will be a tier2 (KActivities will move to tier1 quite
> soon).

I just had a quick look and the first thing I saw by opening a random file 
(resultset.h) is that it uses GPL instead of LGPL.

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: opening dialogs using a "foreign" WId

[Martin Graesslin]

On Thursday, January 28, 2016 5:28:24 PM CET René J. V. Bertin wrote:
> René J. V. Bertin wrote:
> > Which is all I'm hinting at, and certainly not that a single (or small
> > group of) person(s) implement this for all platforms.
> 
> Of course, if cross-process WIds are basically only usable under X11/Xcb one
> could probably replace their use with something that encapsulates them and
> adds whatever information is required so that comparable behaviour
> (functionality) can be obtained on all supported platforms? In the case of
> the kwalletd example that could mean
> - the password request is posted in a suitable foreground layer where it
> won't go unnoticed
> - once handled, the application for which the request was posted is brought
> back to the foreground if (say) kwalletd pushed itself to the front and was
> allowed to stay there. I don't know about Wayland, but that kind of action
> is possible on OS X (though not currently via an existing Qt API).

To put it simple: we as in Plasma are not interested in a compromise based on 
the least common denominator of all platforms. We want the best possible 
experience. And if you ask the question: what would Apple do? You would also 
want to go for the best possible experience.

So what we need is a way that each platform can implement it in the best 
possible way. X11 made it too easy. We got a crappy implementation, the 
desktop team was not involved.

As frameworks cannot depend on KWayland any solution we come up with for our 
platform will be based on plugins. Thus also other platforms can implement 
plugins.

On the general implementation I must ask for patience. Fixing KWallet on 
Wayland is not yet on our TODO list.

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: opening dialogs using a "foreign" WId

[Martin Graesslin]

On Wednesday, January 27, 2016 10:06:00 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > That depends on the Wayland compositor. In Plasma (KWin) we will certainly
> > make sure this works properly.
> 
> I'd appreciate if that could be done in a way that makes sense on other
> platforms too...

Sorry, we *are* the platform. If we extend the desktop shell to ask for 
passwords, that cannot be used in other platforms because there we don't 
control the desktop shell.

> 
> > But yes currently it most likely will open
> > somewhere behind just like Akonadi asking for KWallet opens behind on X11.
> 
> Curiously password requests on behalf of the akonadi imap agent usually open
> in front on my kde4 system; more often than those of the email dispatcher
> in any case. Do those even get a WId btw?

AFAIK it depends on whether Kontact/KMail is running or not. If Kontact is not 
running it doesn't have a winId and KWin should stack below and deny focus to 
it given that the window is trying to steal focus.

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: KCoreAddons qml plugins

[Martin Graesslin]

On Thursday, January 28, 2016 1:11:38 AM CET David Faure wrote:
> I honestly don't see the problem with having this in KDeclarative, but maybe
> I'm missing a good reason for splitting such qml plugins into a separate
> framework. Or maybe there's no point in doing that either.

The problem is that kdeclarative is starting to become the new "KDELibs". It 
gets dependencies on everything. It's going the opposite way of the 
modularization of kdelibs. If one wants to use KI18n from declarative side one 
also gets e.g. a build dependency on KIO.

But I also agree with you that putting the bindings into KCoreAddons is also 
the wrong way to go.

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 126895: Make KGlobalAccel dependency in KXmlGui optional

[Martin Graesslin]

On Thursday, January 28, 2016 11:10:20 AM CET Jaroslaw Staniek wrote:
> Now instead of that, everything but truly uncommon stuff would be ON by
> default.​ If someone knows what she/he​ is doing, will set to OFF but this
> will be actually a choice, hopefully informed choice.
> 
> Can we encourage the use of this approach?

This is kind of the same as I suggest with the "No DBus Profile"?

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: opening dialogs using a "foreign" WId

[Martin Graesslin]

On Thursday, January 28, 2016 10:40:57 AM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > Sorry, we *are* the platform. If we extend the desktop shell to [...]
> 
> With all due respect, that sounds very wrong for software that's supposed to
> be cross-platform. At the very least those desktop shell extensions should
> be accessed via KF5 or Qt APIs designed to have potential sense on other
> platforms too (QDesktopServices would be a prime candidate).

On Wayland KWin/Plasma is the platform. The whole point of it is to be the 
platform so I don't see how that is supposed to be "cross platform"?

I cannot design a platform specific API which is potentially cross-platform, 
because I have no clue about those other platforms. How am I supposed to know 
that the solution I come up with for KWin/Wayland can also be used on OSX, 
Android, whatever. I don't think that's realistic to assume.

What we do is take the KF5 based software and integrate it into our platform. 
That's the same as you are doing. You integrate KF5 based software into OSX. 
The only difference is that we also have full control over the platform.

So far where we have done this we went through plugins which can be 
implemented on each platform.

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: opening dialogs using a "foreign" WId

[Martin Graesslin]

On Wednesday, January 27, 2016 3:45:12 PM CET René J. V. Bertin wrote:
> Kai Uwe Broulik wrote:
> 
> Hi,
> 
> >> ‎Are there other platforms where WIds cannot be used for this kind of use
> >> case (MS Windows for instance)?
> > 
> > Wayland.‎
> 
> So how do the dialogs behave when, say, kwalletmanager asks kwalletd to
> unlock a locked keychain and a password or passphrase is required? Does the
> dialog open somewhere behind kwalletmanager, as it does on OS X?

That depends on the Wayland compositor. In Plasma (KWin) we will certainly 
make sure this works properly. But yes currently it most likely will open 
somewhere behind just like Akonadi asking for KWallet opens behind on X11.

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: Making polkit-qt-1 a tier1 framework

[Martin Graesslin]

On Saturday, January 23, 2016 11:59:28 AM CET David Faure wrote:
> On Thursday 14 January 2016 13:20:01 Martin Gräßlin wrote:
> > Hi all,
> > 
> > I want to suggest to move polkit-qt-1 [1] from kdesupport to frameworks.
> > Reasons are:
> > 
> > * kdesupport is basically what became tier1 in frameworks
> > * it's used by other frameworks, e.g. KAuth (tier 2) and in
> > kde/workspace
> > * polkit-qt-1 is currently in a not really released state (last release
> > in 2014, quite a few bugfixes around)
> > 
> > By moving it to frameworks we get closer to getting rid of kdesupport
> > and get the making releases problem solved once and for all: bug fixes
> > will get to users in a timely manner.
> > 
> > Opinions?
> 
> Sounds good. A few questions come to mind:
> 
> - Will you be the official maintainer? (Otherwise who will?)

eh no, my domain knowledge is not enough and I already maintain too much.

My suggestion for maintainer is shared responsibility of Plasma team. Not 
optimal, but still better than the unmaintained state it's currently in. And 
Plasma needs polkit.

> 
> - Is this an opportunity for a better name? I keep wondering why this lib
> targets Qt 1 :-)

The name makes kind of sense. It's a Qt wrapper for polkit-1. If you have a 
better name suggestion: sure, but it shouldn't cause breakage for existing 
code.

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

[Martin Graesslin]

On Thursday, December 24, 2015 12:16:13 PM CET Simon Lees wrote:
> Hi All,
> 
> Sorry for double posting, but after chatting with someone on IRC we
> discovered that exporting  QT_QPA_PLATFORMTHEME=kde or
> QT_QPA_PLATFORMTHEME=gtk2 fixes the issue. For now I can just patch
> enlightenment to export one of these and it will fix my issues. If I
> have a lot of free time oneday I could write a Platform theme for
> enlightenment but atm I don't.

This might indicate that enlightenment is not recognized as a platform by Qt 
at all. And I just verified, check: qtbase/src/platformsupport/themes/
genericunix/qgenericunixthemes.cpp - method GenericUnixTheme::themeNames()

As I do not know how enlightenment is recognized, I suggest that you have a 
look there and add it to the list of gtkBasedEnvironments - that's not 100 % 
correct, but should at least give you working applications.

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: Draft split for qpt plugin from frameworkintegration

[Martin Graesslin]

On Thursday, December 17, 2015 5:48:47 PM CET Martin Graesslin wrote:
> On Thursday, December 17, 2015 4:32:48 PM CET Aleix Pol wrote:
> > On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin <mgraess...@kde.org>
> 
> wrote:
> > > Hi all,
> > > 
> > > following up on [1] I have prepared a split of frameworkintegration to
> > > move
> > > the QPT plugin into a dedicated repository. You can find it in [2].
> > > Please
> > > have a look at the split repo to verify that it looks fine. If
> > > everything
> > > is OK, I'll request a new repo from sysadmins.
> > > 
> > > Some general notes
> > > * new repo name: plasma-integration
> > > * new plugin name: PlasmaDesktopPlatformTheme
> > > * new src folder name: src/plasma-desktop-platformtheme
> > > 
> > > Explaining the name changes:
> > > The plugin is renamed to not conflict on install with the existing
> > > plugin
> > > from frameworkintegration and also incorporating future changes Marco
> > > pointed out: we need a different QPT plugin for mobile.
> > > 
> > > How to remove the plugin from frameworkintegration:
> > > After the split we cannot remove it from frameworkintegration yet as
> > > that
> > > would break setups on the next framework release. Given that I plan to
> > > only
> > > phase it out: Introduce a cmake option to build and install it, which
> > > defaults to true till at least Plasma 5.6 is released. Afterward
> > > swapping
> > > the default to false, with a big fat warning and keeping it like that
> > > for
> > > at least half a year. Then remove it. We don't provide any guarantees
> > > for
> > > it, so we can remove it, but I want to keep the impact small.
> > > 
> > > Cheers
> > > Martin
> > > 
> > > [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> > > 029234.html
> > > [2] kde:scratch/graesslin/platform-integration
> > > (https://quickgit.kde.org/?
> > > p=scratch%2Fgraesslin%2Fplasma-integration.git )
> > 
> > I have my doubts that we want a different QPT for desktop and mobile.
> > If we want to provide any convergence we need to strive to have the
> > same on both platforms.
> 
> Good point! Marco is right: we need different presets whether it's desktop
> or mobile. You're right that different plugins would result in making
> switching impossible. Sounds like the plugin would have to learn to switch
> at runtime.
> 
> Given that feedback I'm considering to not rename the directory.

pushed a new variant without the rename of the source folder and the plugin 
renamed to KDEPlasmaPlatformTheme.

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: Draft split for qpt plugin from frameworkintegration

[Martin Graesslin]

On Thursday, December 17, 2015 4:32:48 PM CET Aleix Pol wrote:
> On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > Hi all,
> > 
> > following up on [1] I have prepared a split of frameworkintegration to
> > move
> > the QPT plugin into a dedicated repository. You can find it in [2]. Please
> > have a look at the split repo to verify that it looks fine. If everything
> > is OK, I'll request a new repo from sysadmins.
> > 
> > Some general notes
> > * new repo name: plasma-integration
> > * new plugin name: PlasmaDesktopPlatformTheme
> > * new src folder name: src/plasma-desktop-platformtheme
> > 
> > Explaining the name changes:
> > The plugin is renamed to not conflict on install with the existing plugin
> > from frameworkintegration and also incorporating future changes Marco
> > pointed out: we need a different QPT plugin for mobile.
> > 
> > How to remove the plugin from frameworkintegration:
> > After the split we cannot remove it from frameworkintegration yet as that
> > would break setups on the next framework release. Given that I plan to
> > only
> > phase it out: Introduce a cmake option to build and install it, which
> > defaults to true till at least Plasma 5.6 is released. Afterward swapping
> > the default to false, with a big fat warning and keeping it like that for
> > at least half a year. Then remove it. We don't provide any guarantees for
> > it, so we can remove it, but I want to keep the impact small.
> > 
> > Cheers
> > Martin
> > 
> > [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> > 029234.html
> > [2] kde:scratch/graesslin/platform-integration (https://quickgit.kde.org/?
> > p=scratch%2Fgraesslin%2Fplasma-integration.git )
> 
> I have my doubts that we want a different QPT for desktop and mobile.
> If we want to provide any convergence we need to strive to have the
> same on both platforms.

Good point! Marco is right: we need different presets whether it's desktop or 
mobile. You're right that different plugins would result in making switching 
impossible. Sounds like the plugin would have to learn to switch at runtime.

Given that feedback I'm considering to not rename the directory.

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: Draft split for qpt plugin from frameworkintegration

[Martin Graesslin]

forgot CC to plasma

On Thursday, December 17, 2015 4:32:48 PM CET Aleix Pol wrote:
> On Wed, Dec 16, 2015 at 4:12 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > Hi all,
> > 
> > following up on [1] I have prepared a split of frameworkintegration to
> > move
> > the QPT plugin into a dedicated repository. You can find it in [2]. Please
> > have a look at the split repo to verify that it looks fine. If everything
> > is OK, I'll request a new repo from sysadmins.
> > 
> > Some general notes
> > * new repo name: plasma-integration
> > * new plugin name: PlasmaDesktopPlatformTheme
> > * new src folder name: src/plasma-desktop-platformtheme
> > 
> > Explaining the name changes:
> > The plugin is renamed to not conflict on install with the existing plugin
> > from frameworkintegration and also incorporating future changes Marco
> > pointed out: we need a different QPT plugin for mobile.
> > 
> > How to remove the plugin from frameworkintegration:
> > After the split we cannot remove it from frameworkintegration yet as that
> > would break setups on the next framework release. Given that I plan to
> > only
> > phase it out: Introduce a cmake option to build and install it, which
> > defaults to true till at least Plasma 5.6 is released. Afterward swapping
> > the default to false, with a big fat warning and keeping it like that for
> > at least half a year. Then remove it. We don't provide any guarantees for
> > it, so we can remove it, but I want to keep the impact small.
> > 
> > Cheers
> > Martin
> > 
> > [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2015-December/
> > 029234.html
> > [2] kde:scratch/graesslin/platform-integration (https://quickgit.kde.org/?
> > p=scratch%2Fgraesslin%2Fplasma-integration.git )
> 
> I have my doubts that we want a different QPT for desktop and mobile.
> If we want to provide any convergence we need to strive to have the
> same on both platforms.

Good point! Marco is right: we need different presets whether it's desktop or 
mobile. You're right that different plugins would result in making switching 
impossible. Sounds like the plugin would have to learn to switch at runtime.

Given that feedback I'm considering to not rename the directory.

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

Draft split for qpt plugin from frameworkintegration

[Martin Graesslin]

Hi all,

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

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

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

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

Cheers
Martin

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

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

Re: kdeinit freezes on Wayland in OOM protection

[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

[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: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, December 10, 2015 1:07:42 PM CET Boudhayan Gupta wrote:
> On 10 December 2015 at 12:32, Martin Graesslin <mgraess...@kde.org> wrote:
> > yes, that's the annoying one which is lots of work and lots of possible
> > regressions. I'm not sure whether I'm willing to do that work which I
> > consider a useless exercise.
> 
> In my opinion this discussion is an useless exercise, because:
> > Well it doesn't need to be a global bump of compiler requirements. But we
> > could consider different compiler requirements for frameworks which are
> > non- portable. KWayland will never be built on Windows neither on OSX. So
> > any compiler restrictions on it just shouldn't matter.
> 
> Exactly. Anything that's Wayland related is supposed to be on the
> bleeding edge right now. Setting compiler restrictions on this
> particular framework will serve only to (apologies for my language,
> but there really is not a more apt term for this) cockblock KWayland
> development. Developing new technologies from scratch is hard; being
> unable to use easier constructs for solving problems not only makes
> your job harder but frustrates you more (it's there, why can't I use
> this?)
> 
> I may be wrong, but I'm guessing Wayland came quite a while after
> gcc-4.5 did, and that they use features that require gcc>4.5.

I rather doubt that this is actually the case. Wayland is a c-library and we 
need to explicitly set in KWayland:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu90")

in order to compile generated Wayland protocols.

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

[Martin Graesslin]

On Thursday, December 10, 2015 2:39:36 PM CET Mark Gaiser wrote:

> > That is why I don't get your point. It just doesn't make sense to me and
> > it
> > sounds being based on wrong assumptions.
> 
> Yes, it will. Here is the proof (taking archlinux as example since it is
> very much like upstream with close to zero patches applied).
> plasma-workspace:

how is plasma-workspace's dependencies a proof? Once again, why would the 
logical moving change dependencies?

> https://www.archlinux.org/packages/extra/x86_64/plasma-workspace/
> Depends (among others) on breeze.

That's wrong. plasma-workspace doesn't define a dependency on Breeze. Looks to 
me like a fix on Arch to get the runtime dependency installed. Proper fix: 
runtime depend from QPT plugin (which would be correct way!). Which we cannot 
do at the moment because breeze is in kde/workspace, but QPT plugin is in 
frameworks.

> That in turn depends on kdecoration:

That's correct. Breeze provides a kdecoration theme. You get this dependency 
when using QPT plugin currently as well, as it requires breeze.

> https://www.archlinux.org/packages/extra/x86_64/breeze/
> plasma-workspace itself depends on kscreenlocker.

That's correct as up until a few weeks ago kscreenlocker was part of plasma-
workspace

> kwin is required by plasma-workspoace, but compile time only. Ok, i give
> you that one.
> And you're right about systemsettings. It is only required by
> plasma-desktop, not workspace.
> 
> > And even if dependencies by distros would be set up that it pulls in let's
> > say
> > KWin. What would it change? A few files get installed, that's it. It would
> > not
> > have any runtime impact. That's what I meant with the barrier in people's
> > head. You cannot install Plasma (just install, not run!) because it will
> > taint
> > the lightweight system. If that is not what you think, then please
> > elaborate
> > why moving the plugin to kde/workspace is bad from your perspective.
> 
> 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.

Sorry, but that's what I consider as nonesense and is not what we should 
optimize for. That is exactly the "you cannot install KDE software, because 
deps!!!" thing we have argued against for years. Right now my install size of 
all KDE applications against Qt 5 in debug build with maybe multiple copies 
takes less than 4 GB on my system. With current storage costs that's 0.12 $

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

Yes optimize, don't minimize install size! Install size just doesn't matter. 
On Android phones it's no problem that each and every app ships and installs 
it's own Qt, but on desktop systems with way less storage constraints and less 
connectivity constraints it's supposed to be a problem?

> > It would not be on purpose, obviously. It's just that it can happen,
> > because
> > we are not aware on how it will be used outside Plasma. And I'm sure we
> > already did break for other environments. Let's consider for example the
> > infinite loop if a system doesn't provide SNI and no xembed. Happened,
> > couldn't happen on Plasma because it provides SNI.
> 
> There is a difference here.
> As it is right now, breaking it would be a bug that has to be fixed.

who says that bugs have to be fixed? Honestly, if it's in code I would have 
added and only affects a minority of users in a weird setup I cannot reproduce 
without investing lots of time: unlikely. Like the interesting crash reports 
of screenlocker when using Compiz - not going to get fixed, not able to 
reproduce.

> 
> When it moves to plasma workspace the breakage may be intentional for
> integration purposes.

No difference to current state. If we break things due to integration with 
Plasma (and we did so, see SNI), it breaks. And again: we wouldn't do on 
purpose. We don't go "oh let's break i3 users today!" And that also means that 
if we get a bug report and it's reasonable (because there are also Plasma+i3 
users) we might fix it, or not, like explained above.

> 
> > Other examples could be integration with services provided by workspace
> > and we
> > just don't consider that it doesn't exist, connection to powerdevil dbus
> > services, dependencies on KWin, etc.
> 
> Could it be that "frameworkintegration" is not named properly?

Please see earlier thread on that topic. The naming is correct, it's the QPT 
plugin which shouldn't be there.

> It sounds
> like it should be "Plasma framework integration" since the examples you
> give are quite specific to the needs of plasma.
> 
> To be clear, my assumption with the name "frameworkintegration" is as
> follows.
> I expect it to integrate framework specific features (like the file open
> dialogs) as replacements 

Re: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, November 5, 2015 11:10:49 AM CET Kevin Ottens wrote:
> Hello,
> 
> On Thursday 05 November 2015 10:50:06 Martin Graesslin wrote:
> > There are two things which make the move to frameworks difficult and I
> > don't see a solution to it at the moment:
> > 
> > 1. We require C++11 without exceptions: reason, it's designed for Linux
> > and
> > it didn't come to my mind to restrict us on the compiler due to lack of
> > support in Visual Studio.
> > 
> > 2. We use Qt 5.4.
> > 
> > For item 1 I only see the possibility of adding an exception [1].
> 
> I personally don't like exceptions, it gets complex fast.
> 
> Now are you sure it is really problematic? To me it looks like you're using
> almost exclusively features from the white list. It is probably just a
> matter of s/nullptr/Q_NULLPTR/ and s/override/Q_DECL_OVERRIDE/ in your
> case.

I just started looking into doing the replacement and noticed that I'm also 
using:
* Non-static data member initializers (N2756), gcc 4.7
* Range-based for (N2930), gcc 4.6
* constexpr, gcc 4.6
* possibly also delegating ctors, gcc 4.7 (difficult to find)

Overall it looks to me like I cannot make this code base to work again with 
gcc 4.5 without spending a lot of time and possibly introducing regressions.

So how should we go on?

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

[Martin Graesslin]

On Wednesday, December 9, 2015 1:29:41 PM CET René J.V. Bertin wrote:
> KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT
> use the plugin architecture currently, but simply assumes that
> QWindow::fromWinId() will always work (and never crash).

oh that explains a lot... Like why couldn't I find it in my Wayland backend, 
why do random applications crash on Wayland...

> For the time being
> it will thus require ifdefs.

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

> Beyond that, exactly how should I adapt it?
> Never do anything on OS X (the solution used currently in
> KDELibs4/MacPorts)? Or check the result from QWidget::find() and only do
> its job when that function returns a valid pointer (which could actually be
> the general approach if that find() function isn't expensive on platforms
> where calling it is redundant).
> 
> Beyond that I suppose that setMainWindow() is *not* the place to push the
> new window to the foreground so that it doesn't get overlooked - or is it?
> In other words, what exactly is the role of KWindowSystem's main window?

It's an X11 thing (like most KWindowSystem methods) for parent-child 
relationship. It's not about raising windows, etc. That's up to the windowing 
system.

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

[Martin Graesslin]

On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser <mark...@gmail.com> wrote:
> > On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> >> On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:
> >> > I thought the frameworkintegration plugin was exactly that and usable
> >> > for
> >> > any platform if they wish to use it.
> >> > Or is my assumption wrong and is it really only for Plasma and should
> >> > others stay away from it?
> >> 
> >> well obviously it's only for plasma as it's bound to env variables set by
> >> startkde. And in 4.x time the qpt plugin was in kde-workspace repo, see:
> >> 
> >> https://quickgit.kde.org/?p=kde-workspace.git=blob=4f67cc55104fe1081b
> >> 05d381e9516e0215f8e24a=1b97d4427257120e305408404bff5ec6be0b65a9=qgui
> >> platformplugin_kde %2Fqguiplatformplugin_kde.cpp
> >> 
> >> > My assumption can very well be wrong, but then i think we need to have
> >> > a
> >> > "base" frameworkintegration that every app dev can use with or without
> >> > plasma. And a plasma specific version that integrates more in plasma i
> >> > suppose.
> >> 
> >> I don't think it's anything an app developer should care about. It's
> >> integration, that's not something the app developer picks - otherwise the
> >> app
> >> breaks on integrating with other platforms.
> >> 
> >> > I don't care for that either. It's logical and to be expected.
> >> > I do care when i want to use the KF5 filedialog and need to install
> >> > plasma
> >> > (which has absolutely nothing to do with the dialog) just to get it.
> >> > With "use" i mean the file open dialog, not the ones you can just call
> >> > from
> >> > the C++ side of things.
> >> > 
> >> > And i definitely do not want to make a QPA just to have that working.
> >> 
> >> Well you have to. The file dialog is part of integration. If you want to
> >> have
> >> a specific integration you need to provide a QPT (not QPA) plugin.
> >> Application
> >> developers must keep away from that.
> >> 
> >> Please also read up on the topic of why KFileDialog got removed from our
> >> API.
> >> 
> >> Cheers
> >> Martin
> > 
> > I see what you mean, i understand your opinion, but... I just don't like
> > it
> > for all the reasons given earlier.
> > I might be a minority here, not many people are responding besides Aleix
> > and myself.
> > 
> > Lets both take a step back and let some other opinions flow in.
> 
> I don't really understand your points...
> 
> LXQt/Other Desktops can depend on Plasma packages if they wish. Some
> of them have used KWin at some point, AFAIK.

+1. I also just don't get Mark's points. It sounds to me like the "oh gosh a 
dependency on Plasma is EVIL". If users have a problem with installing the 
dependency because it's part of Plasma and not part of Frameworks I'd say bad 
luck for them. We shouldn't code around barriers in people's mind.

> 
> We also provide the classes to set up the QPT in our frameworks, they
> can create their own (and probably should, if you ask me).

+1. And as I said: if other desktop environments consider our file dialog 
superior, we should make sure they can use it through a framework in their 
QPT. But they should not use our QPT. If they use our QPT they will hit a 
problem somewhen in future when we change something for better integration 
with Plasma and that just doesn't work at all with $DE.

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: Moving KWayland to frameworks

[Martin Graesslin]

On Wednesday, December 9, 2015 6:14:47 PM CET Kevin Ottens wrote:
> > I just started looking into doing the replacement and noticed that I'm
> > also
> > using:
> > * Non-static data member initializers (N2756), gcc 4.7
> > * Range-based for (N2930), gcc 4.6
> 
> Note that if you do that with Qt containers it's likely a bad idea. It's
> likely to detach and copy whole containers if they are non-const. Qt
> containers should be used with foreach always to avoid problems (and yes
> that's a shame IMHO).

I'm aware of that and my usage of the range-based for is only in cases where 
it's not going to detach.

> 
> > * constexpr, gcc 4.6
> > * possibly also delegating ctors, gcc 4.7 (difficult to find)
> > 
> > Overall it looks to me like I cannot make this code base to work again
> > with
> > gcc 4.5 without spending a lot of time and possibly introducing
> > regressions.
> I would disagree here, it's not exactly difficult for all the cases to move
> back to being supported by gcc 4.5. Most of the features you mentioned are
> almost unused in your code base. I found only one constexpr use, two
> inherited ctors, no delegated ctors. The only annoying ones could be the
> data member initializers since you got a few in private headers and the for
> range loop (which I think you should change anyway).

yes, that's the annoying one which is lots of work and lots of possible 
regressions. I'm not sure whether I'm willing to do that work which I consider 
a useless exercise.

> 
> > So how should we go on?
> 
> My opinion still stands: fix it. :-)

As I just said: I consider this as a useless exercise and a waste of my time 
(and of anybody else who would do that). If we cannot have an exception I 
think I'll leave KWayland in kde-workspace.

> 
> Alternatively, we could bump the compiler requirements globally for KF5
> again. But I think it's too early for that, I'd wait for Qt 5.7 to be out
> (since they'll move their baseline as well at that point anyway).

Well it doesn't need to be a global bump of compiler requirements. But we 
could consider different compiler requirements for frameworks which are non-
portable. KWayland will never be built on Windows neither on OSX. So any 
compiler restrictions on it just shouldn't matter.

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

[Martin Graesslin]

On Tuesday, December 8, 2015 6:03:47 PM CET Mark Gaiser wrote:
> I thought the frameworkintegration plugin was exactly that and usable for
> any platform if they wish to use it.
> Or is my assumption wrong and is it really only for Plasma and should
> others stay away from it?

well obviously it's only for plasma as it's bound to env variables set by 
startkde. And in 4.x time the qpt plugin was in kde-workspace repo, see:
https://quickgit.kde.org/?p=kde-workspace.git=blob=4f67cc55104fe1081b05d381e9516e0215f8e24a=1b97d4427257120e305408404bff5ec6be0b65a9=qguiplatformplugin_kde
%2Fqguiplatformplugin_kde.cpp

> 
> My assumption can very well be wrong, but then i think we need to have a
> "base" frameworkintegration that every app dev can use with or without
> plasma. And a plasma specific version that integrates more in plasma i
> suppose.

I don't think it's anything an app developer should care about. It's 
integration, that's not something the app developer picks - otherwise the app 
breaks on integrating with other platforms.

> I don't care for that either. It's logical and to be expected.
> I do care when i want to use the KF5 filedialog and need to install plasma
> (which has absolutely nothing to do with the dialog) just to get it.
> With "use" i mean the file open dialog, not the ones you can just call from
> the C++ side of things.
> 
> And i definitely do not want to make a QPA just to have that working.

Well you have to. The file dialog is part of integration. If you want to have 
a specific integration you need to provide a QPT (not QPA) plugin. Application 
developers must keep away from that.

Please also read up on the topic of why KFileDialog got removed from our API.

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

[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

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

[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: Purpose as a KDE Framework

[Martin Graesslin]

On Tuesday, December 1, 2015 3:01:10 PM CET Aleix Pol wrote:
> Hi,
> I've been working on Purpose since some months now, with the intention
> of becoming a framework some day. Some information about it can be
> read here:
> https://projects.kde.org/projects/playground/libs/purpose/repository/revisio
> ns/master/entry/README.md
> 
> As it is right now it's a tier 2 framework (kcoreaddons and ki18n)
> plus the plugins. Plugins raise the tier to 3 because of KIO which is
> used by some plugins.

do plugins have to be inside the framework? Otherwise an option might be to 
split out the plugins and move them to frameworkintegration?

> 
> As it is now, it's being used by: Kamoso, QuickShare plasmoid and
> KDevelop for patch sharing. I'd like to see it used in other cases
> than sharing as well as in other applications, but here's where we are
> at the moment. I think it's something to build upon.

having started using QuickShare with it a few days ago when I learned that it 
just needs pupose to be installed: all for 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: setting default widgetStyle (and ColorScheme)

[Martin Graesslin]

On Monday, November 30, 2015 11:06:57 AM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > In my opinion: no. I even think the frameworkintegration framework should
> > get removed from frameworks and moved into Plasma Workspace. Because
> > that's what it is about: integrating Qt applications into plasma.
> 
> I don't care where the framework is, but I do think users should have the
> choice of enjoying all the effort that goes into making great KDE
> themes/styles on platforms other than Linux (and at the same time have as
> close a visual experience as possible using the same applications on
> different platforms, if they chose so).

That's not the point! Any user can use whatever theme they want. The question 
is whether we should default to our Plasma defaults on non-Plasma. And the 
question to that can only be: NO!

Given that: no, the framework integration plugin should not be used anywhere 
except on Plasma.

> 
> Qt does a good job in providing an appearance that matches up with the
> native style, but it will always remain a compromise in cross-platform
> code.

Then change the QStyle. There's an env variable to specify 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

Scope of framework integration plugin?

[Martin Graesslin]

Hi all,

there is currently a review request to add OSX specific changes to framework 
integration plugin [1].

This seems wrong to me. I think our framework integration plugin is about 
integration Qt applications into the Plasma workspace. In my opinion it should 
not be used anywhere else. Not on GNOME, not on Windows and not on OSX. The 
idea of integration is that applications look native on the desired platform. 
The plugin defines the native look on Plasma and by that using it on other 
platforms is automatically breaking the integration.

Now I understand that some people don't like the native look of their platform 
and would prefer using Plasma. Sorry I don't have an answer to that. 
Unfortunately I think it's completely out of scope for the integration 
platform to be considered outside Plasma.

Given that: if people agree with my view that the framework integration is 
only about Plasma, I suggest that we move the framework integration to kde/
workspace to release it together with Plasma instead of frameworks.

Opinions?

Martin

[1]: https://git.reviewboard.kde.org/r/126198/

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: Scope of framework integration plugin?

[Martin Graesslin]

On Monday, November 30, 2015 12:59:02 PM CET Luigi Toscano wrote:
> On Monday 30 of November 2015 12:48:26 Martin Graesslin wrote:
> > Hi all,
> > 
> > there is currently a review request to add OSX specific changes to
> > framework integration plugin [1].
> > 
> > This seems wrong to me. I think our framework integration plugin is about
> > integration Qt applications into the Plasma workspace. In my opinion it
> > should not be used anywhere else. Not on GNOME, not on Windows and not on
> > OSX. The idea of integration is that applications look native on the
> > desired platform. The plugin defines the native look on Plasma and by that
> > using it on other platforms is automatically breaking the integration.
> > 
> > Now I understand that some people don't like the native look of their
> > platform and would prefer using Plasma. Sorry I don't have an answer to
> > that. Unfortunately I think it's completely out of scope for the
> > integration platform to be considered outside Plasma.
> 
> Really? I see people trying to use KDE Applications (for example on #kde) on
> different desktop environment and being confused for the look and feel. I
> understand that:
> - you don't want the Plasma look used outside Plasma
> - yes, other desktop environment should provide and integration plugin
> 
> but isn't it really possible to have a "simpler" default integration plugin,
> when no one else is provided, that at least show the icons, for example?

That would belong into Qt, shouldn't it?

> 
> I think we are not helping users of KDE applications but not Plasma users,
> and let's be realistic about the possibility of other desktop environment
> providing an integration plugin.
> 
> > Given that: if people agree with my view that the framework integration is
> > only about Plasma, I suggest that we move the framework integration to
> > kde/
> > workspace to release it together with Plasma instead of frameworks.
> 
> IMHO only if it's possible to package and load it outside Plasma, or
> otherwise if there is a more sane default plugin.

what's more sane? Qt should do sane things, if not it needs to be patched.

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: Scope of framework integration plugin?

[Martin Graesslin]

On Monday, November 30, 2015 1:02:01 PM CET Aleix Pol wrote:
> On Mon, Nov 30, 2015 at 12:48 PM, Martin Graesslin <mgraess...@kde.org> 
wrote:
> > Hi all,
> > 
> > there is currently a review request to add OSX specific changes to
> > framework integration plugin [1].
> > 
> > This seems wrong to me. I think our framework integration plugin is about
> > integration Qt applications into the Plasma workspace. In my opinion it
> > should not be used anywhere else. Not on GNOME, not on Windows and not on
> > OSX. The idea of integration is that applications look native on the
> > desired platform. The plugin defines the native look on Plasma and by
> > that using it on other platforms is automatically breaking the
> > integration.
> > 
> > Now I understand that some people don't like the native look of their
> > platform and would prefer using Plasma. Sorry I don't have an answer to
> > that. Unfortunately I think it's completely out of scope for the
> > integration platform to be considered outside Plasma.
> > 
> > Given that: if people agree with my view that the framework integration is
> > only about Plasma, I suggest that we move the framework integration to
> > kde/
> > workspace to release it together with Plasma instead of frameworks.
> > 
> > Opinions?
> 
> Hi,
> I agree with you, I've proposed the same thing as you in the past,
> although there's some issues that would then need to be sorted.
> 
> What you actually want is, IMHO, to move the QPlatformTheme plugin
> together with Plasma, but frameworksintegration is not entirely about
> that nowadays: it has code that integrates different frameworks with
> each other:
> - FrameworkIntegrationPlugin: this doesn't really belong in plasma,
> integrates KMessageBox with KNotifications.

agree, does it belong into framework integration, though?

> - infopage: this is used by applications as well as plasma

same question: does this belong into framework integration?

> - KStyle: Plasma can provide styles, but this seems more like a QStyle
> creation framework.

maybe we need a dedicated kstyle framework?

> - platformtheme: Plasma integration. There I agree.

yep, that's what I actually was thinking about. All the defaults for in Plasma

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

[Martin Graesslin]

On Monday, November 30, 2015 1:17:20 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> 
> Is this going to turn into another shouting match?

sorry what?

> 
> > That's not the point! Any user can use whatever theme they want. The
> > question is whether we should default to our Plasma defaults on
> > non-Plasma. And the question to that can only be: NO!
> 
> I'm not suggesting it should be the default, unless the USER CONFIGURES IT
> TO BE.
> 
> > Given that: no, the framework integration plugin should not be used
> > anywhere except on Plasma.
> 
> So, yes, it should be POSSIBLE to use that plugin. What's the point in
> disallowing it if it only requires minimal modifications?

what you put on review board is in my opinion not a minimal modification. That 
are lots of ifdefs and each ifdef is a huge burden for the framework. It means 
platform specific changes which cannot be tested properly. Each of these 
changes make it more difficult for every other developer to work on that code 
base.

Given that: we need to be extremely careful when we consider adding platform 
specific code and need to evaluate very careful the advantages for it.

> 
> Would there be a point in disallowing someone to run a full plasma session
> on a platform that allows it and that isn't Linux?

It's impossible to run a full plasma session on a platform that isn't Linux or 
an X11/Wayland Unix. This is not something which in theory could be possible. 
No it's not! No matter how much work is put into porting: it's impossible to 
port Plasma to non Linux or an X11/Wayland Unix.

So there is no point discussing that. It will never be possible to use Plasma 
on OSX or Windows as it's at least not possible to port KWin to these 
platforms.

> I'd hope the answer to that is no, and
> 
> > Then change the QStyle. There's an env variable to specify it.
> 
> I already stated that that's not enough. Maybe I wasn't clear: using
> QT_STYLE_OVERRIDE or `-style XXX` changes the widget graphical appearance
> but does not apply font or palette settings.

I don't think we should add the ifdefs you proposed in the review request 
because you don't like OSX default settings. We need to look a little bit 
further than what our personal preferences are when we want to do changes 
which affect all developers.

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

[Martin Graesslin]

On Monday, November 30, 2015 3:01:40 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > what you put on review board is in my opinion not a minimal modification.
> > That are lots of ifdefs and each ifdef is a huge burden for the
> > framework. It means
> ...
> 
> > Given that: we need to be extremely careful when we consider adding
> > platform specific code and need to evaluate very careful the advantages
> > for it.
> I won't argue that, and I'll repeat that I have no issues splicing the code
> into a few dedicated files, moving the "ifdefs" to the CMake file.
> It's what I ended up doing with the changes required for kdeinit5, but that
> concerned a lot more ifdefs.
> 
> That'd put the maintenance burden on people who care about the code and the
> platform on which it's supposed to function.

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

But if the platformtheme plugin does get moved to Plasma I would say that it 
doesn't belong there as I think Plasma should only care about targeting X11 
and Wayland. That's something the Plasma team needs to decide on, though. At 
the moment we (to my knowledge) don't have a restriction on that. Only KWin 
specifies itself to only target xorg windowing systems (that is X11 and 
Wayland).

> 
> >> Would there be a point in disallowing someone to run a full plasma
> >> session
> >> on a platform that allows it and that isn't Linux?
> 
> ...
> 
> > So there is no point discussing that. It will never be possible to use
> > Plasma on OSX or Windows as it's at least not possible to port KWin to
> > these platforms.
> 
> "Never say never" mean anything to you?

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

And that doesn't restrict to OSX. It's also not possible to get Plasma on 
GNOME Shell or Plasma on Unity for pretty much the same reason: it's 
impossible to exchange the window manager.

> 
> Regardless, my remark was a purely rhetorical question (OS X is indeed not a
> platform that currently allows to run a full Plasma session without severe
> hacking). With all due respect, your reaction sadly supports an impression
> I have been getting that I probably best leave unvoiced publicly...

Better state clearly what you mean instead of hinting things.

> 
> So KF5/Plasma removed the possibility to use a window manager that's not
> KWin?

No. But Plasma is a coherent product consisting of well integrated components. 
If you talk about Plasma as a product it includes KWin as the window manager. 
If you remove KWin as the window manager, you might be using plasmashell, but 
that's not Plasma anymore in my book (and probably also for all other Plasma 
devs).

> > I don't think we should add the ifdefs you proposed in the review request
> > because you don't like OSX default settings. We need to look a little bit
> 
> It's not just I, and it's about just as much to do with the general
> princpiple of allowing user choice (something *I* am -almost- religious
> about) and not introducing regressions w.r.t. KDE4 .

Honestly: if the "allow user choice" means introducing ifdefs, then I don't 
care about it. Everybody is free to have all the choice they want, but don't 
make your wish for user choice cost for others.

That's similar to running Plasma without KWin: yes it's possible, but don't 
expect us Plasma devs to spend time to fix issues you get when not using KWin. 
You have the freedom of choice, but don't expect that anybody else cares about 
that ;-)

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

[Martin Graesslin]

On Saturday, November 28, 2015 7:58:47 PM CET René J. V. Bertin wrote:
> Olivier Goffart wrote:
> > A pure KF5 appliation would anyway use the KDE platform theme plugin
> > provided by KDE Frameworks.  (in frameworkintegration)
> > (So in other words: that code should not be executed when kde frameworks
> > is
> > installed, in theory)
> 
> So... No, it doesn't. Not on OS X when using the default QPA plugin (Cocoa).
> From the looks of it that one lacks support for theme plugins. Or rather,
> it doesn't return the appropriate thing(s) from
> QGuiApplicationPrivate::platform_integration->themeNames().
> 
> Now the question is, should KF5 applications be able to use the KDE platform
> theme plugin provided by kf5-frameworkintegration if that framework is
> installed?

In my opinion: no. I even think the frameworkintegration framework should get 
removed from frameworks and moved into Plasma Workspace. Because that's what 
it is about: integrating Qt applications into plasma.

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

kdeinit freezes on Wayland in OOM protection

[Martin Graesslin]

Hi all,

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:
#0  0x7f2bbd812446 in do_sigsuspend (set=0x7ffc9d6f7b80) at ../sysdeps/
unix/sysv/linux/sigsuspend.c:31
#1  __GI___sigsuspend (set=0x7ffc9d6f7b80) at ../sysdeps/unix/sysv/linux/
sigsuspend.c:41
#2  0x0040af7a in reset_oom_protect () at /home/martin/src/kf5/
frameworks/kinit/src/kdeinit/kinit.cpp:461
#3  0x0040b85c in launch (argc=2, _name=0x4133cd "klauncher", 
args=0x7ffc9d6f8210 "--fd=9", cwd=0x0, envc=0, envs=0x0, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x4133d7 "0")
at /home/martin/src/kf5/frameworks/kinit/src/kdeinit/kinit.cpp:573
#4  0x0040ce49 in start_klauncher () at /home/martin/src/kf5/
frameworks/kinit/src/kdeinit/kinit.cpp:1033
#5  0x0040f0f3 in main (argc=5, argv=0x7ffc9d6f83f8) at /home/martin/
src/kf5/frameworks/kinit/src/kdeinit/kinit.cpp:1792

It's frozen in this line of code:
sigsuspend();   // wait for the signal to come

The other one has the following stacktrace:
#0  0x7f2bbd8b65e0 in __read_nocancel () at ../sysdeps/unix/syscall-
template.S:81
#1  0x0040c33b in launch (argc=2, _name=0x4133cd "klauncher", 
args=0x7ffc9d6f8210 "--fd=9", cwd=0x0, envc=0, envs=0x0, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x4133d7 "0")
at /home/martin/src/kf5/frameworks/kinit/src/kdeinit/kinit.cpp:754
#2  0x0040ce49 in start_klauncher () at /home/martin/src/kf5/
frameworks/kinit/src/kdeinit/kinit.cpp:1033
#3  0x0040f0f3 in main (argc=5, argv=0x7ffc9d6f83f8) at /home/martin/
src/kf5/frameworks/kinit/src/kdeinit/kinit.cpp:1792

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.

Any advise is welcome.

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 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Martin Graesslin]

On Wednesday, November 18, 2015 5:28:27 PM CET René J.V. Bertin wrote:
> On Wednesday November 18 2015 15:01:59 Martin Gräßlin wrote:
> > idiotic
> 
> If we're starting to call names arguing indeed becomes pointless as the
> apparent lack of actual reading my arguments already suggested. It leaves
> me with no other choice but to discard the RR and put up a mirror in place.

I want to apologize for saying that. Please be aware that this was only 
intended as a description of code (yes I also call code written by myself 
idiotic and worse things) and not against you.

I hope you don't fork, because I think that would be bad. Not because you move 
the code else where, but because the issues pointed out would be unresolved 
giving users of your code a bad framework and thus harming both your users as 
well as the frameworks project for distributing bad code. The problem of 
polling is real. Please accept this feedback.

Best regards
Martin Gräßlin


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: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 5:04:09 PM CET René J. V. Bertin wrote:
> > I can say for Wayland as I wrote that recently:
> I'm guessing Wayland will provide a mechanism that's inspired by what Xcb
> provides?

eh no. As I control both the server (hello KWin) and the client (hello 
KWayland) I just designed a protocol which is ideal for KIdleTime.

> 
> > * it will fire if it's hit - there might be a delay which I think doesn't
> > matter in the case of being swapped out.
> 
> Do you mean that the delay is independent of whether or not you're swapped
> out, or that the question of how long the delay is is moot if you are
> (were) swapped out? It will "Fire if it's hit", but what "it" doesn't get
> hit at the configured time but at a later time?

Sorry, but I just don't get your problem here. This all sounds highly 
theoretical to me and is nothing which I considered at all.

The implementation is basically:
* Wayland client registers an idle timeout
* KWayland::Server creates a QTimer
* on each input event the QTimer is restarted
* if the QTimer times out in the Wayland server the Wayland client is notified

Now this includes a few IPC roundtrips which are completely outside the 
control of my code. Like the last step. What do I know when the client will be 
notified by the kernel about it?

> 
> > The Wayland implementation doesn't give a guarantee that if there is an
> > idle time of 5 sec it will be signalled exactly after 5 sec. That's
> > something a non-realtime system cannot provide.
> 
> Of course not. But that doesn't mean it is pointless to try to minimise the
> delay (for instance by polling ;))

There is absolutely zero polling in the Wayland implementation!

> And I really don't see the point in providing a framework for this (and
> basically only this) if it's not going to try to be as versatile as
> possible. It can and should aim to avoid hogging any resources in the
> default configuration.

Repeat after me: no polling! I mean that: NO POLLING! Don't add code which 
polls. Don't do that.

NO POLLING!

If you cannot do that on OSX, I really think it's better to not provide it. If 
you think it's unfair that there is a backend for X11 which performs polling, 
then I'm going to delete the XScreenSaver based one.

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: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 2:59:57 PM CET René J.V. Bertin wrote:
> KIdleTime really seems to have captured my attention - it's after all very
> closely related to "problems" I've had to solve more than a few times in a
> previous life.
> 
> Currently, the MS Windows and OS X backends have 2 issues with detecting &
> signalling idle timeouts, aside from the fact they allow a heavy margin of
> error:
> 
> - timeouts can be (and are) signalled early (by up to the detection margin).
> I tend to think that time delays should not never be reported early. -
> timeouts can fail to be reported if detected too late.

I don't really understand. How can it signal too early?

> What does the XCB alarm-based mechanism do in this case? I would expect an
> alarm to fire even if it's late, rather than being missed completely. Also,
> does the XCB implementation allow for early reporting of timeouts?

I can say for Wayland as I wrote that recently:
* it cannot fire too early
* it will fire if it's hit - there might be a delay which I think doesn't 
matter in the case of being swapped out.

The Wayland implementation doesn't give a guarantee that if there is an idle 
time of 5 sec it will be signalled exactly after 5 sec. That's something a 
non-realtime system cannot provide.

And honestly I don't think it matters. KIdleTime is about being noticed about 
being idle. We are talking here about timeouts which are in an area where 
realtime doesn't matter and also being swapped out doesn't matter. If you want 
to use KIdleTime for anything below let's say half a minute, I think it's the 
wrong tool for 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: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 6:33:17 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > NO POLLING!
> > 
> > If you cannot do that on OSX, I really think it's better to not provide
> > it. If you think it's unfair that there is a backend for X11 which
> > performs polling, then I'm going to delete the XScreenSaver based one.
> 
> I'm not adding code that polls, I'm modifying an implementation that polls.
> I'm even making it less dependent on frequent polling in its default
> configuration, inspired by WidgetBasedPoller.
> 
> I'm not touching your Wayland implementation, nor the Xcb implementation,
> but I don't see your gripe with changing things in code that is written by
> someone else...
> 
> If developing KF5 frameworks isn't a democratic endeavour I don't really see
> what I'm doing here either.

erm, I don't see how you can come to that conclusion. I'm providing my 
feedback here based on the fact that I recently:

* changed KIdleTime to use plugins
* implemented a Wayland backend

The feedback I'm giving you is "no polling". You so far ignored this feedback 
and came up with very confusing mails about things which absolutely do not 
matter in the framework and stuff like optimal polling intervals and what not. 
All things that are completely irrelevant if you don't use polling. This makes 
the interaction very difficult, because I have a feeling of being ignored and 
having to explain things again and again.

Now of course I care about the implementation of KIdleTime on OSX. KIdleTime 
is a useful framework, but if it polls it's in my opinion a useless framework 
and hardly useable for applications. The idea of the framework is to be 
smarter than what applications would come up with. If the implementation polls 
it triggers wakeups in each application which uses it. This is bad, I hope I 
don't have to explain how bad it is. And this is completely independent on 
whether the code already polled or not. We have a common code ownership and 
this includes that I do care about the implementation on other platforms. 
Especially as I have written one of the supported platforms. At the moment 
there is nobody in KDE who could provide you better feedback on the framework, 
please don't ignore it.

It is relatively easy to change the architecture in ways that it doesn't poll 
in each application. If it's really impossible to do this without polling: 
create a dedicated process which does the polling for all other users. It's 
easy to come up with such solutions: all it needs is taking a step back when 
getting feedback which is "no polling".

Other solutions could involve looking at what OSX provides and not 
implementing everything. E.g. on Wayland I decided to not implement 
forcePollRequest because I considered this as exposing information a Wayland 
client is not proposed to get. Platform abstracted code also means to look at 
a platform and decide what's doable and what not.

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: KIdleTime : provide a settable resolution for the polling backends?

[Martin Graesslin]

On Tuesday, November 17, 2015 8:42:31 AM CET Martin Graesslin wrote:
> On Monday, November 16, 2015 1:31:02 PM CET René J.V. Bertin wrote:
> > Hi,
> > 
> > Working on modernising the OS X plugin for KIdleTime, I realised that
> > there
> > is no mechanism foreseen to set the frequency at which the current system
> > idle time should be sampled on those platforms that need to use a polling
> > approach (OS X, MS Windows and apparently also XScreenSaver).
> 
> Maybe you see something which I do not: where does XScreenSaver use polling?

Ah found it. It's in the parent WidgetBasedPoller. I think that implementation 
already answers how you should do the polling, because it has an 
implementation for it. But nevertheless: please try to not poll.

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: KIdleTime : provide a settable resolution for the polling backends?

[Martin Graesslin]

On Monday, November 16, 2015 1:31:02 PM CET René J.V. Bertin wrote:
> Hi,
> 
> Working on modernising the OS X plugin for KIdleTime, I realised that there
> is no mechanism foreseen to set the frequency at which the current system
> idle time should be sampled on those platforms that need to use a polling
> approach (OS X, MS Windows and apparently also XScreenSaver).

Maybe you see something which I do not: where does XScreenSaver use polling?

> 
> The frequency with which idle time is polled (sampled) determines the delay
> with which the resumingFromIdle signal can be sent, but also the precision
> of the timeoutReached signals.
> 
> At the moment I'm using a QTimer interval of 0 to poll idle time, meaning
> the timer fires and idletime is fired about as fast as possible when there
> are no events to process. That is fine for a system that wants to react as
> fast as possible to the end of an idle period, but probably overkill in
> many other situations. It strikes me that the required resolution is
> something that only the calling code can know, though there are probably
> several values that are reasonable defaults (10x per second seems a bit
> much, 4x maybe just too low).
> 
> Thoughts?

Don't poll. Never ever, don't poll. That's the opposite of what an application 
wants to do. The application wants to sleep till there is an event where it 
should do something. Keeping the application in a busy loop is the exact 
opposite So don't poll.

I know that is easy said, but in the end I think it's better to not provide 
the feature than to perform polling. I don't see a problem with a specific 
feature not being available. Consider for example my implementation for 
Wayland (in kwayland-integration). I had the complete control over the 
platform, but decided not to add support for supporting the forcePollRequest.

Please find a solution which doesn't use polling.

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: KGlobalAccel on ~Linux?

[Martin Graesslin]

On Friday, November 13, 2015 5:24:51 PM CET René J.V. Bertin wrote:
> Hi,
> 
> KDE4's kglobalaccel works just fine on Mac OS X; is there a reason why the
> KF5 wouldn't?

because nobody ported it to Qt's new native event filter. I would love to see 
this enabled again for the non Linux platforms.

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: KGlobalAccel on ~Linux?

[Martin Graesslin]

On Friday, November 13, 2015 5:54:01 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > because nobody ported it to Qt's new native event filter. I would love to
> > see this enabled again for the non Linux platforms.
> 
> Hmm, I see. That's something I should look into then, if I find its
> functionality is indeed lacking. I know kglobalaccel4 works and gets started
> when apparently needed, but I actually do not know what it's used for ...
> :)
> 
> After applying my (committed!) patch from KDE4 that ensures the daemon runs
> as an "agent", the autotest succeeds (and starts the KDE4 kglobalaccel).
> However, starting kglobalaccel5 directly gives
> 
> $ /opt/local/bin/kglobalaccel5
> Could not find drkonqi at /opt/local/lib/libexec/drkonqi
> "No such object path '/org/kde/kglobalaccel'"
> 
> which seems like it has nothing to do with a missing backend or however
> you'd want to call it.

Well it could also mean that kglobalaccel5 directly crashes because it doesn't 
have a backend and we just don't see the backtrace due to missing drkonqi.

Anyway, I'm quite certain that it needs porting as I did the X11 porting :-)

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: Build and test failures with Qt 5.6 and Qt 5.3

[Martin Graesslin]

On Wednesday, November 11, 2015 10:22:13 AM CET Jan Kundrát wrote:
> On Tuesday, 10 November 2015 08:34:02 CET, Martin Graesslin wrote:
> > Yes, most tests don't require a WM. Especially the Net* tests
> > simulate being a
> > window manager. Only the KWindow* tests need a window manager.
> 
> Interesting; it was a Heisenbug, apparently. I cannot reproduce it anymore,
> but I've added code which at least prints out a warning if the Xvfb and/or
> openbox dies for some reason.
> 
> > Well for me there is not much to do. I don't get them failing
> > on my system, so
> > I have no clue what I should fix to make them work again.
> 
> I believe that the CI system and the tests together should be designed to
> provide enough diagnostic information. If you as a developer say "I cannot
> reproduce it on my system, therefore I cannot help you", what can I do as a
> CI administrator to improve the situation? Should we perhaps reduce the
> number of CI-specific scripting to make the deployments closer to what the
> developers run? Would you like pre-built VM images?

Well I did what the CI system does. I started Xvfb with exactly the same 
command as in the build output and also used openbox on that Xvfb and run the 
unit test on the Xvfb. So I think I reproduced the setup. I really tried hard 
to get to the broken state and tried also a few different setups which all did 
not result in a broken test. It takes a long time till I give up on trying to 
reproduce a test, in this case it has happened. (I also must point out that I 
think there is something somewhere horribly broken if we need to adjust our 
tests because Qt changed - currently I need to adjust the tests for each 
release, I'm rather pissed by the "ABI stability" Qt provides).

I wouldn't know what further information the tests could provide to debug it. 
I could tell if I were able to reproduce them and see what goes wrong. At the 
moment all I have is "wm might have crashed" which is nothing the tests can 
check for.

In the long run I want to spend some time in getting our "Xvfb + openbox" 
setup replaced by kwin_wayland on the virtual backend. It would mean KWin gets 
automatically more testing (that's the selfish part) and we have a known base 
for our tests and don't depend on openbox.

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

Frameworks API documentation broken

[Martin Graesslin]

Hi all,

I just wanted to raise awareness of the fact that the Frameworks API 
documentation on api.kde.org is completely broken. Currently one only gets 
error 404 when clicking on the framework links and also in the search I cannot 
find e.g. the frameworks variant of KAboutData.

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: Build and test failures with Qt 5.6 and Qt 5.3

[Martin Graesslin]

On Monday, November 9, 2015 6:00:43 PM CET Jan Kundrát wrote:
> On Monday, 9 November 2015 08:21:21 CET, Martin Graesslin wrote:
> > I'm sorry, but I'm not able to reproduce the failure on my
> > local Qt 5.6 setup.
> > The failures look like there is no WM running on the CI system,
> > maybe openbox
> > crashed? (We had that before that our tests were able to trigger crashes
> > in
> > openbox).
> 
> All Qt versions are hitting the same pool of VMs, and the failure only
> happens on Qt 5.6. Unless there's something in Qt 5.6 which makes openbox
> crash, I don't think that it's a plausible explanation.
> 
> Anyway, if you look at the test log, you can see that the remaining tests
> all passed. Would they still pass even if there was no running WM at that
> point?

Yes, most tests don't require a WM. Especially the Net* tests simulate being a 
window manager. Only the KWindow* tests need a window manager.

> 
> I can add some extra diagnostics to the build scripts if it's really
> needed, but let's figure out other possibilities first, please.

Well for me there is not much to do. I don't get them failing on my system, so 
I have no clue what I should fix to make them work again.

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: Build and test failures with Qt 5.6 and Qt 5.3

[Martin Graesslin]

On Saturday, November 7, 2015 11:59:48 AM CET David Faure wrote:
> > - [5.6] kwindowsystem: KWindowInfoX11Test fails tests
> 
> Martin, can you take a look at
> http://ci-logs.kde.flaska.net/0c/0c4039dc8d4c3fa9eed18a4f5604a90648fe3e84/re
> builddep/rebuilddep-kf5-qt56-gcc-el7/d8b3c13/shell_output.log ?

I'm sorry, but I'm not able to reproduce the failure on my local Qt 5.6 setup. 
The failures look like there is no WM running on the CI system, maybe openbox 
crashed? (We had that before that our tests were able to trigger crashes in 
openbox).

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: Moving KWayland to frameworks

[Martin Graesslin]

On Thursday, November 5, 2015 10:50:06 AM CET Martin Graesslin wrote:
> 2. We use Qt 5.4.

Given David's suggestion on having the last three released Qt releases 
supported, this issue will resolve itself once Qt 5.6 is released. Given that 
this is on the horizon I will delay the move of KWayland to frameworks till Qt 
5.6 is released and Qt 5.4 the required frameworks version.

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

Moving KWayland to frameworks

[Martin Graesslin]

Hi,

after the Plasma 5.5 release I would like to move KWayland to frameworks. The 
main reason is that it is oddly placed in plasma-workspace as it's also a 
library useful for applications (example kde-connect uses it already).

KWayland is designed to be a tier1/integration framework. The current 
dependencies are:
* QtGui 
* Wayland Client (1.7)
* Wayland Server (1.7)
* EGL

License is  LGPL version 2.1, or version 3 or later versions approved by the 
membership of KDE e.V.

There are two things which make the move to frameworks difficult and I don't 
see a solution to it at the moment:

1. We require C++11 without exceptions: reason, it's designed for Linux and it 
didn't come to my mind to restrict us on the compiler due to lack of support 
in Visual Studio.

2. We use Qt 5.4.

For item 1 I only see the possibility of adding an exception [1]. For 2 it 
might be possible to get it down to 5.3 again. The biggest usage of Qt 5.4 
code is the new QSignalSpy syntax in autotests. I don't want to remove that, 
but it's of course possible to make autotests to only build with Qt 5.4. Of 
course I would also accept an exception ;-)

Given the release schedule I would target either the January or February 
frameworks release for inclusion.

Opinions?

Best Regards
Martin Gräßlin


[1] It might make sense to formalize the exception that integration frameworks 
which are not buildable on some platforms are not bound to restrictions of 
that framework.

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: icons packages with frameworks

[Martin Graesslin]

On Wednesday, October 21, 2015 4:17:57 PM CEST Jonathan Riddell wrote:
> Oxygen icons used to be part of KDE Applications and it's regeneration
> by the VDG has it moved to Plasma as part of desktop integration, this
> gives us problems with the version numbers going from 15.04 to 5.5 and
> I plan to rename it to oxygen-icons-plasma as a result.
> 
> It's been suggested that oxygen-icons and also breeze-icons could be
> released as part of frameworks since they can be used generally with
> any application.
> 
> This would give the same problem of version number/name as releasing
> it with Plasma and it would mean a new release every month which may
> well be too much disk space/bandwidth wastage, so I'm not currently in
> favour of it myself, but thought I'd bring up the idea anyway to
> check.

+1 for having them in frameworks. Oxygen Icons used to be part of kdesupport 
for a reason. I think it's exactly not the message we want to put out that you 
can only have icons for your KDE applications if you install Plasma.

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: Policy for Dependencies

[Martin Graesslin]

On Tuesday, October 13, 2015 10:07:18 PM CEST Jaroslaw Staniek wrote:
> Hi,
> Just wanted to say I'd like to minimize dependencies for Kexi on Windows
> too, among other things.
> 
> With my realistic hat on, risky ideas are like:
> - depending on kdecoration to just have default icons

I hope that's not done anywhere as kdecoration is a kde-workspace library 
which should only be used by styles and KWin.

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: Policy for Dependencies

[Martin Graesslin]

On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote:
> Hi,

thanks for raising this topic. I think it's very important that we have a 
general strategy for frameworks and not have thousands of micro-fixes in 
various frameworks.

> 1) "Normal" deployment like we do in on Linux => just installing it with all
> features if possible. 2) "Application Bundles/Installer" like we will have
> to do it on Win/Mac and 3rdparty Linux people will need to do.
> 
> I think the easiest solution is to make stuff optional. That will avoid ugly
> "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people to still
> build stuff with that deps on that operating systems if really wanted.

Given from the no-X11 fixes I think that we should avoid all if (WIN OR APPLE) 
as that:
a) is hard to maintain
b) doesn't scale
c) not testable for the devs working on Linux

Given that it should be feature based and we should make as much usage of the 
built in CMake features we have. I really like the approach we have now found 
for X11 on OSX: disable certain find modules at a global level.

I think that is something which could be applied for more things. Control 
through global ECM settings. This could if we don't want to have global 
changes also through convenient command switches:

e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE

which then implies e.g. no phonon and no dbus and ...

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: Policy for Dependencies

[Martin Graesslin]

On Tuesday, October 13, 2015 2:20:31 PM CEST Christoph Cullmann wrote:
> Hi,
> 
> different take on that below:
> > Hi,
> > 
> >> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote:
> >>> Hi,
> >> 
> >> thanks for raising this topic. I think it's very important that we have a
> >> general strategy for frameworks and not have thousands of micro-fixes in
> >> various frameworks.
> > 
> > ;=)
> > 
> >>> 1) "Normal" deployment like we do in on Linux => just installing it with
> >>> all features if possible. 2) "Application Bundles/Installer" like we
> >>> will have to do it on Win/Mac and 3rdparty Linux people will need to
> >>> do.
> >>> 
> >>> I think the easiest solution is to make stuff optional. That will avoid
> >>> ugly "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people
> >>> to still build stuff with that deps on that operating systems if really
> >>> wanted.>> 
> >> Given from the no-X11 fixes I think that we should avoid all if (WIN OR
> >> APPLE) as that:
> >> a) is hard to maintain
> >> b) doesn't scale
> >> c) not testable for the devs working on Linux
> >> 
> >> Given that it should be feature based and we should make as much usage of
> >> the built in CMake features we have. I really like the approach we have
> >> now found for X11 on OSX: disable certain find modules at a global
> >> level.
> >> 
> >> I think that is something which could be applied for more things. Control
> >> through global ECM settings. This could if we don't want to have global
> >> changes also through convenient command switches:
> >> 
> >> e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE
> >> 
> >> which then implies e.g. no phonon and no dbus and ...
> > 
> > For X11 that might cut it, as it is non-sense to compile it on mac, but I
> > doubt such
> > global magic will cut it for other stuff like phonon or dbus.
> > 
> > You might want to have both on mac and windows, too.
> > 
> > If we start to make this global disabled, we will annoy people, too.
> > In addition: If we want to have 3rdparty devs use our stuff, it must be
> > possible to avoid these dependencies on Linux, too.
> > 
> > I really would like to have the normal CMake strategy: non-required stuff
> > is optional.
> > 
> > For KNotifications thats even obvious, given its internals are build in a
> > ways that this
> > stuff is an internal "plugin".
> > 
> > I don't think we need yet an other level of magic, beside things like "X11
> > on Mac/Win are non-brainers",
> > which is not much more than we do with other global compiler/cmake flags
> > specific for OSes.
> 
> Ok, after the reasonable criticisms of making the sound stuff optional in
> knotifications per default:
> 
> Could we have some ECM switch like (name is just an example):
> 
> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies
> from required to optional as possible, this might lead to a loss of
> functionality." OFF)
> 
> Based on that option, we can make stuff optional and we will have best of
> two worlds:
> 
> 1) no by accident loss of functionality and bug reports (like feared by
> some, and I must confess that might be realistic) 2) an easy to use
> solution for people wanting minimal dependencies as this is "one" switch
> and it will work on all operating systems

I'm not sure whether it's the best solution. The problem you try to fix with 
it is distros breaking packaging. I agree with Martin K that this is a huge 
problem and that it will happen - since the automation of packages I also 
experienced that nobody looks at the output of optional dependencies and the 
packaging breaks.

Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but 
rather a mode which will break if not found during distro builds.

Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if 
distros build (and maybe also kdesrc-build), but is optional if anybody else 
builds.

But I'm not sure how this could be done. Anyway, long story short: I think we 
need the other way around. It should be optional by default, but should be 
turned into stricter requirements on the linux distro case.

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

X11 on Windows

[Martin Graesslin]

Hi frameworks and windows devs,

from the release announcement of the latest frameworks release I learned that 
there were multiple changes to disable finding X11 on Windows (e.g. [1]). I 
think such changes are wrong and I have spoken against such changes (they are 
wrong, CMake supports disabling modules without checking in code!) in the past 
multiple times when I was aware of them (please include me in any reviews 
touching X11).

Given that we came up with a good solution for OSX directly in ECM [2]. Can we 
get a similar solution for Windows? Then we can stop to patch random 
frameworks.

Cheers
Martin

[1] http://commits.kde.org/kdelibs4support/
9cd0b4ffe5d837f16f98346402300db0949b94e7
[2] http://commits.kde.org/extra-cmake-modules/
d4bcaf7eb3ff501ad0a5f06ed0724964e0e0f404

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: X11 on Windows

[Martin Graesslin]

On Monday, October 12, 2015 10:01:42 AM CEST Jaroslaw Staniek wrote:
> On 12 October 2015 at 08:33, Martin Graesslin <mgraess...@kde.org> wrote:
> > Hi frameworks and windows devs,
> > 
> > from the release announcement of the latest frameworks release I learned
> > that there were multiple changes to disable finding X11 on Windows (e.g.
> > [1]). I think such changes are wrong and I have spoken against such
> > changes (they are wrong, CMake supports disabling modules without
> > checking in code!) in the past multiple times when I was aware of them
> > (please include me in any reviews touching X11).
> > 
> > Given that we came up with a good solution for OSX directly in ECM [2].
> > Can we get a similar solution for Windows? Then we can stop to patch
> > random frameworks.
> 
> Hi Martin,good point.
> The difference is that KDE on Mac developer(s) prefer to support X11,
> and I am not sure anyone wants to spend precious time for supporting
> X11 on Windows.

No they don't. There were some confusing mails on the mailing list. The 
situation is exactly the same as on OSX and the change done in ECM is exactly 
based on the assumption that nobody wants to compile Qt software with X11 
support on OSX [1]

> 
> I am not, and I would be assuming WIN32 => NOT X11 in code I maintain.
> So if this is consistent with general direction, equivalent of
> APPLE_FORCE_X11 for windows makes no sense.

I agree that it's probably not needed on Windows unless one wants to keep the 
theoretic workflows alive. The solution for OSX is also more to keep a 
compatibility as it's in fact a compatibility breakage.

> So the case for Windows in KDECMakeSettings.cmake could be simpler,
> but yes, it's needed. Please give me some time for that.

Sure! Thanks for looking into it!

Cheers
Martin

[1] There is the theoretic option to build Qt with X11 support on OSX. I 
assume such a theoretic option would also exist on Windows, if one wants to go 
crazy.

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: Problem investigating a heap-use-after-free in kwindowsystem

[Martin Graesslin]

On Friday, October 2, 2015 8:38:20 PM CEST Michael Pyne wrote:
> On Fri, October 2, 2015 23:59:00 Albert Astals Cid wrote:
> > El Friday 02 October 2015, a les 22:24:00, Martin Graesslin va escriure:
> > > Hi all,
> > > 
> > > I added a new unit test to kwin today [1] and it failed on the CI system
> > > due to the enabled ASAN with an error in kwindowsystem. I'm able to
> > > reproduce it locally, but fail to understand it. To me the code and the
> > > test conditions looks correct. Relevant part of the bt:
> > > #0 0x7f5198ac2c84 in strncpy
> > > (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x73c84) #1 0x7f5190b2be24 in
> > > nstrndup /home/martin/src/kf5/frameworks/
> > > kwindowsystem/src/platforms/xcb/netwm.cpp:110
> > > 
> > > #2 0x7f5190b425ff in NETRootInfo::update(QFlags,
> > > 
> > > QFlags)
> > > /home/martin/src/kf5/frameworks/kwindowsystem/src/
> > > platforms/xcb/netwm.cpp:2142
> > > 
> > > #3 0x7f5190b2f8bf in NETRootInfo::activate() /home/martin/src/kf5/
> > > 
> > > frameworks/kwindowsystem/src/platforms/xcb/netwm.cpp:614
> > > 
> > > #4 0x7f519852be87 in KWin::VirtualDesktopManager::load()
> > > 
> > > /home/martin/src/ kf5/kde/workspace/kwin/virtualdesktops.cpp:348
> > > 
> > > Full backtrace in [2]. The content of the list names is according to
> > > qDebug: ("Desktop 1"). From trying with qdebug it seems to fail in the
> > > first iteration of the for loop.
> > > 
> > > Any help appreciated to get that fixed more than appreciated (I like my
> > > tests green ;-) ).
> 
> Look at the definition of get_stringlist_reply in xcb/netwm.cpp:
> 
> if (reply->type == type && reply->format == 8 && reply->value_len > 0) {
> const char *data = (const char *) xcb_get_property_value(reply); int len =
> reply->value_len;
> 
> if (data) {
> const QByteArray ba = QByteArray::fromRawData(data, data[len -
> 1] ? len : len - 1);
> list = ba.split('\0');
> }
> }
> 
> free(reply);
> 
> QByteArray::fromRawData is highly dangerous here: proper use requires that
> the source of the 'raw data' is kept alive for the entirety of the new
> QByteArray's own lifetime.
> 
> Of course in this case it appears that we immediately use the new QByteArray
> to split into a list, with what will presumably be new QByteArrays
> constructed using the normal (copying) constructor, and that therefore this
> is simply a safe local optimization.
> 
> But look at QByteArray::split()'s API docs: "If sep [\0 here] does not match
> anywhere in the byte array, split() returns a single-element list
> containing ***this*** byte array." (emphasis mine).
> 
> I'm willing to bet you're running into a case where libxcb is sending a
> reply that doesn't contain '\0' (after all, the resultant QList<> contains
> only 1 item), which ends up in a QByteArray that is ::fromRawData()'d, but
> had the source of that data freed at "free(reply)".

This could in deed be the case. The autotests of KWindowSystem cover the code 
in question and do not fail there. So the normal condition seems to work.

> 
> Regards,
>  - Michael Pyne


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

Problem investigating a heap-use-after-free in kwindowsystem

[Martin Graesslin]

Hi all,

I added a new unit test to kwin today [1] and it failed on the CI system due 
to the enabled ASAN with an error in kwindowsystem. I'm able to reproduce it 
locally, but fail to understand it. To me the code and the test conditions 
looks correct. Relevant part of the bt:
#0 0x7f5198ac2c84 in strncpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x73c84)
#1 0x7f5190b2be24 in nstrndup /home/martin/src/kf5/frameworks/
kwindowsystem/src/platforms/xcb/netwm.cpp:110
#2 0x7f5190b425ff in NETRootInfo::update(QFlags, 
QFlags) /home/martin/src/kf5/frameworks/kwindowsystem/src/
platforms/xcb/netwm.cpp:2142
#3 0x7f5190b2f8bf in NETRootInfo::activate() /home/martin/src/kf5/
frameworks/kwindowsystem/src/platforms/xcb/netwm.cpp:614
#4 0x7f519852be87 in KWin::VirtualDesktopManager::load() /home/martin/src/
kf5/kde/workspace/kwin/virtualdesktops.cpp:348

Full backtrace in [2]. The content of the list names is according to qDebug: 
("Desktop 1"). From trying with qdebug it seems to fail in the first iteration 
of the for loop.

Any help appreciated to get that fixed more than appreciated (I like my tests 
green ;-) ).

Cheers
Martin


[1] http://commits.kde.org/kwin/7fed20f13687035d6aa38e9ffa850259f757343d
[2] https://paste.kde.org/pdbwjaxqo

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: ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[Martin Graesslin]

On Monday, August 24, 2015 10:39:57 AM CEST you wrote:
 On Monday 24 August 2015 10:00:43 Martin Gräßlin wrote:
  Am 2015-08-24 01:03, schrieb Kevin Funk:
   Right now whenever I start kdevelop I get the following daemons up and
   running
   on Windows:
   - dbus-daemon
   - kded5
   - kglobalaccel5
   - kioslave
   - klauncher
  
  KGlobalAccel should only be started if there is something trying to
  interact with KGlobalAccel (it's dbus activated). A git grep in kdevelop
  doesn't show it to be used. So I assume it might be a kdevelop-plugin or
  maybe a kded module? In general I think there shouldn't be a reason for
  kglobalaccel to be started in the case of kdevelop. That certainly
  sounds wrong.
 
 I think that kglobalaccel5 is invoked as soon as KXmlGui gets involved
 (which KDevelop makes use of).
 
 Code in kxmlgui.git somewhat agrees: There are references to
 KGlobalAccel::self() in, which will initialize KGlobalAccel which in turn
 starts the kglobalaccel5 daemon (right?). Looks like that is only being done
 if *global* shortcuts are involved, but I'm not sure whether I'm free of
 global shortcuts...

I'll have a look at kxmlgui. There certainly should not be calls to 
KGlobalAccel if no global shortcuts are used.

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: ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[Martin Graesslin]

On Monday, August 24, 2015 10:58:30 AM CEST Martin Graesslin wrote:
 On Monday, August 24, 2015 10:39:57 AM CEST you wrote:
  On Monday 24 August 2015 10:00:43 Martin Gräßlin wrote:
   Am 2015-08-24 01:03, schrieb Kevin Funk:
Right now whenever I start kdevelop I get the following daemons up and
running
on Windows:
- dbus-daemon
- kded5
- kglobalaccel5
- kioslave
- klauncher
   
   KGlobalAccel should only be started if there is something trying to
   interact with KGlobalAccel (it's dbus activated). A git grep in kdevelop
   doesn't show it to be used. So I assume it might be a kdevelop-plugin or
   maybe a kded module? In general I think there shouldn't be a reason for
   kglobalaccel to be started in the case of kdevelop. That certainly
   sounds wrong.
  
  I think that kglobalaccel5 is invoked as soon as KXmlGui gets involved
  (which KDevelop makes use of).
  
  Code in kxmlgui.git somewhat agrees: There are references to
  KGlobalAccel::self() in, which will initialize KGlobalAccel which in turn
  starts the kglobalaccel5 daemon (right?). Looks like that is only being
  done if *global* shortcuts are involved, but I'm not sure whether I'm
  free of global shortcuts...
 
 I'll have a look at kxmlgui. There certainly should not be calls to
 KGlobalAccel if no global shortcuts are used.

The problematic call seems to be:
KActionCollection::addAction

which interacts with KGlobalAccel::hasShortcut. I'll investigate whether this 
can be changed in a way that kglobalaccel won't be started.

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