The longer I stumble through the beta program the more I keep coming across sugars as the solution for every shortcoming/feature request in Espresso. They’ve been suggested for everything from managing sugars (which seems like a sort of paradox to me) to managing projects to enhancing all sorts of built-in features.

While I know Espresso is flexible and that the plug-in architecture is very robust, what I don’t fully understand is how end users will interact with installed sugars. Obviously sugars that impact markup in some way will likely be transparent. Right now I have a PHP sugar installed and I assume it’s doing it’s thing. But what about features that users need to directly interact with? Would we access these items from the actions menu? For example if we theoretically had a sugar that managed clips/code snippets would I access the snippets manager from the actions menu?

I’m just trying to get a better handle from a U/I perspective where sugars fit in.

Yes, the main way to access the functionality of sugars is through the action menus.

Cocoa sugars can display any UI imaginable, so that’s really down to the ability of the sugar programmer.

There are currently 2 UI pieces where sugars are inserted: file context/action menus and the Actions menu and toolbar button for text actions. The system for the was designed so there’s no real distinction between built-in functionality and something added by sugars.

alexgordon - 07 January 2009 01:44 PM

Yes, the main way to access the functionality of sugars is through the action menus.

Cocoa sugars can display any UI imaginable, so that’s really down to the ability of the sugar programmer.

Unfortunately, this is still limited by the Actions menu.

We can either bring up a UI when an action is activated, or we can bring up a UI when the action is first tested for ‘activate-ability’, that is, whether the current context is relevant to said UI. There’s no real way to add buttons to the toolbar or anything better, we’re stuck either burying ourselves below the File menu, unsemantically attaching ourselves to a text action, or forcing ourselves into the Users’ faces on Espresso’s launch.

The first poster brings up a good point. A third UI option for more advanced sugars would be nice - General Actions, that are neither based on currently open files nor on text.

elliottcable - 08 January 2009 09:46 PM

alexgordon - 07 January 2009 01:44 PM

Yes, the main way to access the functionality of sugars is through the action menus.

Cocoa sugars can display any UI imaginable, so that’s really down to the ability of the sugar programmer.

Unfortunately, this is still limited by the Actions menu.

We can either bring up a UI when an action is activated, or we can bring up a UI when the action is first tested for ‘activate-ability’, that is, whether the current context is relevant to said UI. There’s no real way to add buttons to the toolbar or anything better, we’re stuck either burying ourselves below the File menu, unsemantically attaching ourselves to a text action, or forcing ourselves into the Users’ faces on Espresso’s launch.

The first poster brings up a good point. A third UI option for more advanced sugars would be nice - General Actions, that are neither based on currently open files nor on text.

alexgordon - 09 January 2009 03:49 AM

Surely you can put extra menus in the menubar if you want?

You can’t add top level menus from actions without doing hacky stuff (and it’s going to stay that way, the action/category system was designed so the menus can be embedded anywhere we want). However, we will be adding additional UI hooks for actions in the future. It’s mostly a matter of testing the waters before it becomes an open API.

elliottcable - 08 January 2009 09:46 PM

A third UI option for more advanced sugars would be nice - General Actions, that are neither based on currently open files nor on text.

My gut feeling is that if you’re coding a general action Sugar that relies on custom interface elements, you should put a single invoke command at the root level of the Actions menu.  Sugars that rely on multiple contextual actions should make sure to organize their menu items into sub-menus.

What might be an interesting extension to the current menu-invoked model would be allowing Sugar developers to hook into Espresso triggers in addition to setting up menu items.  So, for example, Espresso might have an “on file save” trigger.  User launches program, Sugar registers an action for the “on save” trigger (via XML, so little overhead), and then when the user saves a file the Sugar can do whatever (for instance, maybe it’s a simple Git GUI, so it refreshes a status list for the current project).

George the Flea - 09 January 2009 11:24 AM

elliottcable - 08 January 2009 09:46 PM

A third UI option for more advanced sugars would be nice - General Actions, that are neither based on currently open files nor on text.

My gut feeling is that if you’re coding a general action Sugar that relies on custom interface elements, you should put a single invoke command at the root level of the Actions menu.  Sugars that rely on multiple contextual actions should make sure to organize their menu items into sub-menus.

What might be an interesting extension to the current menu-invoked model would be allowing Sugar developers to hook into Espresso triggers in addition to setting up menu items.  So, for example, Espresso might have an “on file save” trigger.  User launches program, Sugar registers an action for the “on save” trigger (via XML, so little overhead), and then when the user saves a file the Sugar can do whatever (for instance, maybe it’s a simple Git GUI, so it refreshes a status list for the current project).

Wouldn’t be hard at all. I’m sure Jan would be amenable to implementing this, it’s just a matter of setting up some delegate methods, we’ve already got a sexy Cocoa API they’d work great with…