[KDE Bugtracking System] REMINDER: current Plasma regressions

2012-07-04 Thread bugzilla_noreply
Please find below a list of the current regressions reported for Plasma

  This search was scheduled by myr...@kde.org.


Plasma regressions
--
Bug 291676:
  https://bugs.kde.org/show_bug.cgi?id=291676
  Priority: NOR  Severity: normal  Platform: Gentoo Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Device Items resize on hover due to visibility change of the status 
text
Bug 300885:
  https://bugs.kde.org/show_bug.cgi?id=300885
  Priority: NOR  Severity: critical  Platform: Ubuntu Packages
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Weather widget does not work anymore with bbcuk or wetter.com 
provider
Bug 301424:
  https://bugs.kde.org/show_bug.cgi?id=301424
  Priority: NOR  Severity: normal  Platform: openSUSE RPMs
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Cannot open battery monitor applet if set to hidden in systray
Bug 301533:
  https://bugs.kde.org/show_bug.cgi?id=301533
  Priority: NOR  Severity: normal  Platform: Other
  Assignee: plasma-b...@kde.org
Status: NEW
   Summary: Option Show Multiple Batteries does nothing
Bug 302331:
  https://bugs.kde.org/show_bug.cgi?id=302331
  Priority: NOR  Severity: normal  Platform: Ubuntu Packages
  Assignee: ignat.seme...@blue-systems.com
Status: UNCONFIRMED
   Summary: [post 4.9beta2] Folderview does not show any to activity linked 
files


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


Re: Review Request: kickoff: save recent applications list on every change to it

2012-07-04 Thread Andriy Gapon

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

(Updated July 4, 2012, 7:57 a.m.)


Review request for Plasma and Trever Fischer.


Changes
---

Complying with request to not hold KConfigGroup over long time.


Description
---

Currently recent applications list in kickoff is saved only when kickoff 
gracefully exits.  This could be a minor annoyance when X/KDE/plasma crashes.  
I think that saving the list on every update to it should be a good idea.  It 
should be a low overhead too, because the list changes only when a user 
launches an application via KDE.


This addresses bug 206511.
http://bugs.kde.org/show_bug.cgi?id=206511


Diffs (updated)
-

  plasma/desktop/applets/kickoff/core/recentapplications.cpp 3e05389 

Diff: http://git.reviewboard.kde.org/r/105112/diff/


Testing
---


Thanks,

Andriy Gapon

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


Re: Review Request: use window role to detect the dashboard

2012-07-04 Thread Andreas Demmer

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

Ship it!


Ship It!

- Andreas Demmer


On June 28, 2012, 7:42 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105382/
 ---
 
 (Updated June 28, 2012, 7:42 p.m.)
 
 
 Review request for kwin, Plasma, Aaron J. Seigo, and Martin Gräßlin.
 
 
 Description
 ---
 
 see bug. i guess the window role is the natural and more distinct hint.
 
 
 This addresses bug 302523.
 http://bugs.kde.org/show_bug.cgi?id=302523
 
 
 Diffs
 -
 
   kwin/effects/dashboard/dashboard.cpp bb803a9 
   plasma/desktop/shell/dashboardview.cpp d6762b6 
 
 Diff: http://git.reviewboard.kde.org/r/105382/diff/
 
 
 Testing
 ---
 
 yes, dashboard still triggers the effect, renamed xterm no longer
 
 
 Thanks,
 
 Thomas Lübking
 


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


Re: Review Request: use window role to detect the dashboard

2012-07-04 Thread Martin Gräßlin

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

Ship it!


from my side ok, maybe wait a day whether a plasma dev wants to comment :-)

- Martin Gräßlin


On June 28, 2012, 7:42 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105382/
 ---
 
 (Updated June 28, 2012, 7:42 p.m.)
 
 
 Review request for kwin, Plasma, Aaron J. Seigo, and Martin Gräßlin.
 
 
 Description
 ---
 
 see bug. i guess the window role is the natural and more distinct hint.
 
 
 This addresses bug 302523.
 http://bugs.kde.org/show_bug.cgi?id=302523
 
 
 Diffs
 -
 
   kwin/effects/dashboard/dashboard.cpp bb803a9 
   plasma/desktop/shell/dashboardview.cpp d6762b6 
 
 Diff: http://git.reviewboard.kde.org/r/105382/diff/
 
 
 Testing
 ---
 
 yes, dashboard still triggers the effect, renamed xterm no longer
 
 
 Thanks,
 
 Thomas Lübking
 


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


Re: Review Request: use window role to detect the dashboard

2012-07-04 Thread Andreas Demmer


 On July 4, 2012, 7:57 a.m., Andreas Demmer wrote:
  Ship It!

I missed that windowRole would be a much better distinction than windowClass is 
when I initially implemented this effect. Your patch definitely makes sense, so 
ship it!


- Andreas


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


On June 28, 2012, 7:42 p.m., Thomas Lübking wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105382/
 ---
 
 (Updated June 28, 2012, 7:42 p.m.)
 
 
 Review request for kwin, Plasma, Aaron J. Seigo, and Martin Gräßlin.
 
 
 Description
 ---
 
 see bug. i guess the window role is the natural and more distinct hint.
 
 
 This addresses bug 302523.
 http://bugs.kde.org/show_bug.cgi?id=302523
 
 
 Diffs
 -
 
   kwin/effects/dashboard/dashboard.cpp bb803a9 
   plasma/desktop/shell/dashboardview.cpp d6762b6 
 
 Diff: http://git.reviewboard.kde.org/r/105382/diff/
 
 
 Testing
 ---
 
 yes, dashboard still triggers the effect, renamed xterm no longer
 
 
 Thanks,
 
 Thomas Lübking
 


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


Re: Review Request: kickoff: save recent applications list on every change to it

2012-07-04 Thread Andriy Gapon


 On May 31, 2012, 10:09 a.m., Aaron J. Seigo wrote:
  plasma/desktop/applets/kickoff/core/recentapplications.cpp, line 42
  http://git.reviewboard.kde.org/r/105112/diff/1/?file=65943#file65943line42
 
  holding on to groups like this is a bit dangerous; you need to be able 
  to know that the kconfig object behind it is always valid at all times. 
  better to just create the group when needed.
  
  a method that returns such a group on demand lets the code be shared, 
  avoiding duplication of magic strings. e.g.:
  
  KConfigGroup config()
  {
  return componentData().config()-group(RecentlyUsed);
  }

I've been using the original version of the patch for several weeks and haven't 
run into any problems.  In theory, either holding a group should be safe or 
not, there can't be any middle ground. If it is unsafe, then a group may become 
invalid even between group(xxx) is called and its return result is 
immediately used. The _probability_ of the problem could be reduced, but 
correctness won't be increased nevertheless.
In any case, it was trivial to comply with this request, so I just did that.  I 
didn't create a separate config() method as was suggested, because the group is 
obtained in only a single place, save() method.


 On May 31, 2012, 10:09 a.m., Aaron J. Seigo wrote:
  plasma/desktop/applets/kickoff/core/recentapplications.cpp, line 77
  http://git.reviewboard.kde.org/r/105112/diff/1/?file=65943#file65943line77
 
  it pains me to see such calls in paths which could be called quite 
  often. yes, in theory should only happen when apps launch, but there is no 
  guarantee that this will remain that way or that such events will not 
  happen in rapid bursts.

If you have better suggestions I am all ears :-)
Again, I haven't run into any issues with this patch myself...
Theoretically speaking, the bursts, if any, would be limited by human being 
capabilities anyway. And if the kickoff menu to be interacting with more than 
just the kickoff menu, then, I hope, this logic would get the major overhaul 
being discussed.  So this code (and the patch) would become irrelevant and the 
stuff would be done via zeitgeist (plus nepomuk, etc).


- Andriy


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


On July 4, 2012, 7:57 a.m., Andriy Gapon wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105112/
 ---
 
 (Updated July 4, 2012, 7:57 a.m.)
 
 
 Review request for Plasma and Trever Fischer.
 
 
 Description
 ---
 
 Currently recent applications list in kickoff is saved only when kickoff 
 gracefully exits.  This could be a minor annoyance when X/KDE/plasma crashes. 
  I think that saving the list on every update to it should be a good idea.  
 It should be a low overhead too, because the list changes only when a user 
 launches an application via KDE.
 
 
 This addresses bug 206511.
 http://bugs.kde.org/show_bug.cgi?id=206511
 
 
 Diffs
 -
 
   plasma/desktop/applets/kickoff/core/recentapplications.cpp 3e05389 
 
 Diff: http://git.reviewboard.kde.org/r/105112/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Andriy Gapon
 


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


Re: Review Request: kickoff: save recent applications list on every change to it

2012-07-04 Thread Andriy Gapon


 On May 31, 2012, 10:09 a.m., Aaron J. Seigo wrote:
  the real fubar here is that it stores this information internally in its 
  own config file. this really ought to be stored/retrieved from nepomuk 
  and/or zeitgeist.
  
  i've cc'd Trever on this because he may have something to say about that as 
  well.
 
 Trever Fischer wrote:
 I actually just recently patched Dragon to do so, and it took very few 
 lines: 
 http://quickgit.kde.org/index.php?p=dragon.gita=commitdiffh=92fb6296e424dc829e0c5cc541aa3581856d2098
 
 Since Kickoff uses QAbstractItemModels, switching things to use a 
 QZeitgeist::LogModel should be trivial. Alternatively, implementing the 
 RecentApplications class to use Zeitgeist can be trivial as well, and would 
 seem like the easiest way to do things.
 
 Aaron J. Seigo wrote:
 if we could dump RecentApplications that'd be great. there's not much 
 reason to go through a local class just to get to another library 
 (qzeitgeist) class. then the LogModel can be used in the RecentlyUsedModel .. 
 
 in fact, if KRecentDocument in kdelibs/kio/kfile/ were made to use 
 zeitgeist, i bet we could just drop the RecentlyUsedModel altogether, or at 
 worst have it as a thin layer around LogModel (don't know what LogModel 
 provides, so I can't really offer a concrete suggestion there). that sounds 
 like frameworks 5 work, though, so we'll have to just hold off on that for 
 kickoff .. but would seem to be the natural progression and something that 
 could implemented immediately in the frameworks branch in any case...
 
 Trever Fischer wrote:
 logmodel.h: 
 http://quickgit.kde.org/index.php?p=libqzeitgeist.gita=blobh=2ef6bfac0ab917ed5508da64b3a9d1a9290e65e6hb=a58d1caaa953b514b7bd1697c44aebf75b11829df=src%2Flogmodel.h
 
 It provides a bunch of shortcuts for access to the underlying event 
 object data, or you can access the event in its entirety.
 
 What it doesn't provide that the recentlyusedmodel provides is the 
 immediate ability to remove events. You'd need to grab the event and then ask 
 a Log object to delete it from the database. I am considering adding that API 
 to the 0.10 release.
 
 Ivan Čukić wrote:
 Another thing for these types of models that we *need* to start adding is 
 the support for different results based on the activity.
 
 Has Zeitgeist moved in that direction as promised before (in Randa)?
 
 Seif Lotfy wrote:
 This is supported. Just attach the id of the activity to the 
 event.origin. You can then query Zeitgeist with event.origin set to the 
 activity id and it will return only results based on events that happened in 
 that activity

What are the current prospects of overhauling this piece of code to make use of 
zeitgeist, etc?
If it's not going to happen soon, then I would like to still nominate this 
change for inclusion.


- Andriy


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


On July 4, 2012, 7:57 a.m., Andriy Gapon wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105112/
 ---
 
 (Updated July 4, 2012, 7:57 a.m.)
 
 
 Review request for Plasma and Trever Fischer.
 
 
 Description
 ---
 
 Currently recent applications list in kickoff is saved only when kickoff 
 gracefully exits.  This could be a minor annoyance when X/KDE/plasma crashes. 
  I think that saving the list on every update to it should be a good idea.  
 It should be a low overhead too, because the list changes only when a user 
 launches an application via KDE.
 
 
 This addresses bug 206511.
 http://bugs.kde.org/show_bug.cgi?id=206511
 
 
 Diffs
 -
 
   plasma/desktop/applets/kickoff/core/recentapplications.cpp 3e05389 
 
 Diff: http://git.reviewboard.kde.org/r/105112/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Andriy Gapon
 


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


Review Request: better handling of Removable property for volumes in soliddevice engine

2012-07-04 Thread Andriy Gapon

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

Review request for Plasma and Solid.


Description
---

Currently the code in SolidDeviceEngine::populateDeviceData sets volume's 
Removable property in straightforward fashion:
- tries to cast volume's (immediate) parent device to Solid::StorageDrive
- if that succeeds, checks isHotpluggable() and isRemovable() properties of the 
parent
The problem is that there could be intermediate devices in solid device 
hierarchy between the volume and its Solid::StorageDrive ancestor, for example 
partition-type devices.

The proposed code walks up the hierarchy to try harder to find 
Solid::StorageDrive ancestor of a given device.

BTW, I think that getAncestorOfType() helper function introduced in the 
proposed change can be useful for other code too, so it might make sense to 
nominate it for inclusion into Solid API.


Diffs
-

  plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 608da25 

Diff: http://git.reviewboard.kde.org/r/105432/diff/


Testing
---


Thanks,

Andriy Gapon

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


Re: Review Request: better handling of Removable property for volumes in soliddevice engine

2012-07-04 Thread Andriy Gapon

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

(Updated July 4, 2012, 8:28 a.m.)


Review request for Plasma and Solid.


Description
---

Currently the code in SolidDeviceEngine::populateDeviceData sets volume's 
Removable property in straightforward fashion:
- tries to cast volume's (immediate) parent device to Solid::StorageDrive
- if that succeeds, checks isHotpluggable() and isRemovable() properties of the 
parent
The problem is that there could be intermediate devices in solid device 
hierarchy between the volume and its Solid::StorageDrive ancestor, for example 
partition-type devices.

The proposed code walks up the hierarchy to try harder to find 
Solid::StorageDrive ancestor of a given device.

BTW, I think that getAncestorOfType() helper function introduced in the 
proposed change can be useful for other code too, so it might make sense to 
nominate it for inclusion into Solid API.


Diffs
-

  plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 608da25 

Diff: http://git.reviewboard.kde.org/r/105432/diff/


Testing
---


Thanks,

Andriy Gapon

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


Adding an image to slideshow.

2012-07-04 Thread Varun Herale


 i think that would be a highly unexpected for the user as image files
 would end
 up copied seemingly randomly all over the place. no .. what needs to
 happen is
 that the wallpaper plugin needs to be fixed so that it remembers the added
 path
 correctly.
 (classic example of fix, don't work around, the bug)


True, but I was thinking copying them to the folder will mean all the
concerned images are in one place. But I understand how that can cause
other problems.

How about adding another key to the config file which comes under
slidepaths ? This key could hold a list of all user-added images to the
current slideshow and if the user changes the slideshow folder the paths
can be cleared.

I think this should be best option if the added images are to be remembered
even after restart while plasma-desktop is loading. Or is there another way
to remember between sessions ?

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


Re: Review Request: better handling of Removable property for volumes in soliddevice engine

2012-07-04 Thread Alex Fiestas

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


The patch may make sense but, what does it fix exactly?

- Alex Fiestas


On July 4, 2012, 8:28 a.m., Andriy Gapon wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105432/
 ---
 
 (Updated July 4, 2012, 8:28 a.m.)
 
 
 Review request for Plasma and Solid.
 
 
 Description
 ---
 
 Currently the code in SolidDeviceEngine::populateDeviceData sets volume's 
 Removable property in straightforward fashion:
 - tries to cast volume's (immediate) parent device to Solid::StorageDrive
 - if that succeeds, checks isHotpluggable() and isRemovable() properties of 
 the parent
 The problem is that there could be intermediate devices in solid device 
 hierarchy between the volume and its Solid::StorageDrive ancestor, for 
 example partition-type devices.
 
 The proposed code walks up the hierarchy to try harder to find 
 Solid::StorageDrive ancestor of a given device.
 
 BTW, I think that getAncestorOfType() helper function introduced in the 
 proposed change can be useful for other code too, so it might make sense to 
 nominate it for inclusion into Solid API.
 
 
 Diffs
 -
 
   plasma/generic/dataengines/soliddevice/soliddeviceengine.cpp 608da25 
 
 Diff: http://git.reviewboard.kde.org/r/105432/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Andriy Gapon
 


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