Output View - Build doesn't refresh until compilation is finished

[yunkot]

CodeLite build b78446b5c7e2e19a1dea0371812bb15d01fc6356. Running on Arch with stock wxWidgets version 3.2, GNOME 42.3 on top of Xorg.

When compiling the project with either GCC or Clang, the text in Output View - Build does not seem to refresh until the compilation is finished. If compilation takes a while, the only thing you see during this time is "Entering directory ...".

[eranif]

was it a wx update that broke it? or a recent CodeLite commit?

[yunkot]

Actually, I could compile older CodeLite 14.0.5 with a couple of patches and it seems to exhibit the same issue. So it could be an issue of wxWidgets 3.2. Is there any workaround I can try to force the repaint/refresh?

[yunkot]

This issue also happens when using latest wxWidgets compiled from GitHub (https://github.com/wxWidgets/wxWidgets/commit/667c5c843b89ed46e3a64242f94487866cb8c3be) and CodeLite build 4a1a818412812385ffdc06ae8316d3645e787c52. Can reproduce it on GNOME 41.4 and GNOME 42.3, both running under Xorg.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs (within 5 days). Thank you for your contributions.

[yunkot]

The problem is still present as of commit dfde6e967eff1c820c116ec2af46cb1e8ea1a025, tested on Arch / Gnome 43.1 / Wayland / wxWidgets 3.2.1. In fact, now when I compile the project, a notification window appears that CodeLite is not responding, offering to terminate it (but if I wait, the compilation finishes normally).

[UffeJakobsen]

I have seen something similar (I believe)

My problem have been around for some months now - I've also seen it recently on builds from master - but I need to get my arms around the actual scenario and nail the actual things that that creates this situation

[yunkot]

This issue is still present as of commit c40b9c398217c250584089237fbb1a9efd55ccf2, running on Arch / Gnome 43.4 / Wayland / wxWidgets 3.2.2.

[UffeJakobsen]

I can confirm that - runnning on Arch, wx-3.2.2, LxQT/openbox

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs (within 5 days). Thank you for your contributions.

[UffeJakobsen]

I still see this issue from time to time on latest CL

[eranif]

I spoke too soon :) Indeed, I too see this on Windows

[yunkot]

This issue still exists as of commit 75f3e0da4b3202a88a594f1ad45430ee5006cac2, tested on Debian 12 / Gnome 43.4 / X11 / wxWidgets 3.2.2.

[yunkot]

As a note, using a single thread for compilation, or just two of them, kind of alleviates this problem. For me, I can still see output progress if I use "make -j2" on my Ryzen 5950X machine, "make -j3" makes it semi-unresponsive. The default "make -j32" produces this issue and on Debian 12 / Gnome, you would get a message asking if you want to wait for CodeLite or have it closed, until the compilation finishes.

[eranif]

I see no solution other than replace the current control. Can you try and use the new Terminal tab? does it refreshes for you? if it does, I can make some modifications and use it instead (a variant of it) for the build output

[yunkot]

I do have "Terminal" tab, but it's empty. Is it supposed to be like that?

[eranif]

completely empty? you should have a + button...

Here is a screenshot taken on Ubuntu:

[yunkot]

Thanks, after pressing on plus symbol, I can see terminal with cursor blinking, although can't type anything in it (how can I use it?). But as soon as I hit "Build", the tab changes and I can't get back to "terminal" tab until the compilation is finished.

[eranif]

You should be able to type at the bottom of the terminal, cant you?

[yunkot]

Unfortunately no, I can't type in the terminal - clicking on it and trying to type does not seem to have any effect, like if it was read-only. If you think it's worthwhile, I can report this as a separate (unrelated) issue?

[eranif]

can you post a screenshot?

[yunkot]

Yes, sure, here's a screenshot, where cursor is blinking, but typing has no effect (I've blurred user and machine names):

[eranif]

This is not a real terminal (but its good enough for basic usage) Notice the light grey line at the bottom of the terminal -> type there, for example ls -l

EDIT: trying to type where the orange cursor is, will also take you to the bottom line

[yunkot]

Clicking on light grey line and typing does work, although its cursor is a black square, so a bit difficult to see. But clicking on orange cursor and trying to type text, does not take you to bottom line, although you can move orange cursor around the console with arrow keys and even select text with shift key, however. So at least on my setup, I have to explicitly click on light-grey line to be able to type commands and since there are no other visual clues that this is an edit box, I didn't notice it until you told me to click on it, sorry.

[eranif]

You can use F6 to toggle focus between the editor <-> terminal without using the mouse I am currently fixing the cursor colour + hitting any ascii char (a-z/A-Z) will take you to editing line

But the main thing that I wanted to check here: Can you try and trigger a build using this terminal and see if it refreshes the view?

[yunkot]

Unfortunately, as I've said earlier, trying to type, e.g. pressing on "A" key while inside terminal does not move focus to bottom edit box. Pressing any keys that start compilation immediately switches to "Build" tab and CodeLite remains unresponsive until it finishes, so I can't switch back. I could only do it if I use "make -j3" to reduce number of threads, but this also allows "Build" tab to refresh, although very subjectively, "Terminal" does look a bit more responsive.

[eranif]

the number of threads should not affect, I am building with 24 threads and its very responsive (macOS, Windows & Ubuntu) What I wanted you to try is:

• Open the terminal
• Manually set the focus to the edit area (the last line)
• type in the terminal edit area: cd <build directory>
• type in the terminal edit area: make -j$(nproc)

[yunkot]

I'm pretty sure this issue also happens on Ubuntu as well. I have tested it on latest Arch, Debian 11, Debian 12 and Ubuntu 20.04. I've tried executing "make -j32" in terminal area and it refreshes very well.

[eranif]

So, making sure here, triggering a build from the terminal (the CodeLite built-in terminal) - works as expected?

[yunkot]

Yes, that is right. Actually, triggering build from the terminal tab seems to make compilation much faster. So, in my project, pressing F7 and waiting for it to compile takes around 6 seconds, whereas doing the same from terminal tab takes just a second or two. Both execute "make -j32" as far as I can tell.

[yunkot]

This issue is still present as of CodeLite revision 6246eac495fe34000d0b6494d9d4a2f58e19c495, wxWidgets 3.2.3.