Menu
▾
▴
#1255 Gray out file not build/link by the currently selected target
Hello,
As far as I know, when I have multiple target and a file is not included in the build/link operation of one target, whenever this target is selected or not the file name is black, as if it's actually use by the selected target.
Could it be possible to dynamically change the color of (aka gray out) the name of the file depending on it's usage by the currently selected target ?
It would be sweet and help keep track of which file is currently used.
Thanks !
Cheers,
I checked and it is greyed out in both the 20.03 and the last nightly release. If you still have an issue please post on the help C::B forum. and include info from the Help->About->Information tab.
As such this feature request can be closed.
Are you talking about the file tree?
Where do you want the name greyed out?
What I mean is the following :
Let's consider the following project in project_test.zip:
I have a main file, and a library that is composed of two c file and a header. I need to files .c because implementation of this library completely change if I'm building in release or debug mode, but the API stay the same.
So, my target Debug build main.c and lib_debug.c, and the Release one build main.c and lib_release.c
I've setup this in the properties of the project (Project/Properties/Build Target menu), and ticks the file I want for each target. Then, right clinking on each of lib_debug.c and lib_release.c and (Properties.../Build) show that this setup is well understood (lib_debug.c got only teh Debug target selected for build/link, and same for lib_release.c in Release target)
The build actually work as intended, of course, with both target.
BUT
Observe that in the tech tree, both lib_debug.c and lib_release.c are listed in black, as if they could be actually built, whenever the selected target is. To get them actually gray out (like lib.h), I should right click on them, and disable both the build and link stage. But that of course ignore my target setup, so it's not the way to go.
What could be sweet :
When I select the Debug target, only main.c and lib_debug.c should be in black, lib_release.c and lib.h in gray.
When I select the Release target, only main.c and lib_release.c should be in black, lib_debug.c and lib.h in gray.
I hope this example make thing clearer for you :)
Again, that not a deal breaker, but could be a very nice touch.
This new behavior could be made optional as well, with for instance a tick-box when right-click on "Workspace", as the "Categorize by file types" one, for instance.
PS : You should find a screenshot in the zip attached of how my tree appear to me, just to make sure we discusses on the same thing :)
Also I add two screenshot (one per target) of what I would like to have, if possible :)
Cheers !
Codeblocks infos :
Name : Code::Blocks
Version : 20.03-r11997
SDK Version : 2.0.0
Scintilla Version: 3.7.5
Author : The Code::Blocks Team
E-mail : info@codeblocks.org
Website : http://www.codeblocks.org
wxWidgets Library (wxGTK port)
Version 3.0.5 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.20.
Last edit: Yann LEROY 2022-04-11
So in summary, you want: * A new option to conditionally include files in different target types in the project.
No, he wants an option that greys out files in the project tree when they are not compiled/linked in the current active target. No change in compilation or targets needed, only a visual thing
I think this should easily be doable, i mean we do it in some kind already...
@bluehazzard, yes you got my idea :) I do think it's "just" a matter of tweaking the display process, it has nothing to do with how c::b should work otherwise.
I would be interested in trying to do so myself, but I'm not familiar with svn nor the c::b codebase ... :/
Last edit: Yann LEROY 2022-04-18
i have looked into it. Generally it is easy to implement.
The problem is, it is really hard to implement right....It is possible to switch active target from multiple places (ex, script, multiple places in code, the actual switching happens in the cbProject class, that should not contain any UI stuff, so we can not add any update ui stuff there), so it is hard to repaint the tree every time the active project switches. The UI for switching targets is in the compiler plugin, but the tree ctrl resides in the Project manager UI, so all in all there is no central point to update UI...
I will investigate how difficult it is to add a new internal event, somehow called switch active target...Edit: There is a event already...
Last edit: bluehazzard 2022-04-20
I do think you got that already, but I've dug a bit into the code, and this condition https://sourceforge.net/p/codeblocks/code/HEAD/tree/trunk/src/src/projectmanagerui.cpp#l3136
trigger the "gray out" aspect. Maybe something like 'if(file in active target)' instead but I don't know how to do that !
Note that currently to "gray out" aspect is only driven by the "Build" toggle that whe could change by right-click on a file -> Option -> Compile File
First, why not take in consideration the linking stage as well ?
Secondly, this toggle ignore the "per target" build rules... Should it stay like that ? I don't see many use case, because it's kinda a duplicate of the file list in the Project Properties -> Build target -> Build target files
Man... It is actually quite difficult to decide if a file is compiled or not...
There are targets, virtual build targets, compile flag ecc....
Also i do not know what to do with other projects, grey out all items if the project is not compiled?
Or use the active target of the inactive project?
I attached a patch with first work done...
Changing active project does not work, i am not really sure why...
Last edit: bluehazzard 2022-04-24
That some work done I didn't expected, I feel bad to make you work that much... But thank you ! :)
You're right about virtual target, that not clear what should be considered...
I think that file should be displayed as "compile" (ie displayed in black) if one of the target of the selected virtual target compile this file.
"Also i do not know what to do with other projects, grey out all items if the project is not compiled?
Or use the active target of the inactive project?"
Hum, yes, I think so, and when a user want to know why the files are or aren't built, well he will just have to activate the project to see the name of the current target, if that make sense. (and maybe display the current target of each project in the tree, next to each project name, for instance in parenthesis ?)
Question for other devs:
Should this be an option? I changes the default visual behaviour of the tree quite a lot, but on the other end now it represents really what was intended from the beginning....
And I'm a bit sad, but I'm not able to built C::b from source :/ C::B ask me for env-vars that I've no clue about... So trying your code is not possible for me, for now...
ok, patch 2 for this...
i think i have a crash on exit, that i still have to investigate...
@other devs, i still would like some opinion about if this should be an option, or this is expected behaviour (i am for the later....)
edit: Yea i am hitting a close crash, that i introduced.... This is going to be fun to resolve....
Last edit: bluehazzard 2022-05-09
Ok, this is patch 3
this should work without crashes
can other test this?
I get a warning:
because the first parameter is const in the prototype but not in the definition.
When I load a project all the files are grayed, I must select another target and then return to the original to get them right.
Can you describe more? I was not able to reproduce this....
Loading codeblocks worspace worked fine also loading a single project worked
My project has two targets, Release and Debug. Both targets compile all files.
When I open the project, target Release is shown but all the files under Sources are shown grayed. I then select the Debug target and now all files under Sources are shown in black. Now I reselect Release and the files are shown in black.
This looks like an initialization problem, probably cbEVT_BUILDTARGET_SELECTED is not sent when the project is loaded the first time.
Thank you for testing!