Thanks for the ideas, guys. seems like it might be possible. I'm trying to stay away from any custom delete function, since that's a bit too high level of a change. the bookmarker script is almost exactly the ticket - thanks Howard (and Diogo)
wiring up some sort of confirmation prompt or message to an onDestroy callback is a good idea but I think the problem is that onDestroy is invoked when closing the script, which would unnecessarily trigger all of the prompts, right? Is there any way to suppress the onDestroy prompts from triggering when closing the script? with some sort of onScriptClose callback inserting something clever? we really do need a new "onUserDestroy" callback to get around the whole script closing onDestroys thing. On Mon, Feb 13, 2012 at 3:40 AM, Howard Jones <[email protected]>wrote: > What Diogo did for the bookmarker tools we cooked up was to change the > icon to a bookmark icon. > We search for this and produce a list. > > Maybe create a lock icon and search for that? (see bookmarker on nukepedia > for full code if you want) > eg. > sn = nuke.selectedNodes() > if sn['icon'].value() != 'lock.png' > call built-in delete function > > Howard > > ------------------------------ > *From:* chris <[email protected]> > *To:* Nuke user discussion <[email protected]> > *Sent:* Monday, 13 February 2012, 11:18 > *Subject:* Re: [Nuke-users] node lock? > > this is a wild shot, but maybe it's possible replace the > standard delete action with your own function? (or at least have > the delete keyboard shortcut to call your function)? > > that way you could do something like: > > if selectedNode is part of a doNotDeleteList > put up alert (or do nothing) > else > call built-in delete function > > might be a completely stupid idea, but might help to think of > other things > ++ chris > > > On 2/13/12 at 11:15 AM, [email protected] (Chris Bevan) wrote: > > >The only thing that came to mind for me was adding an onDestroy > >callback to check whether the node is one we're not supposed to delete: > > > >def showError(): > >nuke.message("You deleted the wrong node!") > >nuke.addOnDestroy(showError, nodeClass='Dot') > > > >I tried triggering an undo during the callback, but > >unfortunately it undoes the previous action, because the node > >deletion hasn't been registered yet at that point. From a > >quick glance I also wasn't sure how to see what node was being > >deleted, other than the class. > > > >May be food for thought, anyway... > > > >- Chris > > > >On 08/02/12 19:55, J Bills wrote: > >>is there any way to essentially lock a node so it can't > >accidentally be > >>deleted? > >> > >>I'm making a template and for organizational sake, some of > >the > >>expressions rely on certain dots and noop nodes being in > >place. without > >>them, my script looks like a rats nest, but with them it's > >gold. but I > >>don't want someone who's not all that down with dots or > >whatever to > >>start deleting things. > >> > >>other than putting a "do not delete" in the label, is there > >anything > >>scripty I could do here? > >> > >> > >>This body part will be downloaded on demand. > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
