Global RISC-V Toolchains name does not change with dropdown box

[laomaolaile]

Global RISC-V Toolchains name does not change with dropdown box

[jonahgraham]

And thanks to Renesas for supporting me to do this work.

[ilg-ul]

tentatively the end of the week, there are a few small issues to fix.

Unfortunately we still have an open issue (#580, which was split from #576; Jonah is working on it); we'll make the release when ready.

[ilg-ul]

The fixed version will be part of v6.4.0.

[laomaolaile]

I understand, thank you
The above function is to determine who is the default Toolchain
The following functions will list all Toolchains
@ilg-ul
thank you too @TommyMurphyTM1234

[jonahgraham]

@jonahgraham what do you think? In other preferences pages I saw grouping or tabs. What would be the best way to redesign these windows to avoid the confusion?

I'm experimenting now with the code to understand what I can propose.

[ilg-ul]

'All configurations' seems a bit too verbose, I was thinking that we can go without it for the majority of projects, but if you think that consistency is important, perhaps you can shorten it.

[ilg-ul]

I would say that it looks great, thank you!

[jonahgraham]

Ok, got it, thanks for your explaination.

Thanks for asking the questions - this stuff is pretty complicated and making it easier to understand for users is really important.

Some questions list below:

For the global preference, is it used to set the default toolchain path for each toolchain? If yes, but according to the screenshot, it display settings used by different projects?

The current UI allows you to set the path used by the toolchain, but to keep the UI from being very big, only the toolchains in use in your workspace are displayed here.

For the workspace preference, is it used to set the default toolchain path for each toolchain and overwrite the settings in global settings?

Yes that is correct. If you don't set anything in the workspace level the global level is used.

[jonahgraham]

Here are the screenshots to go with my latest update, key changes are adding/fixing some of the wording in description areas and I added links from project settings back to workspace/global settings.

Project Settings Page:

Clicking on the links opens the specified page and limits the visible pages to only global/workspace setting like this (note only two pages visible in the tree on the left):

Workspace settings:

Global settings:

As for long lists, the text does wrap

See the above screenshots that show wrapping on the long project and config names.

@fanghuaqi - does that seem clearer now to users?

[ilg-ul]

PR #575 was merged, it'll be part of the new release.

Many thanks to @laomaolaile and @fanghuaqi for revealing the issue and even more to @jonahgraham for contributing the quite large PR.

[ilg-ul]

The Default toolchain is used when creating new projects and changing it has no effect on existing projects.

[TommyMurphyTM1234]

The Default toolchain is used when creating new projects and changing it has no effect on existing projects.

But the Window > Preferences > MCU > Global RISC-V Toolchains Paths dialog is not operating on an existing project.
It does seem odd that the dropdown can be reconfigured but it has no obvious effect in this context?

[laomaolaile]

This Default toolchain should be able to be set to different settings, but now it seems that it cannot be set or changed

[ilg-ul]

That's what Preferences are for, to configure the Eclipse instance or the workspace.

The projects have Properties.

[TommyMurphyTM1234]

I don't understand.
Forget about projects,
Focus on the global settings in Window > Preferences > MCU > Global RISC-V Toolchains Paths.
When the Default toolchain dropdown is modified nothing happens to the Toolchain name or Toolchain folder fields.
That seems confusing.
What is the purpose and effect of changing the Default toolchain setting in this dialog?

[ilg-ul]

When the Default toolchain dropdown is modified nothing happens to the Toolchain name or Toolchain folder fields.

That's expected, because they are not related in any way.

The selection you make in the Default toolchain field will be proposed as default when you create new projects.

Why do you think that a setting named Default XXX should have any effect on existing projects?

Existing projects already have a toolchain, so they no longer require a default one.

[TommyMurphyTM1234]

Why do you think that a setting named Default XXX should have any effect on existing projects?

I don't.
You're the one who keeps mentioning projects!

So the effect of changing the Default toolchain dropdown here is that whatever is selected will be the default toolchain proposed when creating a new project?
That's not really clear from the dialog in my opinion.
I assumed (like @laomaolaile I suspect) that changing it would have some effect on the two fields below it.

Maybe a tooltop explaining the purpose and function of the Default toolchain dropdown would help?

[laomaolaile]

[ilg-ul]

... the two fields below ...

The two fields below actually can be pairs of multiple settings (name/paths) for all toolchains referred by the projects in the workspace.

For portability reasons, projects configurations do not use paths, but toolchain names (actually internal unique IDs).

These MCU Preferences pages allow to assign a path to each toolchain.

Maybe a tooltop explaining the purpose and function of the Default toolchain dropdown would help?

PRs are welcome!

[TommyMurphyTM1234]

PRs are welcome!

I know, but I simply don't know enough about Eclipse/plugins/Java to help directly.
Sorry.

[ilg-ul]

Two projects, one referring to the deprecated toolchain, and one to the latest one.

[laomaolaile]

I think combining these two functions together may be more in line with everyone's conventional thinking，hahaha~

[ilg-ul]

I think combining these two functions together...

Please describe the desired behaviour.

[laomaolaile]

In the last step of creating the project, there is an interface for selecting the Toolchain. I think this implementation may be better,

[fanghuaqi]

Yes, I agreed with @TommyMurphyTM1234 @laomaolaile , maybe this global settings could be improvded, each toolchain could have a seperated toolchain path, if we want to improve it, is there any suggestion about how to improve it?

[ilg-ul]

I think this implementation may be better ...

In what way?

[ilg-ul]

each toolchain could have a separated toolchain path

Each toolchain already has a separate path. And you can set it globally, per workspace or per project.

[fanghuaqi]

Hi @ilg-ul , as decribed here, these are not working as expected, when changing different toolchain path, not effective, and toolchain name remaining unchanged.

Thanks

[ilg-ul]

these are not working as expected, when changing different toolchain path, not effective, and toolchain name remaining unchanged.

Hmmm... @fanghuaqi take a look at the picture at #574 (comment), since the pictures you used are not relevant; that Preferences page may list multiple toolchains, if multiple different projects are defined in your workspace.

Describe exactly what you expect to happen when you change the default toolchain.

[fanghuaqi]

OK, @ilg-ul I understand now, this screenshot above, the marked 1 and 2 have two different functions:

1. is used to select default toolchain
2. is used to set different toolchain and its default toolchain path, but why there are 2 listed in your screenshot and only 1 list in @laomaolaile

Previously I thought 1 is used to select the toolchain, and 2 is used to set the selected toolchain path, but it seems that I am wrong.

Maybe a extra split line could be added between 1 & 2 or add more spaces before 1 & 2 to let user be confused.

Thanks

[ilg-ul]

1 is used to select default toolchain

That's correct

2 is used to set different toolchain and its default toolchain path,

Not exactly. It lists the names of all toolchains used by the projects in the workspace, and allows to set a path for each of them.

but why there are 2 listed in your screenshot and only 1 list in @laomaolaile

Because in my workspace there are two projects, each with its toolchain.

Maybe a extra split line could be added between 1 & 2 or add more spaces before 1 & 2 to let user be confused.

That's a valid suggestion.

I was thinking on moving the default toolchain selection at the end, and somehow visually group the toolchains paths section.

@jonahgraham what do you think? In other preferences pages I saw grouping or tabs. What would be the best way to redesign these windows to avoid the confusion?

[fanghuaqi]

Hi @ilg-ul , thanks for your detailed explaination.

I have an question here:

There are Global and Workspace Path settings in this page, what is the difference here? I thought the global one shared across workspace, and workspace one only override the ones in global and valid in workspace only.

If I want to set each toolchain's global default path, how to archive it?

[ilg-ul]

Global means settings that apply to all projects in all workspaces used by one Eclipse instance. Workspace means settings that apply to all projects in the workspace.

Global Toolchains Paths are actually stored in a special folder inside the Eclipse instance. Workspace Toolchain Paths are stored in a special folder inside the workspace. There are also Project Toolchain Paths, stored in the project folder.

If I want to set each toolchain's global default path, how to archive it?

In the current design, paths are not portable between different platforms and even between different machines using the same platform, thus are not archivable, you have to configure them manually each time you setup a new Eclipse or workspace.

This issue is addressed by the new xPack design.

When you install the toolchain as recommended in the README page, you also get a line added to the package.json, which is archivable.

The toolchain is actually installed in a global folder, but links to it are added in the project. Eclipse knows to use these links, and so you have a portable way of automating toolchain paths.

[jonahgraham]

I have played around a little to come up with a concrete proposal that adds some clarity, whitespace and borders. I also added some additional information in the dialog.

For this example I have a workspace with three projects, blinky, printer and scanner. blinky and printer have Debug and Release build config, and scanner has those two, plus New Board Debug that uses a different toolchain.

As you can see I added:

• groups around the global and per-toolchain settings with labels
• whitespace between different toolchain settings
• new logic that shows which projects + build configs are using each displayed toolchain

If the workspace has no projects with suitable toolchains, this is what it looks like:

I think there is more that could be done here and I invite some feedback on what I have provided here. I may be able to refactor further. I have saved by work to date as a draft PR #575

[ilg-ul]

I invite some feedback

I think it is a good starting point. 👍

As order, I would place the group with the default toolchain after the list of toolchains. This setting actually does not belong here, since the pages are named XXX Toolchains Paths. From this point of view, probably using separate tabs would be more appropriate, since the default toolchain is not related to the list at all.

As small cosmetics:

• the 'On macOS...' notice should be moved inside the list group, possibly after an empty line
• a more explicit text for the default toolchain group might be 'Select the default toolchain to be used when creating new projects'
• for most projects all build configurations use the same toolchain; for such projects displaying the project name is enough; for complex projects, with different toolchains for different build configurations, the build configuration name may be an useful information

[jonahgraham]

OK - I will apply the changes as you have suggested.

• for most projects all build configurations [...]

This is how the current code shows it (project scanner has three configurations Debug, Release and New Board Debug):

Toolchain used by the following projects: printer (All Configurations), scanner (Debug, Release)

Do you want this to be:

Toolchain used by the following projects: printer, scanner (Debug, Release)

or something else?

[jonahgraham]

@ilg-ul Here is what PR looks like with the updates you requested with the following changes:

• Default toolchain moved to the end of the UI, with new label.
• macOS hint moved inside the group
• configurations only listed if the project uses different toolchains for different configs.

As far as moving the default toolchain dropdown to a new tab, that will have to be deferred to another day/issue.

I'm going to assume the above is ok and I will work on the other 5 tabs that display the same info.

[jonahgraham]

The updated PR (coming soon) which applies the same change to both the RISC-V and ARM pages for Global, Workspace, and Project has this for the Project version which is limited to a single project.

All configs use same toolchain:

Multiple in use toolchains:

[fanghuaqi]

The updated PR (coming soon) which applies the same change to both the RISC-V and ARM pages for Global, Workspace, and Project has this for the Project version which is limited to a single project.

All configs use same toolchain:

Multiple in use toolchains:

It looks clear than before, in this screenshot the Global and Workspace are merged into one? So this settings will be saved in eclipse ide installation location or workspace settings? If saved in eclipse ide installation, if user don't have permission to write this eclipse ide installation location, how will it be handled?

And in the new look, will all the different workspace toolchain settings be displayed in this page, if the workspace contains many different toolchain path settings, will this page display them all?

Thanks

[jonahgraham]

The screenshots you quoted are for the project properties - this is the GUI you get when you right-click on a project and select properties.

However I see a glaring error here - the description text at the top is wrong (looks like a long ago copy and paste error or perhaps a behaviour change that never got updated in the description).

The top text currently reads:

eclipse-plugins/plugins/org.eclipse.embedcdt.managedbuild.cross.arm.ui/src/org/eclipse/embedcdt/internal/managedbuild/cross/arm/ui/messages.properties

Lines 67 to 72 in 8619bd2

	ProjectToolchainsPathsPropertiesPage_description=\
	Configure the location where various GNU Arm toolchains are installed. \
	The values are stored in the workspace (not in the project). \
	They are used for all build configurations of this project, \
	and override the workspace or global paths. \
	\n

It probably should read:

ProjectToolchainsPathsPropertiesPage_description=\
Configure the location where various GNU Arm toolchains \
used by this project are installed. \
Values entered here are stored in the project \
and override the workspace or global paths. \
\n

[jonahgraham]

It looks clear than before, in this screenshot the Global and Workspace are merged into one?

No - there continue to be three levels to store settings:

1. Global - i.e. in the Eclipse installation location - shown in screenshot https://user-images.githubusercontent.com/679236/248949120-1d9d4c59-b8bd-4599-8613-b1802a7bd07e.png
2. Workspace - no screenshot available right now
3. Project - shown in screenshot https://user-images.githubusercontent.com/679236/248967359-d4daf247-f9a3-45b2-a4c8-f41de694bf08.png

[fanghuaqi]

Ok, got it, thanks for your explaination.

Some questions list below:

For the global preference, is it used to set the default toolchain path for each toolchain? If yes, but according to the screenshot, it display settings used by different projects?

For the workspace preference, is it used to set the default toolchain path for each toolchain and overwrite the settings in global settings?

[fanghuaqi]

Thanks @jonahgraham , your explaination make me more clear now, especially this part, could you add some notices in the virtual group to let user know this design.

The current UI allows you to set the path used by the toolchain, but to keep the UI from being very big, only the toolchains in use in your workspace are displayed here.

And for this new UI look, as screenshot below:

If in the workspace, it contains many projects, eg. 20 or more, this red marked placed may display a very very long text, is there any prevention idea here to avoid long text displayed here.

Thanks

[jonahgraham]

I'll figure out what additional text I can add to address your comments.

As for long lists, the text does wrap so that should resolve that part of the issue. I can provide a screenshot of what that looks like tomorrow if helpful.

[ilg-ul]

If saved in eclipse ide installation, if user don't have permission to write this eclipse ide installation location, how will it be handled?

That's just another good reason why you should not install Eclipse in a system folder with administrative permissions.

Install it in your home folder; you'll have no problems with global preferences, and you'll also be able update it at your will.

Even more, if you are working on multiple projects requiring different sets of plug-ins, install multiple Eclipse instances, one for each project. This will allow you to update each Eclipse without possibly breaking other projects using different plug-ins.

[fanghuaqi]

Here are the screenshots to go with my latest update, key changes are adding/fixing some of the wording in description areas and I added links from project settings back to workspace/global settings.
[... redundant content removed. please do not reply by email to these messages... ]
See the above screenshots that show wrapping on the long project and config names.

@fanghuaqi - does that seem clearer now to users?

Hi @jonahgraham @ilg-ul , thanks for the great work to make this looks much clear.

[fanghuaqi]

Hi @ilg-ul , is there any timeline on this new release will be release? Thanks!

[ilg-ul]

... timeline on this new release ...

tentatively the end of the week, there are a few small issues to fix.

[fanghuaqi]

Thanks for the info

[jonahgraham]

@fanghuaqi perhaps you can try the CI build to make sure that the development branch works as you expect in your environment before the release. The develop branch is autobuilt and published to https://download.eclipse.org/embed-cdt/builds/develop/p2/

[fanghuaqi]

Hi @jonahgraham ， I tried to install the new plugins in windows 11 of eclispe cdt 2023.03, but it didn't change the look.

Thanks
Huaqi

[jonahgraham]

Sorry about that - turns out the the CI build was not running automatically. I have changed a config parameter and checked the build has run - try https://download.eclipse.org/embed-cdt/builds/develop/p2/ again please.

[fanghuaqi]

I tried it, it looks okay to me now.

[jonahgraham]

That's great to hear. Thanks @fanghuaqi