Ask to open file#15024
Conversation
| table.insert(radio_buttons, genRadioButton(provider.provider)) | ||
| end | ||
| else | ||
| local provider = DocumentRegistry:getFallbackProvider() |
There was a problem hiding this comment.
Should that function be removed if you're just doing it here? (Or conversely, adapted to do what you're changing it to do here.)
There was a problem hiding this comment.
It is also used in DocumentRegistry:getProvider().
And the fallback provider is the first provider that supports txt:
koreader/frontend/document/documentregistry.lua
Lines 146 to 152 in 2c5dae9
I think it makes no sense, but it was added long ago for some reasons.
There was a problem hiding this comment.
By the way, DocumentRegistry:getProviders() doesn't use it and returns nil for unsupported files.
There was a problem hiding this comment.
I've just separated the method, not changing the idea.
| separator = true, | ||
| }, | ||
| { | ||
| text = _("Ask to open file"), |
There was a problem hiding this comment.
this sound a bit unnatural, "ask to open files" sounds proper or "ask before opening files"
I also feel this would go better with the "show... " boxes at the top
|
|
||
| if not no_dialog and G_reader_settings:isTrue("file_ask_to_open") then | ||
| UIManager:show(ConfirmBox:new{ | ||
| text = _("Open file?") .. "\n\n" .. BD.filename(file:match("([^/]+)$")), |
There was a problem hiding this comment.
this is also incredibly robotic and not a proper sentence, "Do you want to open this file?"
|
|
||
| if not no_dialog and G_reader_settings:isTrue("file_ask_to_open") then | ||
| UIManager:show(ConfirmBox:new{ | ||
| text = _("Open this file?") .. "\n\n" .. BD.filename(file:match("([^/]+)$")), |
There was a problem hiding this comment.
This is still not a proper sentence, but convincing you of that seems impossible
There was a problem hiding this comment.
Thank you for your recommendations.
There was a problem hiding this comment.
You might find it annoying, but there is a reason rules and semantics exist. People won’t have the code beside them to decipher what a particular setting does; it is your responsibility to present that information clearly and correctly. In this case, we have a yes/no question, so it should be constructed properly. You already spent time writing the code, spent an extra ten minutes making sure the one and only thing users have to understand you code makes sense.
There was a problem hiding this comment.
Iirc "delete/open this file" is the phrasing recommended both Google and Apple for this kind of purpose. (But Apple seems to have reorganized and rewritten theirs, so I can't find it anymore.)
Microsoft/Windows goes for the longer sentences instead.
We traditionally tend to go with the longer ones, but you can't disagree with Apple and Google that it's more verbose. :-)
There was a problem hiding this comment.
In this case, we have a yes/no question
Mind, we're explicitly against Yes/OK as the answer. ;-)
There was a problem hiding this comment.
The difference here is, this isn't a subitem in the long-press menu (where it would be acceptable), is a direct question in a confirm widget. "would you like to open this file" is a correct sentence, we are not short of space, we're not messaging our mate.
Mind, we're explicitly against Yes/OK as the answer. ;-)
Very funny, but you know that is not what i'm saying.
Closes FR: txt.zip/txtz improvements #14620
This change is