Author Topic: ThreadSearch 0.7 release  (Read 49280 times)

Offline dje

  • Lives here!
  • ****
  • Posts: 683
ThreadSearch 0.7 release
« on: June 29, 2007, 12:00:41 am »
Hi all !

I'm proud to release ThreadSearch plugin 0.7  :D

Features :
  • multi-threaded "Search in files"
  • preview of the results (left single click on log window)
  • file open (left double click on log window)
  • check boxes instead of radio boxes to allow searches with both project and directories for example.
  • contextual menu "Find occurrences" to start a search in files with the word under cursor (can be activated or not)

Why ?
  • I am working on very big projects (700 Mo of cpp, h files) and text searches take up to 5 minutes. It is very frustrating being blocked because of the search. It is now possible to continue editing code during searches.
  • I do not like leaving the editor position to browse 'Search in files' resuts. There is now the 'Code preview' to do this with possibility to open the file at the right position.

What's new ?
New features :
  • The ThreadSearch toolbar is available (@jamieo)
  • Search graphical widgets can be shown or hidden on the ThreadSearch panel to spare space.
  • The File path column in list log is splitted in directory and file name to improve readability and space (@Jamie).
  • 'Search' menu 'Thread search'item now searches for word under cursor or adds panel to Messages notebook if no word is selected (Jamie contrib, thanks).
  • Focus is automatically set to list log after running a search (Jamie contrib, thanks).
  • Default mask is now *.cpp;*.c;*.h instead of *.cpp;*.h to better fit user needs (@Mario)

Bug fixes :
  • "Failed to convert file "x:\y\filename.cpp" to Unicode." was sometimes raised during searches. Thanks to Tiwag for solution !
  • Configuration save fixes.
  • Options window was not centered on the main window.
  • Log line items were not systematically aligned on the right.

Installation :
  • Download the following files:
    Windows ThreadSearch 0.7 plugin or Linux (Ubuntu 6.10, 32 bits) ThreadSearch 0.7 plugin and pngs.zip
  • Extract pngs.zip
  • Move ThreadSearch.png and ThreadSearch-off.png in the <...>\CodeBlocks\share\CodeBlocks\images\settings directory
  • Move other pictures (findfdisabled.png, options.png, optionsdisabled.png, stop.png and stopdisabled.png) in the <...>\CodeBlocks\share\CodeBlocks\images\16x16 directory
  • Click on Plugins/Manage plugins
  • Click on Install new and select the downloaded plugin

Build
Extract the source code in src\plugins\contrib\ThreadSearch, open the CodeBlocks project and build it. The .cbplugin is generated in src\plugins\contrib\ThreadSearch and is ready for install.

EDIT: this is the dedicated wiki page

Feel free to send feedbacks !  :)

Dje

« Last Edit: July 01, 2007, 11:33:41 pm by dje »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: ThreadSearch 0.7 release
« Reply #1 on: June 29, 2007, 12:39:41 am »
It'd be better if you left the image files in a zip, as the other plugins have their images etc. in their own zip files.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: ThreadSearch 0.7 release
« Reply #2 on: June 29, 2007, 11:28:03 am »
I'm proud to release ThreadSearch plugin 0.7  :D
Nicely done, looks great.

Hence I have found a serious bug that will for sure give you some headache:
- enable toolbar and view of the plugin
- go to "manage plugins"
- disable plugin
- enable plugin
Result:
- C::B toolbar is completely messed up and cannot be used anymore
- starting from now closing C::B result is a crash

Notice: This is advanced stuff. Besides from that it works great - have searched the whole C::B workspace - no issues.

With regards, Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: ThreadSearch 0.7 release
« Reply #3 on: June 29, 2007, 12:59:56 pm »
... I have found a serious bug that will for sure give you some headache:
- enable toolbar and view of the plugin
- go to "manage plugins"
- disable plugin
- enable plugin
Result:
- C::B toolbar is completely messed up and cannot be used anymore
- starting from now closing C::B result is a crash
...

better you let it enabled  :P  :P

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: ThreadSearch 0.7 release
« Reply #4 on: June 29, 2007, 02:12:01 pm »
I confirm the bug at least on Windows.
The RPT gives interessant details.

There will probably be a 0.10 release soon...

Thanks for feedback !

Dje

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: ThreadSearch 0.7 release
« Reply #5 on: June 29, 2007, 03:52:38 pm »
Hi Rick !

It'd be better if you left the image files in a zip, as the other plugins have their images etc. in their own zip files.

I did not really know how to proceed. I first thought about including them in manifest/.cbplugin. I was told it should be like that but not implemented.

As I saw 16x16 in C::B toolbar management and my code use 2 existing C::B icons, I chose to put them there.
If it is better to place them in an images\ThreadSearch directory, I'll do it next on next release.

Dje

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: ThreadSearch 0.7 release
« Reply #6 on: June 29, 2007, 04:12:04 pm »
dje: I want to implement a "search directory" context menu action in your plugin (it will respond to right clicks on directories in the File Explorer in my Interpreted Languages plugin). I have most of the code in place, BUT your ThreadSearchView doesn't publicly expose a means to set the FindData in the view. If you can expose this functionality I will send you a complete patch.

besides the missing member declarations/event handling gunk, adding the feature is as simple as adding some extra code to BuildModuleMenu:

Code
void ThreadSearch::BuildModuleMenu(const ModuleType type, wxMenu* pMenu, const FileTreeData* data)
{
...
    if ( (type == mtEditorManager) && (m_CtxMenuIntegration == true) )
...
    if(type==mtUnknown) //Assuming file explorer -- fileexplorer fills the filetreedata with ftdkFile or ftdkFolder as "kind", the folder is the full path of the entry
    if(data)
    {
            size_t sep_pos=pMenu->GetMenuItemCount();
            size_t added=0;
            if(data->GetKind()==FileTreeData::ftdkFile)  //right clicked on file in file explorer
            {
                wxFileName f(data->GetFolder());
                wxString filename=f.GetFullPath();
                //**** Could do a search within a file here...****
            }
            if(data->GetKind()==FileTreeData::ftdkFolder) //right clicked on folder in file explorer
            {
                wxFileName f(data->GetFolder());
                wxString filename=f.GetFullPath();
                wxString sText = wxT("Search Directory...");
                m_SearchDirectory=filename;
pMenuItem = pMenu->Append(idMenuDirThreadSearch, sText);
                pMenuItem->Enable(!m_pThreadSearchView->IsSearchRunning());
                added++;
            }
            if(added>0)
                pMenu->InsertSeparator(sep_pos);
    }

and an event handler:

Code
void ThreadSearch::OnMnuDirThreadSearch(wxCommandEvent &event)
{
if ( !IsAttached() )
return;

    ThreadSearchFindData findData=m_FindData; //****Alternative pull findData from the actual logpanel****
    findData.SetScope(ScopeDirectoryFiles);
    findData.SetSearchPath(m_SearchDirectory);
    findData.SetRecursiveSearch(true);

//**** Need to update the Log Panel with the contents of findData****

    AddAndShowThreadSearchLogPanel(true);
}

the ****'s denote the incomplete code
« Last Edit: June 29, 2007, 04:51:26 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: ThreadSearch 0.7 release
« Reply #7 on: June 29, 2007, 04:21:34 pm »
Hi Rick !

It'd be better if you left the image files in a zip, as the other plugins have their images etc. in their own zip files.

I did not really know how to proceed. I first thought about including them in manifest/.cbplugin. I was told it should be like that but not implemented.

As I saw 16x16 in C::B toolbar management and my code use 2 existing C::B icons, I chose to put them there.
If it is better to place them in an images\ThreadSearch directory, I'll do it next on next release.

Dje

take a look at the post build steps of most contrib plugins (there's a zip command) (or alternatively look at my win32 InterpretedLangs project file from my cbilplugins project on berlios)

you should use the #cb global variable to setup the paths to your project includes, libraries and other dependencies. remove the path specifiers in the link libraries put the paths in library search paths.

You shouldn't need separate build and debug targets if youre build is set up to output your dll and zip files to the devel directory (this is where the debug build of codeblocks goes). when you run update.bat your files will be included in the stripped binaries in the output folder.

MortenMacFly had other good advice for me in this post: http://forums.codeblocks.org/index.php/topic,6297.msg48251.html#msg48251
« Last Edit: June 29, 2007, 04:52:25 pm by dmoore »

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: ThreadSearch 0.7 release
« Reply #8 on: June 29, 2007, 04:32:37 pm »
It'd be better if you left the image files in a zip, as the other plugins have their images etc. in their own zip files.

To my knowledge, there is currently no way that .cbplugin images get copied to the necessary CB share directories.

So leaving the images in the zip file will not work.

However, since I was also working on the problem for another plugin, I'll also write it so images can be loaded from /share/codeblocks/<plugin>.zip by the plugin itself and make a call to cbLoadBitmap() if necessary.

I'll use ThreadSearch a the guinea pig if that's ok with dje.



Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: ThreadSearch 0.7 release
« Reply #9 on: June 29, 2007, 04:49:17 pm »
To my knowledge, there is currently no way that .cbplugin images get copied to the necessary CB share directories.

So leaving the images in the zip file will not work.

Pecan: can you explain this in more detail? I have an xrc toolbar in my Python plugin that loads a bunch of images. those images are all stored in the PyPlugin.zip along with the xrc file and the manifest and it *appears* to work fine.... So you must be talking about a different case?
« Last Edit: June 29, 2007, 04:50:51 pm by dmoore »

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: ThreadSearch 0.7 release
« Reply #10 on: June 29, 2007, 05:00:24 pm »
Hi !

@dmoore, I'll have a look this WE, I find your idea very interesting (ThreadSearch external calls).
For now, Search in dir is possible, not search in file.

For the near future:
  • Morten's bug fix (crash on plugin disable). It does not look too difficult.
  • windows project rework to put threadSearch plugin under SVN contrib plugins.
  • pictures management

@Pecan
Quote
I'll use ThreadSearch a the guinea pig if that's ok with dje
Shame on my English  :oops:
I don't understand what you mean

Dje

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: ThreadSearch 0.7 release
« Reply #11 on: June 29, 2007, 05:06:15 pm »
Quote
I'll use ThreadSearch a the guinea pig if that's ok with dje
I don't understand what you mean
Me not, too. WiKiPedia has a lot of different meanings for that but I'd say none of them really matches... Hehe...:
http://en.wikipedia.org/wiki/Guinea_pig_%28disambiguation%29

Edit: Ah:
# (idiomatic) A person who volunteers for an experiment or to try anything new; an experimental subject (from the use of the rodent in laboratory experiments).
e.g. "Would you like to be the guinea pig for our new product concept?"

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: ThreadSearch 0.7 release
« Reply #12 on: June 29, 2007, 05:11:22 pm »
@dmoore, I'll have a look this WE, I find your idea very interesting (ThreadSearch external calls).
For now, Search in dir is possible, not search in file.

thanks for taking the time. the nice thing is that I don't need to do anything on my end that's specific to ThreadSearch (i.e. the fileexplorer will add whatever items that any plugin wants to put into the fileexplorer context menu). the plugin architecture takes care of the communication between the two plugins, so you don't have to worry about messy #includes.

I realize that search in file isn't possible, but just left it in to show the possibilities (I did take out the more complex multiple file/directory targets, which sends a list of a space separated files and directories that the user selected before right clicking)

btw, it could have been something I did wrong, but I was getting a crash on exit (even without starting up a threadsearch)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: ThreadSearch 0.7 release
« Reply #13 on: June 29, 2007, 05:31:14 pm »
To my knowledge, there is currently no way that .cbplugin images get copied to the necessary CB share directories.

So leaving the images in the zip file will not work.

Pecan: can you explain this in more detail? I have an xrc toolbar in my Python plugin that loads a bunch of images. those images are all stored in the PyPlugin.zip along with the xrc file and the manifest and it *appears* to work fine.... So you must be talking about a different case?

You have an .xrc that gets loaded with LoadResources(), I guess, which in turn loads the .png from the resource .zip.

However, ThreadSearch has no .xrc, but a bunch of .png's .
So they're being  loaded via cbLoadBitmap() or new() etc.

That's ok when they're already extracted in  .../images/16x16 etc, but if they're in the .zip with no xrc, some routine has to go extract them.

I was thinking that the easiest solution is simply to glom onto the CB plugin .zip extraction routine, modify it, & use it locally to grab the needed .png when needed.
« Last Edit: June 29, 2007, 05:36:07 pm by Pecan »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: ThreadSearch 0.7 release
« Reply #14 on: June 29, 2007, 07:25:12 pm »
hmm...  it would be possible to specify a sequence of wxBitMaps in an XRC file as follows:

Code
<resource>
    <object class="wxBitmap" name="img1">images/image1.png</object>
    <object class="wxBitmap" name="img2">images/image2.png</object> 
etc...
</resource>

zip the XRC in with the images and manifest (using the relative paths for the images as in the xrc). Then after you call

Code
Manager::LoadResource(_T("myplugin.zip");

you can access your images with

Code
    wxBitmap bmp;
    // typedef
    bmp = wxXmlResource::Get()->LoadBitmap(_T("img1"));