Re: [Builder] Find/replace implememtation



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2015 07:46 AM, Erick Pérez Castellanos wrote:
I've started this the weekend, and haven't move very far mostly 
because I've been reading Builder's code.

Excellent, this is much needed!

Now, there's things to consider when doing find/replace

+ Do we want the find/replace dialog to belong to a particular
view, or application wide. By doing it application wide we allow
the user to switch between sources and keep executing the same
search.

I think we can separate this into two features (at least logically) to
the user.

  Search in File
  Search in Project

Search in Project could be similar to what we did in MonoDevelop. The
search results appear as a list in a pane below your text editor.
Activating the row opens the file and jumps to the match.

+ There's two mockups for the feature, one making it dialog and
one making it part of the chrome on a view [1]. By choosing one
over the other we kinda fix the issue stated before

Those do indeed look nice. I'll defer to your judgment.

+ Also, some code editors has the ability to "find in files" an 
SublimeText at least has the ability to replace on various files
at once. Do we want this?

The actual search/replace functionality is fairly easy to implement
now (even with regex support) thanks to GtkSourceSearch{Context,Settings}.

However, that means if we want to reuse that code (and I presume we
do), we need to create a GtkSourceBuffer for every file we want to
search/replace. It's not quite as bad as opening a new view for each
file, but we will want to make sure to disable highlighting and other
background content parsing that typically happens in GSV.

+ Just another thing, we might want to mark the gutter/scrollbars
with the place of the occurrences if/when the file is huge.

This would be nice. Unfortunately many developer systems wont have a
gutter to draw on with the new overlay scrollbars. What should we do
in that case? Maybe we should just use a GtkSourceGutterRenderer on
the GTK_TEXT_WINDOW_RIGHT? Maybe we burn another couple pixels on the
left?

## On the implementation front

Considering the issues before solved, where do we attach the 
find/replace functionality. If it would be local is easy, that
would make it part of GbEditorFrame (or at it launching from
there). If we should to make it application wide, we need to hear
on the activation of GbEditorViews from someone so we can adjust to
it when the user change the source he's viewing/editing.

The nice thing about attaching it to the GbEditorFrame is that you
know exactly which TextView to advance as you move through the buffer.
If you do it on the GbEditorView, you'll have to keep track of which
frame was last focused.

I rather like the inline design, which would lend well to attaching to
the GbEditorView (even if it requires a little more hand-wavy tracking
of the focused frame).

## Schedule

I'd like it to get it in time for 3.15.4, but as with every simple 
thing made right it takes time to cook the details. I'm guess it
will be done after the release on Monday.

That's okay. I think we are already in good shape for an initial
release, but if it lands, all the better!

Thanks!

- -- Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUt+g5AAoJEDTRnfr1IpSG8xQP/jydAodOjDfwmZLf0sc44ut5
XYuGYAg8gd5VkxnBmn2RkQH+JWOWQ9LPMt2osRPqbJO/mwLZa2zH6mg5Md6gvh25
uIK/RnmSrD85OQ36x99RXy9UbN5DGdhnzk64zesnXos6a0FRuJ83uh6x/Zvvf4ez
KF2/Yn8tp9GHDIQ47NgzAnW9MZLV1lJpQ7YvyDejTEelyyPCfiW8qJhoixf6Je1O
600ZBfUWR8wiaLiTsTO907JPujPJw6QThLppyc343zsnC3I7n7Dn2s0EAAIZ38o0
MtXJwhzUmJZfwbAuAkycVZPm5OE1ZNTOH91L/PDTcK8+aXogSAHONEZAqRw+cxBY
4Q2F1gmj0128K04WWj/W66frLGERxrb+dLH4KAsb+WDGe8+AkjutDya7eHZoWcm+
SmjdlBRWzNhVwEgfedcldJjSXik8w9GHCX3XfiZd9HfSF/vFu9UYhrfNebSwBNPb
XFDZCx3s1tNiHMCcNu6sYTp1bs/P+cD5ClXMVPGFJNlXSUnCdTTOBY2GvQbwmCzM
tBFfjT440tb0H5lF8XE5oIicn/gS7vmo/3PBL0sOgFRhMx5e6LnMaYruxWl9y7p7
/lKwxY/iiFdA39jAixmhW7JS2lmMZR7PNfIfaYEwbZDmPRmc+uF4+9EVz34nCHne
dnjPgbdzOsvNdWe4Aw92
=qvzq
-----END PGP SIGNATURE-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]