comments and doc

This commit is contained in:
Jean-Francois Dockes 2011-05-07 09:32:42 +02:00
parent 4113397f49
commit 297ff2d225
5 changed files with 64 additions and 46 deletions

View File

@ -479,24 +479,32 @@ recoll
<sect1 id="rcl.indexing.beaglequeue">
<title>Using Beagle WEB browser plugins</title>
<para><application>Beagle</application> is a concurrent desktop
<para><application>Beagle</application> is (was?) a concurrent desktop
indexer, built on Lucene and the Mono project (C#), for which a
number of add-on browser plugins were written. These work by
copying visited web pages to an indexing queue directory, which the
indexer then processes.</para>
indexer then processes. Especially, there is a
<application>Firefox</application> extension.</para>
<para>If, for any reason, you so happen to prefer &RCL; to
<application>Beagle</application>, you can still use
the browser plugins (they are written in Javascript and completely
independant of C#, Beagle, Lucene...). &RCL; can process the
<application>Beagle</application> queue directory. Of course, this
supposes that <application>Beagle</application> is not running,
else both programs will fight for the same files.</para>
<application>Beagle</application>, you can still use the
<application>Firefox</application> plugin, which is written in
Javascript and completely independant of C#, Beagle, Lucene..., and
set &RCL; to process the <application>Beagle</application> queue
directory. This supposes that <application>Beagle</application> is
not running, else both programs will fight for the same
files.</para>
<para>This feature can be enabled in the GUI indexing configuration
panel, or by editing the configuration file (set
<literal>processbeaglequeue</literal> to 1).</para>
</sect1>
<para>There are more recent instructions about how to find and
install the <application>Firefox</application> extension on the
<ulink url="https://bitbucket.org/medoc/recoll/wiki/IndexBeagleWeb">
Recoll wiki</ulink>.</para>
</sect1>
<sect1 id="rcl.indexing.periodic">
<title>Periodic indexing</title>

View File

@ -141,9 +141,9 @@ ConfBeaglePanelW::ConfBeaglePanelW(QWidget *parent, ConfNull *config)
ConfLink lnk2(new ConfLinkRclRep(config, "webcachedir"));
ConfParamFNW* cp2 =
new ConfParamFNW(this, lnk2, tr("Web cache directory name"),
tr("The name for a directory where to store the cache "
"for visited web pages.<br>"
new ConfParamFNW(this, lnk2, tr("Web page store directory name"),
tr("The name for a directory where to store the copies "
"of visited web pages.<br>"
"A non-absolute path is taken relative to the "
"configuration directory."), true);
cp2->setEnabled(cp1->m_cb->isChecked());
@ -152,7 +152,7 @@ ConfBeaglePanelW::ConfBeaglePanelW(QWidget *parent, ConfNull *config)
ConfLink lnk3(new ConfLinkRclRep(config, "webcachemaxmbs"));
ConfParamIntW *cp3 =
new ConfParamIntW(this, lnk3, tr("Max. size for the web cache (MB)"),
new ConfParamIntW(this, lnk3, tr("Max. size for the web store (MB)"),
tr("Entries will be recycled once the size is reached"),
-1, 1000);
cp3->setEnabled(cp1->m_cb->isChecked());

View File

@ -58,7 +58,12 @@ public:
virtual string getReason();
enum CreateFlags {CC_CRNONE=0, CC_CRUNIQUE=1, CC_CRTRUNCATE = 2};
enum CreateFlags {CC_CRNONE=0,
// Unique entries: erase older instances when same udi
// is stored.
CC_CRUNIQUE=1,
// Truncate file (restart from scratch).
CC_CRTRUNCATE = 2};
virtual bool create(off_t maxsize, int flags);
enum OpMode {CC_OPREAD, CC_OPWRITE};

View File

@ -89,24 +89,46 @@
</ul>
<h2><a name="b_1_15_7">recoll 1.15.7</a></h2>
<li>Using search preview while the indexing thread is running will
sometimes crash the GUI or provoke other strangeness. This is
apparently due to insufficient protection of resources shared by
several threads. After recent cleanup, the problem occurs quite
seldom but it is not completely gone. The current and
unsatisfying workaround, is to avoid the situation, for example
by using the standalone recollindex program instead of the GUI
<ul>
<li>Using the result preview while the indexing thread is
running will sometimes crash the GUI or provoke other
strangeness. This is apparently due to insufficient
protection of resources shared by several threads. After
recent cleanup, the problem occurs quite seldom but it is
not completely gone. The current and unsatisfying
workaround, is to avoid the situation, for example by using
the standalone recollindex program instead of the GUI
indexing thread.</li>
<li>The GUI preview function sometimes failed with a
<li>The GUI preview function sometimes fails with a
non-sensical message about a non-related missing
helper.</li>
<li>The ignored suffixes list (recoll_noindex) is
ignored in some cases.</li>
<li>Most operations on the parent document in the result table
view are not connected and do nothing.</li>
<li>The operations on the parent document in the result list
right click menu (Preview and Open), do not work, they
access the file's parent directory instead.</li>
<li>The GUI option to remember sort state between invocations
only works for sort by date.</li>
<li>The rclzip filter can't handle utf-8 in path names for archive
members. An <a href="http://www.recoll.org/filters/rclzip">
updated filter</a> is available. </li>
<li>The rclzip and rclchm filters can't handle archive members
with a colon (':') in the file name or path. The files are normally
indexed and can be searched for, but they can't be displayed
(neither opened nor previewed). There is a
<a href="https://bitbucket.org/medoc/recoll/changeset/3751ea8ea179">
patch</a> which fixes the issue (then needs full reindex for these
files).</li>
<li>The ignored suffixes list (recoll_noindex) is itself
ignored in some cases.</li>
<li>The man filter creates groff temporary png files in the
home directory.</li>
@ -120,31 +142,17 @@
user ends the section at this point.</li>
<li>Starting the indexing thread inside the GUI while another
indexer (batch or real-time) was active would silently
indexer (batch or real-time) is active will silently
failed. It should show an error dialog.</li>
<li>When an open error occurs on an external index while
starting the GUI, the initial indexing dialog is started,
which is incorrect because it cannot fix the problem.</li>
<li>The operations on the parent document in the result list
right click menu (Preview and Open), do not work, they
access the file's parent directory instead.</li>
<li>Most operations on the parent document in the result table
view are not connected and do nothing.</li>
<li>The rclzip filter can't handle utf-8 in path names for archive
members. An <a href="http://www.recoll.org/filters/rclzip">
updated filter</a> is available. </li>
<li>The rclzip and rclchm filters can't handle archive members
with a colon (':') in the file name or path. The files are normally
indexed and can be searched for, but they can't be displayed
(neither opened nor previewed). There is a
<a href="https://bitbucket.org/medoc/recoll/changeset/3751ea8ea179">
patch</a> which fixes the issue (then needs full reindex for these
files).</li>
<li>The result table row height is not adjusted according to
default font size, and the vertical position of text in cells
is often bad.</li>
</ul>
<h2><a name="b_1_15_5">recoll 1.15.5</a></h2>

View File

@ -72,9 +72,6 @@
etc.).</li>
<li>Estimated result counts are displayed in the
status line.</li>
<li>Set row height according to default font size, and better
adjust row height and vertical text position in
cells.</li>
</ul>
</li>