Weston text input bug?

[Joshua Watt]

All,

I've been working on implementing a text input client (via the
zwp_text_input_v1 protocol) using weston as a reference, and I've come
across some behavior that I do not understand related to the
show_input_panel and hide_input_panel methods. For example, look at the
following sequence of commands (from the clients perspective)

1. -> zwp_text_input_v1 at 25.show_input_panel()
2. -> zwp_text_input_v1 at 25.activate()         -- Panel is now visible
3. -> zwp_text_input_v1 at 25.hide_input_panel() -- Panel is now hidden
4. -> zwp_text_input_v1 at 25.show_input_panel() -- Panel is now visible
5. -> zwp_text_input_v1 at 25.hide_input_panel() -- No change

In this example, the last hide_input_panel call doesn't result in the
panel visibility changing. This can also be triggered with this shorter
sequence of events (assuming the panel starts off hidden):

1. -> zwp_text_input_v1 at 25.activate()        
3. -> zwp_text_input_v1 at 25.show_input_panel() -- Panel is now visible
2. -> zwp_text_input_v1 at 25.hide_input_panel() -- No change

In this example, once the input panel is shown, it can never be hidden.

I've read through the code in compositor/text-backend.c, and I believe
that the reason for this bug(?) is caused by improper tracking of the
current_panel in the text_input_manager object. Currently, the
implementation of hide_input_panel in weston checks that current_panel
is equal to the requesting text input (IHMO current_panel seems
inappropriately named), then hides the panel and sets current_panel to
NULL. The only way current_panel can be set to anything other than NULL
is during activate, which means that once the panel is hidden, it can
never be hidden again, although it can be shown (this is the behavior
in the first example). The second example is caused because activate
only sets current_panel if the text input is visible before it gets
called. This means that if the panel is not visible at activation time,
it can never be hidden once show, as seen in the second case.

I believe this bug is pretty easy to fix, and I have a patch I can
submit that I beleive fixes it, I just wanted to check and make sure
that I am not misunderstanding how the behavior is intended to work
before I try to change it.

Thanks,
Joshua Watt