Find in files improvement
-
- CodeLite Guru
- Posts: 351
- Joined: Mon Oct 20, 2008 7:26 pm
- Genuine User: Yes
- IDE Question: C++
- Location: France
- Contact:
Find in files improvement
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 ?
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 ?
You do not have the required permissions to view the files attached to this post.
Jérémie
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Find in files improvement
I had in mind the implementing the KDevelop concept: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).
Create new tabs on the fly, each tab's title is the name of searched string
Eran
Make sure you have read the HOW TO POST thread
-
- CodeLite Guru
- Posts: 351
- Joined: Mon Oct 20, 2008 7:26 pm
- Genuine User: Yes
- IDE Question: C++
- Location: France
- Contact:
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Find in files improvement
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
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
Make sure you have read the HOW TO POST thread
-
- CodeLite Guru
- Posts: 351
- Joined: Mon Oct 20, 2008 7:26 pm
- Genuine User: Yes
- IDE Question: C++
- Location: France
- Contact:
Re: Find in files improvement
Thanks
Just wait for saturday to have the "use new tab for result" request...
Just wait for saturday to have the "use new tab for result" request...
Jérémie
-
- CodeLite Guru
- Posts: 351
- Joined: Mon Oct 20, 2008 7:26 pm
- Genuine User: Yes
- IDE Question: C++
- Location: France
- Contact:
Re: Find in files improvement
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
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
You do not have the required permissions to view the files attached to this post.
Jérémie
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Find in files improvement
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
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
Make sure you have read the HOW TO POST thread
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Find in files improvement
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
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
Make sure you have read the HOW TO POST thread
-
- CodeLite Guru
- Posts: 351
- Joined: Mon Oct 20, 2008 7:26 pm
- Genuine User: Yes
- IDE Question: C++
- Location: France
- Contact:
Re: Find in files improvement
Hi Eran
Thanks for pointing and fixing this. I need to test harder my patches.
See you
Thanks for pointing and fixing this. I need to test harder my patches.
See you
Jérémie
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Find in files improvement
I know you arejfouche wrote:I need to test harder my patches
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
Make sure you have read the HOW TO POST thread