Customising the Spreadsheet add button

[themissingcow]

Hey Team Gaffer,

I’ve been committing assorted crimes against Gaffer, in the form of custom nodes built around a Spreadsheet (see themissingcow/gaffer-astro@3a17d3d as an example). This is all working well, but I’d like to customise the process for adding rows - principally to:

• Provide presets (dynamic and static) as per ShaderTweaks, etc...
• Disable certain cells on creation.

I can do all this with a custom widget in the plug layout, but I don’t think there is a way to hide the standard add button from the rows PVW, or customise its action.

Would there by any interest in me putting up a PR to help support this? If so, any preference on how?

Allowing one to hide the button (perhaps as per spreadsheet:defaultRowVisible) would do me, rather than attempting to add in suitable customisation signals for a menu + row creation.

No worries either way,
Many thanks in advance,
Tom

[johnhaddon]

Hey Tom,

Would definitely welcome a PR for this. Metadata to hide the default button seems reasonably pragmatic, but might it be a pity that the new + button would be out of line with the info row?

I wonder if a static SpreadsheetUI.addButtonMenuSignal() in the model of PlugValueWidget.popupMenuSignal() might be a reasonable alternative that lets us use the existing button. I'm thinking we could emit the signal on click, and if the menu gets populated we show it. If the menu doesn't get populated then we just do the default operation as usual. You'd connect a slot for your custom node, which would check the plug is on an instance of your node and then add the menu items you want.

Would that suit your use case, or do you want to customise the button more heavily? It perhaps doesn't give complete control, but I can imagine it providing sufficient control for a bunch of things we might want to do in Gaffer.

Cheers...
John

[johnhaddon]

Yep, probably best not to use childAddedSignal() for that. If there was only one menu item added, do you think it would be too much to just call that directly rather than show the menu?

[themissingcow]

Sounds like a practical compromise, given this is a rather niche area. Thanks!

[themissingcow]

Whilst testing this, authors of these new menu items may wish to initiate editing as per the default action. This is done via _PlugTableView.editPlugs. I can do this via the back-door, but it seems a fairly common desire. Might it be worth adding _RowsPlugValueWidget.editPlugs, to avoid exposing the multi-table nature of the implementation? This is potentially becoming a little 🐰 🕳️ though, so can leave it for now if so desired.

[johnhaddon]

If we could keep the 🐰 out of that particular 🕳️ for now I think that would be good. But longer term I think it probably would be reasonable to expose RowsPlugValueWidget publicly and furnish it with a few methods to expose the key functionality of the inner widgets.

[themissingcow]

Yeah, its not super straight forward is it either way....