So, what you would like is for TreeView / TerraTreeViewSkin to keep track of the node enable/disable state and so instead of the application implementing a disabledNodeFilter the app would traverse the nodes on its own and call setNodeEnabled() on each and have TreeView keep (duplicate) track of the state?
Just trying to understand. And so what you're really asking for is a method in Component / ComponentSkin to disable UI interaction on disabled components in general? ~Roger -----Original Message----- From: Josh R [mailto:[email protected]] Sent: Thursday, August 23, 2012 11:58 AM To: [email protected] Subject: Re: How to block UI input to a disabled/busy TreeNode On Thu, Aug 23, 2012 at 1:24 PM, Roger Whitcomb <[email protected]> wrote: > 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. > Well, that's the whole point. The core libs should handle the node enable/disable part. The app knows when to enable/disable based on some internal state. So why should all the apps write their own nodeFilter function? > 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. > Ok, but contextMenu is one example. Assume it's an IDE like split-pane. And if a node is clicked on the left-side, the right-hand-side tabs get displayed. If you just block the mouse-event the apps don't need to worry about anything. Plus, it's a little cleaner in the sense that the event won't need to propagate to any other component[s] and their listeners. Performance wise too(how many ever function calls we can eliminate). So I feel that pivot-core should handle it and not the apps. thanks
