[Octave-bug-tracker] [bug #57635] Editor often has focus but no cursor until clicking elsewhere and then clicking in editor

[Hg200]

Follow-up Comment #36, bug #57635 (project octave):

Hello Torsten,

> Great, Hg200. I have played around a little bit on Linux and have not found
any changes in the behavior without the setFocusProxy.

By the looks of it, it seems to solve the problem on linux fedora. But i feel
uncomfortable. At least unless i understand a bit more what is happening. Some
questions / hints are:

- How should we deal with other setFocusProxy () statements? For example there
is another one in file_editor::handle_editor_state_changed. Shall we just
remove the one for m_edit_area?
- Why is octave_qscintilla::focusInEvent executed two times if the "patch" is
applied? For this please have a look at my test report attached to this
comment. It is test No. 2. Could be a tab_change and tab_remove reason?
- Off topic, but I would like to mention that this patch does not fix the bug
#57969. Is there really no relation ship between both bugs?

Options:

- I can spend a little more time on backtrace investigation. Who is triggering
the focusInEvent for what reason? But I will need help to some extent.
- I can't promise any success but i can step with gdb into the FocusProxy.

> Why do you think that setFocus has no effect? When I comment it out (line
954, togehter with setFocusProxy in 266) the focus is not transferred to the
edit area whenever the editor or a tab gets activated. Uncommenting
setFocusProxy seems to make it work again.

What I want to say is that the "Switching Tab-Test" can pass even though the
m_edit_area->setFocus statement is commented. This happens when the FocusProxy
is up. Commenting / uncommenting on m_edit_area->setFocus has no effect in
this particular scenario because the cursor is presumably restored by a
different caller. In the attached test report these are the tests #1 and #3.
But you are also right: Of course, it does not imply that
m_edit_area->setFocus is a useless statement. For example
m_edit_area->setFocus becomes a mandatory statement when the FocusProxy is
down (tests #2 and #4). So my wording was unfortunate. Sorry for the mess.

> Could you please test on WIndows whether removing setFocus and leaving
setFocusProxy also fixes the issue. Maybe calling setFocus on the focus proxy
is a problem.

I don't use windows nor do i have access to a windows computer. Maybe @Philip
Nienhuis can do that for us. He reported the problem on windows.




(file #48932)
    _______________________________________________________

Additional Item Attachment:

File name: focusInEvent-test_results_v1_2020_04_25.pdf Size:86 KB
   
<https://savannah.gnu.org/file/focusInEvent-test_results_v1_2020_04_25.pdf?file_id=48932>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57635>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/