Replace slow Distributed Notifications

[jannis-baum]

We've talked about this before, unfortunately the DNs can be very slow. They seem to have an incredibly low priority for the scheduler. The video below uses Wooshy & Scrolla as a demo but it's the same for kV (see "inWooshy"/"inScrolla" variables towards the bottom of the screen as I toggle the two programs):

https://github.com/godbout/kindaVim.docs/assets/85999315/adc3a39f-c60c-499f-93c0-b6c5983925fa

Of course, remapping keys with it being this slow is less fun than it could be🙊

After our discussion, the best[^1] solution in my mind would be switching to a JSON state file, similar to how it's done in Karabiner Elements[^2]. Writing to & reading from a file is more than fast enough for any state-dependent use case I can imagine.

With kV writing its current mode to a little JSON file somewhere, we can

• use a tool like jq to directly read the state when we need to know it
• use a tool like watchman if we actually need to be notified of changes

The same wish of replacing DNs with a state file of course also goes for Wooshy and Scrolla, but to me it has the highest priority here😊 Let me know in case you want me to open issues over there as well though.

[^1]: Judging by a combination of user-friendliness, implementation overhead & bloat. Other (I think inferior) considerations are a CLI or server we can ask for a current state, or giving the option to have kV run a program (like a user-provided shell script) on mode changes. [^2]: Information taken from https://github.com/pqrs-org/Karabiner-Elements/issues/2278 and https://github.com/pqrs-org/Karabiner-Elements/issues/2651#issuecomment-795348836

[godbout]

1. for the json: ~/.kindaVim/mode.json?
2. or server we can ask for a current state why not a custom URL then? 😂️
3. Let me know in case you want me to open issues over there as well though. good for now thanks, this one will require some digestion because the choice made will have quite some impact on the apps' directions. thank you!

[jannis-baum]

• for the json: ~/.kindaVim/mode.json?

Yes! Having a ~/.kindaVim directory leaves me with wanting #136 as well haha but I guess that's mostly dismissed🙈

• or server we can ask for a current state why not a custom URL then? 😂️

Hahah I don't think it's possible to send data back as a response from the app's URI is it?

[godbout]

Yes! Having a ~/.kindaVim directory leaves me with wanting #136 as well haha but I guess that's mostly dismissed🙈

what do you want exactly from #136? handling the different locations? or kV's Settings in yml or toml rather than a plist?

Hahah I don't think it's possible to send data back as a response from the app's URI is it?

good point LOL. although could then write info in a json file. like only when requested. but not sure it's worth the trouble.

[jannis-baum]

what do you want exactly from #136? handling the different locations? or kV's Settings in yml or toml rather than a plist?

Yes, exactly, being able to (easily) configure everything from Vim in a more human friendly format than plist. And being able to keep the config in my dotfiles repo (I know that I could also keep the plist in my dotfiles but the hassle of using a UI to make adjustments and then copying the plist to the dotfiles repo is unfortunately not worth it).

But anyways, I get if it's not worth implementing. Probably kind of annoying to maintain the UI config and this one at the same time.

good point LOL. although could then write info in a json file. like only when requested. but not sure it's worth the trouble.

Yes true. Is this worth the extra effort (in terms of UX) though compared to just always writing the state to the JSON? I haven't tested anything but since Karabiner does it I don't suspect it to be problematic performance wise

[godbout]

Yes, exactly, being able to (easily) configure everything from Vim in a more human friendly format than plist. And being able to keep the config in my dotfiles repo (I know that I could also keep the plist in my dotfiles but the hassle of using a UI to make adjustments and then copying the plist to the dotfiles repo is unfortunately not worth it).

But anyways, I get if it's not worth implementing. Probably kind of annoying to maintain the UI config and this one at the same time.

hmm. depends what we're talking about. i could have UI Settings (the current ones) that could be extended or overridden by a kV config file?

but when you say configure everything from Vim what do you mean exactly? kV, or Vim? coz basically yeah, currently kV merely uses any Vim setting, right? it would have to be built, which is kinda insane. if one day i go down this road, probably it would make much more sense to see if i can use a Vim backend engine for the Accessibility Strategy, rather than rewriting every move and every setting 😂️

Yes true. Is this worth the extra effort (in terms of UX) though compared to just always writing the state to the JSON? I haven't tested anything but since Karabiner does it I don't suspect it to be problematic performance wise

probably not yeah. could start simple tho, and change if/when experiencing issues.

[jannis-baum]

hmm. depends what we're talking about. i could have UI Settings (the current ones) that could be extended or overridden by a kV config file?

Yes that sounds great!

but when you say configure everything from Vim what do you mean exactly? kV, or Vim? coz basically yeah, currently kV merely uses any Vim setting, right? it would have to be built, which is kinda insane. if one day i go down this road, probably it would make much more sense to see if i can use a Vim backend engine for the Accessibility Strategy, rather than rewriting every move and every setting 😂️

Oh, sorry, I think my phrasing wasn't good. By "configure everything from Vim" I just mean configuring the settings that kV has right now with a plain text file (that I can edit with whatever editor I want, i.e. Vim) with a comfortable (i.e. not plist haha) format.

If there's more to talk about for the config file thing let's keep talking on #136 instead🙈

[godbout]

Yes that sounds great!

any experience with this tho? i'm not sure whether this could be done easily. i'm using Swift @AppStorage that makes it super easy to save config without having to care where and how (un)fortunately 😂️ guess i'd need to write a wrapper around this.

[jannis-baum]

any experience with this tho?

Nope, sorry :( my app has no UI settings and instead only the plain text file haha so there it was just a matter of reading the file & falling back to defaults for everything that's not set.

[godbout]

Nope, sorry :( my app has no UI settings and instead only the plain text file haha so there it was just a matter of reading the file & falling back to defaults for everything that's not set.

yeah, straightforward in that case. with @AppStorage it makes it super easy to save config but yeah, all the magic is hidden behind. i guess a wrapper with all the @AppStorage is gonna be necessary then, and handle the reading/writing myself 😴️ not sure it's gonna be a priority 😅️ you shouldn't be changing the config often, right?

[jannis-baum]

not sure it's gonna be a priority 😅️ you shouldn't be changing the config often, right?

Yes, low priority☺️ I don't change config often, basically almost never. It's more about having it at a nice location in my dotfiles repo. But I guess if I say I almost never change kV's config then I could also just put the plist file into my dotfiles repo haha

---

Replacing the DNs with something faster is definitely much higher priority to me😇

[godbout]

done in https://github.com/godbout/kindaVim.docs/releases/tag/59