Skip to content
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

Add profile resolution to global configuration (kdeglobals) #15

Open
FelixResch opened this issue Nov 21, 2019 · 6 comments
Open

Add profile resolution to global configuration (kdeglobals) #15

FelixResch opened this issue Nov 21, 2019 · 6 comments
Assignees

Comments

@FelixResch
Copy link
Collaborator

Should the profile for the kde globals be the same profile as for the other configuration? Or should we use a different one, maybe with a fallback option (if no globals profile is set, check if another profile is set, if so use this, else use the default profile)

@markus2330 what are your thoughts on this?

@FelixResch FelixResch self-assigned this Nov 21, 2019
@markus2330
Copy link
Contributor

What exactly do you mean with "profile"? Ideally we would treat everything with a simple ksLookup and do not handle any keys differently.

@FelixResch
Copy link
Collaborator Author

The keys are currently in the form /sw/org/kde/<app_name>/#<major_version>/<profile>/. For the kde globals I have used kdeglobals as app_name but currently always use "current" as profile.

The profile can be either set programmatically, by parameter --elektra-profile or by environment variable KCONFIG_APP_PROFILE. (I still need to document those, will do so tomorrow)

I am not using ksLookup because KConfig backends populate the key map on load and therefore I iterate over all keys.

As kde globals have a special meaning in KDE I wanted to ask, if we should make it possible to use different profiles for the applications and the global settings.

@markus2330
Copy link
Contributor

The profile can be either set programmatically, by parameter --elektra-profile or by environment variable KCONFIG_APP_PROFILE. (I still need to document those, will do so tomorrow)

Good, so this is something similar to what the profile plugin does: https://www.libelektra.org/plugins/profile

Please already start documenting this, so that we know which features are intended and how they work.

I am not using ksLookup because KConfig backends populate the key map on load and therefore I iterate over all keys.

You can and should also call ksLookup even if you iterate over all keys.

I just see that this is not explained in doc/tutorials/application-integration.md but it already says: "To make this work within your application make sure to always call ksLookup before using a value from Elektra."

As kde globals have a special meaning in KDE I wanted to ask, if we should make it possible to use different profiles for the applications and the global settings.

Yes, I agree that it makes sense. Just because someone switches the profile of an application does not mean someone wants to switch to different kde globals.

@FelixResch
Copy link
Collaborator Author

Please already start documenting this, so that we know which features are intended and how they work.

I added the documentation, should I create a separate PR for this branch?

You can and should also call ksLookup even if you iterate over all keys.

I am now using ksLookup on the keys.

@markus2330
Copy link
Contributor

I added the documentation, should I create a separate PR for this branch?

Yes, please separately. We should merge #13 or #15 as fast as possible, as it is now quite chaotic what is reviewed and what is from you.

I am now using ksLookup on the keys.

Thank you! Did you use cascading lookup (without namespace)? Did this change anything in the performance?

@FelixResch
Copy link
Collaborator Author

FelixResch commented Nov 24, 2019

Thank you! Did you use cascading lookup (without namespace)? Did this change anything in the performance?

Yes, I am using cascading namespaces. As far as I can tell, there is no noticeable change in performance.

edit: added space

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants