"passthrough" click_script for alias

[donaldguy]

I wanted to pull forward the unfurl of an item mirrored on click of an alias.

I assume someone else has done this (and if you have a different/better version please share 😬), but I didn't find it so I wanted to share my AppleScript versions. - which ... mostly work

[Probably the logic here could be more succinctly/reliably turned into Objective C if Felix is inclined or someone wants to PR; either into sketchybar per se or as an accessory process]

What google mostly says, which mostly doesn't work

This approach worked in my very first testing with (only) Fantastical!

sketchybar --default \
click_script='osascript -e "tell application \\"System Events\\" to tell process \\"${NAME%,*}\\" to tell first menu bar item of menu bar 2 to click"'

Alas for pretty much* everything else this returns missing value with no sign of life.

I also had no better luck with perform action "AXPress" (nor other guesses like e.g. directing the click to occur at the site of item, trying to direct the click/action through the menu bar delegate, etc.; unhiding menu bar didn't seem to change; calling activate, select)

*the exception that proved the rule was "CleanShot X", which did respond with unfurl to the click, but only after I first manually made it visible by opening the Bartender Menu - this is part of what leads to...

Imperfect but works: Bartender 4

Pro: Seems to work across items
Cons:

• depends on a non-free ($14 or as part of SetApp) app,
• re-shows hidden menu bar first; position corresponds to where the app unfurls (for some, yabai -m config mouse_follows_focus on moves mouse there but for others no)

If like me, you are half-committed to the the sketchybar lifestyle, you probably have Bartender running still;

and in checking OSA dictionaries I found it exposes a scripting hook for activating arbitrary menu bar items.

the sketchybarrc "one"-liner

I arrived at this version later, and it's probably the saner place to start. It doesn't require/create extra files - its slow in theory but idk that its super noticeable.

ALIAS_NAME="Fantastical Helper,Fantastical"

BARTENDER_MIID="$(printf "%s-%s" \
  "$(lsappinfo info -only bundleID -app "${ALIAS_NAME%,*}" | cut -d= -f2 | tr -d \")" \
  "${ALIAS_NAME##*,}"
)"

sketchybar --set $ALIAS_NAME \
click_script="$(which osascript) -e 'tell application \"Bartender 4\" to activate \"$BARTENDER_MIID\"'"

the AppleScript maximalist approach (w/ JIT + memoized compilation)

I spent hours doing premature optimization (and remembering how ✨interesting 🤔 OSA is) and you can (benefit from it) too!

sketchybarrc

# PREVIOUS_DEFAULT_CLICK="$(sketchybar --query defaults | jq '.scripting.click_script')"

sketchybar --default \
click_script="$(which osascript) '$PLUGIN_DIR/bartender_dispatcher.scpt' "\
'"${NAME%,*}" "${NAME##*,}" "'"$PLUGIN_DIR"'/bartender/$NAME.scpt"'

# ADD ALIASES
# e.g. 
#   sketchybar --add alias "Fantastical Helper,Fantastical" right
#
# THEN
#   sketchybar --default click_script="$PREVIOUS_DEFAULT_CLICK"
# not sure how/if this behaves with "(null)"

$PLUGIN_DIR/bartender_dispatcher.scpt

script BartenderDispatcher
  on run argv
    set scptFile to (POSIX file (item 3 of argv))

    -- if the applet was already compiled, just run it
    try
      set scptAlias to scptFile as alias
      run script scptFile
      return
    on error errText number errNum
      if errNum is not -1700 then -- "can't make alias, i.e. the file doesn't exist"
        display alert "Unexpected error in " & (POSIX path of (path to me)) & ":
 " & errText & "( " & errNum & ")"
        return
      end if
    end try

    -- otherwise create/compile an item-specific applet and then run it
    set appName to (item 1 of argv)
    set menuItemName to (item 2 of argv)

    -- sketchybar formats as "<App Display Name>,<Item tile>"
    -- but Bartender does <bundle_id>-<item name> so we need to translate real quick
    tell application "System Events"
      set appBundleId to bundle identifier of process appName
    end tell
    set bartenderFormatName to appBundleId & "-" & menuItemName

    script activateItem
      global savedBartenderFormatName
      on run
        tell application "Bartender 4" to activate bartenderFormatName
      end run
    end script
    -- though osadecompile doesn't show it, a copy to global is set ~statically
    -- in the compiled script object
    tell activateItem to copy bartenderFormatName to savedBartenderFormatName


    store script activateItem in scptFile
    run script scptFile
  end run
end script

on run argv
  set memoizeDir to (item 3 of argv)
  set dirCmd to "mkdir -p `dirname " & memoizeDir & "`"
  do shell script dirCmd

  -- replace self with compiled version of above
  set myPath to (path to me)
  set srcPath to (POSIX path of myPath) & ".src"
  do shell script ("mv '"& (POSIX path of myPath) & "' '" & srcPath & "'")
  store script BartenderDispatcher in myPath replacing yes

  -- then execute it
  run script myPath with parameters argv
end run

the first time you run this it will move itself (the source code) version to ${path}.src - and also will attempt to create the per-alias storage location from the third arg of the first call (so $PLUGIN_DIR/bartender/ as shown above).

There might be some small speedup if you reconfig

there is/are probably also middle ground(s) between these two extremes

[donaldguy]

scrap findings with System Events

I threw a lot of time down this well with little success

It seems like what we care mostly/(exclusively?) is UI Elements with property subrole of "AXMenuExtra";

I wrote some manual filtering for that after I found that some apps (like iStats) were in fact populating stuff into menu bar 1 (vs 2 as seems mostly the case, since 1 is usually {File, Edit, etc.})

wip AliasHelper.scpt

script AliasHelper
	property theApp : null
	property menuBar : null
	property menuItem : null
	
	on findBar(whatApp)
		set theApp to whatApp
		tell application "System Events"
			tell process whatApp
				repeat with n from 1 to count of menu bars
					set mi to properties of first menu bar item of menu bar n
					if (mi contains {subrole:"AXMenuExtra"}) then set menuBar to (a reference to menu bar n)
					
				end repeat
			end tell
		end tell
	end findBar
	
	-- also started an on findItem, but didn't seem to go anywhere
end script

But then I come to realize that the menu bar with the items, at least seems to be reliably advertised under the "AXExtrasMenuBar" attribute

so (as continues to work with Fantastical and not others), we can at least change the call from the first google answerto the slightly more general

set processName to "Fantastical Helper" --e.g. 
tell application "System Events" to tell (value of attribute "AXExtrasMenuBar" of process processName ) to click first menu bar item

calling select on items does seem to return them but does not, that I've been able to notice, make them not say false to get selected (nor as in the AXSelected attribute)

[FelixKratz]

Some time ago I did some tinkering with this as well. I ultimately stopped experimenting with it since I was not able to move the popup window to the appropriate location below sketchybar. Maybe it is possible via the AX API but I was not successful.

I can contribute this snippet which I used for testing:

helper.c

#include <Carbon/Carbon.h>

void ax_init() {
  const void *keys[] = { kAXTrustedCheckOptionPrompt };
  const void *values[] = { kCFBooleanTrue };

  CFDictionaryRef options;
  options = CFDictionaryCreate(kCFAllocatorDefault,
                               keys,
                               values,
                               sizeof(keys) / sizeof(*keys),
                               &kCFCopyStringDictionaryKeyCallBacks,
                               &kCFTypeDictionaryValueCallBacks     );

  AXIsProcessTrustedWithOptions(options);
  CFRelease(options);
}

void ax_perform_click(AXUIElementRef element) {
  if (!element) return;

  AXUIElementPerformAction(element, kAXPressAction);
}

AXUIElementRef ax_get_extra_menu_item(AXUIElementRef app, char* name) {
  AXUIElementRef extra_menus_ref = NULL;
  CFTypeRef extra_menu = NULL;
  CFArrayRef children_ref = NULL;

  AXError error = AXUIElementCopyAttributeValue(app,
                                                kAXExtrasMenuBarAttribute,
                                                (CFTypeRef*)&extra_menus_ref);
  if (app) CFRelease(app);

  if (error == kAXErrorSuccess) {
    error = AXUIElementCopyAttributeValue(extra_menus_ref,
                                          kAXVisibleChildrenAttribute,
                                          (CFTypeRef*)&children_ref);

    uint32_t count = CFArrayGetCount(children_ref);

    if (count == 1 || (count > 0 && !name)) {
      extra_menu = CFRetain(CFArrayGetValueAtIndex(children_ref, 0));
    } else {
      // Loop through array and find correct item via name...
    }
    CFRelease(extra_menus_ref);
    CFRelease(children_ref);
  }
  return (AXUIElementRef) extra_menu;
}

int main (int argc, char **argv) {
  ax_init();
  pid_t pid = 0;
  if (argc > 1) {
    char* pid_str = argv[1];
    pid = strtol(pid_str, NULL, 10);
  }
  if (!pid) return 1;

  AXUIElementRef app = AXUIElementCreateApplication(pid);
  AXUIElementRef menu = ax_get_extra_menu_item(app, NULL);
  ax_perform_click(menu);
  return 0;
}

(compile with clang -std=c99 -framework Carbon helper.c -o helper)

which presses on a menu item when given the pid of the parent process. e.g. with brew install pidof:

./helper $(pidof MeetingBar)

Note that the current implementation will always click the "first" item. If there is more than one the else branch in ax_get_extra_menu_item must be populated.

[donaldguy]

Re moving into place:

Well, its not NOT madness ¹ but, for the record/public-interest, the following (alongside the bartender_dispatcher.scpt from above for doing actual display) mostly²-works for items which generate a window (vs e.g. displaying a traditional menu - that's probably essentially similar? but certainly is ignored by yabai).

Not sure how much of it is strictly dependent on the private apis and scripting-additions of yabai vs what might be more easily available to sketchybar directly

(it probably could mostly also be achieved similarly with a "simple" yabai -m rule --add app=... grid= but I haven't really used that functionality so wasn't clear how to calculate it (and wanted to forge ahead to PoC))

.sketchybarrc (or .yabairc or ~wherever)

ALIAS_NAME="iStat Menus Status,com.bjango.istatmenus.time"

sketchybar --add alias "$ALIAS_NAME" right

APP_NAME="${ALIAS_NAME%,*}"
# making floa
yabai -m rule --add app="$APP_NAME" manage=off #mouse_follows_focus=on

X_SPOT=$(sketchybar --query "$ALIAS_NAME" | jq '.bounding_rects."display-1".origin[0]')

yabai -m signal --add app="${ALIAS_NAME%,*}" event=window_created action="$(cat <<EOS
bash -c "
#for debugging:
#set -x; exec > $HOME/output.txt; exec 2> $HOME/output.txt
X_SPOT=$X_SPOT;"\
'ffm=\$(yabai -m config focus_follows_mouse)
mff=\$(yabai -m config mouse_follows_focus)
yabai -m config focus_follows_mouse off
yabai -m config mouse_follows_focus off

INFO="\$(yabai -m query --windows --window \$YABAI_WINDOW_ID)"
# echo "\$INFO"
WIDTH="\$(echo "\$INFO" | jq "(.frame.w)|floor")"
REAL_X_SPOT=\$(( \$X_SPOT - \$WIDTH/2 ))
yabai -m window \$YABAI_WINDOW_ID --move abs:\$REAL_X_SPOT:25 --focus

yabai -m config mouse_follows_focus \$mff
yabai -m config focus_follows_mouse \${ffm//disabled/off}'
EOS
)"

In addition to handling the major "bug" I'm seeing as in ² below, it could probably/definitely be otherwise tightened up to not (in other cases) ~false-positive; and probably, you know, use labels on the rules and signals to create some level of idempotence? also possiblt worth caching the width and/or desired spot after the first call.

Footnotes

1. probs would be less so if I just moved the action to a separate file vs playing stupid quoting games, but where's the fun in that? ↩

2. In the case of the example, it is moving to far-right where I like my clock, and/but either with the mouse_follows_focus signal version or just when I move the mouse into the dropdown, it unfurls a side-menu which also gets hit by the signal and covers or displaces-off-the-screen the original menu
   This problem could probably be suppressed by a) title filter, if title was in fact set; or by b) e.g. having the signal self-destruct on completion, but reinstall via a paired event=window_destroyed handler) ↩ ↩²

[FelixKratz]

Moving new windows is no problem via AX (see below for a snippet). The default popups from the macOS menubar are not windows, they are menus, hence it is not (that I can tell) possible to move them. It would, however, be possible to recreate them by parsing the AX tree (like e.g. MenuWhere does it with File, Edit, View..., see #170).

Moving only next new window of app:

#include <Carbon/Carbon.h>

void handler(AXObserverRef observer, AXUIElementRef element, CFStringRef notification, void* context) {
  CGPoint pos = CGPointMake(100, 100);
  AXValueRef pos_ref = AXValueCreate(kAXValueTypeCGPoint, &pos); 
  AXUIElementSetAttributeValue(element, kAXPositionAttribute, pos_ref);
  AXObserverRemoveNotification(observer, context, kAXWindowCreatedNotification);
}

void ax_init() {
  const void *keys[] = { kAXTrustedCheckOptionPrompt };
  const void *values[] = { kCFBooleanTrue };

  CFDictionaryRef options;
  options = CFDictionaryCreate(kCFAllocatorDefault,
                               keys,
                               values,
                               sizeof(keys) / sizeof(*keys),
                               &kCFCopyStringDictionaryKeyCallBacks,
                               &kCFTypeDictionaryValueCallBacks     );

  AXIsProcessTrustedWithOptions(options);
  CFRelease(options);
}

AXObserverRef ax_observe_application(AXUIElementRef app, pid_t pid) {
  AXObserverRef observer = NULL;
  if (AXObserverCreate(pid, &handler, &observer) == kAXErrorSuccess) {
    AXObserverAddNotification(observer,
                              app,
                              kAXWindowCreatedNotification,
                              (void*)app                   );

    CFRunLoopAddSource(CFRunLoopGetCurrent(),
                       AXObserverGetRunLoopSource(observer),
                       kCFRunLoopDefaultMode                );
  }
  return observer;
}

int main (int argc, char **argv) {
  ax_init();
  pid_t pid = 0;
  if (argc > 1) {
    char* pid_str = argv[1];
    pid = strtol(pid_str, NULL, 10);
  }
  if (!pid) return 1;

  AXUIElementRef app = AXUIElementCreateApplication(pid);
  if (!app) return 0;
  AXObserverRef observer = ax_observe_application(app, pid);
  if (!observer) return 0;
  CFRunLoopRun();
  return 0;
}

[donaldguy]

Yeah - ironically, of all the things ~passively in my native menu bar (not tucked away by Bartender), all but one of them draw windows and just place them as though they were menus - but that one that uses a normal menu is: 1. the one that is actually an important enough part of my workflow that it inspired me to undertake any of this (/ was blocking my using of a custom top bar that would remove it from view; now is keeping me from setting topmost=true), 2. also the only one that is a cross-platform app (I think its drawing a native Cocoa/Carbon menu, but probably somewhere in the (unavailable) source is closer to tk, wxWidgets, etc)

--

[... here I started to say what you already said before I realized you had said it (now that it was scrolled out of view) – that we could probs re-draw them rather than locate them - but yeah.]

In practice for native menus (on menu bar 1 as AppleScript would mostly have it) I tend to often use e.g. https://appmakes.io/paletro - but far as I know it (& the like, e.g. the Raycast navigation core "extension") haven't been taught to consider "extras"' menus :-(

[donaldguy]

but far as I know it (& the like, e.g. the Raycast navigation core "extension") haven't been taught to consider "extras"' menus :-(

there is, of course, the hotkey-bindable (and it looks like AppleScriptable! as might be my new better plan) "Quick Search Menu Items" in Bartender (which indeed presents a pretty similar UX to Paletro) - I should probably just settle for that

---

Of more potential broad interest, at least in theory:

They (the devs at Surtees Studio) also are somehow getting away with presenting it (a menu extra selected via their "Quick Search" dialog/palette; whether a native menu or a window-menu) AND THEN making it hold focus (or remain painted in any case) until I can get my mouse up to it (immune to blur/dismiss by yabai -m config focus_follows_mouse autoraise and even yabai -m config focus_follows_mouse autofocus along the path)

it also tends to manage to consistently place the unfurl ~right under (or just to the right of) the bartender separator - but they are clearly doing this by, in fact, temporarily relocating the menu item as a whole first - it doesn't e.g. work for control center

It's likely not worth the trouble to chase down - but yeah - theoretically (for a top bar of certain close-enough widths); it did previously occur to me but I didn't state) it would work to relocate the menu bar item to under the alias (by e.g. inserting items to draw spacers around it?) before forwarding the click/press¹ — but far as I know there are not public APIs to control order (and whatever tricks Bartender is doing, its not reexposing an API for it as e.g. AppleScript)

Footnotes

1. or even merely let it pass-through directly. I mean, if you could force the item to be under the location in the first place, that would also maybe obviate the need for screen recording and re-draing vs just not drawing /drawing Sketchybar translucent for that portion/cutout) ↩

[donaldguy]

Self-quoting most recent message (#236 (reply in thread)) :

theoretically (for a top bar of certain close-enough widths); it did previously occur to me but I didn't state) it would work to relocate the menu bar item to under the alias (by e.g. inserting items to draw spacers around it?) before forwarding the click/press1 — but far as I know there are not public APIs to control order...

I'm not gonna fall prey to digging into it at least at the moment, (cause its 3am and I should go to sleep and/cause like ... I don't even know Swift (or Obj C really) - but it seems like this nut might have been cracked and shared by either

https://github.com/dwarvesf/hidden
or
https://github.com/Mortennn/Dozer/