Community
Participate
Working Groups
I am not sure how feasible or concrete this is (with the existing FilteredTree ). But this could be quite useful. This is for tree widget having multiple columns. The filtered tree could use a dropdown menu next to the text widget ( like the small black triangle next to the text on OpenResourceDialog ) to select a ' filtering-criterion' column. The menuitems could be various column names. The filtering could happen based on the selected column. This is the first thing that comes to my mind when dealing with large trees and locating items by a particular criterion.
Sounds useful if it's not too hard to implement... Dani? BTW, if I shouldn't be sending these your way just punt it back with a note...
>Dani? BTW, if I shouldn't be sending these your way just punt it back with a >note... Moving back. I prefer to have bugs in my inbox where I plan to work on and not as a bin to group components. In Text land we use the category keywords ([blah]) in the summary to do this and move the bug from new to assigned inbox.
(In reply to comment #2) > >Dani? BTW, if I shouldn't be sending these your way just punt it back with a > >note... > Moving back. I prefer to have bugs in my inbox where I plan to work on and not > as a bin to group components. The Platform UI policy is to triage them out of the inbox immediately (if it is in the inbox, it will just be triaged again in a couple of days). Stuff left in the inbox messes with our scripts. We could move it to the text inbox if you would prefer. PW
>Stuff left in the inbox messes with our scripts. Well, now it messes with my personal inbox ;-) >We could move it to the text inbox if you would prefer. Nope, as the name says: it is the inbox for text bugs. I started to discuss with Boris whether Platform UI should allow bugs which are not actively being worked on to live as ASSIGNED in the inbox. The scripts would triage the NEW bugs only and the committer that gets the bug (and is on the cc-list from then on) can move it back to the inbox but directly with ASSIGNED state. Boris will probably discuss this with you guys in today's UI meeting.
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.
