-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moved ControlType and ControlColor objects into class specific namesp… #308
base: master
Are you sure you want to change the base?
Conversation
…ace. This resolves a conflict with some other libraries that also use global definitions.
The open questions are: Is this OK |
Hm... so this creates a bit of a breaking changes, but I can see the defines are still there ? I like the idea of addressing the incompatibilities... and I think it is fair enough to go about them like so. I dont think we have any other libraries that have ESPUI as an upstream dependency (not like ArduinoJSON) so I am also less concerned... As for taking it further, any reason why the control array is public ? I assume nobody uses it in user code right ? Else I would guess it makes sense to go further, any other issues you have in mind here ? |
I have no idea why it is public. We have accessors to get a control by ID so I do not see a reason for it. The other major breaking change would be to modify the control structure so that its fields are all private. Then force people to use an accessor to modify the values. That will be a significant change to the applications that are taking shortcuts. As for the #defines, the names are pretty unique and the value is now class specific so the chances for a collision are smaller. If you really want to segregate the code, we could put the ESPUI code into its own name space and then access it with a "using" statement. |
Added upgrade instructions.
Just added upgrade instructions to the readme and bumped the version to 2.3.1 |
The ESPUI Verison ? I would rather do that when releasing, not on the merge, but I agree that this should be the next version number. Shall I release current master as 2.2.4 now to include your upgrades for ArduinoJSON or should we wait till this pr is merged ? (I think a release now makes sense) |
I would release it as it is. and then we add the breaking change. |
did release and updated PIO :-) |
Update the control management process one level up in OOO. ID and type are now protected by accessors and are now read only. The management of the list of controls has been gathered into a single file called ESPUIcontrolMgr. This is a singleton factory class responsible for creating, deleting and manipulating controls. This is about as far as I would want to take things at this time. There are more OOO design patterns that can be applied, but they would be onerous on the existing user base. |
…ace. This resolves a conflict with some other libraries that also use global definitions.