[MonoDevelop] SearchBar patch

Jacob Ilsø Christensen jacobilsoe at gmail.com
Thu Oct 5 17:32:20 EDT 2006


Does this look like a good place for the search bar?

/Jacob

On 9/29/06, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> Hi Rafael.
>
> Inline.
>
> On 9/28/06, Rafael Teixeira <monoman at gmail.com> wrote:
> > Hi Jacob,
> >
> > inline
> >
> > On 9/28/06, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > Hi.
> > >
> > > 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...
>
> Yes, those options will need to be passed as well. The example above
> was just a simple first case.
>
> > >
> > > 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.
>
> Yes, that would be the responsibility of the DisplayBinding.
>
> > >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.
>
> Yes, the other way around is the best way to do it. I just did not
> know how to make it appear just below the active DisplayBinding. How
> do I best make it appear right below the Gtk.Notebook which holds the
> DisplayBindings? I mean, what class represents that Gtk.Notebook?
>
> > >
> > > 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.
>
> I agree. Ctrl+F (including menu item etc.) should do nothing if the
> active DisplayBinding does not implement ISearchable.
>
> > 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.
>
> That probably won't be included in the first version. :-) But I will
> keep it in mind.
>
> > > 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.
>
> I agree. :-)
>
> > >
> > > 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.
>
> You have indeed.
>
> > Sorry I don't have time just
> > now to prototype the whole thing to present it in a more consistent
> > state.
>
> That's perfectly ok. I really appreciate your input. Thanks!
>
> > Feel free to ask any other details if you need.
>
> Look above. :-)
>
> /Jacob
>
> > 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
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search.jpg
Type: image/jpeg
Size: 47731 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/monodevelop-list/attachments/20061005/7c3f54c7/attachment-0001.jpg 


More information about the Monodevelop-list mailing list