[Accepted] SDL 0159 - Static SDL Icon Names Enum #463
Comments
|
Thank you for your proposal. I was actually wanted to propose something about static icons a while ago but never made it through the potential downsides you mention.
This is true for Ford head units. The list of static icons is long. Not sure if the list is available somewhere... My question would be what would be included in
Not sure if I can follow. You're saying the app developer should still send |
There is currently a list of icons implemented by Ford. Livio is in the process of creating "generic" versions of these icons which will be implemented into the Generic HMI and available for all OEMs to use in their own head units if desired. This common set of icons is what would be named. It is true that not all icons may be implemented, but it's still better (in my opinion) to have the names available instead of the developer needing to hunt down a list and type in the hex values. In the future, all OEMs should implement all the icons, especially since there will be a free set of icons available. Even if they do not implement all of the icons, I still think this proposal is an improvement.
@NicoleYarroch Do you know what core will return if you attempt to use an unimplemented static icon? |
No one says it's a bad idea. I'm just saying there's no guarantee that the named static icons work. Using them would silently fail without a warning and the proposal doesn't cover this downside.
Would that be a requirement when integrating SDL core? What does that mean "a free set of icons"? Would Livio provide a set of image files? I think it makes sense to add a new system capability type for static icons. This way the app developer or a manager can read out what icons are available so trying to use icons that are not available wouldn't just fail without warning (because it's possible to figure out if an icon is available or not). <enum name="SystemCapabilityType">
:
<element name="STATIC_ICONS"/>
</enum>
<struct name="StaticIconsCapability">
<param name="availableStaticIcons" type="String" array="true"/>
</struct>
<struct name="SystemCapability">
:
<param name="staticIconsCapability" type="StaticIconCapability" mandatory="false"/>
</struct> |
Yes, as I said above, a full, free set of icons will be implemented into the Generic HMI and available for all OEMs to use in their own systems, unless they want to create their own icon set.
Perhaps, but this would be a much larger, separate proposal, and the need for it should be mitigated by the free icon set that will be provided. |
|
At least with a |
I guess what I was saying is that a developer cannot write code that detects the failure. The potential downside is not correct unless the developer has access to a head unit with unsupported icons. That's why I proposed to add system capability. I don't believe app developers would use static icons if they cannot be sure the static icon works throughout all the SDL head units on the road. There's no real benefit compared to DYNAMIC (except more effort using PutFile) if dynamic images must be used anyway as a fallback. If the SDLC agrees to a mandatory set of static icons the system capability wouldn't be necessary. |
I don't think relying on failed request to detect missing icons is a great experience - I'd prefer to have an idea what will display on an HMI before sending a request. I'm not familiar enough with core understand exactly what 'implemented into the Generic HMI' means, but if there's a chance some values will be missing I'd like to know which ones.
Agreed. I like the current proposal and don't see the enums couldn't be defined independently from the other work discussed.
Might the If it's not baking too much OEM-specific logic into the mobile libraries, it might be nice if under the hood this was computed client-side when connected to HMIs not supporting such an attribute. |
Probably not, the RAIR already contains too much information, and this would not be a small response.
To do this in the libraries would require dozens of requests to be sent out on every connection, which I think is unreasonable. I would also like to note that by the time that something like a In any case, this discussion is somewhat off-topic. It sounds like we're all in agreement that the proposal, as written, should be accepted. |
|
@joeljfischer Agreed, the discussion now seems like it should have its own proposal submitted on how to improve the static icon feature. Also, the static icon set was added to the Core Certification guidelines as a requirement if supporting images. As Joel has previously stated, Livio will be completing a sample set for all static icon values; these will be included in the generic_hmi project. Everyone in the SDLC Steering Committee should have received a copy of the guidelines to review and comment on. |
theresalech
changed the title
|
The Steering Committee agreed to accept this proposal. It was clarified that this proposal is specific to the existence of an enum in the proxies that matches the hex values in the list of agreed upon static icons, and that the list of required static icons will be finalized via the SDLC's review of the Core Certification Guidelines. |
Hello SDL community,
The review of "Static SDL Icon Names Enum" begins now and runs through April 24, 2018. The proposal is available here:
https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0159-Static-SDL-Icon-Names-Enum.md
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
#463
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:
Please state explicitly whether you believe that the proposal should be accepted into SDL.
More information about the SDL evolution process is available at
https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md
Thank you,
Theresa Lech
Program Manager - Livio
theresa@livio.io
The text was updated successfully, but these errors were encountered: