Bug 274580 - plasma-tablet applets strip: folderview breaks rendering of applets right of it
Summary: plasma-tablet applets strip: folderview breaks rendering of applets right of it
Status: RESOLVED FIXED
Alias: None
Product: Active
Classification: Plasma
Component: General (show other bugs)
Version: PA 2
Platform: openSUSE Linux
: NOR normal
Target Milestone: unscheduled
Assignee: active
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 09:46 UTC by Stefan Majewsky
Modified: 2012-12-09 11:35 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Snapshot of misrendered folderviews (194.45 KB, image/jpeg)
2011-06-28 20:22 UTC, Stefan Majewsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Majewsky 2011-05-31 09:46:35 UTC
Version:           unspecified (using Devel) 
OS:                Linux

I have Plasma Active installed on a recent WeTab 3G on openSUSE 11.4 (as per the installation instructions on the wiki, using the KDE:Active repo). I currently have one activity configured and placed two folderviews on the applets strip.

The second of these applets is usually not rendered at all. When I start to pull the SAL from the bottom, a bit of the bottom of the second applet becomes visible for a short instant. The second applet also becomes visible when I drag it. Especially, when it snaps back to its position, it stays visible until I do something else. I can therefore confirm that the whole applet is there and works; it's just not rendered usually.

Which applet is misrendered depends on the position in the applets strip: The first applet to the left is always rendered correctly, while the second one is always misrendered as explained above.

The problem is there since about a month (I always forgot to write the report), and AFAIR was introduced by an upgrade. The problem is unrelated to the screen resolution: I use both 1366x768 and 768x1366, i.e. landscape and portrait format, regularly.

I'm ready to provide you with any config files etc. which you need for investigations.

Reproducible: Always
Comment 1 Aaron J. Seigo 2011-05-31 10:56:50 UTC
does this happen with all widgets, or just folderviews?
is it possible to get a screenshot?
Comment 2 Stefan Majewsky 2011-06-28 20:22:03 UTC
Created attachment 61425 [details]
Snapshot of misrendered folderviews

Here's a snapshot of my two folderviews. For the first one, the background image is rendered much too small (in the upper left corner of the applet) and the controls at the lower edge are missing. The second applet is missing completely.ß

This is only the static situation:
1. When I pull one of the applets, both are visible with correctly sized background images, though the controls at the lower edge are still missing.
2. When I pull one of the applets, and release it while it is still moving, only those parts of the applets are rendered which overlap with the final position of the first applet (i.e., the left third of the applets strip's visible area).
3. When I pull one of the applets, and release it only after all applets have reached their final position, they stay visible (modulo move/configure buttons at the lower edge, as usual). If I now pull out the SAL, the second applet is wiped away by the SAL and its handle moving along the screen below my fingertip.
4. When I pull out the SAL, but release it halfway so it does not open completely, the move/configure controls at the lower edge of the folderviews become visible as the SAL collapses, and stay until I interact with the applets again.

Also, the button for adding a new applet and configuring the wallpaper are generally not visible, only in one situation: when I pull out the activity switch and collapse it again.

...OMG It seems that this is actually a bug of the folderview applet: I just added some other applets (namely two instances of the Kickoff application launcher). They render fine if (and only if) they are placed left of any of the folderview applets. Any applet which is right of a folderview (not just on the direct right, anything right of a folderview will do) is misrendered like described above for the second folderview.

plasma-mobile version is 0.2.6 (the most current version from the KDE:Active repo at the time of this writing). I updated by "sudo zypper dup && sudo zypper dup -r kde-active", because it needs kdelibs packages et al from KDE:Active repo instead of KDE:Unstable:SC because of symbols from some "Activities Controller" class.
Comment 3 Ignat Semenov 2012-03-03 15:13:17 UTC
I've just downloaded the iso at

http://share.basyskom.com/contour/Deployment/latest-meego-plasma-active-stable.html

and there is now FoldeView available at all. So unfortunately I can't test nor fix the bug. Please tell me how to enable FW in PA to have the bug fixed :)
Comment 4 Aaron J. Seigo 2012-05-28 13:19:07 UTC
yes, it isn't included in the image. you would need to install it yourself on top of the image, or you could install plasma-mobile from kde's git and run `plasma-device --nodesktop` to try it with the plasmoids on your devel system (probably easiest..)
Comment 5 Thomas Pfeiffer 2012-12-06 21:20:08 UTC
We need someone to re-test if this only happens with Folderview. If it only happens with Folderview, we won't have to care since it's not supposed to be present in PA anyway.
Comment 6 Sebastian Kügler 2012-12-09 11:35:29 UTC
This part of the code in the Activity Screen has changed considerably, solving this whole class of bugs. I recall folderview being problematic in other QML containments, as well, also these issues are gone now.

I'm closing this bug since the problem showing in the screenshot is gone, and folderview doesn't exhibit any strange behaviour anymore. If you still encounter this bug, please file a new report (with new screenshot).