Comment 4 for bug 452226

Hi Arthur,

Can you please review and if OK commit to master implementation of search?

https://bazaar.launchpad.net/~riaguzov/xpad/add_search/revision/1006

If you are wondering why I've removed pointers from XpadToolbar, the answer is:

If 0 is used for class_offset subclasses cannot override the class handler in their class_init method by doing super_class->signal_handler = my_signal_handler. Instead they will have to use g_signal_override_class_handler(). (c) https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-new

so they are useful only in case of someone wishes to inherit from XpadToolbar and I cannot find any sensible reason why someone would want to do this.

Please also note that searchbar appears in the top right corner for two reasons:

- This is how gedit does it
- This actually makes sense. searchbar is in overlay and it covers text which is searched. In the beginning of the document first several lines are usually short (for example title and an empty line after it), so putting searchbar in top right corner creates less chances for covering what is searched

Please also note that there are two key difference from gedit implementation and this one:

- In gedit searchbar dissapears if user moves cursor to text buffer. Here it is not the case. I found gedit implementation irritating in case I want to search for something, change some text, searchg for the same thing again. As xpad is not a full-blown text editor there is no search and replace functionality (and I don't know if it is needed?) but not hiding searchbar when it looses focus is at least a step to being a better text editor
- In gedit there is a complex logic to highlight search entry red if nothing is found. It is done on the fly with timers, because searching of the buffer is asynchronous and gtk_source_search_context_get_occurrences_count might not return search count immediately, so they set a timer (but not long enough to allow changing text in search entry). To avoid this complex logic I highlight search entry red only when enter/prev/next are actually clicked. If text in search entry is modified it is "unhiglighted". Also if user will move cursor to text buffer and insert the previously not found text, the search entry will stay "highlighted red" but only until enter/prev/next is pressed again on it - then it will find previously not found text

Please also note that wrap-around is set to both search forward and backward (enter and "down" button search forward, "up" button search backward). This is done to ease life. With wrap-around there is no need to grey out the prev(up)/next(down) buttons, they will just wrap-around or highlight text entry if nothing is found. Also I'm seeing wrap-around behavior in other editors like vim.