Version: (using KDE 3.5.9) Installed from: SuSE RPMs Originated from: http://bugs.kde.org/show_bug.cgi?id=160691 The problem is that (probably) with the number of files opened at startup the difference between the moment the visual feedback disappears and kdevelop being fully operational increases. In my case it is several seconds, hard to miss. Please, stop displaying visual feedback until Kdevelop is fully operational (after the default project is loaded, not before).
You should've included more details. Without reading the other bugreport its completely unclear what you're complaining about. So this is about WaitCursor disappearing before KDevelop is actually usable. However I can't reproduce this, for me the waitcursor is there (with 2 breaks actually where it switches back to normal and then to wait again) until I can start typing.
That's why I included link -- no point in duplicating content of the report, I think. Andreas, what version do you use? Me: kdevelop3-3.5.1-20.1. And it is not about wait cursor but KDE visual feedback (in my case: bouncing cursor). It looks like this: 1) run kdevelop 2) bouncing cursor 3) splashscreen, still bouncing cursor 4) kdevelop main window appears, normal cursor 5) default projects = ~100 files, it is loading, and loading, still normal cursor 6) default project is fully loaded -- still normal cursor My wish: for (4) and (5) still show the bouncing cursor
Thats basically a wontfix then I think and its a wishlist bug for kdelibs. The bouncing cursor is not from KDevelop its done by a component in kdelibs, kwin or kdesktop (dunno where exactly). You want me to re-open the report and re-assign it to kdelibs or do you want to re-open the original report?
Andreas, thank you, I will reopen the original report.
PS. But even wait cursor (from KDevelop) in (4) and (5) would be nice. But you said it works for you, so I guess I'll wait for KDE4 and Kdevelop4, right?
I meant KDevelop 3.5, the busy-wait-cursor is shown until I can start writing in the editor for me (tested on my KDevelop3 project).
Just to ensure what is with busy cursor I did more tests: a) opening project -- busy cursor -- correct b) launching kdevelop with default (autopen) project -- no busy cursor -- incorrect c) closing project -- no busy cursor d) and closing entire kdevelop with project -- no busy cursor, but I guess it is simple effect of (c)
There's no busy cursor during shutdown, right. However during startup and loading of the last used project it works for me.
Ok, maybe somebody else will comment how kdevelops behaves on his/her system.
ad.b) I clarify -- there is busy cursor for tiny amount of time, I guess when the file project is loaded, soon after the actual project (files from project) is loaded -- no busy cursor Could this be dependant of chosen UI in Kdevelop?
I think this is provided by kwin and not KDevelop. Therefore is a KDE bug and not a KDevelop bug.
? I didn't write a lot of code in Qt/KDE but cursor change is made on explicit request from application, right?
the busy cursor, yes. But not the bouncing thing thats there during app startup.
Ok, since there is nothing it can be done with bouncing cursor, I changed the my wish -- to provide busy cursor (however it is WORKSFORYOU :-) so I check with the next upgrade).
There was no further activity since almost 10 years. I assume this can be closed.
I have noticed that it works properly for some apps, while not for others. Kwrite, Qalculate-gtk are some apps for which the launch feedback vanishes immediately on the appearance of the window. While for VLC, the feedback continues even after the appearance of the window, up to the timeout specified in settings.