This should already be handled via the call to the super class's init (i.e., InputDialog.init(self)), which handles the false branch, coupled with the fact that the (super) class default is true.

I believe that onCloseKeyboard and closeWidget kills the tracking because, any further attempt to call self.keyboard_visible is always nil true

disregard the previous comment. however self.keyboard_visible is true even when it shouldn't

    logger.dbg("MultiInputDialog:", self.keyboard_visible, "1")
    -- init title and buttons in base class
    InputDialog.init(self)
    logger.dbg("MultiInputDialog:", self.keyboard_visible, "2")
    -- Kick InputDialog's own field out of the layout, we're not using it
    table.remove(self.layout, 1)
    logger.dbg("MultiInputDialog:", self.keyboard_visible, "3")
    -- Also murder said input field *and* its VK, or we get two of them and shit gets hilariously broken real fast...
    self:onCloseKeyboard()
    logger.dbg("MultiInputDialog:", self.keyboard_visible, "4")
    self._input_widget:onCloseWidget()
    logger.dbg("MultiInputDialog:", self.keyboard_visible, "5")

    -- Initialize keyboard_visible
    -- if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:isFalse("virtual_keyboard_enabled") then
    --     self.keyboard_visible = false
    -- else
    --     self.keyboard_visible = true
    -- end
    logger.dbg("MultiInputDialog:", self.keyboard_visible, "6")

12/28/24-22:33:56 DEBUG MultiInputDialog: true 1 
12/28/24-22:33:57 DEBUG MultiInputDialog: false 2 
12/28/24-22:33:57 DEBUG MultiInputDialog: false 3 
12/28/24-22:33:57 DEBUG MultiInputDialog: true 4 
12/28/24-22:33:57 DEBUG MultiInputDialog: true 5 
12/28/24-22:33:57 DEBUG MultiInputDialog: true 6 

or should we do this instead?

function InputDialog:onCloseKeyboard()
    self._input_widget:onCloseKeyboard()
    if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:isFalse("virtual_keyboard_enabled") then
        return
    end
    self.keyboard_visible = self._input_widget:isKeyboardVisible()
end

Hmm. Probably less mysterious with the duplication you went with, as it sort of matches the super class.

I would definitely add a comment about this being needed because InputDialog:onCloseKeyboard updates InputDialog:onCloseKeyboard though ;).

Huh. that's... interesting. Absolutely no time to check, but might be an artifact from being in init on all sides still.

Had a Eureka moment on the toilet. #12994

Had a Eureka moment on the toilet. #12994

I hope you only had one eureka moment there, and if you had more than one, please don’t share number 2. ;)

In binary that'd be equal volume number 10.

I'll see myself out.

Defecation joke tally: No. 2

Oops. No. 3 now...

Can you find out why so? Maybe it should be fixed somewhere?

That's what I meant by #12951 (comment)

InputDialog:onCloseKeyoard does what it says on the tin: it closes the VK, which means it's no longer visible, so it forcibly always sets the visibility flag to false.

Modifying its behavior just to fix this very specific interaction seems like it could lead to more unintended consequences than just dealing with it this way here.

InputDialog:onCloseKeyoard does what it says on the tin: it closes the KB, which means it's no longer visible, so it forcibly always sets the visibility flag to false.

Well, technically, to self._input_widget:isKeyboardVisible(), which should pretty much always lead to a false after InputText:onCloseKeyboard() ;).