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
