Re: [documancer] Re: [documancer-users] a few bugs?

[<arn...@we...>]

Hi,

first let me thank you very much for your response and the fixes (!).

On Wed, 24 Dec 2003, Vaclav Slavik wrote:

> arn...@we... wrote:
> >   The documancer files were put in
> >     ${HOME}/PYTHON_TST/lib/documancer
> >   where I would have expected them to be in
> >     ${HOME}/PYTHON_TST/lib/python2.3/site-packages/documancer
>
> Sorry, why? Documancer is *not* a Python package, it's an application,
> so why install it into the place where Python libraries are
> installed?

Well, my "expectation" came from other applications,
e.g. mayavi or pycrust, idle, helpviewer,...

> Also, you can currently run single Documancer installation
> using both 2.2 and 2.3 interpreter, but you'd have to have two
> installations

That's a good point, indeed.

> >   (Actually, a setup.py file might be nice).
>
> While setup.py may be useful for installing multi-platform Python
> packages, I don't find it terribly useful for installation of
> applications. In fact I consider autoconf's checks much more useful
> -- is there some way to seemlessly integrate autoconf and setup.py?
> Also, note that Documancer is mixed-language code (C and Python).

I don't know distutils well enough, but I heard about
several people/projects being pretty unhappy with it in many respects.

Anyway, I did not have any problems in installing documancer,
so maybe it's better to leave this aside, there are more
interesting and more important topics to be delt with ;-)


> > - When clicking on a link to a ps or pdf document
> >   there is always a kind of download window,
> >   titled wxmozilla. It contains a list of all the
> >   previous .ps/.pdf.
> >   Is there a way to (optionally)
> >   prevent this window from showing up at all?
>
> I don't know. But I'm [almost] sure it can't be done on wxMozilla
> level.

Hmm, I really don't like it so I will have a closer look at
that (not questioning your expertise here, but sometimes
naive user questions, ignorant of implementation specific
details, may encourage developers (wxMozilla) for changes ;-)

So far I tried to set in ~/.documancer/mozilla-profile/prefs.js
  user_pref("browser.download.progressDnldDialog.keepAlive", false);
which is "accepted" (according to about:config)
but does not give the desired effect (maybe it is
the wrong option ;-).

> >   (even though it might be sometimes nice as it allows to inspect
> >    the settings for wxmozilla with about:config)
>
> This inspired me to add "Configure Mozilla" menu item that opens
> about:config, but it doesn't work well (read-only, doesn't workd &
> even crashes when you try to edit the prefs).

That looks nice - also checked it here: same happens ....
(BTW: maybe it is problematic to link the mozilla configuration
from ~/.mozilla to the one from documancer as suggested in the FAQ
as changes on the documancer side reflect back to the "normal"
mozilla (which might be even a different version) ...)


[...]
> >   Therefore it would be nice to have the search indices
> >   for these documents just generated once (by "root")
> >   so that the users to not have to create and store
> >   their own copy of this.
>
> Yes... It opens some problems, though:
> * How do you edit global vs. root-user-only books?

sorry, I don't understand the question -  what do
you mean by "global" books ?

> * Provided Documancer can update index if it detects its out of date
> (it will support it, eventually),

Great - looking forward to that ...

> how can it update shared books if
> it is not run as root?

Hmm, maybe this is asking too much: the program could just say: "sorry,
I cannot update the index, please ask root to do it...".
Optionally it could offer to create a local index
(which gets removed if there is an updated global one ??)
Generally I would think that documentation on the root
level will not change that often ...

Anyway, you are absolutely right, this requires a bit of thinking ...


> > - In addition to html files there might be also pdf files.
> >   Would it be possible to include these into the search
> >   when they are referenced from a html file?
>
> Not easily -- I can't index PDF files currently, I can only display
> them if Acrobat Reader is installed, I can't highlight search results
> in them, have bookmarks, i.e. they cannot be first class citizens in
> Documancer yet. But I'd like to be able to fully use them at some
> point (by means of xpdf or something similar).

Personally I would say that indexing PDF files would be
a big step forward. Searching inside the PDF file would
then be just done via acroread's search.
So it would not be a first class or third class ;-) citizen
but maybe second class. Fine enough as more than a start IMHO ;-).

By now I had a look at swish-e and actually
one can tell it to index pdf files
(or anything else) by providing the appropriate filters.

I tried the prog variant (i.e. example9.config from
the swish-e examples), however I ended up with
"Warning: XML parse error in file".
In contrast  example8.config, which uses a filter,
_pdf2html.pl and the xpdf package , works fine!
((The call is just
swish-e  -c example8.config -v 3  -f index.swish-e
/directory_with_html_and_pdf/
))
In contrast the call
swish-e -v 3  -f index.swish-e -i    /directory_with_html_and_pdf/
will also index the pdf files, but "raw", i.e. without
conversion to html or xml, producing useless index entries.
If you want I can look further into this
so that one could add this to the configuration file
written indexer.py.

> > - Thinking of having a documancer session open all the time
> >   it would be nice if there is a way to
> >   direct queries from an interactive (I)python session
> >   (or pycrust, or emacs, or ...)
> >   to documancer.
>
> Also planned...

Alright, I also looked into this a bit - I have set up a small
example which communicates via sockets
To incorporate this into documancer the approach could be the following
 - app.py: DocumancerApp(wxApp):
    def OnInit(self):
        [....]
        docuServer.runDocuServer(inBackground=1,DoSearch)

   # - here DoSearch is defined in MainFrame.py
   # Question: should one use the uiCallback for making
   #           this available here ?

 - MainFrame.py:

    def DoSearch(self,query):
       [... old OnSearch ...]

    def OnSearch(self, event):
        DoSearch(self.search_text.GetValue())

Now any external programm which wants to send a search string
needs to know the address of the "docu server"
(determined analogously to getServerPort (from utils.py)).
Should one store that number in a file in the ~/.documancer
directory?
What do you think, does the above sound like a reasonable
approach ? If you want I can try to piece the things
together...
Hmm, there is one missing bit in the above approach:
in some way we need to specify the book in which the search should be
done ...
(so maybe the external program needs to parse ~/.documancer/config.ini,
and pre-pend this to the search string ?).

> But the TODO with my plans is way too big, so I could
> definitely use some help, as usual ;)

Honestly, I would love to help out more, but presently
I am really swamped with other (scientific) stuff
which only leaves me little time to look into python things
(and I have couple of small python things which eat up that "spare" time).
So at this point I better don't make any promises
and just restrict myself to some kind of "testing".

Best,

Arnd