Community
Participate
Working Groups
Created attachment 105085 [details] work in progress Just capturing my work so far - this snippet demonstrates async and checkbox, but does not have filtering support. It also needs clean up.
Susan - if you have time, could you give this a try and run the snippet? It would be good to know if I got it right at least so far...
so far, so good. Already better than what p2 has. I like that the check on a parent starts the async fetch right away without having to expand anything. Also that you can play with the state of the pending node during the fetch and have that state honored.
Created attachment 105213 [details] now with filtering Other than an occasional gray-check state that I haven't tracked down, this seems to be working now. Before I go and clean up the code, it would be good to know if the behaviour is correct. (Note that for testing refresh, you can trigger it by double-clicking on a repository node.)
This looks really promising. Some things I noticed right away: - FilteredTree causes an expansion of elements when it filters, so the user sees immediately the effects of filtering. So SDK users are used to this behavior in the pref dialog, show view, p2, etc. In this example, the expansion state does not change on filtering. I think it's safe to assume that the filtered items should be made visible with whatever mechanism makes the most sense - If I expand a site and checkmark the "Pending..." node, the pending node and the site get a checkmark (good). But when "Pending..." is replaced with the actual categories, they are not checkmarked, but the site remains checked. If I expand the categories, then the items show up with checkmarks and the category gets check marked. The end state is correct, but the visuals are wrong until the category is expanded. - I'm hoping/assuming I can make use of the bold label providers that automatically bold the filtered items. I'll try this. As a next step, I will look more closely at the client-side/example code and see how to integrate into an alternate version of the p2 available IU group. That will surface the next level of issues.
Created attachment 106468 [details] updated patch after merging conflicting changes
Thanks, Boris. I've been away from this patch for a little while dealing with other things and taking a little vacation but plan to return to it next week.
(In reply to comment #5) > - If I expand a site and checkmark the "Pending..." node, the pending node and > the site get a checkmark (good). But when "Pending..." is replaced with the > actual categories, they are not checkmarked, but the site remains checked. If I > expand the categories, then the items show up with checkmarks and the category > gets check marked. The end state is correct, but the visuals are wrong until > the category is expanded. This is caused by the test for instanceof IU in the known elements set listener. Remove the instanceof test and the items are checked as expected.
Thanks, Matt, I'll have a look at that.
Boris, the snippet uses a timer exec to fake the delay, so the long op is still happening the UI thread. In my case I am doing network access and can't tie up the UI thread. Is it my responsibility then, to start a background job and when it is complete, I would add the result to the observable in the UI thread? I haven't quite groked what the deferred observable changes are doing for me...
(In reply to comment #10) > Boris, the snippet uses a timer exec to fake the delay, so the long op is still > happening the UI thread. In my case I am doing network access and can't tie up > the UI thread. Is it my responsibility then, to start a background job and > when it is complete, I would add the result to the observable in the UI thread? Yes - I used timerExec to simulate a background thread that does some work and then uses asyncExec to update state in the UI thread.
(In reply to comment #10) > I haven't quite groked what the deferred observable changes are doing for > me... The problem is that you are wanting to set the check state of elements as they are added to the viewer, but getKnownElements() is updated before the elements have been realized. getKnownElements() was originally written to support label providers so we have to populate the set before we add new elements to the viewer, so that the correct labels will be available. The solution that we are contemplating now (and there is some disagreement about this approach) is to introduce another set, getRealizedElements(), which is updated while the element is present in the viewer. Thus by monitoring this set you will be able to set the check state of new elements right after they are added, and save the check state of elements right before they are removed.
Created attachment 111741 [details] Updated patch using getRealizedElements()
Created attachment 114127 [details] Fixed to apply properly I tried the latest patch, and had trouble applying it. Attached is an updated version which should apply properly. I ran it, and there seem to be some noticeable problems with the logic. Here are some examples: - Check Eclipse SDK Update Site, then expand. After the delay, its children are unchecked. - Type "abc" into the textbox and the console spills stack traces for NPEs then crashes. - Due to the crashing, I'm having trouble reproducing this one, but often the filtering/unfiltering causes inconsistent checkbox states.
Boris, see bug #233269. I elected in the end not to use data binding for my problems, mainly because the success wasn't instant enough for me to bite off learning how to debug and work through the issues I had. So I ended up doing a refactoring/simplification on the p2 side. I still think it's useful/important to support filtering/checkbox/async retrieval in data binding and if I were already using data binding, I would have pushed harder on this. (I also think it's important to address the selection maintenance problems that plague ContainerCheckedTreeViewer, but I think there is a different bug for that, and I am able to work around that.) Thanks for your time on this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
