Closed ptweety closed 2 years ago
Sorry, but I cannot accept these changes, especially since they are mainly only related to code aesthetics. The reason being, that since RaspberryMatic is based on OCCU we have to be very careful what and how we have to patch things in OCCU since we are highly dependent on upstream, thus eQ3 providing further updates of OCCU.
This is the reason why we maintain all these WebUI patches separately and don't have a single WebUI patch for all changes. Simply because we have to keep patches as small, minor and non-invasive as possible! Thus, it is totally contraproductive if we introduce code patches simply because of code aesthetics or because we might prefer Unix line endings compared to windows line endings because this would introduce a large amount of merge conflicts if eQ3 comes up with some updates of these files themselves.
So sorry, but we cannot accept these changes. But what you van do is to provide/demonstrate your proposed changes as separate distinct units/changes and not as a replacement file. Preferably use a PullRequest for doing this or provide your proposed changes as patch/diff files where we can see which lines/things you change rather than just presenting the final file. And thus, even if we cannot take this file as granted, we might be able to extract some passages from your changes that are worth a second look.
i have had the same idea. At atleast to remove preprocessor artitfact like "$_(active)" with standard css variable notation for definitions like "--colormap-active:" an usage like "color: var(--colormap-active);".
@Jens : would you agree if ptweety provides a pull request with only these changes ? (the top two point of hios description)
Which purpose does the pure replacement from $_(active)
to var(--colormap-active)
serve? IMHO while these $_(active)
might be "old-school" and not modern, they work, right? And using those users can use their own color.map
file to override the standard colors with their own ones. So why should we change those and risk additional merge conflicts if eQ3 provides further style.css
updates? As said before: We are highly dependent on eQ3 as long as we use their WebUI code. If we would have a completely independent, new, reworked WebUI or if eQ3 would abadone the CCU completely we could do whatever we want, but as long as eQ3 provides further updates it IMHO would be wiser to keep the WebUI changes as minor as possible or possibly split them into very small pieces to prevent large merge conflicts.
Well Jens, I totally understand your pov. But honestly spoken a refactoring of the webui is not possible with such guardrails.
Hence I really don't have a good idea who to bring some more modern touches to the webui as long as we have to restrict ourselfs to only so much changes ahead of a slowly moving upstream.
Hence I really don't have a good idea who to bring some more modern touches to the webui as long as we have to restrict ourselfs to only so much changes ahead of a slowly moving upstream.
Well, as long as we have the eQ3 WebUI as a dependency - thus as long as we use upstream WebUI code - we are restricted to some boundaries, yes. But if you would come up with a complete new, independent UI based on a completely different Web framework (e.g. ReactJS, Bootstrap, etc.) we could of course work completely independent and without having to look at what upstream does (apart from new device integrations, etc.). But as long as we haven't started this side projects (which I actually really would love to do!) we are hence limited to keep our changes as compatible as possible to the codebase of the eQ3 WebUI and this includes keeping their tabs, their strange indentation, etc. which are only cosmetical.
Is your feature request related to a problem? Please describe. No real problem. Code aesthetics only.
Describe the solution you'd like
solution proposal Sorry for not creating a PR, but I was not able to find a proper place for this change