[InputText, ReaderStyleTweak] add copy/paste to NT devices#14941
Conversation
| self.css_frame.onFocus = function(this) | ||
| this.bordersize = Size.border.thick | ||
| UIManager:setDirty(this, "ui") | ||
| end | ||
| self.css_frame.onUnfocus = function(this) | ||
| this.bordersize = Size.border.thin | ||
| UIManager:setDirty(this, "ui") | ||
| end |
There was a problem hiding this comment.
(When launched, it seems initially unfocused (thin border), but Enter gets "CSS test copied to clipboard" shown.
Also, thick/thin border change is not centered, but the frame grows/shrinks on the right.
Just mentionning that, if fixing it adds more kludge, don't fix it.)
There was a problem hiding this comment.
it does look like a drop shadow, I don't know how to centre it though... any ideas?
There was a problem hiding this comment.
I remember we have used focus_inner_border = true (a property of FrameContainer I think) in keyvaluepage.lua to solve a similar issue.
There was a problem hiding this comment.
I believe now is perfectly centred, have a look
| -- Tap inside CSS text copies it into clipboard (so it | ||
| -- can be pasted into the book-specific tweak editor) | ||
| -- (Add \n on both sides for easier pasting) | ||
| Device.input.setClipboardText("\n"..self.css_text.."\n") |
There was a problem hiding this comment.
The 2 first lines of comments should stay here.
The 3rd line should go into the function where we actually add these \n.
| if self.parent.onSwitchFocus then | ||
| self.parent:onSwitchFocus(self) | ||
| end | ||
| -- clipboard dialog |
There was a problem hiding this comment.
(I have verified there is zero difference in the body of this function before vs. after it has been moved.)
Still a bit sad to see it moved away from its neighbours who deal with related stuff (ie. _hold_handled).
But, can't you just have ?
elseif key["Press"] then
self:onHoldTextBox()I guess the answer is currently "no" , because all of these are set up only in a initTouchEvents().
Not sure why we have it done that way, and not just defined always whether we use them - like we do mostly everywhere else, no ? It's just the ges_events that gets setup if touchdevice, but the methods are usually always defined.
It fells akward to just externalize one of them :/ I would clean it all.
As the adage say: if it's not broken, don't fix it - if it's broken on NT, break everything else :)
There was a problem hiding this comment.
(I have verified there is zero difference in the body of this function before vs. after it has been moved.)
where you expecting it to change?
Not sure why we have it done that way
because you were selfish and wanted to keep it all to yourselves, those not challenged in the touch screen department.
It fells akward to just externalize one of them :/ I would clean it all.
the other ones are proceeding functions, this one on the other hand is just a menu declaration, I don't know.. be my guess I suppose.
As the adage say: if it's not broken, don't fix it - if it's broken on NT, break everything else :)
trueeee
There was a problem hiding this comment.
It fells akward to just externalize one of them :/ I would clean it all.
the other ones are proceeding functions, this one on the other hand is just a menu declaration, I don't know.. be my guess I suppose.
I'm not sure I understand.
I'm talking about these:
function InputText:onTapTextBox(arg, ges)
function InputText:onHoldTextBox(arg, ges) - the one you're somehov moving up in the module
function InputText:onSwipeTextBox(arg, ges)
function InputText:onFocus()
function InputText:onUnfocus()
Usually, in most other widgets, all these methods are defined no matter we use them or not depending on touch/key device. It's just the ges_events / key_events that are created or not depending on device capabilities.
Anyway, you moved InputText:holdTextBox a bit far away from its buddies, . It would make more sense to have it nearer (ie. just below InputText.initInputEvents()) if we move around just this one.
There was a problem hiding this comment.
whether those should or should not be defined there, is not my PR business, ;). Having it too close however means a big chunk of code history goes away as most of al gets attributed to me, is weird..
There was a problem hiding this comment.
The attribution should just impact these lines moved, wherever you moved them. Not the other lines in-between or above or below.
And yes, history/context for the section you moved is gone :/
There was a problem hiding this comment.
what I meant was, originally I was moving them to just the end of that init, and somehow it was rewriting all the history, even from lines I wasn't touching, to attribute them to me.
bf106f1 to
0a3a76e
Compare
| UIManager:show(clipboard_dialog) | ||
| end | ||
| self._hold_handled = true | ||
| self:holdTextBox(arg, ges) |
There was a problem hiding this comment.
You could add this comment:
-- Logic moved below as it is also used when not isTouchDevice
so we won't be wondering when in 5 years when all NT devices eventually get dead batteries, we decide to remove all this non-touch ugly legacy code :)
| if Device:hasDPad() then | ||
| self.css_frame.onPress = function() | ||
| local item = self:getFocusItem() | ||
| if item == self.css_frame and Device:hasClipboard() then | ||
| self:copyTextToClipboard(self.css_text) | ||
| return true | ||
| end | ||
| end | ||
| self.layout = {} |
There was a problem hiding this comment.
Can't the Device:hasClipboard() be put upper ?
:hasDPad() and :hasClipboard()
or
if Device:hasClipboard() then self.css_frame.onPress ?
what's new
Replaced
InputContainerwithFocusManagerinTweakInfoWidget, enabling better focus handling and D-pad navigation for the CSS tweak info widget (frontend/apps/reader/modules/readerstyletweak.lua).Added D-pad support and focus callbacks in the CSS tweak widget, so users can copy CSS text to clipboard using D-pad and receive visual feedback on focus state (
frontend/apps/reader/modules/readerstyletweak.lua).Refactored clipboard copy logic into a new
copyTextToClipboardmethod, used both for tap and D-pad press events, reducing code duplication (frontend/apps/reader/modules/readerstyletweak.lua).Moved clipboard dialog and selection logic from
onHoldTextBoxto a new reusableholdTextBoxmethod inInputText, simplifying event handling and enabling invocation from both touch and keyboard events (frontend/ui/widget/inputtext.lua).Enabled triggering the clipboard dialog via keyboard "Press" events, improving accessibility for keyboard users (
frontend/ui/widget/inputtext.lua).related issues
screen recording
expand to see
This change is