> Okidokie. May I then humbly suggest to mention this in the documentation of the elog command client?

I did modify it already, see http://midas.psi.ch/elog/userguide.html at the bottom.

> > Is there any way to configure elog so that attribute fields can be edited 
> > on more than line like the 'text' field? 
> > 
> > (This would be useful so that attributes could contain larger portions of 
> > text including line breaks)
> 
> No, but this request is already on the wishlist
> (http://midas.psi.ch/elog/wishlist.html) since some time. I added your vote.

Stefan,

Was just wondering about the status of the multi-line attributes in Elog, are 
they implemented in elog yet? If not is that something you are planning to do 
in the future?

many thanks

Paul

> Was just wondering about the status of the multi-line attributes in Elog, are 
> they implemented in elog yet? If not is that something you are planning to do 
> in the future?

In order to have multi-line attributes, the whole format of the logbooks has to be
changed. I plan to use XML for the logbook format in the future. We would not have
any more one file per day, but one big file per logbook. I have already some XML
functionality in elog, but this one requires a major rewrite of the whole code. On
the other hand, searching etc. will become much faster afterwards. I plan to start
this development soon, but it might take quite some time, so don't expect it
before summer or fall.

Best regards,

  Stefan

> > Was just wondering about the status of the multi-line attributes in Elog, are 
> > they implemented in elog yet? If not is that something you are planning to do 
> > in the future?
> 
> In order to have multi-line attributes, the whole format of the logbooks has to be
> changed. I plan to use XML for the logbook format in the future. We would not have
> any more one file per day, but one big file per logbook. I have already some XML
> functionality in elog, but this one requires a major rewrite of the whole code. On
> the other hand, searching etc. will become much faster afterwards. I plan to start
> this development soon, but it might take quite some time, so don't expect it
> before summer or fall.
> 
> Best regards,
> 
>   Stefan

Thanks for your help, thats useful to know.

Paul

Hello,

I'm looking for an option to attach a user to a log?

For example:

Rob is making the log, and whant's to dedicate the log to a stagaire,
the stagiare recieves an E-mail so that he can do the job?

Bud we all want recieve the mail bud the stagiare see's that the job is for 
him.

Is there a solution for it?

Best regards Rob de Bruin

> I'm looking for an option to attach a user to a log?
> 
> For example:
> 
> Rob is making the log, and whant's to dedicate the log to a stagaire,
> the stagiare recieves an E-mail so that he can do the job?
> 
> Bud we all want recieve the mail bud the stagiare see's that the job is for 
> him.

Maybe use an attribute for that?

Like

Attributes = Author, ..., stagaire
Options stagaire = Jim, Joe, ...

So Rob can select a stagaire from the list, and the email contains this name.

- Stefan

I would like to increase the spacing between 'MOptions' choices. I have
created a new theme and have been playing with the CSS stylesheet. But can't
find how to increase this spacing. Having lots of fun otherwise!

Tks,

mark

> I would like to increase the spacing between 'MOptions' choices. I have
> created a new theme and have been playing with the CSS stylesheet. But can't
> find how to increase this spacing. Having lots of fun otherwise!

Intersting question (meaning: I don't have an answer... (;-) )

The class which applies there is "attribvalue". You can increase the padding for
that class, but that only increases the space between all options and the cell
border, but not between them. I could put each MOption in a separate cell of a
subtable. Then one could increase the padding between them, but the layout would
be fixed, meaning that they are always left-to-right. As you can see in this
forum, the MOptions nicely place below each other if the screen is too narrow.
This functionality would be lost.

Maybe someone else has a clever solution?