Wooshy.docs
Wooshy.docs copied to clipboard
Support for Character Viewer
Pressing cmd+ctrl+space opens a Character Viewer as a floating window in most applications, e.g. Safari. I can't get Wooshy to target anything on this window.
I think this is because Wooshy only targets the currently active window and the Character Viewer always opens without activating. When I manually activate it and then open Wooshy, it automatically deactivates, giving focus back to the underlying application it was opened from (e.g. Safari). It would be cool if Wooshy could target the Character Viewer without it having to be active.
The Character Viewer:

What the Accessibility Inspector says about the Character Viewer's window:

Pressing
cmd+ctrl+spaceopens a Character Viewer as a floating window in most applications
thank god i found a way to get rid of this ποΈ
I think this is because Wooshy only targets the currently active window and the Character Viewer always opens without activating. When I manually activate it and then open Wooshy, it automatically deactivates, giving focus back to the underlying application it was opened from (e.g. Safari). It would be cool if Wooshy could target the Character Viewer without it having to be active.
yeah so there's two issues here:
- one is Wooshy taking over, and those floating windows disappearing (it's actually more complicated than that. mouse events etc.). i have plans for after v1 to have another mode. basically you'll have a mode with The Input (like you're having now), and you'll have a mode without the Input, that will work like the Character Windows in kV, and that will not steal focus (in the roadmap here: https://github.com/godbout/Wooshy.docs#v1)
- is the type of window that is that Emoji thing. Apple is bringing more and more windows that are just reachable through mouse. no idea why they do that. seems they care more about giving an iOS like to macOS rather than accessibility. i've made an Alfred Workflow to bring any window from the desktop to the foreground. i'm finding that with some windows it's just impossible. like those floating window that ask for permissions, etc. i think the emoji may be the same. i'll check first if i can add it in the Alfred Workflow. if i can't, that means Wooshy will never be able to target it. that being said, that doesn't prevent point number 1 to be an issue in itself.
regarding point 1, the plan was to get Wooshy proper, and a first production release, and then to start working on the mode without Input (will be needed also for Notifications, and probably some other stuff). now i've installed the Ventura public beta 2, and it's getting worse. lots of hover/click shit that require a mouse, or at least something that doesn't take the focus. so i may need to speed up things. see below:
https://user-images.githubusercontent.com/121373/181796029-886aa585-6380-4e6e-be37-b556f01a02a1.mp4
for the mode without Input, that would look something like below. but you wouldn't have full control like on an Input Field. you can delete, but no command a, command v etc.:
https://user-images.githubusercontent.com/121373/181795766-c265c5a2-28cb-4f9f-a43c-044fda0d8526.mp4
so that's grossly the idea regarding this.
That looks good! I really like the idea of having Wooshy not take focus. For me personally, lack of cmd+a and such definitely wouldn't be any issue.
Yeah, Apple sacrificing accessibility and keyboard functionality to iOS-ify macOS is really sad. I'm glad people are working around it
i think that'll be really needed yeah, the mode without stealing the focus. Ventura comes with another batch of stuff like popovers, notifications etc. where basically you have to use the mouse. i guess i'm not gonna retire soon.
just dropping something here. i was working on the Wooshy: Window to the Foreground! Alfred Workflow. i'm adding the Character Viewer. do you use Alfred? if yes, no idea if that may help in anyway but i was thinking of you while doing it.
https://user-images.githubusercontent.com/121373/182193410-0ac5f1fe-7682-4aa0-980b-4720c6ecc042.mp4
at the end the emoji picker in Alfred is: https://github.com/jeeftor/EmojiTaco
very good one. never used the Character View myself, couldn't find a good way to use it. love the Emoji Taco tho.
That looks cool! I don't use Alfred... funny story, I actually have my own Spotlight/Alfred/Search Bar that I originally started implementing because guess what: I wanted a nice window switcherπ Adding a character picker to it is a good idea though, will probably do thatπ
aww nice. is that public somewhere?
No, still private unfortunately. I have some features I really want to implement before making it public and need to add some proper documentation. I can let you know when I make it public though if you want ^^
I can let you know when I make it public though if you want ^^
definitely. i love builders and love seeing what ideas they bring to life!
@godbout β re:
thank god i found a way to get rid of this ποΈ
Might I ask how? I'd love to bind Wooshy to that shortcut but I can't for the life of me figure out how to disable the Emoji thing and Wooshy says...

Might I ask how? I'd love to bind Wooshy to that shortcut but I can't for the life of me figure out how to disable the Emoji thing and Wooshy says...
so that's gonna be two different things.
to get rid of that shortcut (at least, not showing the Character View when you press that combination, which would happen a lot for me), i've just remapped it in the Keyboard Shortcut Settings to something i'll never press:

but then using control command space is still not allowed, because somehow macOS is still reserving it for itself. under the hood Wooshy is using a Swift package to handle this: https://github.com/sindresorhus/KeyboardShortcuts and i've opened an issue a while ago about this: https://github.com/sindresorhus/KeyboardShortcuts/issues/33 but things haven't changed.
i have a plan to build my own keyboard shortcut recorder to allow those shortcuts, and add double modifiers like command command etc., but it's heavy work. i guess in the meantime i could fork KeyboardShortcuts and remove the limitation? i'd keep preventing users to record menu items like command w, but they could override other shortcuts if they know what they're doing?
Thanks for the thorough response @godbout! It looks like you're on macOS Ventura. When I go to the equivalent preference pane in Monterey I see this.

No matter though, if re-assigning that shortcut won't allow KeyboardShortcuts to override it I guess I'm S.O.L. for now.
To be honest, I was kind of hoping you'd pull a rabbit out of your heat like this. π
https://apple.stackexchange.com/a/128851
Thanks for the thorough response @godbout! It looks like you're on macOS Ventura. When I go to the equivalent preference pane in Monterey I see this.
yes. it's not there by default. you have to set it up yourself, so that it overrides the default keyboard shortcut. you can actually do that for any menu on macOS. pretty neat.
No matter though, if re-assigning that shortcut won't allow KeyboardShortcuts to override it I guess I'm S.O.L. for now.
well as said, i could fork it and remove that limitation. probably will do.
To be honest, I was kind of hoping you'd pull a rabbit out of your heat like this. π
https://apple.stackexchange.com/a/128851
π οΈ that should actually be possible. i didn't think of it because i'm not a fan of hacks. the way my brain works, it's gonna be forgotten the next day. so i was looking for a more stable/middle term solution. but that could solve your problem quickly yeah. lemme check and i'll come back to you.
π οΈ that should actually be possible. i didn't think of it because i'm not a fan of hacks. the way my brain works, it's gonna be forgotten the next day. so i was looking for a more stable/middle term solution. but that could solve your problem quickly yeah. lemme check and i'll come back to you.
doesn't work. KeyboardShortcut is overriding the thing. i'll have to fork.
any chance you're using Karabiner-Elements and/or Hammerspoon? probably you could map something there. like in Wooshy you set a crazy shortcut and in Hammerspoon your map control command space to that crazy shortcut. that should work.
ok i just did it with Hammerspoon, and i don't even use it and i always fuck up the config, but still, took me 1 minute:
hs.hotkey.bind({'control', 'cmd'}, 'space', function()
hs.eventtap.keyStroke({'control', 'option'}, 'space')
end)
then you have your control option space :D
you could even actually leave Wooshy's default:
hs.hotkey.bind({'control', 'cmd'}, 'space', function()
hs.eventtap.keyStroke({'shift', 'command'}, 'space')
end)
let me know if that's a possibility for you. then i'll take my time on the fork...
Thanks for this @godbout! I'm running Karabiner-Elements and will try something similar. Please don't go any further out of the way for me.
BTW β I'm loving Wooshy! It's exactly what, I didn't realize, I've been searching for!
Thanks for this @godbout! I'm running Karabiner-Elements and will try something similar. Please don't go any further out of the way for me.
not a user of Karabiner-Elements, but i've fiddled with it for about 2 minutes, and this seems to do the trick:
{
"description": "remap control command space to shift command space",
"manipulators": [
{
"from": {
"key_code": "spacebar",
"modifiers": {
"mandatory": [
"left_control",
"left_command"
]
}
},
"to": [
{
"key_code": "spacebar",
"modifiers": [
"left_shift",
"left_command"
]
}
],
"type": "basic"
}
]
}
you need to paste this in the karabiner.json config file, as a new rule (under the rules array).
BTW β I'm loving Wooshy! It's exactly what, I didn't realize, I've been searching for!
yes. i'm the Coca-Cola of software π οΈ