Skip to content

ui_set_text appends rather than sets #2

Description

@tristanmuzzu

On a freshly launched GNOME Text Editor with an empty document:

ui_set_text(app="gnome-text-editor", role="text", text="ONE")
ui_set_text(app="gnome-text-editor", role="text", text="TWO")
ui_read_text(app="gnome-text-editor", role="text")
  -> "ONETWO"

Expected "TWO". Each call inserts at the caret rather than replacing the widget contents.

The name says set, the README calls it "Preferred text entry. AT-SPI EditableText: no focus, no keyboard, and it reads the widget back to prove the write", and the skill calls it "the good one for typing". Nothing in any of those suggests the previous contents survive. A caller writing a form field twice, or retrying after a failure, silently doubles the value, and the read-back still passes because the text it wrote is present.

Two defensible behaviours, and either is better than the current one:

  1. Set means set. Clear the widget first via EditableText.delete_text, then insert. Matches the name and the docs.
  2. Keep appending but rename, to ui_insert_text, and add a replace: true argument. More work for callers, but honest.

I would take 1, with an append: true for anyone who wants the current behaviour.

Either way the docstring should say which it is, since a caller cannot tell from the outside without reading back and comparing.

Found while scripting a demo: writing progressively longer strings to build up a document produced every prefix concatenated instead.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions