Is there a way to disable editing of the textarea, but still allow editing 
of other fields in the entry? (e.g. Fixed Attributes Edit = Text)
Also, is the data entered in that field accessible through a variable like 
$author? I tried $text, but that doesn't seem to work.

Thanks,
-Todd

By the way... Nice work on this. It has a lot of good features.

> I also have this problem, when a non admin user logs in he does not have access to
> the config file but if he logs out he can then access the config file as non logged
> user.

If he logs out, how can he access a logbook at all? He should be presented a login
screen, nothing else...

> I also tried to upgrade to version 2.5.3 but running under this version does not ask
> for passwords so I reverted to 2.5.2.

Better first let's fix this problem. Under what circumstances does 2.5.3 not ask for
passwords? Maybe you can get the newest version from CVS (see download page) and try
again, I had problems when using the -DHAVE_CRYPT functionality, but I guess you did not
have that, do you?

So once you tried the latest snapshot, and still have problems, describe them carefully,
send me your configuration file, and I will have a look.

- Stefan

> Is there a way to disable editing of the textarea, but still allow editing 
> of other fields in the entry? (e.g. Fixed Attributes Edit = Text)

I could add that option, but I don't know if it helps you (see below).

> Also, is the data entered in that field accessible through a variable like 
> $author? I tried $text, but that doesn't seem to work.

No, that won't work. Attributes are limite to some 500 characters, while the
text body is limited to 250000 characters. If you add $text to an attribute, it
would overflow or you would have to truncate the text, which I guess is not
good in both cases.

If you still want "Fixed attributes edit = text", please explain me you exact
case and I will consider implementing it.

> > Is there a way to disable editing of the textarea, but still allow editing 
> > of other fields in the entry? (e.g. Fixed Attributes Edit = Text)

I added a flag

Fix text = 0|1

A division in "fix text edit/fix text reply" does not make sense here, since I only
can lock the whole textfield, therefor just the switch.

New version under CVS (see download page).

> > > Is there a way to disable editing of the textarea, but still allow editing 
> > > of other fields in the entry? (e.g. Fixed Attributes Edit = Text)
> 
> I added a flag
> 
> Fix text = 0|1
> 
> A division in "fix text edit/fix text reply" does not make sense here, since I only
> can lock the whole textfield, therefor just the switch.
> 
> New version under CVS (see download page).

Thanks Stefan. Again, my hat is off to you for a great app.

Todd

I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
to stop working after the first or second filter attempt. I find that if I 
allow fewer quick filter options it seems to work more consistently. For 
example:

Example 1-
Quick filter = Date
The date filter will work without a problem no matter how many times I use 
it.

Example 2-
Quick filter = Date, Category, Status, Priority
The first filter I use will work, but upon trying a new filter, or just a 
new option in the same filter, all options return to "All Entries" and no 
filter options have any effect on the view.
If I exit the log book, and come back in, it works for the first filter 
attempt, then stops again.

This used to work fine prior to the update. I should also mention that the 
original installation of ELOG was from the Debian package. At that point, 
nothing was where the documentation said it should be (e.g. elogd.cfg was 
called elog.conf and was placed in the /etc/ directory). Everything worked 
fine, so I left it alone. When I recompiled with the newer elogd.c, 
anything that required a path was hosed, so I now have to specify the 
resource directory and the path to the conf file when starting ELOG. I 
don't know why this would affect the Quick Filter, and I'd assume that it 
would just stop working all together. Also, when I recompiled using "gcc -
O -o elogd elogd.c", I received the following warning:

elogd.c:546: warning: conflicting types for built-in function `logf'

Any suggestions?

Thanks!
Todd

Elog is a great program, but it can be slow.

I noticed that the gcc compiler options in the tarball Makefile were not
conducive to speed.  There, I tried changing the gcc options to:

CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall

for version 2.5.3, the compile worked, and the program appears to work as
normal, but a bit faster.   I have not benchmarked it, but I think it should
offer a nominal increase in speed.

In particular, I removed the "-g" profiling option, which is not needed for
production code, and can be safely removed. In addition, I put in slightly
aggressive optimization settings, so if this doesn't work for you, you can
first try removing the -f setting, and then backing off the optimization to -O2.

Other may want to post other settings that work for them.

> I noticed that the gcc compiler options in the tarball Makefile were not
> conducive to speed.  There, I tried changing the gcc options to:
> 
> CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall

Thank your for this hint, I changed my Makefile for the production code. However, I
could not feel any difference between the two options. The real problem is the
function getcfg(), which gets called many thousand times internally and has to parse
elogd.cfg each time. Once I implement a hash table for that function, elogd should
become faster by at least a factor of two.