|Re: [orion-dev] searchClient.js|
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...
Kris 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>
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