[MonoDevelop] SearchBar patch
monoman at gmail.com
Thu Sep 28 17:36:59 EDT 2006
On 9/28/06, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> On 9/28/06, Rafael Teixeira <monoman at gmail.com> wrote:
> > HI, inline
> > On 9/26/06, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > Hi.
> > >
> > > > > * Each open document has its own search bar. Do we want this?
> > > >
> > > > I don't think so. Like in FireFox, the search text and options should be
> > > > global, and shouldn't change when you switch documents.
> > >
> > > I am not quite sure how to do this. The
> > > MonoDevelop.SourceEditor.Gui.SourceEditorDisplayBinding class is used
> > > as a DisplayBinding for text files. How do I make several instances
> > > share the same SearchBar?
> > Make the searchbar a global dockable panel that appears/hide when the
> > active DisplayBinding exposes some searching service (implements some
> > interface that does the real search/positioning).
> Yes, I also thought about making the DisplayBinding classes implement
> some interface. E.g.:
> public interface ISearchable
> void Find(string stringToFind);
Probably you need to pass also some 'options' parameter, for things
like case-sensitivity of search, wrap-around, direction, etc...
> I am not sure what you mean about positioning.
I mean scrolling the text to the point where the found text is, this
should be the DisplayBinding responsability.
>One could extend the
> interface with e.g.:
> void ShowSearchWidget(Widget searchWidget)
> It would then be the responsibility of the DisplayBinding to decide
> where to show the widget.
No, I would go that way. As I said, I prefer a global dock so that
irrespective of the DisplayBinding, except for implementing
ISearchable, it shows where the user wants it to be shown, defaulting
to above the bottom dock that normally contains the
tasks/results/output/etc... pads. This is the way it works on Firefox,
except that firefox doesn't allow the user to drag it to another dock.
> So hitting Ctrl+F would look at the current DisplayBinding. If it
> implements ISearchable. The SearchBar widget will be given as argument
> to ShowSearchWidget. Hitting search in the SearchBar would invoke Find
> on the DisplayBinding.
Well, I think that maybe the whole 'Find' action (Ctrl-F shortcut
included) should be disabled, if the DisplayBinding doesn't support
ISearchable. So when the action is activated (by any means, including
from the Menu or some toolbar button click) one can just show the dock
and look for the currently active DisplayBinding.
Another issue: My translator displayBinding probably will have to add
some option to the search bar (a checkbox for whether the search is
limited to the string currently being edited, or along all the strings
in the .po file), so some search bar contextual extension concept also
need to be devised/implemented.
> But what should happen when changing to another DisplayBinding? Should
> the search widget then be removed from the previous DisplayBinding and
> added to the one now active?
That is why I want to avoid it being in the DisplayBinding itself, but
host in a separate dock panel.
> The reason why I would like the DisplayBinding widget to decide where
> the SearchBar should go is that I would like it to appear right at the
> bottom of the source code. Like in e.g. Firefox.
The user should decide where it wants it, maybe even docked with other
pads. But nothing, AFAIK, prevents it from being docked, by default,
just bellow the center panel where all display bindings appear.
> What do you think?
I hope I've clarified my vision of it. Sorry I don't have time just
now to prototype the whole thing to present it in a more consistent
Feel free to ask any other details if you need. Also everybody can
toss your thoughts on the subject, they are welcome.
Rafael "Monoman" Teixeira
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw
More information about the Monodevelop-list