[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] searchClient.js

I've been looking at https://bugs.eclipse.org/bugs/show_bug.cgi?id=347058, getting favorites to appear in the open resources dialog.  The problem that I am going to have is that the presentation of the search results is wrapped up in the implementation of searchClient.js.  I am going to want to present the favorites the same way as search results are presented, but this means I will have to copy the UI code somewhere so both favorites and search results will look the same in the open resources dialog.  This seems unfortunate to me.

A clean solution would be to have a way to decouple the collecting of the results from how they are presented.  This way we can handle the presentation in one location (like a label provider in the Eclipse world).  If this seems reasonable, I can work with Kris on a good implementation since this seems to span an area that we are both working on.

On Wed, Jan 25, 2012 at 8:13 AM, Susan Franklin McCourt <susan_franklin@xxxxxxxxxx> wrote:

Hi, Kris. First of all, thanks for jumping in and asking questions...

Libing and/or John is probably the right person to work with on getting the fix in, but here's my 2 cents in general:

1) I think we are trying to get away from too many API optional features if we can help it. So I wouldn't start out with the "find a way to turn on the 'add path' functionality." It's the safest, but kind of a copout way. I'm guilty of it myself. Back in Eclipse Platform, this would probably be my choice for a component that's been around forever, and I have no idea how many plugins are depending on the behavior, etc. etc. We have more freedom to do the right thing here.

>From a technical/conceptual point of view, "assume that it's the Ctrl+H implementations problem" is the one I would agree with. As you say, long files could cause the same problem. But then I think that the patch should probably try to clean up Ctrl+H itself if that's not opening too big of a can of worms. Another thing to realize is that we are approaching a milestone, so a fix that improves one area but makes another one look worse is probably not going to get in without some attention to the part that got worse.

2) For 2, I would say use the Orion global search feature on references to mSearchClient, etc....and from there see if there are more hits. My knowledge on this is out of date.

As a general point, I would just mention that some of these bugs might not get looked at til after this week because of our approaching M2 deadline, and all the committers are pretty swamped trying to wrap things up. So don't take that as a lack of interest...


Inactive hide details for Kris De Volder ---01/24/2012 06:31:10 PM---I created a fix for 336277. And no, this message is not abKris De Volder ---01/24/2012 06:31:10 PM---I created a fix for 336277. And no, this message is not about trying to get this fix applied ASAP. R

From: Kris De Volder <kdvolder@xxxxxxxxxx>
To: orion-dev@xxxxxxxxxxx
Date: 01/24/2012 06:31 PM
Subject: [orion-dev] searchClient.js
Sent by: orion-dev-bounces@xxxxxxxxxxx

I created a fix for 336277. And no, this message is not about trying to get this fix applied ASAP.
Rather, I'm having some second thoughts about the 'fix' so I'd like some feedback about some things I'm not so sure about.

All of my changes went into 'searchClient.js' and it does seem to fix what I was trying to fix. I.e. the 'open resource' dialog to look more like the desktop one, with ' - path/to/file' appended to entries that have the same file name.

However I fear about potential side-effects / breakage to other things. Since the searchClient seems to be a more general bit of functionality that's probably used by other things as well...

For one, there's the CTRL-H search function.

I tried that quickly and did find that my 'fix' may cause some UI problems there. The 'post-it' note that pops up for CTRL-H search results doesn't seem to have enough space for results if they have long path names appended to them. (Though I guess the same would probably happen if the file names where too long as well).

So 3 questions:
1) what should/could I do about the breakage of CTRL-H (some options I considered):
 - assume that its the CTRL-H implementations problem to deal with layout/spacing for its search results.
 - find a way to only turn on the 'add path' functionality for CTRL-SHIFT-R dialog
 - limit the length of the path strings somehow by chopping away bits if they are 'too long'.

2) are there other users of searchClient.js that I may have broken that I don't even know about?

orion-dev mailing list

orion-dev mailing list

GIF image