If I set the folder to a timeline:/-url it does not become available after startup. I read the message that the file-indexing-service is not available. I guess this means Nepomuk and the timeline-thing. It works if I set the folder to a timeline-url a while after startup. So the service becomes available later. So I guess the problem is that it is not checked again. Reproducible: Always Expected Results: If the timeline is not available after startup the folder widget should show the "loading"-icon and check until it becomes available or maybe timeline is able to notify applications waiting for it, that it is available now. The folder widget should also be able to recognise when timeline will not become available because the user has disabled it and then should the message it shows now. There is a similar bug in Dolphin.
Bug no for Dolphin: https://bugs.kde.org/show_bug.cgi?id=304918
There is a fix for a similar bug which was in Dolphin available Here: https://bugs.kde.org/show_bug.cgi?id=304918 May be it can be also applied to folder view?
I finally took a look at the code. The code base is quite different, and I'm not sure if adding the check over here would be the correct place. The Dolphin patch worked by connecting to the Nepmouk2::ResourceManager::nepomukSystemStarted signal, and refreshing the contents once that signal has been emitted. This works because Dolphin has a LOT of Nepomuk specific code. This widget in contrast does not know about the existence of Nepomuk. It just uses KIO which uses the timeline kioslave. The proper place to fix this (maybe?) would be in the the timeline kioslave where it listens for that signal and tells the clients about the new files that have appeared. Relevant code: kde-runtime/nepomuk/kioslaves/nepomuksearch/
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham