When you open a big project (CodeBlocks.cbp is a good example), it takes some time to load all files.
C::B seems freezed during that time and nothing informs the user that it is working.
Could an hourglass mouse pointer be added during that time?
Another idea is a progress bar that shows the loading progress.
Obviously the 2 ideas can be used together ;-)
The same thing could be useful for other long operations (if any) except compilation because it already has it's feedback to the user (tool bar buttons that change color and build messages).
wxBusyCursor wait;I think that loading a project in an asyncronous way is not good because you cannot work on it reliably when it is partially loaded.This is not true as it is now, and it is not true for the things I was talking about making asynchronous in the future, either.
When I open codeblocks.cbp and I click on a menu, I find some menu-items disabled. This is not good because I think they are not available for a strange reason, while after some seconds thay become available. I see this more like a bug than like a feature ;-).This bug is what actually makes it reliable. You can only do certain things after the project was fully loaded.
Loading time depends very much on computer speed, so you cannot say: it should be a fast task to execute. On old PC it may take long time.I did not say so, and yes indeed, on a slower PC, it will take longer. That's obvious, but that's not the point.
now loading is very slow also on fast PCsThis is not quite true. On a reasonably "normal" machine (3 GHz, no SMP, no dual-core, no Hyperthreading), project loading takes on the order of 100-200 ms for a small project and on the order of 1.2-1.4 seconds for a project the size of Code::Blocks. Most IDEs are significantly slower than that. Even though we have not yet spent one minute optimising the project loader, we really don't need to hide under a rock.
Then we could divide the loading in 2 parts: syncronous and asyncronous.That's what we're partially doing already, and that's what we will probably extend in the future, as described above.
While the syncronous part is being executed, I think there should be an hourglass (or other). Then the user can start working while the asyncronous part is being done.
Sorry, but a 3 GHz CPU is not so "normal"!Yeah well... a lot of people run 4 GHz and upwards CPUs these days, many of them with either hyperthreading or dual-core (or both). So actually, a plain normal 3 GHz CPU is comparatively slow :)
When code completion parsing starts?Immediately after the actual project loading has finished, but before the GUI comes "alive" again.
Probably the long time I see is related to that.Yes, very likely.
Error occured on Wednesday, July 26, 2006 at 22:11:07.
E:\data\killerbot\CodeBlocks\svn\src\devel\codeblocks.exe caused an Access Violation at location 65ec2863 in module E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll Reading from location 00690054.
Registers:
eax=08ee8f10 ebx=0a35fcc0 ecx=0069004c edx=0069004c esi=ffffffff edi=00000000
eip=65ec2863 esp=0a35fc24 ebp=0a35fc24 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
65EC2863 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65EC2863 PluginSDKVersion
65F01A9B E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65F01A9B std::_Rb_tree_const_iterator<int>::operator++() C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/stl_tree.h:255
65E8F081 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8F081 ClassBrowserBuilderThread::AddTreeNode(wxTreeItemId const&, Token*, bool) E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:276
65E8EC3D E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8EC3D ClassBrowserBuilderThread::AddTreeNamespace(wxTreeItemId const&, Token*, std::set<unsigned, std::less<unsigned>, std::allocator<unsigned> > const&) E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:191
65E8E000 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8E000 ClassBrowserBuilderThread::BuildTree() E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:103
65E8D867 E:\data\killerbot\CodeBlocks\svn\src\devel\share\codeblocks\plugins\codecompletion.dll:65E8D867 ClassBrowserBuilderThread::Entry() E:/data/killerbot/CodeBlocks/svn/src/plugins/codecompletion/classbrowserbuilderthread.cpp:30
61A609D5 E:\data\killerbot\CodeBlocks\svn\src\devel\wxmsw26u_gcc_cb.dll:61A609D5 _ZN8wxThreadD2Ev
77BCB530 C:\WINDOWS\syswow64\msvcrt.dll:77BCB530 _endthreadex
7D4E0729 C:\WINDOWS\syswow64\kernel32.dll:7D4E0729 FlsSetValue
Another thing: this problem is not just for "project" loading, but also for files loading.It does not solve any problem. All it does is show a different cursor. That's following the wrong path. The right path would be to make it behave so it doesn't take that long at all and doesn't freeze.
Try to drag-and-drop 20 or more source files in C::B, it takes a long time and the GUI is freezed.
That single line of code solves this problem too.
CB was like a X-mass tree, those menus flickeringMuch of the flickering when opening/closing many files comes from not disabling the editor notebooks. The code was commented out for some reason a long time ago (don't know why). I uncommented it in cf a week or two ago to test whether there are any problems and there seem to be none, so we can probably leave that. It'll eventually get merged.
codecompletion, that it is does not always work and it has it's limitations, but at this moment it's a crash chance of above 50 %I don't think we'll ever be able to fix this plugin, nobody understands what is happening anyway. For now (until the new one is production quality), I have code completion entirely disabled, and everything works smoothly. I never see a freeze or a crash (except for the one and only known wxSmith crash-on-exit issue) or any other bad condition.
It does not solve any problem. All it does is show a different cursor. That's following the wrong path. The right path would be to make it behave so it doesn't take that long at all and doesn't freeze.What I mean is that now the code is slow and takes a long time.
Besides, the GUI is perfectly responsive under Linux while opening 50 files via D&D (not that it opens them any faster, though). The freeze seems to be a Windows thing.
What I mean is that now the code is slow and takes a long time.I agree with that philosophy. It's called a quick & dirty fix.
When the new code will be ready, we will speak about that way of working.
Now we have another code, a slow code.
Its usage is popular among hackers, who use it to describe a crude solution or programming implementation that is imperfect, inelegant, or otherwise inadequate, but which solves or masks the problem at hand, and is generally faster and easier to put in place than a proper solution.
Quick-and-dirty solutions often attend to a specific instance of a problem rather than fixing the cause of the more general problem. As such, they are sometimes used to keep an item of software or hardware working temporarily until a proper fix can be made.
I agree with that philosophy. It's called a quick & dirty fix.No Takeshi, it's called a no-fix.
Hmm... df reports zero free blocks on /, looks like they're really serious about "no space left".The question is, why you can't even download from svn?
Although it is probably a different physical machine, I'll have a look what happens after deleting a few old nightly builds. We have so much stuff that's many weeks (or even months) old. Maybe we're lucky and that gives us a breather...
You see, I am not against showing that hourglass cursor. What I am against is to show a hourglass cursor instead of actually digging for the root of the evil.
Hmm... df reports zero free blocks on /, looks like they're really serious about "no space left".
Although it is probably a different physical machine, I'll have a look what happens after deleting a few old nightly builds. We have so much stuff that's many weeks (or even months) old. Maybe we're lucky and that gives us a breather...
Hmm... df reports zero free blocks on /, looks like they're really serious about "no space left".
Although it is probably a different physical machine, I'll have a look what happens after deleting a few old nightly builds. We have so much stuff that's many weeks (or even months) old. Maybe we're lucky and that gives us a breather...
busy cleaning up nightlies
Another note:
Why not add the hourglass at the beginning of the function?
It would be only 1 line of code and all switch cases would be affected while now some are skipped.
I assume you are talking about the OpenGeneric.Yes, I forgot to say that ;-)
If so, that's not a good place, since the DnD will call OpenGeneric for every file, that means N times creation/destruction of the glass hour. The glass hour is being constructed though in the Dnd before' all the files are being submitted to OpenGeneric.
Freeze();
Thaw();
1) the hourglass is called, but never shownNot true. It is shown for a short time, but it is reset soon after. We're not doing it, so send your complaints to Julian Smart.
2) the GUI freezes more than beforeThat's what Freeze() does. However, it avoids the flickering due to overdraw, and it makes loading the dropped files significantly faster, which is one thing you complained about in the first place.
3) while the files are being loaded, you can click on the window below C::BDon't do that then.
I don't know Julian Smart, who is him?Quote1) the hourglass is called, but never shownNot true. It is shown for a short time, but it is reset soon after. We're not doing it, so send your complaints to Julian Smart.
Moving the call to the beginning of the function does not change the behaviour.
I never complained about slow loading, but about no feedback during the slow loading. They are different things ;-)Quote2) the GUI freezes more than beforeThat's what Freeze() does. However, it avoids the flickering due to overdraw, and it makes loading the dropped files significantly faster, which is one thing you complained about in the first place.
Probably this was not clear, but this is a bug (probably of wxWidgets).Quote3) while the files are being loaded, you can click on the window below C::BDon't do that then.
I don't know Julian Smart, who is him?Quote1) the hourglass is called, but never shownNot true. It is shown for a short time, but it is reset soon after. We're not doing it, so send your complaints to Julian Smart.
Moving the call to the beginning of the function does not change the behaviour.
Just so you know that should be: "who is he".Ok, thanks! I've just learned something more of this language (english). ;-)
If the code between the Freeze & Thaw are expensive, and you for example press the mouse left click - you might ending up pressing on the application under your application.
The best thing to do is to call the frame child's Freeze & thaw.Do we need to call freeze on all the application?
Do we need to call freeze on all the application?To what avail? The menu bar is not causing any significant overdraw.
Can we freeze only needed widgets (like the menu bar)?
1) menubar is _constantly_ redrawn (flickers)Do we need to call freeze on all the application?To what avail? The menu bar is not causing any significant overdraw.
Can we freeze only needed widgets (like the menu bar)?