determining widget with current focus?

[jkn]

Hi all

    is there an easy way of determining where the focus is currently in Leo (body, tree, log...)?

I find the use of individual 'focus-to...' commands, and any shortcuts, to be a bit awkward. I would like to write a 'focus-cycle' type command, with an action a bit like the standard Alt-Tab, but within Leo. However looking at the code it seems that the current focus is not held in a simple way. I thought I'd ask here before delving deeper...

Thanks, J^n

[Thomas Passin]

Check out QApplication.focusWidget(). That could be a starting point. I doubt that Leo itself knows in most cases.

[Edward K. Ream]

On Wed, Aug 20, 2025 at 4:50 AM jkn <jkn...@nicorp.co.uk> wrote:

Hi all

    is there an easy way of determining where the focus is currently in Leo (body, tree, log...)?

c.get_focus() or g.app.gui.get_focus() return a widget w. You can then look at w.objectName().

Edward

[Edward K. Ream]

On Wed, Aug 20, 2025 at 8:23 AM Thomas Passin <tbp1...@gmail.com> wrote:

Check out QApplication.focusWidget(). That could be a starting point. I doubt that Leo itself knows in most cases.

Leo must be aware of the focus widget in all situations. Binding wouldn't work otherwise.

Edward

[Thomas Passin]

I thought that most of that was handled by the Qt machinery rather than by specific Leo code.  For example, when a user clicks in a text edit box, Qt puts the focus there and directs the input to the box.  Leo gets that input by means of its registered callbacks so it can handle those input events. That's all I meant. In many cases Leo can handle the registered events without learning about the focus because if the focus weren't on the widget, those handlers wouldn't be getting called.

I'm glad to know about those get_focus() methods. I don't think I've used them or even known about them.

[jkn]

Thanks Edward, that sounds very helpful.

    J

[Edward K. Ream]

On Wed, Aug 20, 2025 at 11:22 AM jkn <jkn...@nicorp.co.uk> wrote:

Thanks Edward, that sounds very helpful.

You're very welcome. Yours was an excellent question.

Edward

[jkn]

Heh...

AttributeError: 'LeoQtBody' object has no attribute 'objectName'

[jkn]

I see that 

    c.get_focus()

and

    g.app.gui.get_focus()

actually return different things...

[Thomas Passin]

On Wednesday, August 20, 2025 at 1:00:59 PM UTC-4 jkn wrote:

Heh...

AttributeError: 'LeoQtBody' object has no attribute 'objectName'

w.widget.objectName() 

[Edward K. Ream]

Thanks, Thomas.  Apparently w is a Wrapper object.

Edward

[jkn]

slightly teasing here:

AttributeError: 'LeoQTreeWidget' object has no attribute 'widget'

[Thomas Passin]

Then try for objectName() directly. The name  "LeoQTreeWidget" suggests that it's a actual widget, not a wrapped one.

BTW, the way I learned that LeoQtBody had a widget attribute was to run dir() on it. "widget" showed up at the end of the list.

[jkn]

Sure - I was just pointing out that the calls seem to return different things for different 'focus parts' of the system.

[Edward K. Ream]

On Thu, Aug 21, 2025 at 1:50 AM jkn <jkn...@nicorp.co.uk> wrote:

Sure - I was just pointing out that the calls seem to return different things for different 'focus parts' of the system.

Thanks to you and Thomas for your comments.

My responses were hasty and not too helpful. The only sure reference is the actual code :-)

The signature in question is:  class LeoQTreeWidget(QtWidgets.QTreeWidget):

So yes, a LeoQTreeWidget is a QTreeWidget. And (indirectly!) a QTreeWidget is a QWidget.

I'm not going to change the code. Devs should decide whether g.app.gui.get_focus or c.get_focus is appropriate.

Edward

[jkn]

Yes, it looks like some simple heuristic may be needed. And I am conscious that some plugins, that I may or may not be aware of, may add panes and complications.

Still, it's my own itch that I am scratching, for now anyway. Let's see what I come up with...

Thanks, J