Discussion:
Finder Sync extension menu limitations
Dragan Milić
2015-04-08 18:29:12 UTC
Permalink
Hello,

I wonder if anyone have got more experience developing Finder Sync extensions for Yosemite. I believe I figured out some things I’d like to achieve aren’t possible and I’d like to confirm them. It’s related to FIFinderSync protocol method - [FIFinderSync menuForMenuKind:]. According to documentation, in this method I’m supposed to create a menu containing menu items, which are related to selected and/or target items in one of monitored directories. That menu (that is, its items) will be added to Finder standard contextual menu (provided that FIMenuKind parameter is FIMenuKindContextualMenuForItems).

This all works fine, but I’ve noticed that not exactly menu items I created in above mentioned method are added to contextual menu, but their “shallow" copies. I say “shallow”, because, as far as I can see, only three properties of original menu items are used: title, image and action. All other properties I set to menu items in the protocol method aren’t used, including target, indentation, tag, represented object, etc. Therefore, “shallow" menu items that appear in Finder contextual menu have their targets set to nil, which means all menu item actions have to be implemented by the FIFinderSync subclass. This, as well as impossibility to pass menu items tags and represented objects, disturbs my code organisation a bit, but I can work around it.

But one particular things really bothers me; if I create a menu item which has its own submenu, the “shallow” menu item added to the contextual menu does not include that submenu, effectively preventing one from creating hierarchical menus provided by Finder Sync extension. My extension is supposed to provide quite some number of actions (depending on selection), many of them are logically grouped and not being able to organise them in hierarchical menu really clutters the whole Finder contextual menu with too many items.

Another interesting thing is that if in the action method of a certain “shallow” menu item I try to get a reference to its containing menu (practically trying to get reference to Finder contextual menu), that property returns nil, like the item doesn’t belong in to any menu at all.

If anyone realises I’m doing anything wrong, or knows how to overcome these limitations, I’d be really thankful for eventual insights.

-- Dragan
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent
Dave Lyons
2015-04-09 21:23:45 UTC
Permalink
Hi Dragan,

You're exactly right about the limitations. The only other menu item property that's used is "enabled" (though typically you wouldn't want a disabled menu item here anyway).

Because the presented NSMenu object lives in a different process from your code (in Finder.app, for example), it's impossible for your Finder Sync extension to get a reference to that menu. Some of the other limitations could be removed in the future, so filing a bug report with your priorities is always a good idea.

Cheers,

--Dave
Post by Dragan Milić
Hello,
I wonder if anyone have got more experience developing Finder Sync extensions for Yosemite. I believe I figured out some things I’d like to achieve aren’t possible and I’d like to confirm them. It’s related to FIFinderSync protocol method - [FIFinderSync menuForMenuKind:]. According to documentation, in this method I’m supposed to create a menu containing menu items, which are related to selected and/or target items in one of monitored directories. That menu (that is, its items) will be added to Finder standard contextual menu (provided that FIMenuKind parameter is FIMenuKindContextualMenuForItems).
This all works fine, but I’ve noticed that not exactly menu items I created in above mentioned method are added to contextual menu, but their “shallow" copies. I say “shallow”, because, as far as I can see, only three properties of original menu items are used: title, image and action. All other properties I set to menu items in the protocol method aren’t used, including target, indentation, tag, represented object, etc. Therefore, “shallow" menu items that appear in Finder contextual menu have their targets set to nil, which means all menu item actions have to be implemented by the FIFinderSync subclass. This, as well as impossibility to pass menu items tags and represented objects, disturbs my code organisation a bit, but I can work around it.
But one particular things really bothers me; if I create a menu item which has its own submenu, the “shallow” menu item added to the contextual menu does not include that submenu, effectively preventing one from creating hierarchical menus provided by Finder Sync extension. My extension is supposed to provide quite some number of actions (depending on selection), many of them are logically grouped and not being able to organise them in hierarchical menu really clutters the whole Finder contextual menu with too many items.
Another interesting thing is that if in the action method of a certain “shallow” menu item I try to get a reference to its containing menu (practically trying to get reference to Finder contextual menu), that property returns nil, like the item doesn’t belong in to any menu at all.
If anyone realises I’m doing anything wrong, or knows how to overcome these limitations, I’d be really thankful for eventual insights.
-- Dragan
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to
Dragan Milić
2015-04-09 22:14:18 UTC
Permalink
Hi Dave,
Post by Dave Lyons
Hi Dragan,
You're exactly right about the limitations. The only other menu item property that's used is "enabled" (though typically you wouldn't want a disabled menu item here anyway).
Because the presented NSMenu object lives in a different process from your code (in Finder.app, for example), it's impossible for your Finder Sync extension to get a reference to that menu. Some of the other limitations could be removed in the future, so filing a bug report with your priorities is always a good idea.
Thanks for confirming this, I supposed it had to do something with the fact of object living in different processes. Actually, all those properties I mentioned (+ “enabled”) are just used for menu item visueal appearance, but they’re also initialised to 0/nil/NULL. So, if in menu item’s action method, I try to access a sender’s title, it’s nil, even though the title is drawn on the screen. That applies to item’s “menu” property too, and it’s a bit strange and funny (until one realises the story about different processes) that the item is displayed in a menu, yet it’s “menu" property is nil :-)

I’ll definitely fill a bug report with some things I’d like to see improved or implemented. There aren’t many, I’d like a few more properties of menu items created in an extension to be reusable in items’ action methods:

- representedObject
- tag (although if the “representedObject” is enabled, tag can easily be worked around)
- indentation
- possibility to create hierarchical (sub)menus

The last one is, at the moment, the most important in my opinion, as it would enable creation of much more UI friendlier extensions and reduce contextual menu clutter. For the time being I created a work around this so whenever I’d like to have a hierarchical submenu, I create a single menu item, whose action shows a NSPopover attached to selected item(s) (similar to what Finder does for “Tags…” contextual menu item) and that popover contains NSPopUpButton with additional menu items. Of course, this required some playing around, registering a global event monitor (to record where in the screen a user clicked to invoke the menu and therefore to assume approximately where to “attach” the popover), creating opaque window to attach the popover to etc. But it’d be much better if all this is available out of the box.

Actually, reading this last paragraph, I realised another improvement of Finder Sync extension would be:

- possibility to get a NSPopover attached to selected/target URLs and provide our custom view controller to fill in its contents.

-- Dragan
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-

Loading...