| Re: [cdt-dev] [EXTERNAL] Re: Proposal for cdt resources decoration. |
test_src_1 and test_src_2 are not excluded, they are rather not included in the source folders. This is a different information to the user._______________________________________________If test_src_1, test_src_2 are resources unrelated to c/c++, they should not be cluttered with the decorations. Source folders are the current way to distinguish this. To give another example, another project like Trace Compass which does mix with cdt nature and puts traces in a top-level folder would have its traced all "crossed-out" with this new decoration.Marc-AndréOn Oct 7, 2020, at 12:01 PM, Сергей Ковальчук <serjiokov@xxxxxxxxx> wrote:_______________________________________________Hello Baltasar,Thanks a lot for details.I would say that, I'm targeting is to enhance current decorator logic (not provide a new one).The goal is, explicitly decorate resources that are not used by active build configuration. it is exactly user friendly and obviously for users.Here the result is what I like to achieve.<Proposal.png>/test_src_1- test1.cpp - decorated as source and will be used by the builder./test_src_2- test2.hpp - decorated as inactive (excluded) will not be usedetcLet me know what you think.BR,Sergei Kovalchuk, NXPср, 7 окт. 2020 г. в 16:43, Belyavsky, Baltasar <bbelyavsky@xxxxxx>:_______________________________________________Hi Sergei, and all,
I’m afraid the proposed new decoration might create a bit of confusion for the user, and might also create visual clutter.
Here are a few concerns I have with it:
- If we overload the same decoration which we currently use for buildable resources explicitly excluded from build (using the “Exclude from Build” action), we might make it difficult for user to tell these explicitly excluded resources apart from resources decorated as proposed below. I think this would create confusion.
- We would create unnecessary visual clutter for projects that have many build-configurations. If there are ten build-configurations, nine of them will have to be decorated as proposed below.
- The first screenshot showed dot-resources decorated as “excluded from build”. We would definitely confuse the user if any non-buildable resources are decorated as “excluded from build”.
I think the above concerns would be addressed if we introduced a new visual decoration instead of re-using the “excluded from build” decoration. I think it would look cleaner if the active build-configuration’s folder were simply decorated with the label “ [active]”, for example. I.e. decorate only the single active folder (but none of its child resources). I think that would look a lot cleaner and be more intuitive and self-explanatory.
Thanks,
- Baltasar
From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> On Behalf Of Marc-Andre Laperle
Sent: Tuesday, October 6, 2020 11:52 PM
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cdt-dev] Proposal for cdt resources decoration.
Hi,
I think only resources that are under source entries have any effect of being excluded (decoration, prevent being built). If resources are not under a source entry, they are implicitly not included and won’t be built. But indeed there is no decoration in this case. But this is a bit of a different proposal than your original statement. If you exclude resources that are under a source entry, they should get the decoration and change with the active config (with the correct Indexer preference set). This should be the case for resources you exclude under the “src” folder in your screen shot, based on the blue “c” decoration, it should be a source entry.
So I think the new proposal would be to decorate files that are not under source entries.
For this new proposal, there are two things that come to my mind:
* AFAIK source entries are the way source files are “included” in a cdt project. Exclusions are really filters applied on these source entries.The exclusion decoration seem to reflect that. Changing the decoration to "any resource not under source entries" is now a decoration for files “not included”, i.e. there were not included to begin so are they really excluded? It’s a bit of semantics but this is a different information to the user.
* Projects with multiple natures, not just c/c++. I think it’s useful to have source entries (folders) because we can differentiate folders that cdt should not really deal with. For example, if you have a folder with only java files next to your c/c++ source folder, I would think you would not want the Java folder to be decorated as “excluded”.
Perhaps the added clarify to the users about files not included is worth making the change even considering those two points.
Regards,
Marc-André
On Oct 6, 2020, at 3:25 AM, Сергей Ковальчук <serjiokov@xxxxxxxxx> wrote:
Hello Marc-Andre,
Thanks for the tip, I tried but fail, seems settings does not work for me. What I did, opened pref page for the project, enabled indexer settings, played with "Build configuration for indexer" but it is not sensitive. In all cases, I see the same behavior.
I attached the picture, did I miss something?
P.S. Currently, I'm using CDT 9.10
<Eclipse_cdt_issue_description_indexer.png>
BR,
Sergei Kovalchuk, NXP
пн, 5 окт. 2020 г. в 19:36, Marc-Andre Laperle <malaperle@xxxxxxxxx>:
AFAIK the decorations reflect the config the indexer uses, which is by default not linked with the active one. If you set the Indexer preference to use the active configuration, the decorations are updated properly when you change config.
Marc-André
On Oct 5, 2020, at 3:56 AM, Сергей Ковальчук <serjiokov@xxxxxxxxx> wrote:
Hello All,
I would like to propose some changes for current behavior of decoration resources in Project Explorer for CDT resources. The current behavior of folders decoration is not sensitive for selected (active) build configuration. My proposal is to decorate folder resources related to active build configuration differently than for inactive. The inactive resources should be decorated by another resource icon and color of font.
It helps faster recognize resources taken by the selected builder and used for build procedure than open C/C++ Settings on the property page.
I attached the screenshot for details.
I would like to provide a commit according to my proposal, but
not sure how to classify the issue bug or feature or any?
<Eclipse_cdt_issue_description.png>
--
Best regards,
Sergei Kovalchuk, NXP.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
--
Best regards,
Sergei Kovalchuk
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
--Best regards,Sergei Kovalchuk
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev