Bug 337815

Can't reproduce, do you have any more clues?

Umm, I can reliably reproduce that.. folder is selected as /home/bshah and all other things are default.. when i login to session it don't have correct icons but corrects itself after I either select items or click on items..

Can you dump your Folder config here please?

Also, do you see a pattern in the wrong icons? Is it always the same icons (both in terms of "the same items have the wrong icons" and "the wrong icons are the same pictures")? Are the wrong icons icons that should be used by other items, i.e. are the icons swapped between items?

I can't really see why this would happen (there haven't really been any relevant changes), so every clue is needed.

[Containments][13]
activityId=12188ba2-bfd2-43d1-be08-7a6cf2d8e70c
formfactor=0
immutability=1
lastScreen=0
location=0
plugin=org.kde.plasma.folder
wallpaperplugin=org.kde.image

[Containments][13][Applets][16][Configuration][General]
showSecondHand=true

[Containments][13][ConfigDialog]
DialogHeight=648
DialogWidth=720

[Containments][13][General]
ToolBoxButtonState=topright
ToolBoxButtonX=1338
iconSize=3
positions=2,11,file:///home/bshah/plasma-workspace-git,1,4,file:///home/bshah/Breeze.colors,1,3,file:///home/bshah/2014-07-26-195749_381x140_scrot.png,1,2,file:///home/bshah/Music,1,1,file:///home/bshah/irclogs,0,3,file:///home/bshah/Downloads,0,2,file:///home/bshah/aur,0,1,file:///home/bshah/Desktop,0,0,file:///home/bshah/core.5281,0,6,file:///home/bshah/src,0,5,file:///home/bshah/plasma-desktop-git,0,4,file:///home/bshah/testu.qml,1,0
sortMode=0
url=file:///home/bshah

[Containments][13][Wallpaper][General]
height=768
width=1366

[Containments][7][Wallpaper][General]
SlidePaths=/usr/share/wallpapers/

This is config part, and pattern I see is wrong folder icons only.. files have correct icons.

> This is config part, and pattern I see is wrong folder icons only.. files have correct icons.

- Is it always the same folders?

- Is it always the same icons (pictures)?

- Are the icons related to other items? (I.e. are they using icons that are also used by files in the dir.)

- Can you take a video of it correcting itself when you interact with it? So I can see what might be called in KDirModel.

- Does it still happen when you disable previews?

One more:

- Does it still happen when you set the view to sorted again (e.g. sort by Name) and lose custom positions?

(Please test toggling previews first, before this, the sequence might be important for reproducing.)

(In reply to Eike Hein from comment #6)
> - Is it always the same folders?

no, this happens for the all folders that are in the home.. even this happens for newly created folders.

> - Is it always the same icons (pictures)?

?? you mean wrong icons..? If, yes.. they are always same..

> - Are the icons related to other items? (I.e. are they using icons that are
> also used by files in the dir.)

No

> - Can you take a video of it correcting itself when you interact with it? So
> I can see what might be called in KDirModel.

Sure

> - Does it still happen when you disable previews?

Have not tried it.. but can try.

Also this happens only when you login to session, restarting plasmashell is not enough..

(In reply to Eike Hein from comment #7)
> One more:
> 
> - Does it still happen when you set the view to sorted again (e.g. sort by
> Name) and lose custom positions?
> 
> (Please test toggling previews first, before this, the sequence might be
> important for reproducing.)

Alright, toggling preview not really helped but sorting view helped. if they are unsorted I can reproduce bug.

> no, this happens for the all folders that are in the home.. even this happens for newly created folders.

You mean when you create a new folder in a terminal with "mkdir foo" after login it comes up with the wrong icon?

If it happens for all folders, why does "aur" have a folder icon in your screenshot? Is that not the correct icon?


> ?? you mean wrong icons..? If, yes.. they are always same..

Yes, I wanted to know if it is always the same picture (the page with the four little tetris blocks) or if it varies.

(In reply to Eike Hein from comment #11)
> > no, this happens for the all folders that are in the home.. even this happens for newly created folders.
> 
> You mean when you create a new folder in a terminal with "mkdir foo" after
> login it comes up with the wrong icon?
> 
> If it happens for all folders, why does "aur" have a folder icon in your
> screenshot? Is that not the correct icon?

It is correct icon but I corrected it by selecting it.. (interacting with it)

a video will be really helpful here, wait a moment.

> 
> 
> > ?? you mean wrong icons..? If, yes.. they are always same..
> 
> Yes, I wanted to know if it is always the same picture (the page with the
> four little tetris blocks) or if it varies.

If you change folder/plugin/foldermodel.cpp from:

  dirLister->setDelayedMimeTypes(true);

to

  dirLister->setDelayedMimeTypes(false);

does it fix it?

This wouldn't be an acceptable solution, but it would confirm my current theory of there being a race condition causing Positioner to miss and relay a dataChanged() replacing the icon as MIME types are resolved.

*miss and not relay

Created attachment 87982 [details]
video of problem

look video, also this shows pixel art I am having.. :(

(In reply to Eike Hein from comment #13)
> does it fix it?
yup, seems to fix..

Alright, thanks ... this will be tricky to work on without being able to reproduce, but at least we now have an idea what happens; I'll give it a try next week.

The content of attachment 87982 [details] has been deleted for the following reason:

sound enabled

(In reply to Eike Hein from comment #17)
> Alright, thanks ... this will be tricky to work on without being able to
> reproduce, but at least we now have an idea what happens; I'll give it a try
> next week.

any idea of pixel art I am having? :(

Not really ... I'd blame the driver though since Folder doesn't really do anything special there (the only "special" part  with custom OpenGL code is the DND pixmap stuff).

Please re-test current master, there's a good chance it's fixed now.

Looks like fixed. Thank you!

I guess this commit fixed this, http://commits.kde.org/plasma-desktop/79ab391618c5393941afbcb8a5bc87952701fd28

Alright, sorry but let me reopen this, this issue is fixed to some level. If I create new directory or file I don
t get correct icon and get tetris icon instead.

Can you give me super-detailed steps?

Alright,

1) Switch to folder
2) Set url to home dir
3) Move some icons so that they are in unsorted mode
4) From command line create new folder
--> mkdir foo
5) newly created dir does not have correct folder icon but tetris icon

Created attachment 88037 [details]
video

 ofcourse not a major problem. I can live with this all day but here is video to explain things..

Sure it's a major problem :)

I'll be investigating this over night - I have some concern I might not be able to reproduce it because my SSD is too fast. Will you be online tomorrow morning (European time) like today? Then I can maybe give you a patch to produce debug output for me.

I'll be online in early morning tomorrow yes..

So from debugging with Bhushan, it looks like this remaining issue is caused by KDirModel not emitting dataChanged() when it updates the icon.

He's getting a rowsAboutToBeInserted+rowsInserted signal pair for the new folder, but it initially has the "tetris" icon, and when KDirModel figures out that it's a folder it doesn't emit dataChanged() for the icon change.

This might be down to the interaction between KDirModel and KFilePreviewGenerator, because Bhushan reports that the problem disappears when he disables preview thumbnails.

Meanwhile I still can't reproduce this locally -- I get the insert, too, but it already has the icon by that time. Most likely because my SSD is faster than Bhushan's laptop HDD.

I'm going to CC dfaure here in the hopes that he has an existing familiarity with the problem or so.

I've been able to reproduce it now - turns out it's possible here on file:// urls, but not on desktop:// - and am hunting the bug through KFilePreviewGenerator.

When previews are off it successfully runs the MIME type resolve machinery and ends up calling setData() on the dir model so we get a dataChanged(), but with previews on dispatchIconUpdateQueue() gets called before any previews are ready, and by the time the preview is ready no dispatch happens anymore.

Proposed fix at https://git.reviewboard.kde.org/r/119551/

So I just looked around review request, can not test at the moment but any reason why it works for desktop:// urls and not file:// urls? do desktop kioslave have something special then file kioslave? so it works in it?

I'm guessing the desktop:// kioslave somehow causes the MIME type to be already determined by the time KDirModel emits the rowsInserted(), haven't looked at its code though.

Doesn't it make sense to fix file kioslave (if possible)

No, there's nothing wrong with the file kioslave. It's a design bug in KFilePreviewGenerator. As the review request explains, KDirLister has a "don't determine MIME types unless asked" option, which Folder uses for speed reasons*. KFilePreviewGenerator is in charge of asking and doing model updates, but forgets doing the latter in a specific set of circumstances, which my patch corrects.

As a proof of the principle, you can do the following: In FolderModel::setViewAdapter, disable the construction of the new KFilePreviewGenerator instance. You'll notice then that folders will never get their correct icons, because their MIME type is never asked for. If OTOH you change the setDelayedMimeTypes(true) call to false, it will start working.

In the case of the desktop:// kioslave, for unknown reasons the MIME type is already known by the time the items are inserted into the model. Probably because the kioslave code calls something that causes it to be determined -- which technically defeats the purpose of setDelayedMimeTypes(true), though it doesn't really matter much in case of the desktop.

* = The reason it's a speed optimization is because KFilePreviewGenerator is capable of taking into account which parts of the view are currently scrolled into view and can prioritize preview generation / MIME type resolving based on that.

Git commit 561a812dad85d052ad1181129099ae22549f5603 by Eike Hein.
Committed on 31/07/2014 at 08:04.
Pushed by hein into branch 'master'.

Unsuccessful preview jobs still resolve the MIME type; make the model announce the DecorationRole change.

REVIEW:119551
Reviewed-by: David Faure

M  +16   -9    src/filewidgets/kfilepreviewgenerator.cpp

http://commits.kde.org/kio/561a812dad85d052ad1181129099ae22549f5603