Re: How to help?
Posted: Mon Feb 12, 2018 12:53 pm
I didn't mean to do this all over the program, because I think this is already clearly separated in simple desk and function manager. But it can easily get mixed up while making new fixture definitions since all the channels involving dimmer or color have the "intensity" type. So I would propose to change this to a more clear separation, ie introducing a new channel type "dimmer" for example. Internally we can still handle it as an intensity channel but it will be more clear to the user.mcallegari wrote: ↑Sat Feb 10, 2018 12:14 pm - separate category for dimmer channels so they don't get confused with primary colors
This is an implementation nightmare. Adding/removing a channel type involves god knows how much effort all over the code
I see your point. The question is how to balance the disadvantage of maybe having a little more work on reviewing fixtures against the advantage of having some additional information about the fixture available (maybe a behavior QLC+ can't handle or even information about setting the correct mode on the fixture). Since you are the one reviewing the fixture definitions as last instance I don't have the right to do this weighing but I encourage you to at least consider it.mcallegari wrote: ↑Sat Feb 10, 2018 12:14 pm - add comment field (for e.g. fixture definition author's comments about the definition)
I disagree. I already received fixtures where smartass people try to advertise their website by adding a URL to the author field.
The more freedom they have, the more they will abuse of it. We must start from the fact that QLC+ users are not disciplined and don't follow the common sense rules.
The aliases could simply be added to the searched tags in the adding fixtures dialog so it would be displayed under the normal (first) manufacturer with a hint.mcallegari wrote: ↑Sat Feb 10, 2018 12:14 pm - add alias field (when the same definition applies to more fixtures)
I have no strong opinion about this, but the definition map works by manufacturer/model. I see it difficult to expose a definition for multiple instances of them.
In general, I like the idea of teaming up with OFL since they make some good points (especially in the mentioned issue report) and it would be a waste of time if both of the projects think about a rework and necessary capabilities simultaneously.