Community
Participate
Working Groups
1. Open an editor; focus it. 2. Press Ctrl+H You get a JavaScript prompt asking for a search term. This should be using the CommandParameter API instead, which is much nicer than a modal dialog.
you can look at gotoLine for an example of how we accomplish this. One thing I'm not really sure about is which side of the toolbar search should slide out of. What I've been doing so far is that left side operates on the page resource, right side navigates through the page content. The global search popup is neither of these...
(In reply to comment #1) > you can look at gotoLine for an example of how we accomplish this. > One thing I'm not really sure about is which side of the toolbar search should > slide out of. What I've been doing so far is that left side operates on the > page resource, right side navigates through the page content. > > The global search popup is neither of these... Hmm, to me, "CTRL+SHIFT+R" and "CTRL+H" are both to open a file quickly while I am editing. Maybe we should think about using the similar dialog as "CTRL+SHIFT+R" does. But I believe "search file by keyword" will be slower than "search file name". Plus, I am not sure about the sticky notes approach. Sticky notes is good when you want to switch over to files found. If we want the quick open dialog approach we may want to drop the sticky notes. Hard to decide...
(In reply to comment #2) > Hmm, to me, "CTRL+SHIFT+R" and "CTRL+H" are both to open a file quickly while I > am editing. > Maybe we should think about using the similar dialog as "CTRL+SHIFT+R" does. These are similar in that 1. they're both commands that operate on the whole workspace, not resource or page 2. they both need to collect a parameter 3. they both need somewhere to show their results For (2) I prefer the slideout param-getter as it's less obtrusive. For (3) I actually like the global search popup better. The Ctrl+Shift+R dialog blocks interaction with the rest of the page for no reason. (In Eclipse desktop, I'd use a Quick View for this case: show me the results, but let me dismiss them easily.)
(In reply to comment #3) > For (3) I actually like the global search popup better. The Ctrl+Shift+R dialog > blocks interaction with the rest of the page for no reason. (In Eclipse > desktop, I'd use a Quick View for this case: show me the results, but let me > dismiss them easily.) For any new dialogs/dialog rework I'd like to see us structure it so that the "main code" just generates the HTML and the logic and has "submit" and "cancel" implemented. Then we can play with hosting in a homegrown lightweight div (like global search), or a tooltip dialog, or even the slideout itself (yeah, that's weird, just brainstorming). The point is I'd like to see us separate content from the "host div." The dijit dialogs are very tied into the dijit/widget/template story and aren't reusable outside of that. I think we need to be moving away from this, so I wouldn't want to see us copy the open resource pattern (at least not the dijit dialog part).
> You get a JavaScript prompt asking for a search term. [...] This no longer results in a JavaScript prompt so was fixed at some point.
