But, the way that nodes are disabled is through setting a disabled node filter via "setDisabledNodeFilter" in TreeView. So, adding a second (redundant) method doesn't seem necessary.
So, I think at max, just one new style might be necessary for the TreeView skin to disable mouse interaction on nodes that show up as disabled in the disabled node filter. But, actually, I don't think any change is really necessary, since there is a method "isNodeDisabled(path)" in TreeView and the context menu can be disabled by returning 'true' from "configureContextMenu" and adding no menu sections to the context menu. I will verify this and post a sample to the issue .... But, this is what I'm thinking at the moment. ~Roger On Aug 23, 2012, at 9:36 AM, Josh R wrote: > On Thu, Aug 23, 2012 at 12:19 PM, Roger L. Whitcomb > <[email protected]> wrote: >> I'm kind of struggling with what to (succinctly) call the style.... >> "setDisableUIOnDisabledNodes(boolean)" seems a bit unwieldy.... any >> suggestions? >> > > So: > > A.1) First the node would need to be disabled. For this we could > create a new setEnableNode(boolean). But this setter shouldn't block > the UI. Because some nodes might still > want to show a different menu when they are in this state. > A.2) Second, if users want to disable event propagation then they can > invoke setDisableUIOnNode(). And the pivot-code can internally always > call setEnableNode(false), first and then proceed with the > event-blocking code. > > Or > > B.1) How about a JSON style argument? I love this Pivot approach now ;). > setNodeAttributes ("{enableNode:No, 'disableUI:Yes'}"); > > I don't know how much parsing-work this JSON-style will involve but we > will be able to extend the attributes in future without adding more > setter calls. > > In future: > B.2) setNodeAttributes ("{EnableActivityIndicator:Yes'}") ;) > > >> ~Roger > > > thanks >
