Re: Review Request 124962: Fix CMAKE_INSTALL_LIBDIR not respecting installation prefix

[Maximiliano Curia]

Hi,

On 28/08/15 04:39, Pinak Ahuja wrote:
> https://git.reviewboard.kde.org/r/124962/
> By Pinak Ahuja.
> 
> /Updated Aug. 28, 2015, 7:39 a.m./
> 
> *Repository: * kwallet-pam
> 
> pam_kwallet5.so was being installed to /lib(64) irrespective of what the
> installation prefix was set to. This patch fixes it.
> 
> pam_kwallet5.so seems to install under the directory set as 
> CMAKE_INSTALL_PREFIX
> 
> 
>   * CMakeLists.txt (f60ac41)
> 
> View Diff 

Sorry that I haven't seen this review before plasma 5.5 was released
(containing this change), but pam modules are traditionally installed in /lib,
that is, with an empty prefix. In the same CMakeLists.txt you can read the
intention to honor this:
set_target_properties (${library_name} PROPERTIES PREFIX "")

Sadly, this alone is not sufficient, thus the / in the install rule.

This change forces me to introduce the attached patch in the Debian package,
as pam modules should be available even if /usr is not mounted.

Happy hacking,
Index: kwallet-pam/CMakeLists.txt
===
--- kwallet-pam.orig/CMakeLists.txt	2015-12-10 14:12:47.823621683 +0100
+++ kwallet-pam/CMakeLists.txt	2015-12-10 20:45:45.967413893 +0100
@@ -36,7 +36,6 @@
 endif()
 
 add_library (${library_name} SHARED ${pam_kwallet_SRCS})
-set_target_properties (${library_name} PROPERTIES PREFIX "")
 target_link_libraries (${library_name}
${PAM_LIBRARIES}
${LIBGCRYPT_LIBRARIES}


signature.asc
Description: OpenPGP digital signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 354250] "Switch User" sometimes sends computer to Standby

[Fabian Köster via KDE Bugzilla]

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

--- Comment #8 from Fabian Köster  ---
The problem still occurs with Plasma 5.5.0 (and powerdevil 5.5.0) on Gentoo.
Maybe the fix was not sufficient?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Martin Graesslin]

On Thursday, December 10, 2015 9:54:15 AM CET Mark Gaiser wrote:
> On Thu, Dec 10, 2015 at 8:07 AM, Martin Graesslin 
> 
> wrote:
> > On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> > > On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser  wrote:
> > > > On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin 
> > 
> > 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.
> 
> Really, you're going to act like that?
> Let me remind you that you opened an Request For Comments (RFC) and i spend
> the time giving (in my opinion) constructive arguments on why i think your
> proposal isn't ideal. You should be happy about that. I did exactly what
> one would want when posting an RFC. I've not said a single bad word about
> plasma[1] and did not do and weird assumptions. You did.
> If i use openbox with frameworks i do not want all of plasma being pulled
> in with all the dependencies it in turn pulls in (basically the whole
> plasma desktop environment).

You get this part wrong. Sorry. Just because it moves to kde/workspace, 
doesn't mean that it will bring in all of Plasma. The QPT plugin will 
certainly not:
* depend on KWin
* depend on Systemsettings
* depend on kscreenlocker
* depend on kdecoration
* etc. etc.

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.

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.

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

[Mark Gaiser]

On Thu, Dec 10, 2015 at 8:07 AM, Martin Graesslin 
wrote:

> On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> > On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser  wrote:
> > > On Wed, Dec 9, 2015 at 8:24 AM, Martin Graesslin 
> 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.
>

Really, you're going to act like that?
Let me remind you that you opened an Request For Comments (RFC) and i spend
the time giving (in my opinion) constructive arguments on why i think your
proposal isn't ideal. You should be happy about that. I did exactly what
one would want when posting an RFC. I've not said a single bad word about
plasma[1] and did not do and weird assumptions. You did.
If i use openbox with frameworks i do not want all of plasma being pulled
in with all the dependencies it in turn pulls in (basically the whole
plasma desktop environment).

I've not been offensive or leaning towards that side, but you are leaning
very much in that direction right now.
Voting on not agreeing with me, how childish can you act.

I'm against it, deal with it.
I might be very wrong, there might be very good arguments to do what you
want, but you fail to convince me of the supposed benefit.

Get some more opinions in this thread! Really! And not just of plasma
orientated folks, also framework folks!
I might be the one person against it where everyone else is in favor. But
we don't know right now since only 3 people (Aleix, you and me) have
responded in here.


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

But why would you break it? I really don't see the point...
Convince me of the benefit of better integration with a couple of sample

Re: Review Request 126296: [Window Thumbnails] Don't crash if Composite is disabled

[Kai Uwe Broulik]

> On Dez. 10, 2015, 7:27 vorm., Martin Gräßlin wrote:
> > How is it possible to have damage enabled, but composite disabled?

If you manually disable Composite in your xorg.conf


- Kai Uwe


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


On Dez. 9, 2015, 10:03 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126296/
> ---
> 
> (Updated Dez. 9, 2015, 10:03 nachm.)
> 
> 
> Review request for Plasma and Martin Gräßlin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> We were checking for Composite at compile-time but not at runtime causing a 
> crash.
> 
> There was a bug about it but I can't find it.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 63d919f 
>   src/declarativeimports/core/windowthumbnail.cpp 2b09657 
> 
> Diff: https://git.reviewboard.kde.org/r/126296/diff/
> 
> 
> Testing
> ---
> 
> With Composite -> proper window thumbnail
> Without Composite -> window icon (instead of crash)
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[David Edmundson]

> On Dec. 4, 2015, 4:28 p.m., David Edmundson wrote:
> > src/plasma/private/packages.cpp, line 128
> > 
> >
> > Having the content structure change when you load a specific package is 
> > going to result in weird behaviour. 
> > 
> > package.files() should be usable from just the structure.
> 
> Marco Martin wrote:
> do you think so? I can make this always work but i think is more correct 
> to have the file definition only valid in containments.
> this is already used for some things, like fallback packages (like custom 
> shells that fall back onthe desktop shell) and seems to be fine.
> what changes is that filePath would change between resolving something 
> and just failing in different packages.
> 
> perhaps some more autotests in kpackage to check this is not having weird 
> side effects?
> 
> David Edmundson wrote:
> Right, but I said .files() will miss something if used without a path and 
> you've responded with something about filePath which is completely different.
> 
> Marco Martin wrote:
> true, that wasn't never really tought to matter much (for wallpaper 
> packages pretty much the same thing happens, file definitions change 
> depending from what's in the package).
> if you think it's important, i can add it unconditionally. would just 
> seems weird that this would be available for applets as well

I'm not too fussed, I just wanted you to have considered it and any possible 
consequences.

Ship it


- David


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


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[Marco Martin]

> On Dec. 4, 2015, 4:28 p.m., David Edmundson wrote:
> > src/plasma/private/packages.cpp, line 128
> > 
> >
> > Having the content structure change when you load a specific package is 
> > going to result in weird behaviour. 
> > 
> > package.files() should be usable from just the structure.
> 
> Marco Martin wrote:
> do you think so? I can make this always work but i think is more correct 
> to have the file definition only valid in containments.
> this is already used for some things, like fallback packages (like custom 
> shells that fall back onthe desktop shell) and seems to be fine.
> what changes is that filePath would change between resolving something 
> and just failing in different packages.
> 
> perhaps some more autotests in kpackage to check this is not having weird 
> side effects?
> 
> David Edmundson wrote:
> Right, but I said .files() will miss something if used without a path and 
> you've responded with something about filePath which is completely different.
> 
> Marco Martin wrote:
> true, that wasn't never really tought to matter much (for wallpaper 
> packages pretty much the same thing happens, file definitions change 
> depending from what's in the package).
> if you think it's important, i can add it unconditionally. would just 
> seems weird that this would be available for applets as well
> 
> David Edmundson wrote:
> I'm not too fussed, I just wanted you to have considered it and any 
> possible consequences.
> 
> Ship it

I didn't see particular consequencies, but yeah, if you can find any please 
shout any moment, can always be changed :)


- Marco


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


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[Marco Martin]

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

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


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 5f92df4799ba73bddf7a3adb5414c235acaaacde by Marco Martin 
to branch master.


Repository: plasma-framework


Description
---

the CompactApplet file from the shell package defines the behavior of the 
poopup applets in the panel (it implements an internal dialog and all that jazz)
implementing a simplified systray(both the one for the phone and a separate one 
for the desktop), i noticed that a containment may have different ideas on how 
to expand an applet: the systray would have for instance a single popup dialog 
and put all of its applet full representtions in the same Dialog , this lets 
containment representation to override that file (*if* won't get abused, that's 
the only thing makes me a bit on the fence about this)
It would make possible also fairly different designs that have been proposed in 
the past, such as the bug sidebar similar to the "charm bar"


Diffs
-

  src/plasma/private/packages.cpp c04d36d 
  src/plasma/private/packages_p.h a7c4cb1 
  src/plasmaquick/appletquickitem.cpp efe8611 
  src/plasmaquick/private/appletquickitem_p.h 79c1a2e 

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


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[Marco Martin]

> On Dec. 4, 2015, 4:28 p.m., David Edmundson wrote:
> > src/plasma/private/packages.cpp, line 128
> > 
> >
> > Having the content structure change when you load a specific package is 
> > going to result in weird behaviour. 
> > 
> > package.files() should be usable from just the structure.
> 
> Marco Martin wrote:
> do you think so? I can make this always work but i think is more correct 
> to have the file definition only valid in containments.
> this is already used for some things, like fallback packages (like custom 
> shells that fall back onthe desktop shell) and seems to be fine.
> what changes is that filePath would change between resolving something 
> and just failing in different packages.
> 
> perhaps some more autotests in kpackage to check this is not having weird 
> side effects?
> 
> David Edmundson wrote:
> Right, but I said .files() will miss something if used without a path and 
> you've responded with something about filePath which is completely different.
> 
> Marco Martin wrote:
> true, that wasn't never really tought to matter much (for wallpaper 
> packages pretty much the same thing happens, file definitions change 
> depending from what's in the package).
> if you think it's important, i can add it unconditionally. would just 
> seems weird that this would be available for applets as well
> 
> David Edmundson wrote:
> I'm not too fussed, I just wanted you to have considered it and any 
> possible consequences.
> 
> Ship it
> 
> Marco Martin wrote:
> I didn't see particular consequencies, but yeah, if you can find any 
> please shout any moment, can always be changed :)
> 
> Marco Martin wrote:
> uh! idea:) maybe containment packages may be yet another subclass of the 
> package structure with that file more, so it doesn't do weird things when the 
> path changes

gah, nevermind, since the package is loaded in the applet ctor, isContainment() 
doesn't work yet


- Marco


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


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 124962: Fix CMAKE_INSTALL_LIBDIR not respecting installation prefix

[Martin Klapetek]

Hey,

On Thu, Dec 10, 2015 at 2:54 PM, Maximiliano Curia 
wrote:

> Hi,
>
> Sorry that I haven't seen this review before plasma 5.5 was released
> (containing this change), but pam modules are traditionally installed in
> /lib,
> that is, with an empty prefix. In the same CMakeLists.txt you can read the
> intention to honor this:
> set_target_properties (${library_name} PROPERTIES PREFIX "")
>
> Sadly, this alone is not sufficient, thus the / in the install rule.
>
> This change forces me to introduce the attached patch in the Debian
> package,
> as pam modules should be available even if /usr is not mounted.
>

Thanks for getting in touch!

However if I'm not mistaken, that set_target_properties call does not
do what you imply it does. Setting empty PREFIX means that it will
not prepend "lib" to the filename, eg. "libpam_kwallet.so", but will instead
name it "pam_kwallet.so".

It has nothing to do with install paths.

If you want to have it installed in /lib, just set CMAKE_INSTALL_PREFIX
to "/", then it should install into /lib correctly.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [plasma-devel] Re: 5.5 video

[Sebastian Kügler]

On Wednesday, December 09, 2015 02:55:12 PM Mario Fux wrote:
> Am Tuesday 08 December 2015, 09.21:05 schrieb Lucas S:
> > Hi,
> 
> Morning Lucas
> 
> > -Fixed a typo "managment" => "management".
> >
> > 
> >
> > Thanks for spotting this
> >
> > 
> >
> > Link
> > https://youtu.be/3wFTo34mCj0
> 
> So you're video is in the announcement and I wanted to tel you: thanks a
> lot  for your work and constructive work with the criticism. Hope to see
> much more of your work in the future!

+1, definitely very good work!
-- 
sebas

http://www.kde.org | http://vizZzion.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Mark Gaiser]

On Thu, Dec 10, 2015 at 10:20 AM, Martin Graesslin 
wrote:

> On Thursday, December 10, 2015 9:54:15 AM CET Mark Gaiser wrote:
> > On Thu, Dec 10, 2015 at 8:07 AM, Martin Graesslin 
> >
> > wrote:
> > > On Wednesday, December 9, 2015 4:03:24 PM CET Aleix Pol wrote:
> > > > On Wed, Dec 9, 2015 at 3:56 PM, Mark Gaiser 
> 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.
> >
> > Really, you're going to act like that?
> > Let me remind you that you opened an Request For Comments (RFC) and i
> spend
> > the time giving (in my opinion) constructive arguments on why i think
> your
> > proposal isn't ideal. You should be happy about that. I did exactly what
> > one would want when posting an RFC. I've not said a single bad word about
> > plasma[1] and did not do and weird assumptions. You did.
> > If i use openbox with frameworks i do not want all of plasma being pulled
> > in with all the dependencies it in turn pulls in (basically the whole
> > plasma desktop environment).
>
> You get this part wrong. Sorry. Just because it moves to kde/workspace,
> doesn't mean that it will bring in all of Plasma. The QPT plugin will
> certainly not:
> * depend on KWin
> * depend on Systemsettings
> * depend on kscreenlocker
> * depend on kdecoration
> * etc. etc.
>
> 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 

Review Request 126300: Plasma Search KCM: display the runner descriptions

[Jonathan Marten]

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

Review request for Plasma.


Repository: plasma-desktop


Description
---

In Plasma 5 this KCM only lists the names of the available runners, with no 
explanation of what they do.  In its previous incarnation in KDE4 (the dropdown 
list from the runner config button), the descriptions were displayed.  This 
change restores them.


Diffs
-

  kcms/runners/kcm.h f1239ee454cf40c3721743d5c771b4686d449d21 
  kcms/runners/kcm.cpp 4af82de9c385725a23cc09a074c5803f11a7945f 

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


Testing
---

Built plasma-desktop with this change, checked appearance of KCM in Breeze, 
Oxygen and older styles.


File Attachments


Screenshot before
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/caf0a4d7-ab8d-410a-9409-ae6935d24929__plasmasearch-before-r126300.png
Screenshot after
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/0b695a2b-4307-4a70-9a9b-4c3bb80f7955__plasmasearch-after-r126300.png


Thanks,

Jonathan Marten

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

[Kai Uwe Broulik]

  Hi,Mark, I think you completely misunderstood what move to kde/workspace means. This is not a repository, nobody wants to move that stuff into plasma-workspace. It just has semantic relevance, ie. no frameworks ABI and compiler restrictions, different release schedule, but it will still be its own repository with a minimal set of dependencies. Cheers,Kai Uwe
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 126301: Add protocol for server side decoration

[Martin Gräßlin]

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

Review request for Plasma and Sebastian Kügler.


Repository: kwayland


Description
---

[client] Add implementation for ServerSideDecoration


[server] Add implementation for server side decoration protocol


[autotest] Add tests for ServerSideDecoration protocol


Diffs
-

  autotests/client/test_wayland_registry.cpp 
772da821d634efa1c72d13a7c081994bd78ab7fd 
  autotests/client/CMakeLists.txt 014b5e0798618394ecf11c8b8cfa796dcf9c37f3 
  autotests/client/test_server_side_decoration.cpp PRE-CREATION 
  src/client/CMakeLists.txt 1d2b5492954e07fc77b2209a123ef8e43e340e8a 
  src/client/protocols/server-decoration.xml PRE-CREATION 
  src/client/registry.h c079852a4d96471face2a06795a531abf2e4d8c0 
  src/client/registry.cpp 71640e184da4699bdc27a993b710b1f761c919d2 
  src/client/server_decoration.h PRE-CREATION 
  src/client/server_decoration.cpp PRE-CREATION 
  src/server/CMakeLists.txt cd5c7bb1a93a470fd58cb9c6d86068da961addeb 
  src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
  src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 
  src/server/server_decoration_interface.h PRE-CREATION 
  src/server/server_decoration_interface.cpp PRE-CREATION 
  src/tools/mapping.txt 9dc8204d65092aa86f6ced8ae5a131a2f89018d0 

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


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Possible issue in breeze 5.5 kstyle

[Sandro Andrade]

Hi there,

After upgrading plasma to 5.5 I started to notice some weird behaviour
in using QQuickView to load a QML document:

Ex:

m_quickView->setSource(QUrl("qrc:/main.qml"));
...
setupGUI();
...
if (!m_initialGroup.exists())
runWizard();

The issue is that no QML content is shown if using breeze 5.5. It
works fine with breeze 5.4.3.

After doing some git bisect I've found that commit
6d852f30a1f2c1988359d4e0cdb21e2f1714a6bd in breeze repository added a
QTimer in kstyle/breezepalettehelper.cpp (line 65) to postpone the
update of widget's palette. The consequence is that the loading of QML
scene is probably running *before* the delayed palette update, which
causes the issue.

If something delays the ending of the aforementioned code (for
instance, it executes a wizard in the first run of the application,
when no app's rc setting file exists) then the QTimer has the chance
to has already been finished when showing the QQuickView and things
work properly. Commenting out the line 65 in
kstyle/breezepalettehelper.cpp fixes the issue but obviously should
make something else broken. Such commit fixed BUG 344425.

Any suggestions?

Thanks in advance,
--
Sandro
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126301: Add protocol for server side decoration

[Martin Gräßlin]

> On Dec. 10, 2015, 3:54 p.m., Marco Martin wrote:
> > src/client/protocols/server-decoration.xml, line 45
> > 
> >
> > do clients have to explicitly call that with risks of leaks?

sorry I don't get the question? It's the Wayland protocol way of saying from 
client side that it's no longer needed.


> On Dec. 10, 2015, 3:54 p.m., Marco Martin wrote:
> > src/client/protocols/server-decoration.xml, line 57
> > 
> >
> > the use case is that i can request a mode, but the server can ignore it 
> > and send me a different mode instead?

yes that would be possible. Like client sends "Client" and server answers with 
"None" because phone UI. In general it would acknowledge the Client's choice 
(use case yakuake, Plasma tooltips, etc.)


- Martin


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


On Dec. 10, 2015, 3:03 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126301/
> ---
> 
> (Updated Dec. 10, 2015, 3:03 p.m.)
> 
> 
> Review request for Plasma and Sebastian Kügler.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> [client] Add implementation for ServerSideDecoration
> 
> 
> [server] Add implementation for server side decoration protocol
> 
> 
> [autotest] Add tests for ServerSideDecoration protocol
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_registry.cpp 
> 772da821d634efa1c72d13a7c081994bd78ab7fd 
>   autotests/client/CMakeLists.txt 014b5e0798618394ecf11c8b8cfa796dcf9c37f3 
>   autotests/client/test_server_side_decoration.cpp PRE-CREATION 
>   src/client/CMakeLists.txt 1d2b5492954e07fc77b2209a123ef8e43e340e8a 
>   src/client/protocols/server-decoration.xml PRE-CREATION 
>   src/client/registry.h c079852a4d96471face2a06795a531abf2e4d8c0 
>   src/client/registry.cpp 71640e184da4699bdc27a993b710b1f761c919d2 
>   src/client/server_decoration.h PRE-CREATION 
>   src/client/server_decoration.cpp PRE-CREATION 
>   src/server/CMakeLists.txt cd5c7bb1a93a470fd58cb9c6d86068da961addeb 
>   src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
>   src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 
>   src/server/server_decoration_interface.h PRE-CREATION 
>   src/server/server_decoration_interface.cpp PRE-CREATION 
>   src/tools/mapping.txt 9dc8204d65092aa86f6ced8ae5a131a2f89018d0 
> 
> Diff: https://git.reviewboard.kde.org/r/126301/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-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: Review Request 126246: Add test for dynamically changing file definitions

[Mark Gaiser]

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


+1

I don't know this package, but the change "looks ok" to me.
If nobody objects within - lets say 3 days - then just ship it.

- Mark Gaiser


On dec 4, 2015, 6:23 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126246/
> ---
> 
> (Updated dec 4, 2015, 6:23 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> this, referred to https://git.reviewboard.kde.org/r/126244/ tests that adding 
> or removing a file definition depending on the path (and whatever criteria, 
> like metadata contents) works. since is already done in several places has to 
> work correctly
> 
> 
> Diffs
> -
> 
>   autotests/packagestructuretest.h de2038e 
>   autotests/packagestructuretest.cpp 4784bfd 
> 
> Diff: https://git.reviewboard.kde.org/r/126246/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[David Edmundson]

> On Dec. 4, 2015, 4:28 p.m., David Edmundson wrote:
> > src/plasma/private/packages.cpp, line 128
> > 
> >
> > Having the content structure change when you load a specific package is 
> > going to result in weird behaviour. 
> > 
> > package.files() should be usable from just the structure.
> 
> Marco Martin wrote:
> do you think so? I can make this always work but i think is more correct 
> to have the file definition only valid in containments.
> this is already used for some things, like fallback packages (like custom 
> shells that fall back onthe desktop shell) and seems to be fine.
> what changes is that filePath would change between resolving something 
> and just failing in different packages.
> 
> perhaps some more autotests in kpackage to check this is not having weird 
> side effects?

Right, but I said .files() will miss something if used without a path and 
you've responded with something about filePath which is completely different.


- David


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


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[Marco Martin]

> On Dec. 4, 2015, 4:28 p.m., David Edmundson wrote:
> > src/plasma/private/packages.cpp, line 128
> > 
> >
> > Having the content structure change when you load a specific package is 
> > going to result in weird behaviour. 
> > 
> > package.files() should be usable from just the structure.
> 
> Marco Martin wrote:
> do you think so? I can make this always work but i think is more correct 
> to have the file definition only valid in containments.
> this is already used for some things, like fallback packages (like custom 
> shells that fall back onthe desktop shell) and seems to be fine.
> what changes is that filePath would change between resolving something 
> and just failing in different packages.
> 
> perhaps some more autotests in kpackage to check this is not having weird 
> side effects?
> 
> David Edmundson wrote:
> Right, but I said .files() will miss something if used without a path and 
> you've responded with something about filePath which is completely different.

true, that wasn't never really tought to matter much (for wallpaper packages 
pretty much the same thing happens, file definitions change depending from 
what's in the package).
if you think it's important, i can add it unconditionally. would just seems 
weird that this would be available for applets as well


- Marco


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


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 337674] kded5 is eating CPU

[via KDE Bugzilla]

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

--- Comment #74 from mif...@gmail.com ---
bt here - http://pastebin.com/dxUkvRMx
kde-frameworks/kded 5.16.0
kde-plasma/plasma-desktop 5.5.0
kde-plasma/powerdevil 5.5.0

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126275: Make the "Plasma (Wayland)" xsession file actually say "Plasma (Wayland)"

[Martin Gräßlin]

> On Dec. 10, 2015, 12:03 a.m., Rex Dieter wrote:
> > I (still) think it should be renamed and Wayland mentioned *somewhere*.  
> > Not all login managers distinguish wayland sessions like sddm does.
> 
> David Edmundson wrote:
> Though if you do SDDM will say:
> 
> Plasma (wayland) (wayland)
> 
> Rex Dieter wrote:
> If need be, yes.
> 
> Aleix Pol Gonzalez wrote:
> AFAIR, SDDM is the only one officially supported by Plasma. It's not 
> really acceptable that it has visual regressions.
> 
> Martin Klapetek wrote:
> I agree with Rex though, imo it should be up to the desktop to
> provide the "wayland" string in its file rather than sddm itself.
> Our stuff shouldn't make assumptions about its visual representations.
> 
> Rex Dieter wrote:
> to put another way, some downstreams will need to patch in a wayland 
> identifier (fedora included), i'd rather that not be the case
> 
> Martin Gräßlin wrote:
> I just think there should not be a "Wayland" at all - neither an "X11". 
> It's an extremly technical name no real user will be able to understand. So 
> let's take a step back and think how we want to call it.
> 
> Martin Klapetek wrote:
> > It's an extremly technical name no real user will be able to understand
> 
> True, but for the time being, a wayland session is an extremely
> technical thing no real user should use. So I would say it's fine
> for now to be technical.
> 
> Nevertheless this will have to be taken up with sddm later if you
> don't want "wayland" to appear there at all.
> 
> Aleix Pol Gonzalez wrote:
> Let's call it "Plasma Next" ;)

Next/Legacy is I think the approach to go. Something like "Plasma on 
experimental windowing system" and then in future "Plasma on legacy windowing 
system". It should be named better of course, just not Wayland.


- Martin


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


On Dec. 8, 2015, 3:09 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126275/
> ---
> 
> (Updated Dec. 8, 2015, 3:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The commit/review says it's displayed as "Plasma (Wayland)"
> but the name is just "Plasma", making it confusing in login
> manager.
> 
> 
> Diffs
> -
> 
>   plasmawayland.desktop.cmake c5d5757 
> 
> Diff: https://git.reviewboard.kde.org/r/126275/diff/
> 
> 
> Testing
> ---
> 
> Sddm now clearly shows which "Plasma" is Waylandplasma.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126301: Add protocol for server side decoration

[Kai Uwe Broulik]

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



src/client/protocols/server-decoration.xml (line 38)


that *it* does not want



src/server/display.cpp (line 330)


*this* is not used in the lambda


- Kai Uwe Broulik


On Dez. 10, 2015, 2:03 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126301/
> ---
> 
> (Updated Dez. 10, 2015, 2:03 nachm.)
> 
> 
> Review request for Plasma and Sebastian Kügler.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> [client] Add implementation for ServerSideDecoration
> 
> 
> [server] Add implementation for server side decoration protocol
> 
> 
> [autotest] Add tests for ServerSideDecoration protocol
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_registry.cpp 
> 772da821d634efa1c72d13a7c081994bd78ab7fd 
>   autotests/client/CMakeLists.txt 014b5e0798618394ecf11c8b8cfa796dcf9c37f3 
>   autotests/client/test_server_side_decoration.cpp PRE-CREATION 
>   src/client/CMakeLists.txt 1d2b5492954e07fc77b2209a123ef8e43e340e8a 
>   src/client/protocols/server-decoration.xml PRE-CREATION 
>   src/client/registry.h c079852a4d96471face2a06795a531abf2e4d8c0 
>   src/client/registry.cpp 71640e184da4699bdc27a993b710b1f761c919d2 
>   src/client/server_decoration.h PRE-CREATION 
>   src/client/server_decoration.cpp PRE-CREATION 
>   src/server/CMakeLists.txt cd5c7bb1a93a470fd58cb9c6d86068da961addeb 
>   src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
>   src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 
>   src/server/server_decoration_interface.h PRE-CREATION 
>   src/server/server_decoration_interface.cpp PRE-CREATION 
>   src/tools/mapping.txt 9dc8204d65092aa86f6ced8ae5a131a2f89018d0 
> 
> Diff: https://git.reviewboard.kde.org/r/126301/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126301: Add protocol for server side decoration

[Marco Martin]

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



src/client/protocols/server-decoration.xml (line 45)


do clients have to explicitly call that with risks of leaks?



src/client/protocols/server-decoration.xml (line 57)


the use case is that i can request a mode, but the server can ignore it and 
send me a different mode instead?


- Marco Martin


On Dec. 10, 2015, 2:03 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126301/
> ---
> 
> (Updated Dec. 10, 2015, 2:03 p.m.)
> 
> 
> Review request for Plasma and Sebastian Kügler.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> [client] Add implementation for ServerSideDecoration
> 
> 
> [server] Add implementation for server side decoration protocol
> 
> 
> [autotest] Add tests for ServerSideDecoration protocol
> 
> 
> Diffs
> -
> 
>   autotests/client/test_wayland_registry.cpp 
> 772da821d634efa1c72d13a7c081994bd78ab7fd 
>   autotests/client/CMakeLists.txt 014b5e0798618394ecf11c8b8cfa796dcf9c37f3 
>   autotests/client/test_server_side_decoration.cpp PRE-CREATION 
>   src/client/CMakeLists.txt 1d2b5492954e07fc77b2209a123ef8e43e340e8a 
>   src/client/protocols/server-decoration.xml PRE-CREATION 
>   src/client/registry.h c079852a4d96471face2a06795a531abf2e4d8c0 
>   src/client/registry.cpp 71640e184da4699bdc27a993b710b1f761c919d2 
>   src/client/server_decoration.h PRE-CREATION 
>   src/client/server_decoration.cpp PRE-CREATION 
>   src/server/CMakeLists.txt cd5c7bb1a93a470fd58cb9c6d86068da961addeb 
>   src/server/display.h 154e0f0b4c00375ca7d7f0a980392877fe743f50 
>   src/server/display.cpp 81ea7316e3b77f6db95748339d3dfaa30d33 
>   src/server/server_decoration_interface.h PRE-CREATION 
>   src/server/server_decoration_interface.cpp PRE-CREATION 
>   src/tools/mapping.txt 9dc8204d65092aa86f6ced8ae5a131a2f89018d0 
> 
> Diff: https://git.reviewboard.kde.org/r/126301/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126275: Make the "Plasma (Wayland)" xsession file actually say "Plasma (Wayland)"

[Martin Klapetek]

> On Dec. 10, 2015, 12:03 a.m., Rex Dieter wrote:
> > I (still) think it should be renamed and Wayland mentioned *somewhere*.  
> > Not all login managers distinguish wayland sessions like sddm does.
> 
> David Edmundson wrote:
> Though if you do SDDM will say:
> 
> Plasma (wayland) (wayland)
> 
> Rex Dieter wrote:
> If need be, yes.
> 
> Aleix Pol Gonzalez wrote:
> AFAIR, SDDM is the only one officially supported by Plasma. It's not 
> really acceptable that it has visual regressions.
> 
> Martin Klapetek wrote:
> I agree with Rex though, imo it should be up to the desktop to
> provide the "wayland" string in its file rather than sddm itself.
> Our stuff shouldn't make assumptions about its visual representations.
> 
> Rex Dieter wrote:
> to put another way, some downstreams will need to patch in a wayland 
> identifier (fedora included), i'd rather that not be the case
> 
> Martin Gräßlin wrote:
> I just think there should not be a "Wayland" at all - neither an "X11". 
> It's an extremly technical name no real user will be able to understand. So 
> let's take a step back and think how we want to call it.

> It's an extremly technical name no real user will be able to understand

True, but for the time being, a wayland session is an extremely
technical thing no real user should use. So I would say it's fine
for now to be technical.

Nevertheless this will have to be taken up with sddm later if you
don't want "wayland" to appear there at all.


- Martin


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


On Dec. 8, 2015, 3:09 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126275/
> ---
> 
> (Updated Dec. 8, 2015, 3:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The commit/review says it's displayed as "Plasma (Wayland)"
> but the name is just "Plasma", making it confusing in login
> manager.
> 
> 
> Diffs
> -
> 
>   plasmawayland.desktop.cmake c5d5757 
> 
> Diff: https://git.reviewboard.kde.org/r/126275/diff/
> 
> 
> Testing
> ---
> 
> Sddm now clearly shows which "Plasma" is Waylandplasma.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126275: Make the "Plasma (Wayland)" xsession file actually say "Plasma (Wayland)"

[Aleix Pol Gonzalez]

> On Dec. 10, 2015, 12:03 a.m., Rex Dieter wrote:
> > I (still) think it should be renamed and Wayland mentioned *somewhere*.  
> > Not all login managers distinguish wayland sessions like sddm does.
> 
> David Edmundson wrote:
> Though if you do SDDM will say:
> 
> Plasma (wayland) (wayland)
> 
> Rex Dieter wrote:
> If need be, yes.
> 
> Aleix Pol Gonzalez wrote:
> AFAIR, SDDM is the only one officially supported by Plasma. It's not 
> really acceptable that it has visual regressions.
> 
> Martin Klapetek wrote:
> I agree with Rex though, imo it should be up to the desktop to
> provide the "wayland" string in its file rather than sddm itself.
> Our stuff shouldn't make assumptions about its visual representations.
> 
> Rex Dieter wrote:
> to put another way, some downstreams will need to patch in a wayland 
> identifier (fedora included), i'd rather that not be the case
> 
> Martin Gräßlin wrote:
> I just think there should not be a "Wayland" at all - neither an "X11". 
> It's an extremly technical name no real user will be able to understand. So 
> let's take a step back and think how we want to call it.
> 
> Martin Klapetek wrote:
> > It's an extremly technical name no real user will be able to understand
> 
> True, but for the time being, a wayland session is an extremely
> technical thing no real user should use. So I would say it's fine
> for now to be technical.
> 
> Nevertheless this will have to be taken up with sddm later if you
> don't want "wayland" to appear there at all.

Let's call it "Plasma Next" ;)


- Aleix


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


On Dec. 8, 2015, 3:09 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126275/
> ---
> 
> (Updated Dec. 8, 2015, 3:09 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The commit/review says it's displayed as "Plasma (Wayland)"
> but the name is just "Plasma", making it confusing in login
> manager.
> 
> 
> Diffs
> -
> 
>   plasmawayland.desktop.cmake c5d5757 
> 
> Diff: https://git.reviewboard.kde.org/r/126275/diff/
> 
> 
> Testing
> ---
> 
> Sddm now clearly shows which "Plasma" is Waylandplasma.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126302: [GCI] Make "comment" section of the timezones configuration searchable

[David Edmundson]

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

Ship it!


Nice work.

- David Edmundson


On Dec. 10, 2015, 2:53 p.m., Imran Tatriev wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126302/
> ---
> 
> (Updated Dec. 10, 2015, 2:53 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Here's a link for the task - 
> https://codein.withgoogle.com/dashboard/task-instances/6228912182919168/
> 
> P.S. As coding style says: "Try to keep lines shorter than 100 characters, 
> inserting line breaks as necessary.", therefore I've continued on a new line.
> P.S.S I have write access, so if you're ok with this patch, I can push it. ;)
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/plugin/timezonemodel.cpp 5d23505 
> 
> Diff: https://git.reviewboard.kde.org/r/126302/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> "comment" section works just fine!
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/efd530e3-9c81-40f2-be7a-14c89192b71a__comment_section.png
> 
> 
> Thanks,
> 
> Imran Tatriev
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126244: Let containments override CompactApplet.qml

[Marco Martin]

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


ping?

- Marco Martin


On Dec. 4, 2015, 6:24 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126244/
> ---
> 
> (Updated Dec. 4, 2015, 6:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> the CompactApplet file from the shell package defines the behavior of the 
> poopup applets in the panel (it implements an internal dialog and all that 
> jazz)
> implementing a simplified systray(both the one for the phone and a separate 
> one for the desktop), i noticed that a containment may have different ideas 
> on how to expand an applet: the systray would have for instance a single 
> popup dialog and put all of its applet full representtions in the same Dialog 
> , this lets containment representation to override that file (*if* won't get 
> abused, that's the only thing makes me a bit on the fence about this)
> It would make possible also fairly different designs that have been proposed 
> in the past, such as the bug sidebar similar to the "charm bar"
> 
> 
> Diffs
> -
> 
>   src/plasma/private/packages.cpp c04d36d 
>   src/plasma/private/packages_p.h a7c4cb1 
>   src/plasmaquick/appletquickitem.cpp efe8611 
>   src/plasmaquick/private/appletquickitem_p.h 79c1a2e 
> 
> Diff: https://git.reviewboard.kde.org/r/126244/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126246: Add test for dynamically changing file definitions

[Marco Martin]

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


ping?

- Marco Martin


On Dec. 4, 2015, 6:23 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126246/
> ---
> 
> (Updated Dec. 4, 2015, 6:23 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> this, referred to https://git.reviewboard.kde.org/r/126244/ tests that adding 
> or removing a file definition depending on the path (and whatever criteria, 
> like metadata contents) works. since is already done in several places has to 
> work correctly
> 
> 
> Diffs
> -
> 
>   autotests/packagestructuretest.h de2038e 
>   autotests/packagestructuretest.cpp 4784bfd 
> 
> Diff: https://git.reviewboard.kde.org/r/126246/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126302: [GCI] Make "comment" section of the timezones configuration searchable

[Imran Tatriev]

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

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


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit 6381dbd9b7a0f33dd024a98ef18a5143ba929b0e by David 
Edmundson on behalf of Imran Tatriev to branch Plasma/5.5.


Repository: plasma-workspace


Description
---

Here's a link for the task - 
https://codein.withgoogle.com/dashboard/task-instances/6228912182919168/

P.S. As coding style says: "Try to keep lines shorter than 100 characters, 
inserting line breaks as necessary.", therefore I've continued on a new line.
P.S.S I have write access, so if you're ok with this patch, I can push it. ;)


Diffs
-

  applets/digital-clock/plugin/timezonemodel.cpp 5d23505 

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


Testing
---


File Attachments


"comment" section works just fine!
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/10/efd530e3-9c81-40f2-be7a-14c89192b71a__comment_section.png


Thanks,

Imran Tatriev

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel