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
Remove "Other Services" section from main settings page #1891
Conversation
Persistence services are now configure from the respective add-ons page. Signed-off-by: Jan N. Klug <github@klug.nrw>
Job #1018: Bundle Size — 15.77MiB (~-0.01%).Metrics (no changes)
Total size by type (2 changes)
|
I wonder how we should handle the settings for other addons, because those are also reachable from the addon page. The “problem” I see with removing them here, is that accessing them via the addon page are several clicks more. |
True, there are some more clicks. On the other hand it is far more consistent, since - as you mentioned - other add-ons are also configured from their add-on page. I think removing them from the right columns was also the result of the discussion in #1463 (e.g. #1463 (comment)). |
I meant that when persistence add-ons are removed from the "Other Services" section other add-ons are still there, however reading your linked post, I wonder if the other services section should be removed completely. Everything that can be configured there can be done through the add-on page. |
In general: yes. But for some reason it is currently not possible to configure e.g. basicui or javascript scripting from the add-ons page, I guess the config-description URI is probably not correctly set (confirmed: openhab/openhab-addons#14985) There are also other setting like the LSP that don't have an add-on page. |
It works with InfluxDB, and with the fix I just provided for JDBC. |
Fine ;) Even if I am a little off-topic, maybe you have an idea why it does not work for openhab cloud and voicerss ? |
I also checked DynamoDB, JPA and MongoDB and they work. RRD4J has no configuration. |
For openhabcloud it's due to the issue that was fixed today by @holgerfriedrich: the config-description-uri was wrong. For voicerss the service-id is wrong. |
@J-N-K What is the state here? |
I checked with success configuration access from add-on page for openHAB cloud, BasicUI, VoiceRSS and Vosk. |
IMO persistence services are fine, I did not check the others. |
I've checked IO (openHAB Cloud), UI (BasicUI), MISC (Metrics Service), automation (JS Scripting). |
@@ -201,7 +201,7 @@ export default { | |||
// can be done in parallel! | |||
servicesPromise.then((data) => { | |||
this.systemServices = data.filter(s => s.category === 'system') | |||
this.otherServices = data.filter(s => s.category !== 'system') | |||
this.otherServices = data.filter(s => s.category !== 'system' && s.category !== 'persistence') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I tested this to filter out all add-ons:
this.otherServices = data.filter(s => s.category !== 'system' && s.category !== 'persistence') | |
this.otherServices = data.filter(s => !['system', 'automation', 'bindings', 'io', 'persistence', 'transformations', 'ui', 'voice'].includes(s.category)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Problematic is the rule-based speech intepreter (
org.openhab.rulehli
) because is is provided by core and therefore no add-on, but has the categoryvoice
. Even though it belongs to voice, it should be changed tomisc
orsystem
because it is provided by openHAB core.
I agree. I also think that LSP should be system, because that is probably the only non-add-on service left.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we make an exception for LSP and the rule-based speech intepreter and keep them here in MainUI without breaking their settings in existing setups?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the rule-based speech intepreter could become an add-on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LSP and rule-based speech intepreter are the only non-add-on services left (AFAIK), for LSP I agree that it should be system
and for rule-bases sp...ter I would say either system
or misc
. These two options would make keep them visible in MainUI.
Rule-based sp..ter would be in the system settings section with system
or the only one in the Other Services section with misc
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the category will not break the settings. I'm just not sure if changing the translations works the way I have done it, see openhab/openhab-core#3625
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most important is to not loose settings in existing user setups.
Then showing them in system or other services is a detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the translations: The main properties file should work this way I think, but as translations shouldn’t be done through the files (IIRC) I guess they need to be uploaded to CrowdIn.
How do we proceed here? |
I haven't checked whether Rule HLI and LSP are now displayed under the "System Settings" tab, but if they now are I'd finally remove the "Other Services" section. |
@J-N-K Do you want to contribute in this PR? I could review and merge … |
Signed-off-by: Jan N. Klug <github@klug.nrw>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
Just to defend my original design, consider this: On an iPhone - and half of the openHAB userbase have iPhones if we look at analytics on the website, so it's not that we want to copycat its design, but it can help for users familiar with the design to figure out where things are - you have your App Store and you have your Settings app. Installed apps add entries to the Settings app, below the system options: The "Other Services" section was meant to be that, a section where individual add-ons could have their entries for (OSGi configurable) services they inject into the framework. |
I get you point, but it seems a bit awkward and hard to understand that you configure a persistence (or IO) add-on in one place (on the main setting page) and it's logging at another place (on the add-on page) while both settings are in the same place (the add-on page) for bindings. |
As an iPhone user myself I have already noticed the similarities your original design Yannick, however I agree that it is a bit confusing to have the settings split over a few places. |
I'm not really arguing, just explaining 🤗 . The removal of "Other Services" however offers an opportunity to adjust the Settings menu to keep it balanced when presented on two columns, as we could layout it like this:
|
Sound like a great idea! I have one comment:
I'd probably keep persistence out of the main settings and only have it under the add-on settings in the right column. Could you probably open a PR so we can have a look? |
Add-on service settings are configurable from the respective add-on's page and therefore the "Other Services" section of the main settings page is not needed anymore.
Services provided by openHAB core that were previously listed unter "Other Services" were moved to "System Services".