On 13-10-09 01:01 PM, Dimitar Zhekov wrote:
Hi, all,
I want to discuss how our FiF works, why, and possible improvements.
1. The FiF dialog is created programatically. Is there any reason for
that, or simply nobody cared to XML-ize it? I'm not aware of anything
that can be done gtk+ calls, but can't be done by loading a XML and
less gtk+ calls.
Proposition: move the presentation to glade as much as possible, and
fill the content with code, as in any normal program.
I have done this before in a branch, but just the Glade part, which
AFAIK is basically unmergable now because of volatility of Glade XML
file. What I did was I made one single Search dialog in Glade that
always showed the widgets that are in common between the various search
dialogs (find, replace, fif), and then the specific options for the
search type were each in their own container widget so they could be
hidden/shown depending on which search dialog needs to be shown. There's
some extra code to setup the dialog to be shown/work for the correct
search type but it probably dwarfs the amount of code removed by putting
all of them in the Glade file into a single DRY dialog.
[snip]
3. For non-recursive searches, grep does not allow a directory to be
specified instead of file. To work around that, we read the directory,
back-parse all --include=*.x patterns, and match them manually.
Proposition: grep -rl --include=*.c --exclude-dir=[^.]*
--exclude-dir=.?* void . :)
We pass our Directory as a workind directory to spawn, and the
recursive search already uses . as a grep FILE argument.
--exclude-dir is supported since more than 5 years.
Is there any reason we cannot just walk the directory/subdirectories
ourselves and search the files using GRegex stuff? The pattern syntax
would then be the exact same as the other search dialogs and it would
save having to not only spawn a subprocess but also remove the
dependency on grep (only a problem on Windows). Also, as a future
optimization, if any of the files to search are open in Geany, we could
search their document buffer directly from memory rather than having to
do any file IO for them. GIO/GFile has all the stuff needed to walk a
directory tree and open files both asynchronously and portably IIRC.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
