> > - Irestarted the daemon
> > - attached strace to it
> > - requested the list for a testin logbook, few entries some quite big images 
> >   (two thumbnails, the other are old images get resized my the browser)
> > - repeted previous point a couple of times
> > - press F5 (mozilla-firefox)  the browser hangs 4ever
> > - stop the load
> > - repeat point 3, all right
> > - F5 => hangs
> > - F5 => hangs
> 
> I tried to reproduce this problem, but everything was fine. This problem was never
> reported by anyone else as well.

I tried to rise the problem with konqueror, and all works nice... running
mozilla-firefox gives the problem instead (also running the test at the same time), so
there should be something in firefox or in the interaction between firefox and elog.
I'll send you one of the elog giving the problems so you can test by yourself as you
asked.

btw:
http://midas.psi.ch/elogs/Forum/?mode=full&attach=1  does not gives any problem to me
even running firefox. so the problem may be in some my elog.cong parameter ...

> > - Irestarted the daemon
> > - attached strace to it
> > - requested the list for a testin logbook, few entries some quite big images 
> >   (two thumbnails, the other are old images get resized my the browser)
> > - repeted previous point a couple of times
> > - press F5 (mozilla-firefox)  the browser hangs 4ever
> > - stop the load
> > - repeat point 3, all right
> > - F5 => hangs
> > - F5 => hangs
> 
> I tried to reproduce this problem, but everything was fine. This problem was never
> reported by anyone else as well.

running ethereal I found a bug, hope this is the problem hanging my firefox (I think
we have a good chance it is :-P)

when I have thuimbs enabled, elog returns for the ".thumb" (or ".whatever".. thumb's
extension should be transparent to elog .. uhm... it can't be .. this is a problem)

anyway, having attached a pdf (a big one) and aving attachment display enabled (with
my thumbnails generated by my script)  elog returns for the displayed thumb a
Content-Type for application/x-pdf, instead of the correct image/jpeg. I think this is
the problem.

The only way for elog to know what is the correc\t content type for thumbnails is to
get it from a configuration parameter, becouse it is a chioce of the external script
used to generate them to choose the type of thumbs (jpeg, png, gif ... )
One conf parameter defaulting to jpeg may be the solution

> Newly installed elog gives this response when I try to submit a new record:
> 
> New entry cannot be written to directory "./logbooks/Linux/" 
> Please check that it exists and elogd has write access
> 
> I started the daemon.  I've not yet assigned passwords -- just checking
> things out.  How can I create this access to my own directory?

First, find out under which account the daemon is running. It you account if
you start it interactively, if you installed from the RPM, an account "elog" is
created. Then make sure that the account under which elogd is running has write
access to the ./logbooks/Linux/ directory. One common problem is that people
start the daemon the first time under their account, which causes elogd to
create the logbook directory under the user name. If elogd is later started
under the account "elog" this one of course does not have access to the
directory. A

chown -R elog.elog /usr/local/elog/

issued as root could help in that case. Please replace /usr/local/elog with the
directory where elog is installed.

> I noticed a long url got hard-wrapped when I entered a long one, I patched 
> the source code. I don't know if this was done intentionally, otherwise you 
> might want to change this also.
> 
> diff elogd.c elogd.c.org 
> 4468c4468
> <     rsprintf("<textarea rows=20 cols=%d wrap=soft name=Text>", width);
> ---
> >     rsprintf("<textarea rows=20 cols=%d wrap=hard name=Text>", width);

If the wrap=soft is used, users tend to enter very long lines (without 
hitting return in between). If this line then gets displayed, it can be very 
wide and the user has to horizontally scroll the browser window. What I can 
do is in the display (not the entry) to concatenate URLs which are separated 
only by a CR/LF. But you then have some cases where you have an URL to the 
end of the line, then some other text starting on the next line, which then 
get concatenated falsely (unless you use some clever code which scans 
for ".html" or "xxx/xxx" or something like that.

> Now I don't like both parameters. 20 is too long for my display (1024x768) 
> and 76 is too short. Something dynamically would be cool, but a parameter 
> somewhere in a config file would also be acceptable. (just a thought, makes 
> it easier to upgrade)

You always had the option "Message width = xx" to change the width on the 
text box, and I added in V 2.2.2 the parameter "Message height = xx" where 
you can change the 20 to something else.

> The width of the textarea after pressing reply is too large. 
> The problem is that the algorithm that searches for the longes line
> looks for the next '\r' which it does not find and therefore takes the
> number of characters in the text to be the width of the longest line.
> To search for '\n' instead should solve the problem.  Please find the 
> diff output below.

Ok, implemented, thanks.