Community
Participate
Working Groups
As part a SoC 2007 project we decided to create a lightweight "Find/Replace" that will be both easier to use and solve issues like https://bugs.eclipse.org/bugs/show_bug.cgi?id=36985 . Our current model is Firefox find right now, but there'll also be a floating menu that should display advanced options about Find/Replace. Ease of use and better GUI utilization is our major concern. When finished Incremental Search and Find/Replace will be combined into one GUI component. I tried to create a prototype figure and attached it. (Think of the bar with "Replace" field as a bar that can hold advanced parameters, figure doesn't show all the features - copied directly from Firefox's current Find) We'd like to hear any opinions about possible enhancements,visual look and behaviour from Eclipse users and developers. Thank you.
Created attachment 73077 [details] Prototype figure Prototype figure showing "Find" field together with a floating menu of advanced options.
Very nice. It's is great to see the progress that you've made already. I had a chat about the need for kind of UI with Kevin McGuire at EclipseCon so I'm CC'ing him. While I realize that the trim bar is a better place to prototype this, in the long-run I agree with Eugene's comment on the GSoC blog that the Find bar would be best attached to the workbench part (in this case an editor) that it was invoked from. Some benefits: 1) If there is a view, such as Problems, between the editor and the Find box the fact that they're disconnected can be problematic. For example, on a large display the Find box can be hard to notice when it comes up. 2) Horizontal space is much more limited in the trim bar than in the editor bar. You should be able to get most of what's in Ctrl+F into a bar below an editor, and could use the chevrons from the perspective switcher for anything that doesn't fit. This is not to say that continuing to work on this in trim is not the best way to do this, since trying to hack it into an editor could take considerable time, and you could try to persuade Platform to consider trim-like contributions to workbench parts. An alternative would be to position a one-row Find view to open just below the editor part, but you'd lose a row on for the view tab. Fyi, Mylyn bug 193010 is related because we have been exploring how best to integrate Find functionality for view parts with structured viewers (like the Task List). RSS Owl does a very nice Firefox-like job of placing the find bar at the bottom of the view part on demand whereas Mylyn's Task List keeps it always visible on top.
It'd be fantastic to have the Firefox style in-place find. Just last fall I was lamenting our existing dialog, which has its proud lineage all the way back to VisualAge Smalltalk. I'd say its time for an update. I'm not familiar with the blog discussion but agree with Mik's comment that it should be more proximal to the text editor that it is operating against. Putting it in the trim is also problematic because Jazz has a global text search box in the trim, and Dejan was investigating adding a global text search box to the IDE, so this could be easely confused.
Well, the Find field could be made retargetable i.e. Jazz and Dejan's component could reuse the same Find field.
(In reply to comment #4) > Well, the Find field could be made retargetable i.e. Jazz and Dejan's component > could reuse the same Find field. My concern there would be that each represents a different context (local to the editor, global search) and sometimes you'd want to do one and sometimes another. Having to twiddle some option in the input field to specify if it was local or global would be tedious and error prone. In any case, its best to keep the field as close as possible to where you are working, which means embedded in the text editor.
>In any case, its best to keep the field as close as possible to where you are >working, which means embedded in the text editor. So far we didn't get any complaints against using the status line for incremental find (Ctrl+J). But I agree, that the Find field should be as close as possible to its client hence it would e.g. not be useful to use a generic status line Find field for views. The question is whether it needs to be embedded in the text editor or whether it can fade in / appear over the editor and hence be provided by Platform UI. Otherwise a Platform Text solution would have to be implemented.
(In reply to comment #6) > The question is whether it needs to be embedded in the text editor or whether > it can fade in / appear over the editor and hence be provided by Platform UI. > Otherwise a Platform Text solution would have to be implemented. Ideally the search/replace should not obscure the text that you are searching/replacing (which is why the current one is such an annoyance). I'm guessing Dani that you're of the same thought. My preference would be that it shouldn't obscure *any* text anywhere (ie. including other views) because its a non modal task and thus you can't be sure where the user is looking (and I admit its a personal bias). The options I see are: 1) Some lightweight dialog that comes and goes through some subtle mechanism (we don't have one of these anywhere but perhaps we could invent) 2) Like (1) but add transparency 3) Have it take up space in the layout somewhere, 3a) current option is within the text editor itself ala Firefox, but 3b) perhaps other options could see it laid out below the text editor and above the problems/search/etc stack. The most reliable solution in my mind is (3a). I think (3b) is problematic because we don't have anything at that level that's not a stack, and even if we did we'd lose the strong visual association of the text field belonging to the editor. I am open minded to the possibility of solutions existing for 1 and 2 but the Firefox solution (3a) is where I keep gravitating to because its the most obvious.
Moving to text while Dani and I thumb wrestle on where this is best supported :)
I agree that it should be closer to the editor than the status line. *** This bug has been marked as a duplicate of bug 99294 ***
+1 for 3a. I have not seen a good enough execution of (1) or (2) and I don't see a problem with occluding something like 1-3 rows of text at the top or bottom of the editor.
Created attachment 73493 [details] Initial look (primitive form) I started working on 3a. Here's an initial screenshot that shows a bar attached to the bottom of the editor. I patched AbstractTextEditor#createPartControl in order to do this. I just wrapped the SourceViewer and the lightweight Find/Replace bar with a wrapper Composite. I'm in the process of forming the Find/Replace bar.
Created attachment 73494 [details] Initial work as a patch This is very primitive but I'm including it to show my progress.
Excellent progress. You get this in and you'll be famous! :) Aside: This bug has marked a dupe of bug #99294 but we're continuing to comment in it and post patches. Dani, was it your intention that the discussion and patches now occur in 99294? I am guessing that Cagatay was using this bug to track *his* work.
Normally we discuss in the open bug ;-)
Right, I was thinking that maybe Catagay might want to use this bug to track his development efforts, reopening it but making it block the main bug #99294 (with #99294 describing the problem/requirements and this one a particular implementation effort). In any case I just want us to stop commenting in a closed bug :)
I'm sorry for keeping things in this bug. I'll post future developments on bug #99294 and carry necessary information there. :)
+++ discussion goes on in bug 99294 +++
