Page 1 of 2
Find in files improvement
Posted: Sun Mar 22, 2009 3:00 pm
by jfouche
Hi
I improved "find in files" function by allow user to find files in multiples directories.
This allow to select (for example) :
- Current workspace
- and wx/include
- and wx/contrib/include
The next thing I'm gonna do is to allow user to put search results in a new tab (instead of just having 5 tabs), or keep the actual tab (overwrite previous search).
What do you think ?
Re: Find in files improvement
Posted: Sun Mar 22, 2009 3:42 pm
by eranif
jfouche wrote:The next thing I'm gonna do is to allow user to put search results in a new tab (instead of just having 5 tabs), or keep the actual tab (overwrite previous search).
I had in mind the implementing the KDevelop concept:
Create new tabs on the fly, each tab's title is the name of searched string
Eran
Re: Find in files improvement
Posted: Sun Mar 22, 2009 8:18 pm
by jfouche
Let me do it
Re: Find in files improvement
Posted: Thu Mar 26, 2009 7:07 pm
by eranif
Hi,
I applied the patch you provided - looks very nice (I did some minor UI changes, but other than that I committed it as is)
Eran
Re: Find in files improvement
Posted: Thu Mar 26, 2009 9:42 pm
by jfouche
Thanks
Just wait for saturday to have the "use new tab for result" request...
Re: Find in files improvement
Posted: Sun Mar 29, 2009 1:08 am
by jfouche
Just at time
I think you need to have a check, because I'm not sure that the merge done during my update to revision 2800 takes your modifications (especialy the fbp file, not easy to merge).
Enjoy
Re: Find in files improvement
Posted: Sun Mar 29, 2009 3:45 pm
by eranif
Hi Jeremie,
I applied your patch on my local SVN and after some modifications, I committed it.
here is what I have changed:
- The behavior of keeping always an open tab with no name, is somewhat "not nice" - I removed it, and now if user closes the last search tab, there are no more tabs in the 'find results' tab (ofc, this required fixes in many places to make sure that there is a tab before writing something into it i.e. m_sci != NULL)
- Again, I changed the layout of the find in files dialog (in the fbp file) - I suggest that you simply delete yours and use the one that is now in the SVN so the changes wont get lost again
- removed the gradient background from the search tabs
Maybe other changes, but other than that - it works very nice.
Gonna make an internal .deb package for my team members at work, so we will get some users feedback before releasing it.
EDIT: Another thing I will probably add is adding tab length limitation that after that codelite will truncate the notebook text ( to avoid very long tab names )
Eran
Re: Find in files improvement
Posted: Tue Mar 31, 2009 4:56 pm
by eranif
I just found (and fixed) a nasty bug:
In the patch you provided, you splitted the UI code into findinfiles_dlg which is generated from wxFB. However, in the constructor of the FindInFiles dialog you did not used the loaded 'FindInFiles' settings and adjusted the UI accordingly.
For example, when first starting codelite and launching find in files dialog, you may select the option to use 'regular expression', now after dismissing this dialog and closing codelite, the find in files options are saved into the codelite settings and are loaded on the next startup, but when I tried to search some string like: 'void foo(...)' it failed, even though it does exists in my code, the reason It failed is that it uses regex search, but the regex checkbox was not set in the dialog - and I was not aware of that.
Updating the dialog checkboxs on its construction solved it, since now I know it tries to use regex and this is why no matches were found.
Eran
Re: Find in files improvement
Posted: Tue Mar 31, 2009 7:09 pm
by jfouche
Hi Eran
Thanks for pointing and fixing this. I need to test harder my patches.
See you
Re: Find in files improvement
Posted: Tue Mar 31, 2009 8:58 pm
by eranif
jfouche wrote:I need to test harder my patches
I know you are
Btw, this patch was accepted with alot of enthusiasm at my job - people really liked it.
I also added some more fixes:
- The generated tabs have now fixed width size
- If the search string is too long to fit the tab's label - it is truncated (ofc, this fix was added to the notebook control, so this feature can be used in other places as well)
Eran