Re: [documancer] Re: a few bugs?

Hi,

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

On Wed, 24 Dec 2003, Vaclav Slavik wrote:

> arnd.baecker-S0/[email protected] 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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click