How to disable automatic cleanup of notes in Smart Adornments?

Hello!

I have a smart adornment that collects notes based on a query. The query is working fine, but I would like to turn off the automatic cleanup (to the grid) that is currently happening when the notes are collected inside the adornment.

I did try setting the $CleanupAction to “none” on the adornment, but it does not seem to help in this situation.

I am basically looking to have the smart adornment automatically “collect” the matching notes inside the adornment’s boundaries, but manage the spatial organization of the notes inside the adornment manually.

Any help is very much appreciated!

$CleanupAction does not affect smart adornments.

These two points from the reference mentioned by @PaulWalters suggest that this may not be controllable in the way you would like:

  • Matched notes are laid out in a grid (sort) order on the adornment until the available areas is filled. Thereafter notes may be stacked on top of one another or alongside the adornment until the latter is manually resized to accommodate all matched notes.
  • $CleanupAction is ignored. When a query is set the user cannot re-arrange items on the adornment.

@PaulWalters and @JFallows,

Thank you for Your help. Looks like what I am trying to do with adornments will not work.

I have worked around this with an agent and a plain adornment for now, which achieves a similar outcome.

Thanks again,
Anupam

The difficulty here is that the smart adornment needs to find some place to put the notes it gathers. This can be difficult or impossible if the adornment can’t rearrange its notes.

As ever, I’m open to alternatives here.

Would it be possible to have a new attribute option for $CleanupAction (perhaps skip?), using which the gathered notes can be simply brought inside the adornments boundaries, with a best-effort fitment, and potential overlap/stack-up of the notes if there is not enough space?

Something. similar to:

44 PM

This would certainly be an acceptable solution to me :slight_smile:, and the new attribute value should ensure backward compatibility and not break existing files.

Side thought to this: does a smart adornment suppress the parent map’s $NeverComposite or does the adornment have its own that trumps the map’s and is itself trumped by query based placements?

The status quo is fine with me.

Well, then that’s just another kind of “clean up” isn’t it?