Rediscuss the "hidden" proposal from NXP #112

fred-r · 2022-03-29T15:28:58Z

coming from here:
#100
is not linked to generators.

To me the point with "visible" was to say that some components can be seen as "intermediate" components.

Some IDEs may decide to hide it, some IDEs may implement more advanced strategies.
But I think it may be worth having an attribute to say that a component is not absolutely mandatory for project representation to the end-user.
The criteria to define it would depend on the Pack provider.

A typical use-case to me would be this:
Application--requires-->Middleware--requires-->Wrapper--requires-->Driver

Then probably the Wrapper has no real added-value for the end-user (because maybe the wrapper is induced by the driver we select or there is only one wrapper available).
We may decide that it is not "mandatory" to show it (but mandatory to have it in cproject.yml).

The exact behavior would remain IDE dependent, it would only be an indication from the pack designer that this component is not a "meaningful" element in a project.

So the proposal is to provide an indication when describing a component telling if this component is a "meaningful" component for a project or if it is an "enabler" component that is always used "aggregated" with more important components.
We could even think about something like:

indicate the component can be "induced"
optionally, give the condition(s) inducing it

If the condition(s) list is empty then take "induced" into account (activated).
If the condition(s) list is not empty then take "induced" into account (activated) only if at least one condition is verified (this means the addition of the component has been "induced" by the selection of a more meaningful one)
To me this is different from "user selected" because maybe the user had to make a choice even for such a component (wrapper Ethernet or wrapper WiFi for instance?).

Of course some components must not have the '"induced" tag even if they match conditions.

But, the person designing the pack knows if a component can be "induced" or not.

If induced is present and activated, then at UI level you can decide that this component is not as important as the other ones.
Any strategy of your choice can be applied (hide for instance).

@tcsunhao: FYI.

fred-r · 2022-03-29T21:08:26Z

@mdortel-stm, @EmmanuelGrandin: what do you think ?

mdortel-stm · 2022-03-30T07:36:59Z

Hi @fred-r ,
If such attribute is aiming only at graphical behavior, I wonder if the standard should take care about it.
I don't see any semantic / processing consequences ...

fred-r · 2022-03-30T07:39:38Z

In fact the proposal is to say that rather than implementing a logic in the tool based on some heuristics, a pack designer can give an indication to the tool based on his knowledge of his components.
But maybe the approach is not good.

Basically I want something to tell the tool : if you need to "lighten" your UI, this component is less important than the others.
And I prefer providing a standardized info so that the decision making is similar in different tools, even if the rendering can differ.

fred-r · 2022-03-30T15:12:29Z

Point from Evgueni:

I've got a question here: what if each of Usb-device, usb-host and Usb-base have two or more implementations (Cvariant or CsubGroup). The user needs to select the desired ones then and maybe later change the selection. How it would be possible with "hidden" components?

In my opinion, this should be an IDE strategy.
In my opinion, as soon as a warning or choice is to be reproted then the component cannot be hidden any more.
When the point is solved the strategy (hide or something else) can be applied again.

edriouk · 2022-03-31T07:59:03Z

Then, as already mentioned, it is entirely IDE responsibility.

fred-r · 2022-03-31T08:01:02Z

Then, as already mentioned, it is entirely IDE responsibility.

Agree about the rendering but not about the decision making to decide if a component is important or not.
To me, the pack designer knows it better and should give an indication to the IDE.
That's why I make this proposal to update the spec based on NXP's request.

edriouk · 2022-03-31T08:38:47Z

What if a required component is located in another pack, such as CMSIS Core or CMSIS RTOS or a board-specific driver, who is then the pack designer?

fred-r · 2022-03-31T08:41:41Z

Let's take the example of an OS provider.
I may organize my pack like this:
OS API component => mandatory to be displayed
OS core component => mandatory to be displayed
OS porting components => not mandatory to be displayed

And the designer of an application pack using it could say:
My application => mandatory to be displayed
My OSAL API => mandatory to be displayed
My OSAL porting layer => not mandatory to be displayed

So the IDE may do
Application + OSAL API + OS API + OS core component

edriouk · 2022-03-31T09:57:30Z

Why porting layer is not mandatory to be displayed?

fred-r · 2022-03-31T10:02:40Z

Because it is only some "glue", it has no role in the project except porting an API on top of a specific implementation.
But again, it is only an "indication".
The IDE can display all components or he can find some rendering tricks to make it more readable for the end-user and let him focus on the components having the highest added-value.

jkrech · 2022-04-05T11:41:45Z

I suggest that we add a boolean component attribute named "hidden" to the specification to allow us to experiment with it.
I think we have an agreement that it is not mandatory for tools to take this attribute into considerations. The intention is that tools considering the attribute may not list the components by default but must allow users to "access them" in case user interactions require it (hidden component needs to be selected or unselected to resolve a dependency or condition).

fred-r · 2022-04-05T12:08:40Z

Agree with the approach but can't we find a better name than "hidden" ?
To me the rendering strategy is up to the IDE implementer.
I think we just want to say that the component is "induced" by another selection or "resulting" from another selection.
Maybe we may call it "adjunct" or "auxiliary" ?

jkrech · 2022-04-05T12:28:09Z

I want to make sure we are clear that there is no "functional implication" other than not listing/displaying the component, right.

mdortel-stm · 2022-04-05T12:39:01Z

At the origin, @ReinhardKeil did an interesting suggestion which mas focused on business logic and was the notion of "inherent" component (kind of synonym of induced here). Such component should be considered as selected as soon as another component using it is selected by the user.
The only problem is how to identify "who uses who", what is not possible to do with conditions.
To be clearer, it would request an inherent component lists the components using it.

fred-r · 2022-04-05T12:39:21Z

Ok, then maybe we could call it:
"composer_rendering" as an optional field with two values: mandatory/optional.
If the field is absent then mandatory is assumed.
If the field is present and rendering is set to optional then the IDE can decide his rendering strategy ?

ReinhardKeil · 2022-04-05T12:51:31Z

At the origin, @ReinhardKeil did an interesting suggestion which mas focused on business logic and was the notion of "inherent" component...
The only problem is how to identify "who uses who" ...

It requires the following:

the tool should record if a component is selected explicitly by the user or just indirectly via conditions.
if in a later iteration no condition exists that requests this component, the tool can deselected (provided that is has no explicit user selection.

fred-r · 2022-04-05T12:53:37Z

I think that a component can be "auxiliary" even if the selection comes from the user.

ReinhardKeil · 2022-04-05T12:54:33Z

I vote for:

implementing the "inherent" attribute (could be also named differently, i.e. "auxiliary", "hidden", "hide", etc.)
but leave it implementation defined (IDE specific) to actually use it. If not used the components should be shown
for IDEs that support it, it should be recorded if the component is explicitly selected

I think that a component can be "auxiliary" even if the selection comes from the user.
Yes, that is correct

fred-r · 2022-04-05T12:58:45Z

Yes, and we specify that this attribute is meant for rendering purpose only.

edriouk · 2022-04-05T13:00:36Z

Could someone tell me what to do in the following situation:

MyVendor.MayPack@1.0.0 describes a component MyClass.MyGroup@1.0.0 with "hidden=0"
MyVendor.MayPack@1.0.1 describes a component MyClass.MyGroup@1.0.1 with"hidden=1"
MyVendor.MayPack@1.0.2 describes a component MyClass.MyGroup@1.0.2, with "hidden=0"

RTE combines those components in a single aggregate to allow user to select its version
Which hidden flag should be used?

similar: a newer pack adds several Cvariant components with hidden="1", or even with different "hidden" flags.
What should RTE model do?

ReinhardKeil · 2022-04-05T13:13:02Z

If the "hidden" attribute conflicts (different settings), it would be considered as "hidden=0"

edriouk · 2022-04-05T13:20:15Z

Which means for Device.Startup components it is always "0" because already existing components would have hidden="0" by default.
Actually only very new components could utilize that flag

fred-r · 2022-04-05T13:34:56Z

If the "hidden" attribute conflicts (different settings), it would be considered as "hidden=0"

Unclear to me, for me:

if the project specifies nothing about pack and component versions, then the latest version should be considered
if the project specifies versions, then we apply the values from the selected version

Why conflicting here ?

edriouk · 2022-04-05T13:58:20Z

The conflict arises if you change either pack or component version (the latter you can't if component is hidden)

fred-r · 2022-04-05T14:10:41Z

Ok, I see.
So you have a project with Component version 1.0.1 and you want to move to 1.0.2.

In this case, the IDE must offer the possibility to have the "full" rendering or "minimal" rendering.
Same idea when conflicts are detected.

So I would expect IDEs to solve it like this, it is not a spec issue

fred-r · 2022-04-08T07:40:49Z

I still think that the "hidden" wording is too strong.
It makes a direct link to a rendering solution.
I would prefer something like "auxiliary".

Indeed the rendering startegy can then be very different from one IDE to another:

hide
present 2 tables : use-case components + auxiliary components
use italic for auxiliary components
...whatever...

To me, typical auxiliary components are for instance:

component: CMSIS:CORE
component: STMicroelectronics::Device:Startup

They are mandatory for the project to work but they are not part of the "use-case".

Then another category is more complex.
Let's take this example:

I use a UART driver with a DMA
Maybe I have 2 components: UART and DMA
But here DMA is only auxiliary, the function that matters is the UART
I use DMA alone
Here DMA is not auxiliary, it is at the heart of the use-case.

For this situation I see 3 options:

either we think that by combining the "auxiliary" attribute and the pdsc conditions the IDE can make decisions
or we think the auxiliary attribute may need its own "condition"
or we do not address it as it is too complex

DavidJurajdaNXP · 2022-04-12T15:24:05Z

SW component as used currently in NXP is just set of files typically compiled together, There is not any explicit information about provided API or other features. Some components contain common files, which are used by other components, but it is not expected to be selected directly by user during project creation.

Goal of "hidden" is UI simplification. Components which only contain common files, but does not represent useful application construction feature, could be hidden.

There is issue with multiple component vendors. What is "hidden" component for one vendor could be meaningful component for another.

Which components should not be hidden?
Components which carry some explicitly defined application feature (API, Layer...)

UI simplification could be achieved also via filtering by features (e.g. show only components with explicit API).

Tool could hide unclassified sets of files without explicit features.

In case #104 (comment)
intermediate and base component could be unclassified (without exposed explicit API).

Automatic addition of components should be allowed only after explicit user call of auto-resolver. User should be informed in case of ambiguity.

I think it might be better to use unclassified components (raw set of files) instead of "hidden".

UI simplification could be done via filtering based on categories (features) like:
solution
project
application_layer
API (class, group, sub, Capiversion)
set_of_components (pack?, middleware)
sw_component
source_file
c_function_name

User could decide what is desired level of abstraction (API, layers) for project construction instead of strict hidden true/false differentiation.

fred-r · 2022-08-25T20:45:14Z

Dear all,

please find below the proposal made during a meeting on Friday, August 12th with NXP and STM representatives.

Objective
Some components must not be presented at composition stage to avoid confusing the end-user.
Nevertheless, the end-user must still be able to define his own filtering choices to simplify the selected components view.

Approach
We think the CMSIS pack designer can give a "visibility" indication to the tool (via pdsc, for each component).
Proposal :

The Visibility attribute from the component definition applies unless the end-user defines another filtering criteria.
For instance, the end-user can decide that all components belonging to the Cclass=”Board Support” must be hidden.
In this case, the user’s choice takes precedence over the visibility criteria.

Proposed Specification Update
Attribute: Visibility (optional attribute)

Scope: This attribute defines the default behavior the tool should apply to decide if a component is shown or hidden at composition stage.

Applicability: Applicable but with a lower priority than the end-user’s choice. If the end-user defines a display criterion (for instance, filtering all Board Support components), then the end-user’s criteria takes precedence over this attribute.

Values:

Always (default) : this component must always be presented to the end-user. Overriden by end-user’s choice if any.
Typical components: any component implementing a mandatory logic (a driver, a middleware).
Never : this component must never be presented to the end-user, even when it is added to the project by dependency resolution. Overriden by end-user’s choice if any. Typical components: documentation, porting layer.

NOTE: To be defined : is it presented in the list of selectable components: I guess not, such a component can probably not be added manually ?

Maskable: tool’s choice based on current tool context. Overriden by end-user’s choice if any.
- this component is presented to the end-user in a list of selectable components
- this component is presented to the end-user in the list of components being part of the project, except when a “simplified UI” is entered (if the tool defines such UI mode).
- Typical components: porting layer, “glue”, mid-layer components not used directly by the user application
- Example: User application uses
  o component A providing service SA, relying on sub-components A1 and A2: A1 and A2 can be masked
  o component B providing service SB, relying on sub-component B1: B1 can be masked
  The simplified UI can show: User-Application view with A and B components only.

Example (user flow)

Component A, a Device component, has Visibility = Maskable
Component A is shown in the list of available components.
The end-user adds component A to his project.
The end-user enters a “simplified UI” view of the tool : component A becomes hidden.
The end-user applies a display filter of his choice : “show all Device class components”.
Component A becomes visible, even in the simplified UI view.

ReinhardKeil · 2022-08-29T10:57:29Z

I believe the attribute should influence the user flow a bit further:

Components with this attribute set:
- could be automatically selected if there are other components that require it (provided that they are unique). No user interaction required.
- could be automatically deselected if there is no other component that requires it. Again no user interaction required. If it is explicitly selected, the tool might issue an user notification that the component is no longer required.

If we agree, we should perhaps use the attribute name "auto" with optional tool behavior described above, plus the information that tools may have an option to hide components that are automatically selected.

fred-r · 2022-09-05T07:36:35Z

Hi @ReinhardKeil ,

I think we should not correlate too many needs.
The primary need under this ticket is the need to simplify the composition UI by "masking" some components.

Your point is more about how to improve the conditions resolutions so that:

the tool can automatically resolve conditions by selecting a component without user-interaction
the tool can automatically clean-up the composition by deselecting the components which are not required any more

In my opinion:

the visibility attribute must be specified because we need to agree on how a pack designer can let the tool know which components are maskable or not
the conditions resolution logic, and the automaton of some choices, is more an implementation choice : I would let it up to tools designers

@DavidJurajdaNXP @tcsunhao : what do you think about the requirement ?
@slhultgren : what do you think about the conditions resolution aspect ?

mdortel-stm · 2022-09-05T07:54:07Z

@fred-r
I'm more aligned with @jkrech point of view.
Talking about visibility means putting GUI consideration in a specification which did not intend to talk about that kind of topic, IMHO.
And the notion of resolution must be associated to that request because, if a component is not visible from the user, you must determine how it will be selected.
So, personally, I'd rather talk about "implicitly selected components" rather than "non visible components".

ReinhardKeil · 2022-09-05T08:05:28Z

Let's discuss tomorrow and drive this to conclusion. I agree with @mdortel-stm, and as such we should define the tool behavior for component resolution.

fred-r · 2022-09-06T07:27:55Z

I understand the point of view, but to me, the initial request is really about "simplifying the UI view for the end-user" and how a pack designer can provide information to the tool for this purpose.

I think the spec already takes care of some GUI considerations to a certain extent.
For instance, we can specify the "image" to be displayed for a board : this is only for GUI purpose I guess ?

Regarding the selection of components : the spec specifies conditions, so defines a way to express dependencies.
But, the spec says nothing about the resolution strategy in the tool.
To me, this concept of implicitly selecting/deselecting components is a tool's choice.
If we look at Keil uvision, we are offered 2 options:

the tool only highlights the dependencies issues
or the tool tries to solve the dependencies issues automatically (implicit selection but no implicit removal)

I think this freedom of behavior is part of the User Experience your tool wants to offer.
But I agree this can be discussed and anyway, initially the ticket is from our NXP colleagues, so let's see what they prefer.

mdortel-stm · 2022-09-06T09:51:49Z

@fred-r
Two remarks:

For instance, we can specify the "image" to be displayed for a board: the PDSC only provides the material ; the specification does not indicate how to use it.
The proposal has an impact on the way the components are selected, which was not necessary so far because the user always must do the job. So, for me, it is risky to let this new behavior to the responsibility of the tools.

tcsunhao · 2022-09-06T14:06:06Z

Let me put the original usage for hidden in NXP:

some documentation component which won't be used for project construction, hide it.
basic component that anyway will be selected, like usb.common. We just expose usb.device, usb.host, usb.otg. If usb.common is exposed, users need to click twice. Hide it, only one direct click.

mdortel-stm · 2022-09-06T15:32:00Z

@tcsunhao

I don't really get the purpose of a documentation component in the context of a PDSC : a component is meant to be copied in a project and to bring files to compile. Do you intend to copy the documentation in the generated project?

To react to your second point : basic component that anyway will be selected. So we talk first about automatic selection and not visibility of component.

fred-r · 2022-09-07T05:09:59Z

As discussed during the OpenCMSIS forum weekly:

We may keep this issue to implement the needs expressed by NXP (and this is an optional attribute)
We can use Best way to handle components selection/removal in a project devtools#466 (comment) to discuss the automatic management of components, which is a different topic.

Open-CMSIS-Pack issue Open-CMSIS-Pack#112 Some components may not be presented at composition stage to avoid confusing the end-user. Nevertheless, the end-user must still be able to define his own filtering choices. Hence, the visibility attribute is a hint/recommendation from the pack designer.

fred-r · 2022-09-09T15:33:59Z

see #153

ReinhardKeil · 2022-09-13T13:01:43Z

Added new attribute "view" (https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/pull/154/files)

If this is now OK, we need to reflect it in history and schema.

Adding optional 'view' attribute to component element, allowing the predefined values "always", "never", "maskable".

fred-r mentioned this issue Mar 30, 2022

CMSIS-Pack generator component concept - Proposal #104

Closed

ReinhardKeil added the In Discussion Discussion for this issue is open and ongoing label Apr 5, 2022

jkrech assigned fred-r May 24, 2022

jkrech assigned DavidJurajdaNXP May 24, 2022

jkrech unassigned DavidJurajdaNXP Aug 30, 2022

fred-r mentioned this issue Sep 9, 2022

feat: add visibility attribute at component level #153

Closed

jkrech linked a pull request Sep 13, 2022 that will close this issue

feat: add visibility attribute at component level #153

Closed

ReinhardKeil added a commit to ReinhardKeil/Open-CMSIS-Pack-Spec that referenced this issue Sep 13, 2022

* Adds 'view' attribute to <components> (Open-CMSIS-Pack#112)

a8d0cdc

ReinhardKeil added the Discussion Done Discussion for this issue has converged label Sep 13, 2022

jkrech linked a pull request Sep 20, 2022 that will close this issue

* Adds 'view' attribute to <components> (https://github.com/Open-CMSI… #154

Merged

jkrech closed this as completed in #154 Sep 22, 2022

jkrech added a commit that referenced this issue Sep 26, 2022

Schema changes for #112

05947f8

Adding optional 'view' attribute to component element, allowing the predefined values "always", "never", "maskable".

jkrech added a commit that referenced this issue Sep 26, 2022

Schema changes for #112 (#160)

cedf322

Adding optional 'view' attribute to component element, allowing the predefined values "always", "never", "maskable".

jkrech mentioned this issue Sep 26, 2022

Component should have attribute "invisible" #100

Closed

Rediscuss the "hidden" proposal from NXP #112

Rediscuss the "hidden" proposal from NXP #112

Comments

fred-r commented Mar 29, 2022 • edited

fred-r commented Mar 29, 2022 • edited

mdortel-stm commented Mar 30, 2022

fred-r commented Mar 30, 2022

fred-r commented Mar 30, 2022

edriouk commented Mar 31, 2022

fred-r commented Mar 31, 2022

edriouk commented Mar 31, 2022

fred-r commented Mar 31, 2022

edriouk commented Mar 31, 2022

fred-r commented Mar 31, 2022 • edited

jkrech commented Apr 5, 2022

fred-r commented Apr 5, 2022

jkrech commented Apr 5, 2022

mdortel-stm commented Apr 5, 2022

fred-r commented Apr 5, 2022 • edited

ReinhardKeil commented Apr 5, 2022

fred-r commented Apr 5, 2022

ReinhardKeil commented Apr 5, 2022

fred-r commented Apr 5, 2022

edriouk commented Apr 5, 2022 • edited

ReinhardKeil commented Apr 5, 2022

edriouk commented Apr 5, 2022 • edited

fred-r commented Apr 5, 2022 • edited

edriouk commented Apr 5, 2022

fred-r commented Apr 5, 2022

fred-r commented Apr 8, 2022 • edited

DavidJurajdaNXP commented Apr 12, 2022 • edited

fred-r commented Aug 25, 2022

ReinhardKeil commented Aug 29, 2022

fred-r commented Sep 5, 2022 • edited

mdortel-stm commented Sep 5, 2022

ReinhardKeil commented Sep 5, 2022

fred-r commented Sep 6, 2022

mdortel-stm commented Sep 6, 2022

tcsunhao commented Sep 6, 2022

mdortel-stm commented Sep 6, 2022

fred-r commented Sep 7, 2022

fred-r commented Sep 9, 2022

ReinhardKeil commented Sep 13, 2022 • edited

fred-r commented Mar 29, 2022 •

edited

fred-r commented Mar 29, 2022 •

edited

fred-r commented Mar 31, 2022 •

edited

fred-r commented Apr 5, 2022 •

edited

edriouk commented Apr 5, 2022 •

edited

edriouk commented Apr 5, 2022 •

edited

fred-r commented Apr 5, 2022 •

edited

fred-r commented Apr 8, 2022 •

edited

DavidJurajdaNXP commented Apr 12, 2022 •

edited

fred-r commented Sep 5, 2022 •

edited

ReinhardKeil commented Sep 13, 2022 •

edited