Can't do that, it's an ugly hack: ScrollHtmlWidget is generic and does not have to know about what happens in its users. Remember your principles (reaching across the dinner table and grabbing someone else's wine).
You'll have to find another idea.

On mobile right now, we can talk to our friends not to strangers though. I'm grabbing your wine, but that's fine because we're friends. Self.dialog is our friend too, the other idea would be to add Scroll class variable that DictQuick flips ... better?

Yes, even a method, ScrollHtmlWidget:enableScrollByTap(toggle) (or some other name/param).

Why "CloseWithButton", if it's only associated to closing with... keys ? :)

Back is a button, esc is a key. I suppose is a matter of preference at this point

A mysterious entity once used Key so I'd rather it be consistent. ;p
672be80

For most of us, a Button would be a ButtonWidget.

Maybe more specific naming than "inner" ? And plural if it returns 2 widgets :)
local scroll_widget, content_widget = self:_getScrollAndContentWidgets()

Maybe now that many stuff access these widgets (I remember some hw/tw by @NiLuJe ), we could have the changeDictionary method, that creates/swaps/reuses them, just set them as properties on self.
self.cur_scroll_widget, self.cur_content_widget ?

I guess this check and maybe some other convolutions can go once you have done it for TextWidget.

Some of these are there to stop text from crashing yes

You were always using the word "pages" in your description of this feature, which feels a bit odd to me. Not sure what a better word could be, "view" ?
(There is no occurence of the word "page" in DictQuickLookup (except for Wikipedia full page) and neither in TextWidget, haven't reread it if we have a common word for the slice of the... article/definition/...page :))

It's MuPDF the method is getPages or something like that

Can this happen ? When you do a 2nd seach while the results for a first search are still active?

You just perfectly described when it can happen ;)

Why this?
Looks like there is no other use of :lookupInputWord(), so why this wrapper?

To not sully what clearly is meant to be a declaration of a widget and nothing more. Besides, principle dictates event handlers trigger methods

That's not really how most handlers do. Most of them do the full work. We even call these self:onSomething() directly as methods of the object in the linear code. We even renamed them from :doSomething to :onDoSomething just because they may now be called as an action/event.
We can have these 2 names (and :onDoSomething calling :doSomething) when there are actually some work in :onDoSomething that are event-related, but have nothing to do in the :doSomething(), which may be called in other contexts than events.
Here, your split is gratuitous (it wasn't there before, it does nothing more, it is not required.)

but it is doing something extra

 if self.allow_key_text_selection and self.nt_text_selector_indicator then
        self:onStopTextSelectorIndicator(true)
    end

Extra to what? To what other use that doesn't need that extra?

(I won't fight on this one if you like it like that - but seeing it like this, I, or little Timmy when he'll be older, would go look for some other call site that would call lookupInputWord() directly - because it it has been splitted, there must be a reason and something that needed it without the need for onStopTextSelectorIndicator() - and find nothing, and wonder.)

the idea of the extra is simple, this mode and text selection are natural enemies, so we can't have both coexist at the same time. otherwise the shift+left/right won't work properly

Sorry to insist on this little thing.

scroll_widget:disableTapScrollText(false) : it's a bit hard to get that the double negative will actually enable taps.
No matter the initial state, you can just use a positive one:
scroll_widget:enableTapScrollText(true)
And scroll_widget:enableTapScrollText(false) will read easier that it does not enable it = it disables it.

Also, inside the function:
self._blocked_by_parent = force_block
Why mention it is blocked by parent ? In here, you don't know who is calling you.
Be simple and generic, don't assume the current use case is the single one (it might be your parent, tomorrow your cousing, next month your neighbour, next year me!), just use self.ignore_taps as initially.
tight coupling, don't listen to strangers

we should make it (for real men)

function ScrollHtmlWidget:is_not_un_un_enabled(isnt_not_un_disabled)
    -- If the parent provides a value, we store the inverse of the negation
    if isnt_not_un_disabled ~= nil then
        self.isnt_un_dis_ignored = not isnt_not_un_disabled
    end
    return not (not (not self.isnt_un_dis_ignored))
end

Nitpick: I would keep this just a setter and either add a simple getter or just use ignore_taps directly.

setter and getter does seem more appropriate

If you don't use your getter externally, it's not needed, just use ignore_taps directly.

please lets not play this game again, that is doing a full 360 to what I was doing originally (kind of)

I don't care for this one, but I'd like you to get that: we don't have to have getter and setter for the beauty (or kludgility) of it.
It's good when it's actually called from the outside, to not expose the internals - but it's useless for a class itself which can use its own internals (unless the check for the internal is complex and a function avoids code duplication).

Do you have any other comments?

Does this one exist on the scroll text widget ?
(Something tells me you have done the scroll/search on non-HTML dicts, and you forgot to push these changes ! :))

It will exist in textbox. Essentially all the stuff is ready on dictquick for both, but textbox won't be ready for this PR (as i already mentioned) so when it is ready it'll be a matter of removing the enabled_func and PR'ing the textbox side.

As for the current state of textbox... coming soon ;) it currently "works" but it is not ready

But currently, there is no ScrollTextWidget:setTapScrollEnabled.
I guess that on_clear_search can't currently be called when on a text dict.
But it feels dirty (even as an interim) to have references to stuff that doesn't exist.
I would comment it or leave it out (you'll anyway have to edit dictquicklookup when you'll implement search for text dicts.

(I also wouldn't merge this without its text dict search counterpart in a stable.)

That sounds a lot like coercion "do my bidding or else" ;)

okay let's look closer at what you are saying...

(I also wouldn't merge this without its text dict search counterpart in a stable.)

two options available to us here, option 1 this PR won't be merged until there is a second one with TextBox, or option 2, it can be merged but there won't be a stable release ever again until TextBox is merged.

of the two, only one is enforceable and realistic, so we are left with option 1 only, which begs the question, why comment anything out? also, I don't know how much longer it will take for TextBox to be ready, so will this sit here for months? (assuming it took months for it to be ready)

so what are you saying? because it does sound like coercion, a lot or extortion ;)

There's option 3: wait until after next stable (which is promised next week, since weeks :) I know) to merge this.
There's no hurry to have it merged, it doesn't fix any issue, it's a feature, next stable can be without it.

why comment anything out?

I would say the same if anybody introduced:
if False then UIManager:blowItOut() end
blowItOut doesn't exist, it's not because it's never called that we have to have it in the code.

But that still assumes that textbox will be ready before 2026.05 (or whatever) which i am not happy to guarantee, it will be ready when its ready, so we are back to option 1… i am happy to delay until after 2026.02 just not under thinly veiled threats ;), it goes live in 26.05 with or without textbox… agreed?

It's not a threat.
You bring a feature, half done because you just need it for your Oxford HTML dict.
And somehow promise you'll bring it for TEXT dicts (but without pressure because you don't need it).
Some kind of engagement that you will deliver for v2026.05 (with that pressure) would be welcome, and would somehow reassure me that I won't be the one that will have to finish it.

but without pressure because you don't need it

only, this isn’t true.

Is not half finished, is not my fault one has to double the work here, nowhere else this is the case (i might regret saying that)

You could have simply said, let’s delay till next release, and that would have been fine. Instead you went, well give me the other or else… see the difference?