Gtk app on MS surface pro running windows

I am trying to build a gtk4 app that will run correctly under MS Windows on an MS surface/pro.
One attribute of running “correctly” is that the virtual keyboard automatically appears when the focus is set to a text box in the app. I can build apps that do run for this platform but the virtual keyboard does not automatically appear.

Unfortunately, I’m not knowledgeable enough about either Windows programming or gtk to know if there is any way I can change the app. Does anyone have any experience with this issue or know what I can experiment with?


Good question! I don’t know how it’s done, probably via UI Automation or Text Services Framework.

EDIT: found an interesting link, Touch keyboard is not displayed properly on Windows · Issue #10136 · AvaloniaUI/Avalonia · GitHub

Yes, the UI Automation patterns need to be implemented for any text input widgets: Respond to the presence of the touch keyboard - Windows apps | Microsoft Learn

This is not currently implemented in GTK, I started doing this work but I ran out of resources to finish it, it’s possible though unlikely I may be able to resume it later.

1 Like

Awesome! Could you share some code? I’d like to pick up from your implementation in the future :slightly_smiling_face:

Thanks for the information and the link!

Yes, here is the branch I was working in: Files · uia-atcontext-wip · Jason Francis / gtk · GitLab

The implementation for text widgets is stubbed so it doesn’t do anything currently, it should be possible to make the virtual keyboard work by implementing a few methods and then from there filling out the rest to get other ATs to work.

Also, this one should probably be done first before going further: Add GtkAccessibleText interface for text widgets (#5912) · Issues · GNOME / gtk · GitLab. And to do that someone really needs to go through and document how it compares to AT-SPI, maybe even keep a list of things that might need to be added to AT-SPI if there is a problem with some other text widgets or if there are major differences to how the code can work on Windows.

1 Like

We don’t really use the accessibility API for on-screen keyboards anywhere: OSKs are implemented via input methods. Even if the appropriate API for OSKs on Windows is UIAutomation, we shouldn’t have to go through the GtkAccessible and GtkATContext API for it, and we can keep it isolated inside an input method object that is already attached to every text entry.

I’m currently working on GtkAccessibleText, and I’ve taken inspiration on UIAutomation’s text control interface, so ideally the impedance mismatch is going to be small enough.

Sure, but I suspect the code will want to get merged with the ATContext code eventually, because it implements the same COM interfaces.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.