"Find symbol" dialog no longer grabs focus, resulting in undesirable pasting

[John H.]

For 10 or 15 years, I've been opening the "Find symbol" dialog box, then control-V pasting into it. Now that's broken: the pasted text goes into the live document, instead of the dialog box.

This is with the current v25 beta 2.

[Dennis]

Not able to replicate this problem, but perhaps my config is slightly different.

What command are you using to active the Find Symbol dialog? (normally activate_find_symbol)

When it comes up, do you have it floating, docked, or auto-hidden?

What platform are you on?

[John H.]

I have a keyboard shortcut (F8) tied to activate-find-symbol, so I use F8.
When it comes up, it is as a floating window.
This is on Arch Linux, with a KDE window manager. Updated: details: on Arch, KDE is achieved via the "plasma" package group: https://wiki.archlinux.org/index.php/KDE .

[John H.]

Update: I changed various KDE Window behavior settings, including "revert to defaults", to no avail. The focus fails to switch to the new dialog *every time* for me. I hope someone can reproduce this. It feels like a Qt + KDE problem, maybe with some Slickedit specifics, for what it's worth.

[John H.]

OK, now this is interesting: Slickedit v24 does *not* have this problem. However, there's some details that matter: in both v24 and v25, the Find Symbols window (and, for comparison, others as well, such as activate-files-project) does not show as having the focus: the title bar remains without the "active" color. However, in v24 the windows still manages to capture keyboard input, whereas in v25, it does not capture keyboard input, until I click on the click to make it active.

Fixing either thing (the window really should pick up the focus, upon activation, and the keyboard input needs to be captured, upon activation) should solve this. What I mean is, getting the focus should normally cause the keyboard input to be captured, unless you've got special case code for keyboard input here. Anyway, I am just theorizing in ignorance of the actual implementation, of course.

[John H.]

Just want to add that, although this might sound like an obscure problem, it has a large effect on me. Because I'm using SlickEdit to navigate large projects, and being able to jump to symbols or files is fundamental to that. If the keyboard shortcuts are broken and unfixable as they are now, then I have to pause, use the mouse, resume typing, and probably remember to undo any accidental typing that landed into the document when it should have gone into the "find" window. This is a big deal.

For now, I'll revert back to the production v24 version, and I'm really hoping that you put this on the fix list for v25 before launching it. I'll continue to be here to answer questions and try experiments, though.

[Dennis]

Have you tried docking (or docking and auto-hiding) Find Symbol as a workaround, do you still get the focus problem then? 

It could help, because the window manager won't see it as a different window.

[John H.]

Docking the window does work around the problem! And with the "unpin" clicked, it goes away right after it's done finding something, so that works pretty well. Good workaround, thanks.