-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
[Feature] Dynamic Config Provider #82
Conversation
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
@gilbsgilbs If you want to take a look at this PR, i have now switched a lot of remotes to the new dynamic way. Though there are a lot of missing features and rough edges, so it is not recommended to install it on an actual device. |
Ack. I'm very busy right now, but I'll try to take a look at a non-deterministic point in time. |
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.
IIUC, this adds support for "generic" providers, but at the moment, you cannot add them all from the UI. The list is limited to the providers declared in the provider_ids
array. However, they should still be usable thanks to the import feature, is that correct?
Overall I think it is a fantastic and very useful work. The implementation is rather concise and reads better than I anticipated. Here are some general remarks (I'm sure you're aware of most of them as this is still a WIP):
- I had a build error (related to
de
translations), but removing those values worked around it. Rebasing master and bringing back CI workflows should make that apparent. - As you said here, the amount of configuration per provider is indeed kind of overwhelming. I think this could be very much improved by putting "advanced" options in a separate tab or in a collapsible menu. But another PR for this is fine I think.
- As noted in a comment in your code, dark mode is not supported yet.
- The dropdown options are very small. It's easy to missclick if you have fat fingers.
Regarding translations, my experiments with deepl.com have been fairly impressive, and I've yet to find an completely incorrect translation. With some pre/post-processing, it could be a decent starting point before relying on the community. Their API free-tier allows 500k characters/month. There's currently ~130k characters to translate.
app/src/main/java/ca/pkay/rcloneexplorer/RemoteConfig/extensions/Hubic.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/ca/pkay/rcloneexplorer/RemoteConfig/ConfigExtension.kt
Outdated
Show resolved
Hide resolved
input.setPadding(padding) | ||
val items = ArrayList<String>() | ||
|
||
option.examples.forEach { example -> |
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.
It's smart to use examples for dropdowns, however, I'm unsure this covers all the cases. RClone still allows specifying arbitrary values for options with "Examples". For instance, s3
backend has many endpoint
options with examples, but may you roll out your own S3-compatible storage such as Minio, in which case you'll always want to specify a custom endpoint. Still, it's unclear to me if specifying arbitrary values for those is actually useful in practice ⬇️
"Examples" (resp. "Options") sometimes include a Provider
field, which defines a syntax allowing to restrain an example (resp. an option) to a specific set of providers. Let's take the same s3/Minio/endpoint as an example:
- The backend is
s3
- This backend has a
provider
option, withMinio
as one of the examples, therefore the dropdown for this option will includeMinio
(this is already implemented by this PR) - Then there are multiple
endpoint
options declared by RClone:- one with
"Provider": "AWS"
with specificendpoint
s examples for AWS - one with
"Provider": "ChinaMobile"
with specificendpoint
s examples for ChinaMobile - … so on with other providers …
- one with
"Provider": "!AWS,IBMCOS,…,ChinaMobile,…"
(i.e. not any providers that was previously defined), which doesn't provide any example
- one with
So with our Minio example, we're in the latter case. If "providers filtering" was implemented, it would just display a text field and not a dropdown in this case, because the only endpoint
option that matches our Minio
provider has no examples. So it would be fine. If I'm not mistaken, with the current implementation, it will just display many endpoint
dropdowns and one endpoint
text input, and I'm not sure what's the behavior when passing this to RClone.
All in all, there might be niche use-cases where specifying arbitrary values for options with examples might be useful (such as using a new S3 region/endpoint for a given provider that is not implemented in RClone yet). But IDK, it might just not be worth thinking about it for the moment. However, I do reckon providers filtering should be implemented at some point.
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.
This is exactly the kind of stuff where i wil slip with this, because i cannot extensively test every remote.
Thanks for the writeup, i will have to read this thoroughly to make this work properly, especially to prevent weird behaviour with rclone
Log.e("TAG", " Opt: ${it.name}") | ||
Log.e("TAG", " Opt: ${it.type}") | ||
when (it.type) { | ||
"string" -> { |
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.
So, just for the sake of completeness, here are the types where the UI could be improved by using dedicated components:
bool
, which should be a checkbox (there's also oneboolean
type, but I think it's a bug in RClone)int
, which could include some type validationSizeSuffix
, which could be implemented by specifying a textbox + a "scale" dropdown, and validating that an integer was typed in the textboxDuration/Time
, ditto or, optionally, a clockRFC 3339
, with a clock+calendar popupMultiEncoder
, which could be a multi-select box (but this one is probably niche-enough that we shouldn't bother)SpaceSepList
, which could be multiple text-fields with ➕ and 🚮 icons (also kinda niche)Time/unixtime/decimal number/Tristate/hexadecimal/octal, unix style/filename
not widely used
But that's probably fine as this in a first implementation.
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.
there is some wild stuff in there :D I guess i start with the obvious ones, bool and string are implemented, and i most certainly will implement int aswell. The other-ones will probably have to default to text input, the user has to figure out what input needs to be made :D
app/src/main/java/ca/pkay/rcloneexplorer/RemoteConfig/RemoteConfig.java
Outdated
Show resolved
Hide resolved
app/src/main/java/ca/pkay/rcloneexplorer/RemoteConfig/RemoteConfig.java
Outdated
Show resolved
Hide resolved
Yes. At the moment those are hardcoded, but in the future i want to try to get rid of that aswell, so that everything is "dynamic".
Good idea!
I am a bit on the fence with this idea. Generally i want to refrain from implementing a solution specific to this app, and i also would need to figure out if i am even allowed to use it. (I might want to monetize this app on the play store, so i need to be careful.) My dream-goal would be for the rclone project to implement translations natively, and then we dont have to deal with that twice. I already opened a ticket for that, but i am afraid that will take quite a while. But generally speaking, translations in this app are going to be complicated to pull off properly. |
So let me say thank you! I did not expect such an in depth review, and i am glad you are looking at it! There is lots of great suggestions and i will implement much of it, so that this will make this app easier to maintain and use in the future. |
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
# Conflicts: # app/src/main/res/layout/config_form_template_text_field.xml # app/src/main/res/layout/config_form_union.xml # app/src/main/res/layout/remote_config_form.xml # app/src/main/res/values-de/strings.xml # app/src/main/res/values/arrays.xml # app/src/main/res/values/strings.xml
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Signed-off-by: Felix Nüsse <[email protected]>
Good news! The dynamic config editor will allow rudimentary editing of remotes! Though i will need to test this thouroughly, especially if values are secret. They break if not reentered at the moment. |
Signed-off-by: Felix Nüsse <[email protected]>
# Conflicts: # app/src/main/res/values/strings.xml
closes #63
closes #86
closes #101