Gtk.EditableLabel - What is the intended usecase? Can you listen to changes to `edited` and `Enter/Esc` keypresses while it is in focus?

[PhilMD]

Heyho everybody!
I’m contributing to a library in the nim programming language that wraps gtk and provides the widgets etc. in a more declarative fashion.

I am currently wrapping the EditableLabel widget and I’m noticing things that make me feel like I’m missing something. Particularly as I only have beginner knowledge of gtk as well as native GUI development generally.

For context, the library generally works by having a struct (well, in nim those are called “objects”, but there’s no methods attached by default) with basically the same properties as the gtk-widget. If the nim-program updates the state, it syncs those changes to the gtk-widget via the widget’s setters. If the gtk-widget gets updated via e.g. user interaction, it syncs those changes back to its own state by listening to signals accordingly.

With EditableLabel my approach causes me some problems:

1. When you edit an EditableLabel, that implicitly changes its edited state to true, when you move focus away from it that changes its edited state to false. From what I can see though, there is no signal for that, so I can’t sync those state changes back to my own struct. Is my understanding there so far correct? If so, are there any signals I’m not yet aware of that I could still listen to to catch those changes?

2. EditableLabel does not seem to have an activate signal (unlike e.g. SearchEntry) or an equivalent to a stopSearch signal (which SearchEntry has) . That means when you hit enter while an EditableLabel is in focus, no signal (that I’m aware of) fires, same for pressing Esc. The behaviour I wanted to implement originally, was that if you hit enter, I call gtk_editable_label_stop_editing with commit = true, if you hit Esc I call gtk_editable_label_stop_editing with commit = false and in both cases I set editing = false. Are there ways for me to even notice those keypresses when they’re from editing an EditableLabel?

Particularly issue 2 makes me think I’m misunderstanding the intended usecase for EditableLabel (?).

I thought it was kinda like a lot of the fields on a BitBucket webpage: It looks like uneditable text but is actually sort of “Hiding” a form. If you want to edit it, you can click into it, modify it, press enter and bam, updated the field and it looks as “uneditable” as before, no “visuals” of a form on the page. Thus I wanted to wrap it that way.
Is that perhaps the wrong idea and it should be used in a different manner?

[ebassi (Emmanuele Bassi)]

@PhilMD

When you edit an EditableLabel, that implicitly changes its edited state to true, when you move focus away from it that changes its edited state to false. From what I can see though, there is no signal for that, so I can’t sync those state changes back to my own struct

You use notify::editing to get a notification when the EditableLabel widget changes state. Every readable GObject property emits the “notify” signal when the value changes.

@PhilMD

EditableLabel does not seem to have an activate signal (unlike e.g. SearchEntry) or an equivalent to a stopSearch signal (which SearchEntry has) . That means when you hit enter while an EditableLabel is in focus, no signal (that I’m aware of) fires, same for pressing Esc. The behaviour I wanted to implement originally, was that if you hit enter, I call gtk_editable_label_stop_editing with commit = true, if you hit Esc I call gtk_editable_label_stop_editing with commit = false and in both cases I set editing = false. Are there ways for me to even notice those keypresses when they’re from editing an EditableLabel?

I have no idea why you want to do this: the EditableLabel is already handling Enter and Esc on its own. You cannot override that.

You should use notification in the “editing” property to know when the label is being edited or not; and you use any other property on the Editable interface (which EditableLabel implements) for content-related state changes.

[PhilMD]

The notify signal did it! Thanks for pointing it out!

As for why I wanted the entire keypress thing: That was more an automatism on my end, a lot of widgets in the lib I’m contributing work that way for widgets where behaviour such as this is not handled for you, so I just didn’t think about it. That was incorrect on my end, thanks for pointing that out as well.