$INFO in `space_windows_change` event has empty `apps` key when the app is not in English about sketchybar HOT 13 CLOSED

Nice find! Indeed, the string_copy should be inside of the autoreleasepool, such that it is not prematurely auto-released.

The fix is as simple as extending the autoreleasepool by one line to include the return statement.

from sketchybar.

Ah, interesting! I stopped unloading the apple WM on Sonoma, since they seem to have fixed some stuff that bothered me on Ventura. It is probably best to not unload it anymore.

from sketchybar.

This could be a localisation problem, because this function:

https://github.com/FelixKratz/SketchyBar/blob/e2456e2bdd71f739899fc4342e5ddf09ce81a090/src/workspace.m#L81C1-L81C1

is localization dependent. Could you check in this function wether the PID for the problematic processes yields a localizedName?

from sketchybar.

Thank you for looking into this! However I don't have any experience with AppKit. How should I check this?

from sketchybar.

Okay so I have successfully run a minimal script in the Xcode. Turned out that the line you mentioned still gives the correct name even if it is Chinese, but it became empty after being passed to the string_copy function.
So result in this line is correct and s in this line is empty

from sketchybar.

I think I have located the root cause for this problem. According to this reference it appears that the result from this line could be released after the @autoreleasepool scope and it did happen for Chinese characters.

One way to solve this is to use the strdup() function to copy that string into anther char* and use that in the return line, I have already tested it and it worked.

from sketchybar.

The fix is contained in v2.19.4.

from sketchybar.

@FelixKratz I'm running into something similar? On initial load, $INFO has the expected objects of spaces and windows. After any hot-reload, the same applies.

Thereafter, on any event that fires space_windows_change, $INFO is empty.

I'm using your dotfiles, and made the necessary changes in yabai to trigger window_focus, and added an event specifically for space_windows_change as well.

The empty $INFO variable, as you might expect, is causing an error:

[!] Set: Item not found 'space.'.

Where is $INFO set? Did I miss a line in one of the newer updates?

from sketchybar.

If I put this as sketchybarrc (without anything else):

sketchybar --add item space_windows left \
  --set space_windows script='echo "$INFO"' \
  --subscribe space_windows space_windows_change

and then run sketchybar from the commandline I see the event output when a window is created or destroyed. Can you check if this works for you as well? Nothing additional is needed for this event.

I think this event only works properly on macOS Ventura and up.

from sketchybar.

@FelixKratz hopefully this conveys what I did.

1. Clear sketchybarrc to test space_windows_change alone
2. restart sketchybar
3. Mouse between windows
4. Blank output (both out and err .log)
5. Add full sketchybarrc configuration, save (with hotload on)
6. Note that $INFO is populated on load.
7. My comment inside space_windows_change appears
8. echo $INFO blank line

The bottom right terminal is out.log, to its left is err.log. The last thing I do is restore the configuration I have, which demonstrates end-to end working as expected, but $INFO just isn't there.

I might just wipe my system clean of yabai and sketchybar, with all new files. Unless you have think of the missing piece!

❯ sketchybar --query default_menu_items
[
	"Control Center,AudioVideoModule",
	"Gifox,Item-0",
	"Mouseposé,Item-0",
	"Docker Desktop,Item-0",
	"Bartender 5,statusItem",
	"Bartender 5,EItem",
	"Bartender 5,THSItem",
	"Bartender 5,RHSItem",
	"Bartender 5,HISItem",
	"Bartender 5,Window",
	"TextExpander,Item-0",
	"Proton Mail Bridge,Item-0",
	"CopyClip 2,Item-0",
	"GeekTool Helper,Item-0",
	"CleanMyMac X Menu,Item-0",
	"We Love Lights,Item-0",
	"Proton Drive,Item-0",
	"Keyboard Maestro Engine,Main Status Menu",
	"TextInputMenuAgent,Item-0",
	"Spotlight,Item-0",
	"SystemUIServer,TimeMachine.TMMenuExtraHost",
	"iStat Menus Status,com.bjango.istatmenus.weather",
	"Control Center,Battery",
	"Control Center,WiFi",
	"iStat Menus Status,com.bjango.istatmenus.memory",
	"Control Center,BentoBox",
	"verve,Item-0",
	"1Password,Item-0",
	"iStat Menus Status,com.bjango.istatmenus.cpu",
	"iStat Menus Status,com.bjango.istatmenus.sensors",
	"Control Center,Clock",
	"Itsycal,ItsycalStatusItem"
]
❯ sketchybar --version

sketchybar-v2.19.4
❯ yabai --version

yabai-v6.0.1
❯ system_profiler SPSoftwareDataType SPHardwareDataType

Software:
System Software Overview:
System Version: macOS 14.0 (23A344)
Kernel Version: Darwin 23.0.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Computer Name: 
User Name: 
Secure Virtual Memory: Enabled
System Integrity Protection: Disabled
Time since boot: 1 day, 16 hours, 42 minutes

Hardware:
Hardware Overview:

Model Name: MacBook Pro
Model Identifier: [REDACTED]
Model Number: [REDACTED]
Chip: Apple M1 Max
Total Number of Cores: 10 (8 performance and 2 efficiency)
Memory: 64 GB
System Firmware Version: 10151.1.1
OS Loader Version: 10151.1.1
Serial Number (system): [REDACTED]
Hardware UUID: [REDACTED]
Provisioning UDID: [REDACTED]
Activation Lock Status: Enabled

from sketchybar.

You should not need to trigger this event manually, i.e. your yabai window_focus handler is not needed for this event so just remove:

yabai -m signal --add event=window_focused action="sketchybar --trigger space_windows_change"

from your yabairc, this stops the event from being emitted with empty $INFO.

The space_windows_change event is sent by sketchybar when a new window is created/destroyed on a space and not when a window is focused. It is a new builtin event in sketchybar:
https://felixkratz.github.io/SketchyBar/config/events

So try to delete the yabai signal which triggers space_windows_change and spawn a new window or destroy one to test the event.

from sketchybar.

Sorry I should have mentioned — I didn't have this in yabairc until noticing space_windows_change doesn't fire — at all — unless it's attached to window_focused.

I'll share any findings while starting fresh and introducing changes piecemeal. Thank you for the help!

from sketchybar.

@FelixKratz I found the errant configuration:

# Unload the macOS WindowManager process
launchctl unload -F /System/Library/LaunchAgents/com.apple.WindowManager.plist > /dev/null 2>&1 &

I had absorbed this when first starting with the dotfiles, which included this in yabairc. Hope this helps someone else in the future!

from sketchybar.