[Powerdevil] [Bug 345618] Powerdevil crash from idle desktop.

[Matthew Dawson]

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

--- Comment #2 from Matthew Dawson  ---
As an additional note, this happened after my laptop had been on and idle for a
while.  It wasn't just after startup here.  Seems like it can happen anytime,
at least on KF5.

-- 
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 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.

[Matthew Dawson]

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

(Updated Nov. 2, 2014, 8:18 p.m.)


Status
--

This change has been marked as submitted.


Review request for Documentation and Plasma.


Repository: khelpcenter


Description
---

KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by
default they cannot launch it.  Fix that so KDE4 applications don't lose
their help when someone upgrades to Plasma 5.


Diffs
-

  CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d 

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


Testing
---

Tested installing a manual patch against my system install.  Hitting F1 in 
dolphin launches KHelpCenter as expected, with the dolphin help displayed 
(after running kbuildsyscoca4).


Thanks,

Matthew Dawson

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

Re: Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.

[Matthew Dawson]

> On Aug. 3, 2014, 1:05 p.m., Luigi Toscano wrote:
> > CMakeLists.txt, line 92
> > <https://git.reviewboard.kde.org/r/119589/diff/1/?file=295158#file295158line92>
> >
> > Just to be sure: is khelpcenter/kf5 meant to replace 
> > khelpcenter/kdelibs4, right? (no coinstallability)

As far as I know, this is true.  Both versions use "khelpcenter" as the 
executable name, and kdelibs4 handbooks seem to work fine under khelpcenter/kf5.


- Matthew


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


On Aug. 3, 2014, 12:59 p.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119589/
> ---
> 
> (Updated Aug. 3, 2014, 12:59 p.m.)
> 
> 
> Review request for Documentation and Plasma.
> 
> 
> Repository: khelpcenter
> 
> 
> Description
> ---
> 
> KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by
> default they cannot launch it.  Fix that so KDE4 applications don't lose
> their help when someone upgrades to Plasma 5.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d 
> 
> Diff: https://git.reviewboard.kde.org/r/119589/diff/
> 
> 
> Testing
> ---
> 
> Tested installing a manual patch against my system install.  Hitting F1 in 
> dolphin launches KHelpCenter as expected, with the dolphin help displayed 
> (after running kbuildsyscoca4).
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Review Request 119589: Allow KHelpCenter from Plasma 5 to work with KDE4 applications.

[Matthew Dawson]

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

Review request for Documentation and Plasma.


Repository: khelpcenter


Description
---

KHelpCenter 5.0.0 works with handbooks from KDE4 applications, but by
default they cannot launch it.  Fix that so KDE4 applications don't lose
their help when someone upgrades to Plasma 5.


Diffs
-

  CMakeLists.txt 728b2583c052fd09e85ef66aa3e99d092948837d 

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


Testing
---

Tested installing a manual patch against my system install.  Hitting F1 in 
dolphin launches KHelpCenter as expected, with the dolphin help displayed 
(after running kbuildsyscoca4).


Thanks,

Matthew Dawson

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

Re: Review Request 118512: Turn KFileMetaData into a Framework.

[Matthew Dawson]

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

(Updated June 16, 2014, 5:44 p.m.)


Status
--

This change has been discarded.


Review request for Plasma, Jonathan Riddell and Vishesh Handa.


Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334

http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334


Repository: kfilemetadata


Description
---

Turn KFileMetaData into a Framework.


Diffs
-

  src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e 
  src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b 
  src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 
  src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f 
  src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a 
  src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a 
  src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
  autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 
  KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
  KF5FileMetaDataConfig.cmake.in PRE-CREATION 
  CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc 

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


Testing
---

Tested compiling Baloo against a system install with this patch applied.  Baloo 
sucessfully linked against the KF5 version and all Baloo tests ran to 
completion.

All KFileMetaData unit tests passed too ;)


Thanks,

Matthew Dawson

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

Re: Review Request 118512: Turn KFileMetaData into a Framework.

[Matthew Dawson]

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

(Updated June 14, 2014, 6:40 p.m.)


Review request for Plasma, Jonathan Riddell and Vishesh Handa.


Changes
---

Further testing showed that the include directory was incorrectly referenced in 
a few places.


Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334

http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334


Repository: kfilemetadata


Description
---

Turn KFileMetaData into a Framework.


Diffs (updated)
-

  src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e 
  src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b 
  src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 
  src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f 
  src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a 
  src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a 
  src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
  autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 
  KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
  KF5FileMetaDataConfig.cmake.in PRE-CREATION 
  CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc 

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


Testing
---

Tested compiling Baloo against a system install with this patch applied.  Baloo 
sucessfully linked against the KF5 version and all Baloo tests ran to 
completion.

All KFileMetaData unit tests passed too ;)


Thanks,

Matthew Dawson

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

Re: Review Request 118512: Turn KFileMetaData into a Framework.

[Matthew Dawson]

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

(Updated June 14, 2014, 6:20 p.m.)


Review request for Plasma, Jonathan Riddell and Vishesh Handa.


Changes
---

Replace the renaming effort with the reworking of KFileMetaData into a 
framework.  Patch for Baloo will follow, and I'll chase down any other failures 
as I find them/they are pointed out.


Summary (updated)
-

Turn KFileMetaData into a Framework.


Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334

http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334


Repository: kfilemetadata


Description (updated)
---

Turn KFileMetaData into a Framework.


Diffs (updated)
-

  CMakeLists.txt 5a9eefa89b2fc7e6202347daf105baa867328ffc 
  KF5FileMetaDataConfig.cmake.in PRE-CREATION 
  KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
  autotests/CMakeLists.txt c657a7002d1d0644d6de4438a193bb63657b7ec0 
  src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
  src/extractionresult.h 76dfe590aaf1f1fda265a4835fa1bcdbc81ba58a 
  src/extractorplugin.h 218ef207982e31f0142983d75b4846cd0f45f02a 
  src/extractorpluginmanager.h d4a871e7d5952edb48c5836769741d7cf20bd29f 
  src/extractors/CMakeLists.txt 0099c0878315a07f4d7b1369dc1471a8401f10a7 
  src/propertyinfo.h bb54f58c750eff8c39685861a5346c025265949b 
  src/typeinfo.h 2675cbbd5751de9a7ac77cf9fdda4cb6d0a7806e 

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


Testing
---

Tested compiling Baloo against a system install with this patch applied.  Baloo 
sucessfully linked against the KF5 version and all Baloo tests ran to 
completion.

All KFileMetaData unit tests passed too ;)


Thanks,

Matthew Dawson

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

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Matthew Dawson]

> On June 11, 2014, 11:17 a.m., Matthew Dawson wrote:
> > One other thing that conflicts between the two versions is the 
> > systemsettings view library.  I think just a soname bump is enough to 
> > handle it.
> 
> Hrvoje Senjan wrote:
> see r118387 =)

Sorry, never mind.  I've just been chasing down these issues, didn't want to 
have another one on my hands.


- Matthew


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


On May 28, 2014, 3:32 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 3:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

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

Re: Review Request 118388: rename systemsettings binary to systemsettings5

[Matthew Dawson]

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


One other thing that conflicts between the two versions is the systemsettings 
view library.  I think just a soname bump is enough to handle it.

- Matthew Dawson


On May 28, 2014, 3:32 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118388/
> ---
> 
> (Updated May 28, 2014, 3:32 p.m.)
> 
> 
> Review request for Plasma and Ben Cooksley.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> while workspace might not be targeted to co-exist with 4.x variant - 
> systemsettings should IMHO be able to co-exist. not only workspace components 
> are adjusting in there, and telling people to do kcmshell$notinstalledvariant 
> $wantedkcm is very user-unfriendly...
> one TODO if this gets a green light, is to rename desktop files, so people 
> know which variant they are opening.
> 
> 
> Diffs
> -
> 
>   app/systemsettings.desktop 5f27318 
>   app/kdesystemsettings.desktop 946d498 
>   app/CMakeLists.txt c45f7e7 
> 
> Diff: https://git.reviewboard.kde.org/r/118388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

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

Re: Review Request 118512: RFC: Rename CMake configuration files to KFileMetaData5*

[Matthew Dawson]

> On June 11, 2014, 7 a.m., Vishesh Handa wrote:
> > How about we change the cmake file to KF5KFileMetaDataConfig.cmake instead? 
> > This way there will be no conflicts, and it will be consistent with the 
> > rest of the frameworks as well?
> 
> Aleix Pol Gonzalez wrote:
> I agree it's the best way, the only problem being tha it's actually not a 
> framework, at least according to the list of frameworks and projects.kde.org.
> 
> Vishesh Handa wrote:
> Yes. But it eventually will be.
> 
> This way it is easily co-installable, and there are fewer renames in the 
> future. We already have a KF5::FileMetaData alias.
> 
> Aleix Pol Gonzalez wrote:
> I'll give the shipit, because I'm aware of this being done in similar 
> cases.
> 
> Please make sure everything builds when pushing this.

Sounds good, I'll rename the file.  Should the library also be renamed?

As Baloo also conflicts, should I rename Baloo the same way, and should its 
library also be renamed?  Or just append a 5 to CMake file?


- Matthew


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


On June 4, 2014, 2:28 a.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118512/
> ---
> 
> (Updated June 4, 2014, 2:28 a.m.)
> 
> 
> Review request for Plasma, Jonathan Riddell and Vishesh Handa.
> 
> 
> Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334
> 
> http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> I've posted this RR as an RFC about the general structure of this idea.  I 
> just choose KFileMetaData as that is what my package manager conflicted over 
> first.  Ideally I want to push this change to any needed repositories for 
> Plasma Next.
> 
> As far as I understand the ability for Plasma Next and KDE4 application to be 
> co-installed, all libraries should be co-installable except as listed on this 
> page: http://community.kde.org/Plasma/Coinstallability .  However, on source 
> based distributions, such as Gentoo, to have both the KDE4 and KF5 versions 
> simultaneously installed requires that the development files are also 
> co-installable.  As mentioned on this Gentoo bug[1], the header files are 
> trivially dealt with, and the library simlink will probably be a downstream 
> specific solution (as CMake doesn't require it for compiling).  However, the 
> CMake configuration files are another matter.  This is take one of trying to 
> fix this issue.  If a different naming scheme, or if some different CMake 
> trickery is desired I'll see about changing things to that, otherwise I think 
> this is the simple and easy solution.
> 
> I also volunteer to go through all the dependent packages and have patches 
> ready (as best as I am able), as well as fix up any build failures that occur 
> due to this change.  Only find_package calls need modification, targets are 
> left alone.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=512334
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
>   KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
>   CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 
> 
> Diff: https://git.reviewboard.kde.org/r/118512/diff/
> 
> 
> Testing
> ---
> 
> Tested compiling Baloo against a system install with this patch applied.  
> Baloo sucessfully linked against the KF5 version and all Baloo tests ran to 
> completion.
> 
> All KFileMetaData unit tests passed too ;)
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Re: Plasma 5 Beta 2 tars

[Matthew Dawson]

On June 5, 2014 03:47:59 PM Jonathan Riddell wrote:
> Tars are up for Plasma 5 Beta 2, please try them out and let me know
> of problems.
> 
> I've renamed baloo and milou to have -kf5 in the tar name as you may
> well want the kdelibs4 versions around.  Also kfilemetadata as
> kfilemetadata5.
Regarding this, for source based distributions baloo/kfilemetadata can't be 
co-installed with there kdelibs4 version as the development files conflict, 
the main problem being the CMake files.  I posted an RR here: 
https://git.reviewboard.kde.org/r/118512/ to try and fix that.  Is this 
acceptable?  Otherwise Plasma Next and the rest of KDE SC 4.x can't really be 
co-installed (especially KDEPIM!)

Thanks,
-- 
Matthew

smime.p7s
Description: S/MIME cryptographic signature
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 118512: RFC: Rename CMake configuration files to KFileMetaData5*

[Matthew Dawson]

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

Review request for Plasma, Jonathan Riddell and Vishesh Handa.


Bugs: https://bugs.gentoo.org/show_bug.cgi?id=512334

http://bugs.kde.org/show_bug.cgi?id=https://bugs.gentoo.org/show_bug.cgi?id=512334


Repository: kfilemetadata


Description
---

I've posted this RR as an RFC about the general structure of this idea.  I just 
choose KFileMetaData as that is what my package manager conflicted over first.  
Ideally I want to push this change to any needed repositories for Plasma Next.

As far as I understand the ability for Plasma Next and KDE4 application to be 
co-installed, all libraries should be co-installable except as listed on this 
page: http://community.kde.org/Plasma/Coinstallability .  However, on source 
based distributions, such as Gentoo, to have both the KDE4 and KF5 versions 
simultaneously installed requires that the development files are also 
co-installable.  As mentioned on this Gentoo bug[1], the header files are 
trivially dealt with, and the library simlink will probably be a downstream 
specific solution (as CMake doesn't require it for compiling).  However, the 
CMake configuration files are another matter.  This is take one of trying to 
fix this issue.  If a different naming scheme, or if some different CMake 
trickery is desired I'll see about changing things to that, otherwise I think 
this is the simple and easy solution.

I also volunteer to go through all the dependent packages and have patches 
ready (as best as I am able), as well as fix up any build failures that occur 
due to this change.  Only find_package calls need modification, targets are 
left alone.

[1] https://bugs.gentoo.org/show_bug.cgi?id=512334


Diffs
-

  src/CMakeLists.txt 82dbd5c32050081642e9fff958d229f55893d40c 
  KFileMetaDataConfig.cmake.in b4d1c93b7a23ffcbb03a89e9d4a11559d7e22037 
  CMakeLists.txt aa2b0864ca8b2126ffcabf5cbad28b06dbb682b2 

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


Testing
---

Tested compiling Baloo against a system install with this patch applied.  Baloo 
sucessfully linked against the KF5 version and all Baloo tests ran to 
completion.

All KFileMetaData unit tests passed too ;)


Thanks,

Matthew Dawson

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

Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

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

(Updated June 1, 2014, 2:34 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Plasma and Ivan Čukić.


Repository: kactivities


Description
---

To allow for the library to be co-installed with the frameworks version, allow 
the daemon to be disabled.

I'm not sure if this is the best way to do this.  If there is any better way, 
I'll update the patch as appropriate.


Diffs
-

  src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 

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


Testing
---

Visually inspected install directories.  Seems to remove only what is necessary.


Thanks,

Matthew Dawson

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

Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

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

(Updated May 31, 2014, 10:33 p.m.)


Review request for KDE Frameworks, Plasma and Ivan Čukić.


Changes
---

Updating the RR to match what I push.  I changed the option name to match what 
is in master, and re-verified everything installs as appropriate.


Repository: kactivities


Description
---

To allow for the library to be co-installed with the frameworks version, allow 
the daemon to be disabled.

I'm not sure if this is the best way to do this.  If there is any better way, 
I'll update the patch as appropriate.


Diffs (updated)
-

  src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 

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


Testing
---

Visually inspected install directories.  Seems to remove only what is necessary.


Thanks,

Matthew Dawson

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

Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

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

(Updated May 30, 2014, 11:42 p.m.)


Review request for KDE Frameworks, Plasma and Ivan Čukić.


Changes
---

Change the macro_optional_add_subdirectory to a proper option.  This also 
disables the KCM when the daemon is disabled.


Repository: kactivities


Description
---

To allow for the library to be co-installed with the frameworks version, allow 
the daemon to be disabled.

I'm not sure if this is the best way to do this.  If there is any better way, 
I'll update the patch as appropriate.


Diffs (updated)
-

  src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 

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


Testing
---

Visually inspected install directories.  Seems to remove only what is necessary.


Thanks,

Matthew Dawson

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

Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

> On May 29, 2014, 11:02 a.m., Alex Merry wrote:
> > Did you try compiling this? Because that macro doesn't exist any more - 
> > there is an ecm_optional_add_subdirectory() in ECM if you 
> > include(ECMOptionalAddSubdirectory), though.
> > 
> > However, I think an explicit option(), with a useful help-text, would be 
> > better.
> 
> Alex Merry wrote:
> Ah, seeing David's comment made me realise I hadn't clocked the branch (I 
> generally assume anything the kdeframeworks group has been added to is a 
> frameworks branch). Although my point still stands about using option() to 
> get a more useful help-text.

Sorry for the confusion, I wasn't sure where exactly to address the RR, so I 
addressed it to all the places that seemed relevant.

If David is ok with this patch, and it has a chance of going in I'll change it 
to use an explicit option.  I originally took the path of least resistance, as 
most users wouldn't see this or care.  But the explicit option would make the 
option definitely easier to understand.


- Matthew


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


On May 27, 2014, 1:27 a.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118340/
> ---
> 
> (Updated May 27, 2014, 1:27 a.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> ---
> 
> To allow for the library to be co-installed with the frameworks version, 
> allow the daemon to be disabled.
> 
> I'm not sure if this is the best way to do this.  If there is any better way, 
> I'll update the patch as appropriate.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 
> 
> Diff: https://git.reviewboard.kde.org/r/118340/diff/
> 
> 
> Testing
> ---
> 
> Visually inspected install directories.  Seems to remove only what is 
> necessary.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Re: Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

> On May 29, 2014, 10:57 a.m., David Edmundson wrote:
> > This doesn't look great to me.
> > We'd have to release another 4.x.

Is this too big for the KDE 4.13.x releases?  It doesn't change the default 
behaviour, and as discussed in: https://git.reviewboard.kde.org/r/115602/ , 
this is the only way to have a kactivities installed from both the KDE4 
releases and frameworks.

If it isn't wanted, I'll push it into my distribution (Gentoo) as a downstream 
patch.  But, I have a feeling most distributions will do this, wasting effort.


- Matthew


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


On May 27, 2014, 1:27 a.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118340/
> ---
> 
> (Updated May 27, 2014, 1:27 a.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Ivan Čukić.
> 
> 
> Repository: kactivities
> 
> 
> Description
> ---
> 
> To allow for the library to be co-installed with the frameworks version, 
> allow the daemon to be disabled.
> 
> I'm not sure if this is the best way to do this.  If there is any better way, 
> I'll update the patch as appropriate.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 
> 
> Diff: https://git.reviewboard.kde.org/r/118340/diff/
> 
> 
> Testing
> ---
> 
> Visually inspected install directories.  Seems to remove only what is 
> necessary.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Re: Review Request 105312: Add missing email addresses back into add widget tooltip.

[Matthew Dawson]

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

(Updated May 27, 2014, 2:27 p.m.)


Status
--

This change has been discarded.


Review request for Plasma, Ivan Čukić and Marco Martin.


Repository: kde-workspace


Description
---

When the QML port of the add widget dialog occured, the creator's email address 
got chopped off.  This commit fixes a bug hidding the email address, and also 
starts displaying it again in the tooltip.

There are a couple of issue left with this patch:
1) I have to disable wrapping, otherwise the text wraps at odd points for no 
reason (it fits fine otherwise).
2) The link currently doesn't work as I'm not sure how to hook it up to send 
mail.  Should it be left as is, or just remove the link for 4.9 and update with 
a link for 4.10?


Diffs
-

  libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml 
ba804fd006496ee4a7118e97fe44038f0617eec7 
  libs/plasmagenericshell/widgetsexplorer/plasmaappletitemmodel_p.h 
e745ef58533ab0e22d2109d5beeff6c29c4d18b4 

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


Testing
---

Tested locally in Xephyr.  The tooltip now contains the email address.


Thanks,

Matthew Dawson

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

Review Request 118340: Allow the kactivitymanagerd daemon to be disabled.

[Matthew Dawson]

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

Review request for KDE Frameworks, Plasma and Ivan Čukić.


Repository: kactivities


Description
---

To allow for the library to be co-installed with the frameworks version, allow 
the daemon to be disabled.

I'm not sure if this is the best way to do this.  If there is any better way, 
I'll update the patch as appropriate.


Diffs
-

  src/CMakeLists.txt b4733648fd53ebd681694f185cc5b23f51dfd3f9 

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


Testing
---

Visually inspected install directories.  Seems to remove only what is necessary.


Thanks,

Matthew Dawson

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

Re: Request - Amend GPLv2+ license - Exemption link clause - for KDE weather engine/ions (weather related only) for BlackBerry 10/QNX

[Matthew Dawson]

On January 17, 2013 09:51:45 PM Shawn Starr wrote:
> On Thursday, January 17, 2013 09:47:27 PM Matthew Dawson wrote:
> > On January 17, 2013 08:06:05 PM Shawn Starr wrote:
> > > Hello folks,
> > > 
> > > I need to get approvals from those who made some changes to the engine
> > > code, the change is to append the exemption clause to GPLv2+ so that I
> > > can link the binaries to QNX's libc / and RIM's cascades libs, as these
> > > are considered core to the OS.
> > > 

> > 
> > Sorry if I don't understand what you are asking for, but to link GPL
> > software against system libraries doesn't require exceptions (see
> > http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
> > 
> >  ).  If you are linking other applications against the engine code, then
> >  the
> > 
> > exceptions is required.
> 
> The libraries being linked into are not GPL however thats the need for the
> exemption clause. QNX's libc and RIM's cascades are not GPL/LGPL libraries.
> 
> Thanks,
> Shawn.

I understood that.  However, as the GPL faq states, GPL programs can link to 
system libraries that are closed source.  libc (assuming that is the C 
library) is definitly a system library, and I assume cascades is one too (it's 
stated in the GPL what the definition is).  This is why you don't need an 
exception for GPL software on Windows.

The exceptions you talk about are for applications (a third party) linking 
against libraries (being the weather data engines), thus creating a LGPL like 
license.  The wikipedia article you linked to describes this in detail.

Now, if you are looking for the code to be LGPL like, then I'd think it be 
easiest to re-license the code to the LGPL.  If you simply need to link to 
system libraries, then no exception/re-licensing is necessary.

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

Re: Request - Amend GPLv2+ license - Exemption link clause - for KDE weather engine/ions (weather related only) for BlackBerry 10/QNX

[Matthew Dawson]

On January 17, 2013 08:06:05 PM Shawn Starr wrote:
> Hello folks,
> 
> I need to get approvals from those who made some changes to the engine code,
> the change is to append the exemption clause to GPLv2+ so that I can link
> the binaries to QNX's libc / and RIM's cascades libs, as these are
> considered core to the OS.
> 
> I also want to know if we can dual copyright with the KDE Foundation so that
> even if the code diverges the changes can flow back and forth between the
> QNX/BB10 git repo and KDE's git repository.
> 
> So to reiterate, the code remains GPLv2+ but just gains the exemption clause
> (see here: http://en.wikipedia.org/wiki/GPL_linking_exception).
> 
> What are your thoughts on this? Can this all be done easy? For the wording,
> I would like us to use the most liberal one so that there remains no
> issues/restrictions to anyone.
> 
> Thanks,
> Shawn
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Sorry if I don't understand what you are asking for, but to link GPL software 
against system libraries doesn't require exceptions (see 
http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
 ).  If you are linking other applications against the engine code, then the 
exceptions is required.

(I don't have any copyrights over the code, so the decision doesn't effect me)

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

Re: Breadcrumbs in Kickoff

[Matthew Dawson]

On Tuesday 20 December 2011 17:54:02 Martin Gräßlin wrote: 
> Up to now nobody gave a proper reason *why* we should add a back button.
> Just because we can is no reason, sorry.
> 

First, I understand that the back button is gone and I'm not advocating its 
return.

I do think I understand why there is a backlash about this option, and it 
stems from two points:

1) The back button was a much larger button to hit.  
According to Fitt's Law[1], the smaller a target is to hit, the longer 
it 
takes.  The breadcrumbs, being smaller, decreases the speed at which someone 
can hit the target.  It is readily apparent to me, as I only recently got 
introduced to it.

2) The position of the breadcrumbs is on the upper right hand corner.
People will first look for information to the upper left hand part of 
the 
screen.  With the breadcrumbs positioned where they are, its first of all hard 
to find compared to the back button.  I can't remember if people brought up 
with RTL languages see upper right hand first, but at least for LTR it is.


Based upon these two points, a couple of simple solutions present themselves:

1) Make the text a little bigger.
Since users will approach the breadcrumbs from the bottom, increasing 
the 
height will help them hit the button easier.  This will probably require some 
fiddling with to ensure the best possible result.

2) At least for LTR, move the breadcrumbs over to the left hand side.
This will help users more easily find the breadcrumbs and choose an 
option.  This also helps with selection, as any overshoot to return to the 
beginning, when approached from the right, will hit the edge of the screen and 
avoid too much backtracking, making it easier for users to hit.  Note this 
only applies in Kickoff's default location, but I don't think most people will 
have an issue.

Thoughts?  If these ideas sound useful, I'll try to cook up a patch to 
implment them.


Matthew


[1] http://en.wikipedia.org/wiki/Fitts%27s_law
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: activities overview, take N

[Matthew Dawson]

On Tuesday 13 October 2009 13:09:26 Aaron J. Seigo wrote:
> On October 12, 2009, Chani wrote:
> > > * in a-containment-per-virtual-desktop mode (which i'm starting to feel
> > >  small amounts of regret over offering ... but maybe i'm just being
> > >  pessimistic :) the "Choose Activities" would be per-virtual-desktop. if
> > >  you wanted to migrate an activity from one desktop to another, you'd
> > > have to store it first. the more i think about per-virtual-desktop
> > > containments the more i cringe, though.
> > 
> > this paragraph makes me cringe. I don't get it and I'm not sure I want to.
> 
> yeah, same here.
> 
> 
Thinking about the "a-containment-per-virtual-desktop mode", I feel like I use 
that feature as a substitute for the missing ability of having nepomuk tied 
activities.  I'd think once you have activities proper this feature will seem 
(and feel) redundant.  Maybe the better option would be to simply remove the 
"a-containment-per-virtual-desktop mode" once activities are done?

Another major benefit from this feature is the easy switching between different 
containments.  I am sure there are better ways to switch containments then 
having virtual desktops tied to containments, so I doubt this is any reason to 
retain them.

Matthew


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

Re: Review Request: big revamp of Device Notifier

[Matthew Dawson]

On Friday 11 September 2009 05:56:52 Giulio Camuffo wrote:
> 
> > On 2009-09-10 18:18:27, Jacopo De Simoi wrote:
> > > /trunk/KDE/kdebase/workspace/plasma/applets/devicenotifier/configurationpage.ui,
> > >  line 63
> > > 
> > >
> > > I am not a native speaker either.. but this "the" seems strange to me
> 
> well, i tried with google translate but it leaves me quite confused: 
> http://translate.google.it/translate_t?hl=it&ie=UTF-8&text=mostra+le+periferiche+rimovibili&sl=it&tl=en#it|en|mostra%20anche%20le%20periferiche%20rimovibili
>  and 
> http://translate.google.it/translate_t?hl=it&ie=UTF-8&text=mostra+le+periferiche+rimovibili&sl=it&tl=en#it|en|mostra%20le%20periferiche%20rimovibili.
>  I suppose we need to wait for a native speaker :)
> 
IMH(native speaker's)O, that "the" should not be there, as it makes it sound 
like there is only one particular removable device that the user wishes to be 
shown.


Matthew


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

Re: Review Request: Add fade effect to wallpaper plugin.

[Matthew Dawson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/195/
---

(Updated 2009-03-06 12:09:15.235406)


Review request for Plasma.


Changes
---

* Change from a QTimeline to Plasma::Animator
* Destroy Pixmaps when the animation is finished.


Summary
---

This patch makes the wallpaper plugin fade out the old wallpaper when it 
changes.  Currently the effect only works when in slideshow mode.

Video Demo:
http://mjdsystems.ca/fadedemo.ogv


This addresses bug 168731.
https://bugs.kde.org/show_bug.cgi?id=168731


Diffs (updated)
-

  /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 933647 
  /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 933647 

Diff: http://reviewboard.kde.org/r/195/diff


Testing
---

Locally in Xephyr.


Thanks,

Matthew

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

Re: Review Request: Add fade effect to wallpaper plugin.

[Matthew Dawson]

Hey,

On Monday 02 March 2009 15:06:35 Aaron J. Seigo wrote:
 
> comments on patch (besides "thanks! always great to receive patches from new 
> faces"):
Thanks for the comments!
> 
> - coding style. {s for methods start on their own line (see updateFadedImage) 
> and there is a space between the keyword and the opening ( in a conditional: 
> "If (" not "if(" and ") {" not "){". 
Fixed!
> 
> - it should be using Plasma::Animator for its timer and a CustomTimer so this 
> can be turned off by policy and share the global timer for this. using your 
> own QTimeLine is, in general, a no-go.
I just looked at Plasma::Animator.  Would I use the 
Plasma::Animator::CustomAnimation function to replace the QTimeLine?  Also I 
looked through both the documentation and the sources, and I can't find a 
mention of CustomTimer.  I'm just wondering what it is.
> 
> - it seems that there should be a more performant way of doing this than 
> creating a third pixmap that is the size of the end result, painting into it 
> and then painting another into it! i'd suggest trying something like just 
> painting both images into the exposed rect as passed into the paint method 
> using the current alpha. if that produces acceptable results, i'd say go for 
> it.
After playing around with a simple demo with two colours, it appears that the 3 
pixmap method works best.  I pulled most of the code from 
http://techbase.kde.org/Development/Tutorials/Graphics/Performance#QPixmap::setAlphaChannel.28.29
 .  While 3 pixmaps does seem like overkill, it seems to be the only way that 
works.  I could probably get away with two pixmaps and QPainter.setOpacity, but 
as the above link says that is a performance killer.  I tested different 
combinations of methods.  If you have any other suggestion, I'm happy to try 
them!
> 
> * remember to free the other pixmap when the animation is done so it isn't 
> sitting around in memory. assigning a QPixmap() to it should be enough.
Will do.
> 
> regardless of how its done (other than "in hardware"), doing full screen 
> repaints isn't going to be precisely brilliant for performance, but as an 
> option it's pretty nice :) which reminds me to check the default caching mode 
> for Plasma::Containment with regards to performance (both memory usage as 
> well 
> as speed)
> 
During testing, it appears (at least for QTimeLine) that it skips frames if it 
takes to long to repaint.  So on slower machines it will work, it will just be 
choppy.

Matthew


-- 
/*
 * Buddy system. Hairy. You really aren't expected to understand this
 *
 */
-- From /usr/src/linux/mm/page_alloc.cA


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

Re: Review Request: Add fade effect to wallpaper plugin.

[Matthew Dawson]

Hello,

Unfortunately, reviewboard is not accepting this updated diff, so I'm posting 
it here.  I'm not sure why I thought it didn't work with single images, but it 
does now.  It also works in the configuration dialog box :).

Matthew

On Thursday 26 February 2009 16:02:31 Artur de Souza (MoRpHeUz) wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/195/#review287
> ---
> 
> 
> Hmm...the idea is pretty nice. Why it doesn't work for single images 
> wallpapers (just slideshow) ? Hehe, and this is the typical feature that is 
> trivial to do with Qt Kinetic ;)
> 
> Cheers
> 
> - Artur
> 
> 
> On 2009-02-26 12:24:44, Matthew Dawson wrote:
> > 
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://reviewboard.kde.org/r/195/
> > ---
> > 
> > (Updated 2009-02-26 12:24:44)
> > 
> > 
> > Review request for Plasma.
> > 
> > 
> > Summary
> > ---
> > 
> > This patch makes the wallpaper plugin fade out the old wallpaper when it 
> > changes.  Currently the effect only works when in slideshow mode.
> > 
> > Video Demo:
> > http://mjdsystems.ca/fadedemo.ogv
> > 
> > 
> > This addresses bug 168731.
> > https://bugs.kde.org/show_bug.cgi?id=168731
> > 
> > 
> > Diffs
> > -
> > 
> >   /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 932504 
> >   /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 932504 
> > 
> > Diff: http://reviewboard.kde.org/r/195/diff
> > 
> > 
> > Testing
> > ---
> > 
> > Locally in Xephyr.
> > 
> > 
> > Thanks,
> > 
> > Matthew
> > 
> >
> 
> 
Index: workspace/plasma/wallpapers/image/image.cpp
===
--- workspace/plasma/wallpapers/image/image.cpp	(revision 932504)
+++ workspace/plasma/wallpapers/image/image.cpp	(working copy)
@@ -32,15 +32,20 @@
 
 Image::Image(QObject *parent, const QVariantList &args)
 : Plasma::Wallpaper(parent, args),
+  m_fadeTimeLine(1500),
   m_currentSlide(-1),
   m_model(0),
   m_dialog(0),
   m_rendererToken(-1),
   m_randomize(true)
 {
+//Start at frame 1 otherwise their is a nasty black flicker.
+m_fadeTimeLine.setFrameRange(1, 255);
+
 qRegisterMetaType("QImage");
 connect(&m_renderer, SIGNAL(done(int, QImage)), this, SLOT(updateBackground(int, QImage)));
 connect(&m_timer, SIGNAL(timeout()), this, SLOT(nextSlide()));
+connect(&m_fadeTimeLine, SIGNAL(frameChanged(int)), this, SLOT(updateFadedImage(int)));
 }
 
 Image::~Image()
@@ -233,6 +238,12 @@
 // bitmapBackground already has the size of the viewport)
 painter->drawPixmap(exposedRect, m_pixmap, exposedRect);
 
+if(m_fadeTimeLine.state() == QTimeLine::Running && !m_oldFadedPixmap.isNull()){
+// Put old faded image on top.
+painter->setCompositionMode(QPainter::CompositionMode_SourceAtop);
+painter->drawPixmap(exposedRect, m_oldFadedPixmap, exposedRect);
+}
+
 // restore transformation and composition mode
 painter->restore();
 }
@@ -525,9 +536,19 @@
 
 void Image::updateBackground(int token, const QImage &img)
 {
+
 if (m_rendererToken == token) {
+
+m_oldPixmap = m_pixmap;
+if(m_oldPixmap.isNull()){
+m_oldPixmap = QPixmap(img.size());
+m_oldPixmap.fill(m_color);
+}
+m_oldFadedPixmap = m_oldPixmap;
+
 m_pixmap = QPixmap::fromImage(img);
-emit update(boundingRect());
+
+m_fadeTimeLine.start();
 suspendStartup(false);
 }
 }
@@ -555,4 +576,22 @@
 }
 }
 
+void Image::updateFadedImage(int frame){
+   
+//Create the faded image.
+m_oldFadedPixmap.fill(Qt::transparent);
+
+QPainter p;
+p.begin(&m_oldFadedPixmap);
+p.drawPixmap(0, 0, m_oldPixmap);
+
+p.setCompositionMode(QPainter::CompositionMode_DestinationIn);  
+p.fillRect(m_oldFadedPixmap.rect(), QColor(0, 0, 0, 255-frame));//255*((150 - frame)/150)));
+
+p.end();
+
+emit update(boundingRect());
+
+}
+
 #include "image.moc"
Index: workspace/plasma/wallpapers/image/image.h
===
--- workspace/plasma/wallpapers/image/image.h	(revision 932504)
+++ workspace/plasma/wallpapers/image/image.h	(working copy)
@@ -12,6 +12,7 @@
 #define IMAGE_HEADER
 
 #include 
+#inclu

Review Request: Add fade effect to wallpaper plugin.

[Matthew Dawson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/195/
---

Review request for Plasma.


Summary
---

This patch makes the wallpaper plugin fade out the old wallpaper when it 
changes.  Currently the effect only works when in slideshow mode.

Video Demo:
http://mjdsystems.ca/fadedemo.ogv


This addresses bug 168731.
https://bugs.kde.org/show_bug.cgi?id=168731


Diffs
-

  /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.h 932504 
  /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/image.cpp 932504 

Diff: http://reviewboard.kde.org/r/195/diff


Testing
---

Locally in Xephyr.


Thanks,

Matthew

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

Re: Review Request: Add the ability for applets to change autohide timeout value

[Matthew Dawson]

On Friday 09 January 2009 18:10:25 Chani wrote:
> On January 9, 2009 14:13:28 Matthew Dawson wrote:
> > > On 2008-12-30 17:07:07, Aaron Seigo wrote:
> > > > what is the use case?
> >
> > Some applets may update faster then 3 seconds (such as systemloadviewer).
> > This would allow them to set an update interval so they may still use the
> > auto-hide feature.
>
> huh? what does updated data have to do with autohide?
>
> you can update the tooltip data without hiding it - look at the clock
> tooltip when the clock is showing seconds.

Currently if you update the tooltip's content faster then three seconds, the 
tooltip will never autohide.  This occurs because the timer counting the 
three seconds resets when data is updated.  The problem is that the tooltip 
doesn't go away, not that it never appears.

Matthew

-- 
A feature is nothing more than a bug with seniority.
-- Unknown source


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

Re: Review Request: Add the ability for applets to change autohide timeout value

[Matthew Dawson]

> On 2008-12-30 17:07:07, Aaron Seigo wrote:
> > what is the use case?

Some applets may update faster then 3 seconds (such as systemloadviewer).  This 
would allow them to set an update interval so they may still use the auto-hide 
feature.


- Matthew


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/315/#review309
---


On 2008-12-30 13:21:19, Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.vidsolbach.de/r/315/
> ---
> 
> (Updated 2008-12-30 13:21:19)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This adds an extra property to tooltipcontent called autohideTimeout that 
> allows for an applet to change how long the autohide timeout lasts.  This 
> keeps the default timeout of 3sec.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdelibs/plasma/tooltipcontent.h
>   /trunk/KDE/kdelibs/plasma/tooltipcontent.cpp
>   /trunk/KDE/kdelibs/plasma/tooltipmanager.cpp
> 
> Diff: http://reviewboard.vidsolbach.de/r/315/diff
> 
> 
> Testing
> ---
> 
> Locally on my computer.
> 
> 
> Thanks,
> 
> Matthew
> 
>

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

Review Request: Add the ability for applets to change autohide timeout value

[Matthew Dawson]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/315/
---

Review request for Plasma.


Summary
---

This adds an extra property to tooltipcontent called autohideTimeout that 
allows for an applet to change how long the autohide timeout lasts.  This keeps 
the default timeout of 3sec.


Diffs
-

  /trunk/KDE/kdelibs/plasma/tooltipcontent.h
  /trunk/KDE/kdelibs/plasma/tooltipcontent.cpp
  /trunk/KDE/kdelibs/plasma/tooltipmanager.cpp

Diff: http://reviewboard.vidsolbach.de/r/315/diff


Testing
---

Locally on my computer.


Thanks,

Matthew

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