https://bugs.kde.org/show_bug.cgi?id=469445
--- Comment #44 from pallaswept <pallasw...@proton.me> --- (In reply to Nate Graham from comment #43) > The issue with option #1 is that we'll be playing whack-a-mole forever, Exactly. > This leaves option #2, which is pretty easy but the problem is that checking > for the existence of all those files requires a bunch of stat calls. If for > example we did them at plasmashell startup in a blocking fashion, it would > slow down plasmashell's startup or make it hang ..... Yeh that would suck. It's a good thing we have people like you who understand how KDE works so that you can see these problems coming before they happen. Thank you! I do wonder though, if you'd actually need to make so many stat calls. You could approach this by reading each screenmapping entry, and making a stat call to confirm its existence - or, a single listing of the desktop directory's contents could be taken, and then it's an easy check that each screenmapping entry item is in that listing. Any way, I'm sure someone who knows better than me will figure out the best way to do it. > Maybe it would work if we made the stat calls non-blocking and did them in > the background in a different thread, rather than all at once on startup, it > would be fine. I think that should be fine. I'd say it can take as long as it needs, so long as it reads the screenmapping entry, does its cleanup, and completes before reading the screenmapping entry and applying it; or potentially, reading the screenmapping entry and crashing because it's too long. But I guess that leaves a situation where one might log into a plasma desktop session, and have un-arranged icons for a moment, before the cleanup thread finishes and allows the implementation of the screenmapping entry? Not really a big drama, but just food for thought. Delayed arrangement of icons is certainly better than delaying the whole startup like you described! (And, it would only happen just that once, when there was something to clean up - the next startup would be like normal) > Rer-opening and lowering priority, since it's now been partially fixed enough > to make this not be a pants-on-fire level issue. Legend, thank you! FWIW I agree, it's not super urgent now, with the patches Harald made, the user would have to do something fairly out of the ordinary, to make it fail. -- You are receiving this mail because: You are watching all bug changes.