pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh R <tripano...@gmail.com>
Subject Re: How to block UI input to a disabled/busy TreeNode
Date Thu, 23 Aug 2012 18:58:24 GMT
On Thu, Aug 23, 2012 at 1:24 PM, Roger Whitcomb
<RogerandBeth@rbwhitcomb.com> 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.


View raw message