You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Josh R <tr...@gmail.com> on 2012/08/08 19:44:34 UTC
How to block UI input to a disabled/busy TreeNode
Hi,
My tree will have a bunch of nodes and depending on their state, they
would either be enabled/disabled/busy. I would like to block mouse
input to such disabled/busy nodes.
1) Busy-Indicator:
To implement busy-indicator functionality, I borrowed logic(thanks a
bunch Edvin!) from this thread:
http://apache-pivot-users.399431.n3.nabble.com/Animated-gifs-in-TreeView-node-icons-tt3074038.html#a3086067
The only changes I made were adding calls 'indicator.setActive(false)'
in hideIndicator() and setActive(true) in showIndicator(). Other than
that it was flawless.
2) Disabling-node:
Implemented setDisabledNodeFilter() - thanks to other posts in the mailing list.
my_tree.setDisabledNodeFilter(new Filter<TreeNode>() {
@Override
public boolean include(TreeNode node) {
// get state of this Node.
return (MyObj)node.getUserData().node_state;
}
}
For now, I fire a nodeUpdated call when a user selects the parent-node
of the busy/disabled node:
for (TreeViewNodeListener l : my_tree.getTreeViewNodeListeners())
l.nodeUpdated(my_tree, TreePath,child_idx);
So far so good. This works as expected with the exception that I can't
block UI input to such disabled/busy nodes.
I have added context-menu's to my node. So even when the node is
disabled(via setDisabledNodeFilter), the configureContextMenu() gets
called for such disabled/busy node. For now I'm checking the state of
the node and then just returning from configureContextMenu() call.
How can I block/prevent such UI inputs from reaching the node? Is
there a handy setDisabled(node) function somewhere? If not can it be
implemented?
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 5:36 PM, Sandro Martini <sa...@gmail.com> wrote:
> Hi all,
> some general info below ...
>
>> If adding this functionality to the base class would be considered code-bloat then it would be really great if pivot-developers could add some extended classes to pivot-contrib.
> Ok, this could be an initial solution ... have you got something (or
> are you interested in writing and sharing with us) ?
If I can get something to work by following Roger's directions then I
will certainly post it here.
> Note that maybe even under pivot-stuff you can find something useful ...
>
Infact, I search everything - demos/tutorials/stuff/tests :)
>> 100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
> This is a question that sometimes happens, and I have to say that it's
Just to make sure we are talking about the same thing - by 100% pivot
code, I meant code samples with 100% java code which does the
following(just as an example): add nodes/menus/scrollbars etc.
> true (for example to have all checked at compile time, etc ...), but
> the problem is that we lack time ...
I've managed to create a tree with a bunch of nodes/context-menus etc.
When I get stuck(as I move forward) I will post questions here.
>
>
> And to finish ... I keep more technical details on code for you and
> Roger :-) ... thanks again for now.
>
> Bye,
> Sandro
thanks to everyone for their prompt responses.
Re: How to block UI input to a disabled/busy TreeNode
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
some general info below ...
> If adding this functionality to the base class would be considered code-bloat then it would be really great if pivot-developers could add some extended classes to pivot-contrib.
Ok, this could be an initial solution ... have you got something (or
are you interested in writing and sharing with us) ?
Note that maybe even under pivot-stuff you can find something useful ...
> After spending almost a day on creating modal pop-ups, I found a link to pivot-contrib and saw the BlockingDialog class!
Yes, I'm thinking that after many months if could be useful to put
inside Pivot some of that work, for our 2.1 release, but for this I
have to contact the original author, and ask him if it's interested,
compile the ASF ICAL, and maybe become a Pivot Committer ...
> So the contrib approach is nice too. That way the base classes can stay lean.
Ok, at least for the initial solution.
> 100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
This is a question that sometimes happens, and I have to say that it's
true (for example to have all checked at compile time, etc ...), but
the problem is that we lack time ...
Many time ago I proposed a mixed approach, just as a idea, an
annotation to check at compile time bxml files (at various levels), to
use bxml files, but have some compile time checks ... but still it's
in the future things (but it's in JIRA).
> Also what if someone tampers the bxml?
Of course in your case even obfuscation it's not enough, you have to
deliver all signed jars, and maybe deploy using jnlp descriptor (could
be useful even if you deploy applets), to have other security checks
by the Java Runtime.
Note that there is another (not-so-shown) feature, or the ability to
load bxml files from an URL, for example from an HTTP/S Server (where
they could be managed in a central, safe place) ... and note that bxml
files could even be generated dynamically (from JSP or other web
frameworks). Just as idea.
I have just committed this week a small sample for this under our
tests subproject, search for JavaConsoleTest.java and related files
(it show even how to handle some logic at client side using a mix of
JavaScript interpreted by the JVM, and Java code) ... tomorrow I'll
send to our mailing lists a detailed post on this to see what user
think on this feature. I'd like to refine it and in future put under
our demos, but now it's too early.
And to finish ... I keep more technical details on code for you and
Roger :-) ... thanks again for now.
Bye,
Sandro
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Interesting. Thanks for the explanation. I'd actually never thought of / heard of that kind of thing happening, but that's good to know.
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 1:05 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 3:46 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
>> The application that I'm targeting is similar to IPMI remote login but a more complex version. Depending on the state of the host/hardware we might have to juggle different fields. So it's best to handle that in code rather than writing several different bxmls.
>
> Okay, got it. I can see how that would be hard to handle in bxml.
>
>> Also what if someone tampers the bxml?
>
> Interesting security question.... But, along that line, if someone is really interested in hacking your application, what's to prevent them disassembling the byte code back into Java source and changing it that way also? My point being that if there is a significant security risk if someone were to change the bxml (presumably they are in your packaged .jar file, right?) then you probably need to implement some other checks somewhere so that the application can (at least) detect if things have been tampered with since the .jar file was built?
>
> ~Roger
Hopefully some code obfuscator will work. The goal is to deter casual mischievous snoopers. I've seen a few cases where some folks at the customer site prefer vendor-A vs vendor-B and then they sometimes play dirty tricks and file support issues just to make the software-offering look bad.
The gui will talk to tightened *nix/BSD hosts which doesn't let users run privileged commands.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 3:46 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
>> The application that I'm targeting is similar to IPMI remote login but a more complex version. Depending on the state of the host/hardware we might have to juggle different fields. So it's best to handle that in code rather than writing several different bxmls.
>
> Okay, got it. I can see how that would be hard to handle in bxml.
>
>> Also what if someone tampers the bxml?
>
> Interesting security question.... But, along that line, if someone is really interested in hacking your application, what's to prevent them disassembling the byte code back into Java source and changing it that way also? My point being that if there is a significant security risk if someone were to change the bxml (presumably they are in your packaged .jar file, right?) then you probably need to implement some other checks somewhere so that the application can (at least) detect if things have been tampered with since the .jar file was built?
>
> ~Roger
Hopefully some code obfuscator will work. The goal is to deter casual
mischievous snoopers. I've seen a few cases where some folks at the
customer site prefer vendor-A vs vendor-B and then they sometimes play
dirty tricks and file support issues just to make the
software-offering look bad.
The gui will talk to tightened *nix/BSD hosts which doesn't let users
run privileged commands.
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
> The application that I'm targeting is similar to IPMI remote login but a more complex version. Depending on the state of the host/hardware we might have to juggle different fields. So it's best to handle that in code rather than writing several different bxmls.
Okay, got it. I can see how that would be hard to handle in bxml.
> Also what if someone tampers the bxml?
Interesting security question.... But, along that line, if someone is really interested in hacking your application, what's to prevent them disassembling the byte code back into Java source and changing it that way also? My point being that if there is a significant security risk if someone were to change the bxml (presumably they are in your packaged .jar file, right?) then you probably need to implement some other checks somewhere so that the application can (at least) detect if things have been tampered with since the .jar file was built?
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 12:36 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 3:21 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
>> Depending on the node-state, the menu might even be dynamic. But cases where the node needs to be completely disabled it's just easier if the base library handled that. That way we can also avoid replicating that code in every user's application.
>
> Got it. That's why I suggested filing a JIRA issue for an improvement. Thanks for that.
>
> Just curious -- what is your reason for writing 100% Java code? Our application uses ~100 bxml files and many are dynamically chosen. We found it easier to write even little bxml files for stuff rather than use Java code (if possible), although there is a bunch of pure Java code in some cases too. So, I was wondering what got you to the point of wanting only Java code?
>
Just filed it(Pivot-867).
The application that I'm targeting is similar to IPMI remote login but a more complex version. Depending on the state of the host/hardware we might have to juggle different fields. So it's best to handle that in code rather than writing several different bxmls. Also what if someone tampers the bxml?
>>100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
>
> Agreed, which is why I was wondering about your use case to consider how many others might be in the same place.
>
> Thanks,
> ~Roger
>
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 3:21 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
>> Depending on the node-state, the menu might even be dynamic. But cases where the node needs to be completely disabled it's just easier if the base library handled that. That way we can also avoid replicating that code in every user's application.
>
> Got it. That's why I suggested filing a JIRA issue for an improvement. Thanks for that.
>
> Just curious -- what is your reason for writing 100% Java code? Our application uses ~100 bxml files and many are dynamically chosen. We found it easier to write even little bxml files for stuff rather than use Java code (if possible), although there is a bunch of pure Java code in some cases too. So, I was wondering what got you to the point of wanting only Java code?
>
Just filed it(Pivot-867).
The application that I'm targeting is similar to IPMI remote login but
a more complex version. Depending on the state of the host/hardware we
might have to juggle different fields. So it's best to handle that in
code rather than writing several different bxmls. Also what if someone
tampers the bxml?
>>100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
>
> Agreed, which is why I was wondering about your use case to consider how many others might be in the same place.
>
> Thanks,
> ~Roger
>
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
> Depending on the node-state, the menu might even be dynamic. But cases where the node needs to be completely disabled it's just easier if the base library handled that. That way we can also avoid replicating that code in every user's application.
Got it. That's why I suggested filing a JIRA issue for an improvement. Thanks for that.
Just curious -- what is your reason for writing 100% Java code? Our application uses ~100 bxml files and many are dynamically chosen. We found it easier to write even little bxml files for stuff rather than use Java code (if possible), although there is a bunch of pure Java code in some cases too. So, I was wondering what got you to the point of wanting only Java code?
>100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
Agreed, which is why I was wondering about your use case to consider how many others might be in the same place.
Thanks,
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 12:10 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 2:43 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> Hmm, my feeling is that you're doing it the "right" way by checking the node state and not displaying a context menu if the node is "disabled". I don't think there is a "right" answer as to whether UI input should be enabled/disabled for a specific node if it is in the disabled state. You might, for instance, have a different context menu depending on whether a node is disabled (for example to enable it again in some cases) and so you would want the UI input to get through.
>
Yes, totally agree. Depending on the node-state, the menu might even be dynamic. But cases where the node needs to be completely disabled it's just easier if the base library handled that. That way we can also avoid replicating that code in every user's application.
If adding this functionality to the base class would be considered code-bloat then it would be really great if pivot-developers could add some extended classes to pivot-contrib. After spending almost a day on creating modal pop-ups, I found a link to pivot-contrib and saw the BlockingDialog class! So the contrib approach is nice too. That way the base classes can stay lean.
IMHO, busy/active indicators and capability to enable/disable nodes would be really nice to have.
> Of course, it might be possible to set a style on the tree as to
> whether or not disabled nodes pass through their input, but my feeling
> is that this is better left up to the user what to do..... My 2c...
> You could file a JIRA issue about this and we could think about it.
> Or you could implement it yourself and suggest it as a patch ;)
>
Ok, I will file a JIRA issue.
> Again, thanks for using Pivot.
> ~Roger Whitcomb
Thanks for your time Roger. I like pivot's look and feel, layout etc.
I personally feel that the code samples/demos should have also had parallel examples that don't use bxml at all. I am not an application developer and so it took me a while to translate the bxml to a working pivot code(100% java code). 100% pivot-code will also jump start developers relatively quickly and might trigger adoption at a higher rate.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 8:12 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Okay, I think the thing to do is this:
>
> myApp.startup(...) {
> ...
> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
> ...
>
> Then you don't need a MyTreeview class at all, and when you instantiate a TreeView it will automatically get the MyTreeSkin as its skin....
>
> See if that works.
Nope.
java.lang.IllegalArgumentException: java.lang.InstantiationException:
com.foobar.proto.main_proto$MyTreeSkin
at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:665)
at com.foobar.proto.main_proto.startup(main_proto.java:837)
>
> ~Roger
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Sandro Martini <sa...@gmail.com>.
Hi Josh,
> For now I extended the TerraTreeSkin class as suggested by Roger.
> However, I personally feel that many developers who use dynamic nodes will find this feature very helpful.
yes, I'm with you ...
> So a setxxx method in the pivot package to disable a node will be much appreciated.
Ok, but please could you post in the JIRA issue a patch for this (or a
block of code), to speedup our operations ?
If there aren't changes (but only additions) it could go in 2.0.3,
otherwise we have to wait 2.1 ...
Anyway for the patch (best case) you should synchronize your local
copy of Pivot sources with 2.0.x maintenance branch or trunk
(currently this part if the same), and then submit to jira.
Or otherwise put there a full source with your changes so we can look at it.
Thank you very much,
Sandro
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
I think your first point is actually distinct (although related) to your second one.
The current implementation of TreeView which uses a "disabledNodeFilter" and detects disabled nodes by calling the "isNodeDisabled(path)" (which uses the filter, if installed) is very usable without having to add a different interface.
Adding a style to the TerraTreeViewSkin to disable any mouse events on nodes that respond "true" to "isNodeDisabled(path)" is doable without changing the current way that disabled nodes are determined. I think this is a fairly simple change.
So, I'm not sure I see the advantages of having the TreeView maintain a separate "disabled" state when the disabled filter is already available as the mechanism for doing this....
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Thursday, August 23, 2012 1:40 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Thu, Aug 23, 2012 at 3:45 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> 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?
>
Yes, you got it. The TreeView would need to track disabled nodes(and the apps will track them internally too). I think a new field in
NodeInfo(?) or whichever object that maintains the state. I think I saw some bit-flag(in TerraTreeSkin) somewhere. But I don't know if it can be of help.
The apps will any way create their own Object and stash it using setUserData. And in response to some external event (link to the host is down or host is unreachable), the app can set it's internal field and then call disableMouse() or disableUI(). Hope this example helps.
> 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?
>
Sorry, I'm not an expert and so I don't know when you say ComponentSkin.But, yes some method to disable mouse events on a disabled node.
> ~Roger
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Thu, Aug 23, 2012 at 3:45 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> 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?
>
Yes, you got it. The TreeView would need to track disabled nodes(and
the apps will track them internally too). I think a new field in
NodeInfo(?) or whichever object that maintains the state. I think I
saw some bit-flag(in TerraTreeSkin) somewhere. But I don't know if it
can be of help.
The apps will any way create their own Object and stash it using
setUserData. And in response to some external event (link to the host
is down or host is unreachable), the app can set it's internal field
and then call disableMouse() or disableUI(). Hope this example helps.
> 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?
>
Sorry, I'm not an expert and so I don't know when you say
ComponentSkin.But, yes some method to disable mouse events on a
disabled node.
> ~Roger
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
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:tripanonyr@gmail.com]
Sent: Thursday, August 23, 2012 11:58 AM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Thu, Aug 23, 2012 at 1:24 PM, Roger Whitcomb <Ro...@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.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Thu, Aug 23, 2012 at 1:24 PM, Roger Whitcomb
<Ro...@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.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Roger Whitcomb <Ro...@rbwhitcomb.com>.
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
> <Ro...@actian.com> 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
>
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Thu, Aug 23, 2012 at 12:36 PM, Josh R <tr...@gmail.com> wrote:
> A.2) Second, if users want to disable event propagation then they can
> invoke setDisableUIOnNode(). And the pivot-code can internally always
.....
> B.1) How about a JSON style argument? I love this Pivot approach now ;).
> setNodeAttributes ("{enableNode:No, 'disableUI:Yes'}");
>
I think 'disableMouse' might sound more appropriate. What do you guys think?
So either a disableMouseOnNode() or setNodeAttributes(" {
'disableMouse:Yes' } ")
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Thu, Aug 23, 2012 at 12:19 PM, Roger L. Whitcomb
<Ro...@actian.com> 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
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
I'm kind of struggling with what to (succinctly) call the style.... "setDisableUIOnDisabledNodes(boolean)" seems a bit unwieldy.... any suggestions?
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Thursday, August 23, 2012 8:23 AM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Thu, Aug 23, 2012 at 5:43 AM, Sandro Martini <sa...@gmail.com> wrote:
> Hi all,
> excuse me, on the related JIRA issue here (
> https://issues.apache.org/jira/browse/PIVOT-867 ) there is something
> for us to do now or can we close safely (as won't fix or something
> other) ? Or maybe ad some javadoc comment in TreeView or related
> classes ?
Hi,
For now I extended the TerraTreeSkin class as suggested by Roger.
However, I personally feel that many developers who use dynamic nodes will find this feature very helpful.
So a setxxx method in the pivot package to disable a node will be much appreciated.
>
> Thanks,
> Sandro
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Thu, Aug 23, 2012 at 5:43 AM, Sandro Martini
<sa...@gmail.com> wrote:
> Hi all,
> excuse me, on the related JIRA issue here (
> https://issues.apache.org/jira/browse/PIVOT-867 ) there is something
> for us to do now or can we close safely (as won't fix or something
> other) ? Or maybe ad some javadoc comment in TreeView or related
> classes ?
Hi,
For now I extended the TerraTreeSkin class as suggested by Roger.
However, I personally feel that many developers who use dynamic nodes
will find this feature very helpful.
So a setxxx method in the pivot package to disable a node will be much
appreciated.
>
> Thanks,
> Sandro
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
excuse me, on the related JIRA issue here (
https://issues.apache.org/jira/browse/PIVOT-867 ) there is something
for us to do now or can we close safely (as won't fix or something
other) ? Or maybe ad some javadoc comment in TreeView or related
classes ?
Thanks,
Sandro
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Mon, Aug 20, 2012 at 2:58 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Hi Josh,
> So, I did some more studying and found a couple of things:
> 1) The code that actually processes context menus is in ApplicationContext.java (starting around line 928, if you've got the source code).
> 2) The logic that starts the process is in the "mouseDown" event handling (not "mouseClick" as we had it).
> 3) You could do (one of or both of) two things to disable the popup being shown:
> a) Return "true" (consumed) from the "mouseDown" handler of your tree in the case of a disabled node.
This works. I deleted mouseClick and moved the code in mouseDown. The
event is no longer propagated to the contextMenu handler.
> b) Return "true" (configured) from the "configureContextMenu" handler of your tree, BUT don't add any Menu.Sections to the menu in this case.
>
> HTH,
> ~Roger
>
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Hi Josh,
So, I did some more studying and found a couple of things:
1) The code that actually processes context menus is in ApplicationContext.java (starting around line 928, if you've got the source code).
2) The logic that starts the process is in the "mouseDown" event handling (not "mouseClick" as we had it).
3) You could do (one of or both of) two things to disable the popup being shown:
a) Return "true" (consumed) from the "mouseDown" handler of your tree in the case of a disabled node.
b) Return "true" (configured) from the "configureContextMenu" handler of your tree, BUT don't add any Menu.Sections to the menu in this case.
HTH,
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Saturday, August 18, 2012 9:31 AM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 8:58 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> Okay, I just compiled and tested this simple example and it worked (in
> so far as the TreeView was instantiated correctly and my custom skin
> was installed).
>
> Does your custom skin have a no-arg constructor? That's the only
> reason I can see that the "InstantiationException" would be thrown.
>
> HTH,
> ~Roger
>
> import org.apache.pivot.wtk.*;
> import org.apache.pivot.collections.*; import
> org.apache.pivot.wtk.skin.terra.*;
>
>
> public class Test extends Application.Adapter {
> public static class MyTreeSkin extends TerraTreeViewSkin
> {
> public MyTreeSkin() {
> System.out.println("MyTreeSkin()");
> }
> @Override
>
>
> public boolean mouseClick(Component component, Mouse.Button
> button, int x, int y, int count) {
> return super.mouseClick(component, button, x, y,
> count);
> }
> }
>
> @Override
> public void startup(Display display, Map<String,String> properties)
> {
> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
> new TreeView();
> }
>
> public static void main(String[] args) {
> DesktopApplicationContext.main(Test.class, args);
>
> }
> }
>
>
>
> -----Original Message-----
> From: Josh R [mailto:tripanonyr@gmail.com]
> Sent: Wed 8/8/2012 5:27 PM
> To: user@pivot.apache.org
> Subject: Re: How to block UI input to a disabled/busy TreeNode
>
> On Wed, Aug 8, 2012 at 8:12 PM, Roger L. Whitcomb
> <Ro...@actian.com> wrote:
>> Okay, I think the thing to do is this:
>>
>> myApp.startup(...) {
>> ...
>> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
>> ...
>>
>> Then you don't need a MyTreeview class at all, and when you instantiate a
>> TreeView it will automatically get the MyTreeSkin as its skin....
>>
>> See if that works.
>
> Nope.
>
>
> java.lang.IllegalArgumentException: java.lang.InstantiationException:
> com.foobar.proto.main_proto$MyTreeSkin
> at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
> at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
> at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
> at
> com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:665)
> at com.foobar.proto.main_proto.startup(main_proto.java:837)
>
>
>>
Thanks Roger. I was out so I couldn't try the code earlier. I was able
to extend the custom skin. There was some problem with eclipse(figured
that when your code wasn't working in my IDE). I had to right-click on
the project and choose, Run-As to get it going again...
So getting back to the question - blocking UI input to a TreeNode:
Now this is what I do in my extended MyTreeSkin::mouseClick function:
mouseClick(component, mouse ...) {
boolean consumed=true;
// get the node from the Tree...
// read the node's state...
if (my_node.disable_node)
return consumed;
else
return super.mouseClick();
}
Now, MyTreeView has a right-contextMenu setup via the setMenuHandler.
So when I return 'consumed' from mouseClick above (which would imply
the click was consumed), I was expecting the contextMenu to not get
called. However, my contextMenu() is still getting called for this
node.
Do we need to add anything else too to block the event propagation?
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 8:58 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Okay, I just compiled and tested this simple example and it worked (in so
> far as the TreeView was instantiated correctly and my custom skin was
> installed).
>
> Does your custom skin have a no-arg constructor? That's the only reason I
> can see that the "InstantiationException" would be thrown.
>
> HTH,
> ~Roger
>
> import org.apache.pivot.wtk.*;
> import org.apache.pivot.collections.*;
> import org.apache.pivot.wtk.skin.terra.*;
>
>
> public class Test extends Application.Adapter
> {
> public static class MyTreeSkin extends TerraTreeViewSkin
> {
> public MyTreeSkin() {
> System.out.println("MyTreeSkin()");
> }
> @Override
>
>
> public boolean mouseClick(Component component, Mouse.Button
> button, int x, int y, int count) {
> return super.mouseClick(component, button, x, y,
> count);
> }
> }
>
> @Override
> public void startup(Display display, Map<String,String> properties)
> {
> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
> new TreeView();
> }
>
> public static void main(String[] args) {
> DesktopApplicationContext.main(Test.class, args);
>
> }
> }
>
>
>
> -----Original Message-----
> From: Josh R [mailto:tripanonyr@gmail.com]
> Sent: Wed 8/8/2012 5:27 PM
> To: user@pivot.apache.org
> Subject: Re: How to block UI input to a disabled/busy TreeNode
>
> On Wed, Aug 8, 2012 at 8:12 PM, Roger L. Whitcomb
> <Ro...@actian.com> wrote:
>> Okay, I think the thing to do is this:
>>
>> myApp.startup(...) {
>> ...
>> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
>> ...
>>
>> Then you don't need a MyTreeview class at all, and when you instantiate a
>> TreeView it will automatically get the MyTreeSkin as its skin....
>>
>> See if that works.
>
> Nope.
>
>
> java.lang.IllegalArgumentException: java.lang.InstantiationException:
> com.foobar.proto.main_proto$MyTreeSkin
> at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
> at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
> at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
> at
> com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:665)
> at com.foobar.proto.main_proto.startup(main_proto.java:837)
>
>
>>
Thanks Roger. I was out so I couldn't try the code earlier. I was able
to extend the custom skin. There was some problem with eclipse(figured
that when your code wasn't working in my IDE). I had to right-click on
the project and choose, Run-As to get it going again...
So getting back to the question - blocking UI input to a TreeNode:
Now this is what I do in my extended MyTreeSkin::mouseClick function:
mouseClick(component, mouse ...) {
boolean consumed=true;
// get the node from the Tree...
// read the node's state...
if (my_node.disable_node)
return consumed;
else
return super.mouseClick();
}
Now, MyTreeView has a right-contextMenu setup via the setMenuHandler.
So when I return 'consumed' from mouseClick above (which would imply
the click was consumed), I was expecting the contextMenu to not get
called. However, my contextMenu() is still getting called for this
node.
Do we need to add anything else too to block the event propagation?
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 8:58 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Okay, I just compiled and tested this simple example and it worked (in so
> far as the TreeView was instantiated correctly and my custom skin was
> installed).
>
> Does your custom skin have a no-arg constructor? That's the only reason I
> can see that the "InstantiationException" would be thrown.
Yes, the custom skin class is exactly like yours. Even a simple 'new
TreeView()' instantiation doesn't work. It throws the same exception.
I will try to reproduce the error with a bare minimal tree and post
the code here.
thanks for your help.
>
> HTH,
> ~Roger
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Okay, I just compiled and tested this simple example and it worked (in so far as the TreeView was instantiated correctly and my custom skin was installed).
Does your custom skin have a no-arg constructor? That's the only reason I can see that the "InstantiationException" would be thrown.
HTH,
~Roger
import org.apache.pivot.wtk.*;
import org.apache.pivot.collections.*;
import org.apache.pivot.wtk.skin.terra.*;
public class Test extends Application.Adapter
{
public static class MyTreeSkin extends TerraTreeViewSkin
{
public MyTreeSkin() {
System.out.println("MyTreeSkin()");
}
@Override
public boolean mouseClick(Component component, Mouse.Button button, int x, int y, int count) {
return super.mouseClick(component, button, x, y, count);
}
}
@Override
public void startup(Display display, Map<String,String> properties) {
Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
new TreeView();
}
public static void main(String[] args) {
DesktopApplicationContext.main(Test.class, args);
}
}
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wed 8/8/2012 5:27 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 8:12 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Okay, I think the thing to do is this:
>
> myApp.startup(...) {
> ...
> Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
> ...
>
> Then you don't need a MyTreeview class at all, and when you instantiate a TreeView it will automatically get the MyTreeSkin as its skin....
>
> See if that works.
Nope.
java.lang.IllegalArgumentException: java.lang.InstantiationException:
com.foobar.proto.main_proto$MyTreeSkin
at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:665)
at com.foobar.proto.main_proto.startup(main_proto.java:837)
>
> ~Roger
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Okay, I think the thing to do is this:
myApp.startup(...) {
...
Theme.getTheme().set(TreeView.class, MyTreeSkin.class);
...
Then you don't need a MyTreeview class at all, and when you instantiate a TreeView it will automatically get the MyTreeSkin as its skin....
See if that works.
~Roger
-----Original Message-----
From: Roger L. Whitcomb [mailto:Roger.Whitcomb@actian.com]
Sent: Wednesday, August 08, 2012 4:53 PM
To: user@pivot.apache.org
Subject: RE: How to block UI input to a disabled/busy TreeNode
Yeah. Let me think about this. What I suggested works for some simpler components that don't install their skins already (xxx extends Button for instance, because Button is a fairly abstract class) but will not work for TreeView. But I know others have done similar things, I'm just blanking out at the moment on how to do it. *shame* I'll keep looking.
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 4:29 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 7:16 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> Doh! Try this instead:
> public MyTree() {
> setTreeData(new ArrayList<Object>());
> setSkin(new MyTreeSkin());
> }
>
nope. same exception:
java.lang.IllegalStateException: Skin is already installed.
at org.apache.pivot.wtk.Component.setSkin(Component.java:764)
at org.apache.pivot.wtk.TreeView.setSkin(TreeView.java:941)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:91)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:664)
at com.foobar.proto.main_proto.startup(main_proto.java:836)
> ~Roger
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Yeah. Let me think about this. What I suggested works for some simpler components that don't install their skins already (xxx extends Button for instance, because Button is a fairly abstract class) but will not work for TreeView. But I know others have done similar things, I'm just blanking out at the moment on how to do it. *shame* I'll keep looking.
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 4:29 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 7:16 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> Doh! Try this instead:
> public MyTree() {
> setTreeData(new ArrayList<Object>());
> setSkin(new MyTreeSkin());
> }
>
nope. same exception:
java.lang.IllegalStateException: Skin is already installed.
at org.apache.pivot.wtk.Component.setSkin(Component.java:764)
at org.apache.pivot.wtk.TreeView.setSkin(TreeView.java:941)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:91)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:664)
at com.foobar.proto.main_proto.startup(main_proto.java:836)
> ~Roger
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 7:16 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Doh! Try this instead:
> public MyTree() {
> setTreeData(new ArrayList<Object>());
> setSkin(new MyTreeSkin());
> }
>
nope. same exception:
java.lang.IllegalStateException: Skin is already installed.
at org.apache.pivot.wtk.Component.setSkin(Component.java:764)
at org.apache.pivot.wtk.TreeView.setSkin(TreeView.java:941)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:91)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:664)
at com.foobar.proto.main_proto.startup(main_proto.java:836)
> ~Roger
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Doh! Try this instead:
public MyTree() {
setTreeData(new ArrayList<Object>());
setSkin(new MyTreeSkin());
}
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 3:49 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 6:46 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
> Try just:
> public MyTree() {
> super();
> setSkin(new MyTreeSkin());
> }
>
> And then you don't need any theme code in your startup method.
>
I tried that earlier and got 'skin is already installed' exception.
java.lang.IllegalStateException: Skin is already installed.
at org.apache.pivot.wtk.Component.setSkin(Component.java:764)
at org.apache.pivot.wtk.TreeView.setSkin(TreeView.java:941)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:89)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:662)
at com.foobar.proto.main_proto.startup(main_proto.java:834)
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 6:46 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Try just:
> public MyTree() {
> super();
> setSkin(new MyTreeSkin());
> }
>
> And then you don't need any theme code in your startup method.
>
I tried that earlier and got 'skin is already installed' exception.
java.lang.IllegalStateException: Skin is already installed.
at org.apache.pivot.wtk.Component.setSkin(Component.java:764)
at org.apache.pivot.wtk.TreeView.setSkin(TreeView.java:941)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:89)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:662)
at com.foobar.proto.main_proto.startup(main_proto.java:834)
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Try just:
public MyTree() {
super();
setSkin(new MyTreeSkin());
}
And then you don't need any theme code in your startup method.
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 3:31 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 5:57 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
>> Can something like this work?
>
> Um, not quite. The skin can only be set once, so you would have to create a new component: MyTreeView and a new skin MyTerraTreeViewSkin, and in the constructor of the MyTreeView call "setSkin" to your MyTreeViewSkin.
>
public class MyTreeSkin extends TerraTreeViewSkin {
public MyTreeSkin () {
super();
}
public boolean mouseClick(Component component, Mouse.Button button, int x, int y, int count) {
System.out.println("SKIN comp:"+component.toString());
return super.mouseClick(component, button, x, y, count);
}
}
public class MyTree extends TreeView {
public MyTree() {
super();
installSkin(TreeView.class);
}
}
in startup(display,...) {
this.display = display;
Theme.getTheme().set( TreeView.class, MyTreeSkin.class); .....
}
I'm getting an exception:
java.lang.IllegalArgumentException: java.lang.InstantiationException:
com.foobar.proto.main_proto$MyTreeSkin
at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:86)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:662)
at com.foobar.proto.main_proto.startup(main_proto.java:834)
And:
public void create_hosts_tree() {
my_tree = new MyTree();
...
}
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 5:57 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
>> Can something like this work?
>
> Um, not quite. The skin can only be set once, so you would have to create a new component: MyTreeView and a new skin MyTerraTreeViewSkin, and in the constructor of the MyTreeView call "setSkin" to your MyTreeViewSkin.
>
public class MyTreeSkin extends TerraTreeViewSkin {
public MyTreeSkin () {
super();
}
public boolean mouseClick(Component component, Mouse.Button button,
int x, int y, int count) {
System.out.println("SKIN comp:"+component.toString());
return super.mouseClick(component, button, x, y, count);
}
}
public class MyTree extends TreeView {
public MyTree() {
super();
installSkin(TreeView.class);
}
}
in startup(display,...) {
this.display = display;
Theme.getTheme().set( TreeView.class, MyTreeSkin.class);
.....
}
I'm getting an exception:
java.lang.IllegalArgumentException: java.lang.InstantiationException:
com.foobar.proto.main_proto$MyTreeSkin
at org.apache.pivot.wtk.Component.installSkin(Component.java:834)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:924)
at org.apache.pivot.wtk.TreeView.<init>(TreeView.java:908)
at com.foobar.proto.main_proto$MyTree.<init>(main_proto.java:86)
at com.foobar.proto.main_proto.create_hosts_tree(main_proto.java:662)
at com.foobar.proto.main_proto.startup(main_proto.java:834)
And:
public void create_hosts_tree() {
my_tree = new MyTree();
...
}
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
> Can something like this work?
Um, not quite. The skin can only be set once, so you would have to create a new component: MyTreeView and a new skin MyTerraTreeViewSkin, and in the constructor of the MyTreeView call "setSkin" to your MyTreeViewSkin.
But, otherwise your MyTreeViewSkin would override "mouseClick" as you suggest, so that part should be okay.
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 2:47 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 5:36 PM, Roger L. Whitcomb <Ro...@actian.com> wrote:
<snip>
>
> So, you would need to make a new style in TerraTreeViewSkin (with get/set methods). Then if the style value is set, then when you get an input event (mouse click), get the tree node in that position and check if there is a disabled filter set, check the node with the filter and if the node is included, then eat the mouse click....
>
Thanks for the explanation. Can something like this work?
class MyTreeSkin extends TerraTreeViewSkin { // for now as a quick hack - override mouseClick (...) // then in mouseClick check which node was clicked and then check the state of that node and decide whether or not to consume this click.
}
and then:
my_tree.getTreeViewSelectionListeners().add(new MyTreeSkin());
> ~Roger
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 5:36 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
<snip>
>
> So, you would need to make a new style in TerraTreeViewSkin (with get/set methods). Then if the style value is set, then when you get an input event (mouse click), get the tree node in that position and check if there is a disabled filter set, check the node with the filter and if the node is included, then eat the mouse click....
>
Thanks for the explanation. Can something like this work?
class MyTreeSkin extends TerraTreeViewSkin {
// for now as a quick hack - override mouseClick (...)
// then in mouseClick check which node was clicked and then check the
state of that node and decide whether or not to consume this click.
}
and then:
my_tree.getTreeViewSelectionListeners().add(new MyTreeSkin());
> ~Roger
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Renderers are only called for painting and never get any input events (either mouse or keyboard), so that's why your mouse click listener never gets called.
The other problem is that TreeBranch and TreeNode are both "content" objects and not components, so they don't have an independent "enabled" state like a component does. Also, there is no requirement that objects in a TreeView have to be our TreeNode or TreeBranch objects. They basically could be any objects that have properties that the current tree node renderer can deal with.
I'm thinking what you would need to do is check if the node under the mouse is present in the disabled filter list (if any) and just eat the mouse event in that case (if the new style for disabling input events for disabled nodes) is set.
So, you would need to make a new style in TerraTreeViewSkin (with get/set methods). Then if the style value is set, then when you get an input event (mouse click), get the tree node in that position and check if there is a disabled filter set, check the node with the filter and if the node is included, then eat the mouse click....
Something like that.
HTH,
~Roger
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 2:17 PM
To: user@pivot.apache.org
Subject: Re: How to block UI input to a disabled/busy TreeNode
On Wed, Aug 8, 2012 at 3:09 PM, Josh R <tr...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 2:43 PM, Roger L. Whitcomb
>> Of course, it might be possible to set a style on the tree as to
>> whether or not disabled nodes pass through their input, but my
>> feeling is that this is better left up to the user what to do..... My
>> 2c... You could file a JIRA issue about this and we could think
>> about it. Or you could implement it yourself and suggest it as a
>> patch ;)
>>
TerraTreeViewSkin::mouseClick calls " boolean consumed = super.mouseClick(component, button, x, y, count); " Is this something that would need to be changed?
So may be when a new function " TreeBranch.setEnabled(false)" is called then the nodeInfo's attributes are set/reset and then check
nodeInfo.isDisabled() before calling super.mouseClick() ?
Anyways, for now in my "BusyCapableNodeRenderer extends TreeViewNodeRenderer " class, I'm doing this:
public BusyCapableNodeRenderer(TreeView treeView) {
this.treeView = treeView;
this.getComponentMouseButtonListeners().add(new
ComponentMouseButtonListener.Adapter () {
public boolean mouseClick(Component component, Mouse.Button button, int x, int y, int count) {
System.out.println("comp:"+component.toString()); // print and check if it's a tree...
return false;
}
}
);
}
Is this correct? The mouseclick listener isn't getting called. If possible, I was thinking of blocking the mouse event here.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 3:09 PM, Josh R <tr...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 2:43 PM, Roger L. Whitcomb
>> Of course, it might be possible to set a style on the tree as to whether or not disabled nodes pass through their input, but my feeling is that this is better left up to the user what to do..... My 2c... You could file a JIRA issue about this and we could think about it. Or you could implement it yourself and suggest it as a patch ;)
>>
TerraTreeViewSkin::mouseClick calls " boolean consumed =
super.mouseClick(component, button, x, y, count); " Is this something
that would need to be changed?
So may be when a new function " TreeBranch.setEnabled(false)" is
called then the nodeInfo's attributes are set/reset and then check
nodeInfo.isDisabled() before calling super.mouseClick() ?
Anyways, for now in my "BusyCapableNodeRenderer extends
TreeViewNodeRenderer " class, I'm doing this:
public BusyCapableNodeRenderer(TreeView treeView) {
this.treeView = treeView;
this.getComponentMouseButtonListeners().add(new
ComponentMouseButtonListener.Adapter () {
public boolean mouseClick(Component component, Mouse.Button
button, int x, int y, int count) {
System.out.println("comp:"+component.toString()); // print and
check if it's a tree...
return false;
}
}
);
}
Is this correct? The mouseclick listener isn't getting called. If
possible, I was thinking of blocking the mouse event here.
thanks
Re: How to block UI input to a disabled/busy TreeNode
Posted by Josh R <tr...@gmail.com>.
On Wed, Aug 8, 2012 at 2:43 PM, Roger L. Whitcomb
<Ro...@actian.com> wrote:
> Hmm, my feeling is that you're doing it the "right" way by checking the node state and not displaying a context menu if the node is "disabled". I don't think there is a "right" answer as to whether UI input should be enabled/disabled for a specific node if it is in the disabled state. You might, for instance, have a different context menu depending on whether a node is disabled (for example to enable it again in some cases) and so you would want the UI input to get through.
>
Yes, totally agree. Depending on the node-state, the menu might even
be dynamic. But cases where the node needs to be completely disabled
it's just easier if the base library handled that. That way we can
also avoid replicating that code in every user's application.
If adding this functionality to the base class would be considered
code-bloat then it would be really great if pivot-developers could add
some extended classes to pivot-contrib. After spending almost a day on
creating modal pop-ups, I found a link to pivot-contrib and saw the
BlockingDialog class! So the contrib approach is nice too. That way
the base classes can stay lean.
IMHO, busy/active indicators and capability to enable/disable nodes
would be really nice to have.
> Of course, it might be possible to set a style on the tree as to whether or not disabled nodes pass through their input, but my feeling is that this is better left up to the user what to do..... My 2c... You could file a JIRA issue about this and we could think about it. Or you could implement it yourself and suggest it as a patch ;)
>
Ok, I will file a JIRA issue.
> Again, thanks for using Pivot.
> ~Roger Whitcomb
Thanks for your time Roger. I like pivot's look and feel, layout etc.
I personally feel that the code samples/demos should have also had
parallel examples that don't use bxml at all. I am not an application
developer and so it took me a while to translate the bxml to a working
pivot code(100% java code). 100% pivot-code will also jump start
developers relatively quickly and might trigger adoption at a higher
rate.
thanks
RE: How to block UI input to a disabled/busy TreeNode
Posted by "Roger L. Whitcomb" <Ro...@actian.com>.
Hmm, my feeling is that you're doing it the "right" way by checking the node state and not displaying a context menu if the node is "disabled". I don't think there is a "right" answer as to whether UI input should be enabled/disabled for a specific node if it is in the disabled state. You might, for instance, have a different context menu depending on whether a node is disabled (for example to enable it again in some cases) and so you would want the UI input to get through.
Of course, it might be possible to set a style on the tree as to whether or not disabled nodes pass through their input, but my feeling is that this is better left up to the user what to do..... My 2c... You could file a JIRA issue about this and we could think about it. Or you could implement it yourself and suggest it as a patch ;)
Again, thanks for using Pivot.
~Roger Whitcomb
-----Original Message-----
From: Josh R [mailto:tripanonyr@gmail.com]
Sent: Wednesday, August 08, 2012 10:45 AM
To: user@pivot.apache.org
Subject: How to block UI input to a disabled/busy TreeNode
Hi,
My tree will have a bunch of nodes and depending on their state, they would either be enabled/disabled/busy. I would like to block mouse input to such disabled/busy nodes.
1) Busy-Indicator:
To implement busy-indicator functionality, I borrowed logic(thanks a bunch Edvin!) from this thread:
http://apache-pivot-users.399431.n3.nabble.com/Animated-gifs-in-TreeView-node-icons-tt3074038.html#a3086067
The only changes I made were adding calls 'indicator.setActive(false)'
in hideIndicator() and setActive(true) in showIndicator(). Other than that it was flawless.
2) Disabling-node:
Implemented setDisabledNodeFilter() - thanks to other posts in the mailing list.
my_tree.setDisabledNodeFilter(new Filter<TreeNode>() {
@Override
public boolean include(TreeNode node) {
// get state of this Node.
return (MyObj)node.getUserData().node_state;
}
}
For now, I fire a nodeUpdated call when a user selects the parent-node of the busy/disabled node:
for (TreeViewNodeListener l : my_tree.getTreeViewNodeListeners())
l.nodeUpdated(my_tree, TreePath,child_idx);
So far so good. This works as expected with the exception that I can't block UI input to such disabled/busy nodes.
I have added context-menu's to my node. So even when the node is disabled(via setDisabledNodeFilter), the configureContextMenu() gets called for such disabled/busy node. For now I'm checking the state of the node and then just returning from configureContextMenu() call.
How can I block/prevent such UI inputs from reaching the node? Is there a handy setDisabled(node) function somewhere? If not can it be implemented?
thanks