Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 389431

Summary:	improve the section filtering support
Product:	[ECD] Orion	Reporter:	Susan McCourt <susan>
Component:	Client	Assignee:	Project Inbox <orion.client-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	maciej.bendkowski, Szymon.Brandys
Version:	0.5
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Susan McCourt

2012-09-12 12:45:53 EDT

I really appreciate that we can filter branches now in the repo page.  Here's some feedback...

- the vertical alignment of the combo box is not quite right, the baselines of the section header and combo content don't align
- I wonder if we need the combo box at all.  As it is now, I get a combo box with the filtered branches and then I can cursor around to pick one.  But it seems like the goal in a filter box shouldn't be to "pick one".  If I pick one, I get one branch in the list, but I still need to act on the branch in the list.  Instead, could we just do live filtering of the explorer itself, so that the list of branches gets smaller as I type in the filter box?
- I haven't looked at the code yet, I'm wondering if this implemented in a generic way or not.  We should probably support it at the section level or maybe in explorers.  Perhaps that's a separate bug.  (for example see bug 389309).

Comment 1 Maciej Bendkowski

2012-09-17 05:49:36 EDT

(In reply to comment #0)
> - I wonder if we need the combo box at all.  As it is now, I get a combo box
> with the filtered branches and then I can cursor around to pick one.  But it
> seems like the goal in a filter box shouldn't be to "pick one".  If I pick
> one, I get one branch in the list, but I still need to act on the branch in
> the list.  Instead, could we just do live filtering of the explorer itself,
> so that the list of branches gets smaller as I type in the filter box?

Right now, it does a live filtering only if you press enter (submit). This way you do not have to filter just one. Type in 'bug38' and press enter to see the result. I intentionally decided to filter on the onChange event for efficiency. Rendering one row costs about 10-20ms on my machine. In this situation the best option is to render on the 'onChange' event or after the user types some text and stops for a second or more (as I understand your suggestion). We can experiment with this second option if you wish, but I'm a little bit skeptical about it.

> - I haven't looked at the code yet, I'm wondering if this implemented in a
> generic way or not.  We should probably support it at the section level or
> maybe in explorers.  Perhaps that's a separate bug.  (for example see bug
> 389309).

It is implemented in a generic way, just for now as a git widget (but could be placed anywhere). I added a section hook and render the widget in the repository explorer. Should be quite easy to use in another place for any other item.

Notice just one think. Right now it's implemented quite naive. I load all items into the widget and do all filtering locally, because I don't have any server API which would support asynchronous item filtering (see bug 389262). For efficiency the filtering should be done on the server via a separate xhr call.

Comment 2 Szymon Brandys

2015-04-01 10:29:22 EDT

I don't think we want to do any work in this area.