Refactoring language management for simplicity #130
Conversation
|
Additionally, I'd like to release after this lands - this was an issue I encountered while testing the new API for a 0.3 release |
| /// # Note | ||
| /// Up to 16 languages may be provided. | ||
| pub fn strings(mut self, descriptors: &[StringDescriptors<'a>]) -> Result<Self, BuilderError> { | ||
| // The 16 language limit comes from the size of the buffer used to provide the list of |
There was a problem hiding this comment.
Super-minor nit/question: does the size of that buffer (this one?) have documentation that explains this consequence? Does the limit originate in the USB spec?
There was a problem hiding this comment.
I actually don't think language IDs are even in the specification anymore, so there's not really anything limiting more than 16 languages. It's from USB 1.0 from what I can tell and has largely been deprecated (not sure in favor of what). Even finding the list of lang IDs is hard nowadays. It makes me wonder if we should even support multiple langs, but I guess it makes sense for legacy systems?
This PR builds on #122 by unifying strings under a single
StringDescriptorsstructure to keep things organized a little differently. This eases usage on the end-user, as previously the borrowed slices had to be&'staticborrows, which complicated the construction when i.e. a serial number was read from EEPROM or some other source.