Hi, sorry for pushing this...

Is there any progress on this? I would to love to make some progress on a pending Gio application that is blocked by this ticket: https://github.com/changkun/occamy/pull/51

I think the hotkey register is an example of demonstrating why running on mainthread is necessary for developers. Indeed, an NSObject method permits developers on darwin to run any function on mainthread. Still, the benefits of Gio providing an API for it would be, such execution can be managed from Gio. Similar to the previously mentioned app.(*Window).Run.

Another example would be that Android might also be a platform that developers would like to access mainthread. One more example would be that developers who wrap C code that need mainthread on whatever platform will also be benefit from such an API.

1. When it collaborates with Gio, it is impossible to run on the main thread automatically because Gio occupies it.
2. Even the register is called on the main thread before the Gio app.Main() starts, a user may still wish to dynamically register/unregister the hotkeys at runtime. At this point, it is already impossible to do as runOnMain is not exposed to the public.

The main difference between app.(*Window).Run and app.CallOnMainThread is that: app.(*Window).Run only calls the given f on a customized event loop rather than the OS main event loop, whereas the app.CallOnMainThread communicates to the main event loop, occupied and running internally in by [NSApp run].

The above hotkey example does not work when using app.(*Window).Run.

Running a function on the main thread is impossible and occupied by Gio internally. The reason is that some OS or graphical APIs require to be executed on the main thread.

This fundamentally limits developers to extend unimplemented Gio applications, such as registering a hotkey.

It would be beneficial if "app" package can provide a public API to execute functions on the main thread, the API signature can be:

package app

func CallOnMainThread(f func())

The name can be "RunOnMainThread" or other preferred names.

For a specific example, the package "https://pkg.go.dev/golang.design/x/hotkey@v0.3.0-alpha" collaborates with Gio, which is an unimplemented feature.

Here is a proof-of-concept change that exposes runOnMain: https://github.com/changkun/gio/commit/976e5ed303a0ee2fa192c5a686e3b31fc1e8163a

Here is a complete example that benefits the public version of runOnMain: https://github.com/changkun/demos/blob/main/hotkeys/gioapp/main.go

Any thoughts?

Thanks for the response. Sure, that sounds like a nicer solution. Name may use Symbol, KeyCode, or others that is typed as an integer.

More specifically, for examples:

https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_macos.go#L341 https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_windows.go#L216 https://git.sr.ht/~eliasnaur/gio/tree/main/item/app/os_x11.go#L502

The original key code provided by the system is converted internally through functions like convertKey, DispatchKey, etc. This seems not possible to reverse this process from the userland. Especially when the keyboard is not in US layout.

The reason I am concerning the need for original key code was that I am writing a program to communicate via a so-called guacamole protocol[1] where the original key code must be provided hence requiring reversing from Name string to Keycode integer.

[1] https://guacamole.apache.org/doc/gug/protocol-reference.html#key-instruction

Hi, I wonder how to access the raw platform key symbols quickly.

So far, the key events are described in key.Event, they are represented in a combination of the triggered modifier as well as the name of a key as a string. Yet seems not easy to convert the key symbol of, for instance, a delete key.

Moreover, it is also not entirely clear (from documentation) how to trigger modifier key events individually. Say if a control key is pressed, we will not receive a key.Event from Events() unless we press a non-modifier key.

Any ideas on how to overcome this shortcoming beyond creating a self-maintaining key mapping table?

Sadly nothing is safely cached. The .eml file gets deleted when the client exits. The email sends action failed because of a broken pipe. Wasted all words and have to write the email again.

It is a good software but not yet reliable to use.