~changkun

Munich

https://changkun.de


#319 key: providing key symbols 7 months ago

Comment by ~changkun on ~eliasnaur/gio

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

#332 Expose runOnMain as public API 11 months ago

Comment by ~changkun on ~eliasnaur/gio

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.

#332 Expose runOnMain as public API 11 months ago

Comment by ~changkun on ~eliasnaur/gio

  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.

#332 Expose runOnMain as public API 11 months ago

Comment by ~changkun on ~eliasnaur/gio

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.

#332 Expose runOnMain as public API 11 months ago

Ticket created by ~changkun on ~eliasnaur/gio

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?

#319 key: providing key symbols 1 year, 2 days ago

Comment by ~changkun on ~eliasnaur/gio

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

#319 key: providing key symbols 1 year, 2 days ago

Ticket created by ~changkun on ~eliasnaur/gio

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?

#528 Lost of email 1 year, 2 months ago

Ticket created by ~changkun on ~sircmpwn/aerc2

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.