Community
Participate
Working Groups
When population of children treeitems is done using a background job, a "Pending" TreeItem is places as child 0 of the container treeitem. When the job completes, this treeitem is disposed. So, when the user places the mouse over an item and tries to select it, the item often moves up one position because of the above disposal. To avoid the sifting, the "Pending" item could be the last child instead of the first, since that is where the pending children show up. Or, the parent treeitem could be decorated in its string to show something like: "cdt-home (pending)"
Sorry for the typos. should say "placed" and "shifting". And the point is that the user ends up selecting the treeitem below the intended selection.
I've always prefered decorating the parent instead of using the pending child node. That way if the node is somehow collapsed, you can still understand that it's fetching child nodes.
I originally posted this to UI because I'm not sure if CVS is the only example of this "pending" treeitem. If you know of other examples, feel free to pass the bugzilla around? or open a new one?
Post 3.0
The Pending itme is provided by the workbench. Tod, I wasn't sure what component this should fall under. If Progress is not right, please reassign accordingly.
There are currently no plans to work on this although we would be happy to review patches.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
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.
