On my linux box, every time I select a thread, or start a new entry etc, I see that one or many cookies are sent.

On a terminal, I get the message

Received unknown cookie "CalciumDisplayParams"

Now I do have a perl script called Calcium, (Calendar viewed through the browser) but it's definately not running now, not in any browser window, and in any case why should an action of ELOG trigger this?  I realise it may be due to an idiocyncratic set up of this box.  But in normal operation, I doubt the user would see these cookies being received.

Hi Stefan,

Thanks for the explanation.  I realised it was just an error message of no real import, but it can get irritating at times.

I have had to play around with viewports for other reasons than elog, but I do have a couple of comments to make.  Obviously the meta tag viewpoint has to be added in.  Also, elog was written for large screens (no-one thought anything else was possible when elog was started), and it is relatively recent that mobile devices have become a significant percentage of views of web pages.  Google is downgrading websites that are not mobile-friendly - that is, not starting with the viewport meta tag.  So there may have to be a fair re-arrangement of the default layout of elog for it to remain sensible on mobile devices. 

The attached css file (I made minor edits to someone else's - and they were freely giving it away), allows tabs running along the top of the page (below the title) for navigation.  So it would be nice if the elog tabs could operate in the same way when being used on a mobile device.  If select on one, it can become a drop down menu to select other tabs under that general top layer (I don't think that function is in the attached css file).  I've put a sample of such tabs (not drop down) in header.html attached.  Though I'm sure everyone else can write far better css and html code.

As I'm not a heavy mobile user, and often do need the whole screen to view matters, it would be nice if all of this could be optional in the elog.cfg file.

/* make things look a bit nicer on smaller screens */
@media (max-width: 700px) {
	table.listframe td, table.listframe th {
		display: none;
	}

	/* show id, date, personnel, summary in separate lines */
	table.listframe td:nth-of-type(-n+2), table.listframe td:nth-of-type(4), table.listframe td:nth-last-of-type(2) {
		display: block;
		border: 0px;
	}
}

In the emails generated by anyone making an entry in this log book, every apostrophe is followed by a semi-colon.  So the text "I don't think..."  appears in the email as "I don';t think...", and possibly that comment will appear in the email as "I don';;t think...." - not sure on the last bit.  It has been around in the past few versions of elog, but don't recall precisely when this started occurring.  It was fine back in February, with v2.9.2 (presumably) running.

As a variant of what Stefan has suggested:

Perhaps a simple comment is set up as the pre-loaded reply - perhaps including date and time.  Maybe include the author's name in the comment, but all that is available anyway (see documentation for that).  This bit isn't vital.

Then each user simply has to *reply* to the message concerned, and you then get the list of who has read it, available in threaded view of the comment and replies.

Of course this works best with small numbers of users, and where threads are never very long.  Also, it means that you can lock the original message (prevent it being edited) which may be a particular concern depending on what you are using elog for.

You might also want to define an attribute that a reader can tick to say that they have taken action if it is important that someone has to take further action (as opposed to just reading) - and maybe that changes the colour of the background or the icon in front of the topic.  Then there would be a record as to who has done the necessary, and later readers will know the matter is for information rather than needing attention.   For example,. who kicked the power supply to the ion source on Monday morning to "wake it up" (this is true, but pre-elog, so was a paper record).  John kicked it last Monday, and the power supply respects John, may be a statistic one could find from such information recorded as suggested here.

You may want a second attribute people have to explicity select so as to show they understand what they've read, rather than just reply/submit without having read... e.g. they have to select a digit of the ticket number, or some auto-generated number (or letter, I'm not characterist) that is within the original comment.

We all know people who click on things they've never read, and come on, we've all done it at times...

David.

Hi Alan,

I have no idea if this helps but the Date and Time formats in the config file internally interconnect, as I discovered in trying to define them separately.  Define one, and the other is defined.

I only mention this as I spent some hours trying to sort out the issue, only to learn it was a "feature" that Stefan didn't want to correct as it may affect too many others.  I can understand that, and made a different solution to what I wanted to do.

I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
 replies to an entry.  My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click.  I've always assumed that was the cause of the problem.  The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry.  I'm not sure how this overcomes the branching = 0 detail, though.

That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.

I don't know if you can get elog to generate a log file - check the documentation, I don't bother.  But I do have some experience with this matter.

There are two related circumstances I know of that can arise which will cause elog to crash.

As you are probably aware, the entries are threaded.  I find the main problem is if you move a long thread - I forget the number but over 30 entries - from one log book to another, it will copy across fine, but the deletion of the thread from the source logbook will crash elog *before* the entire thread has been deleted: cause 1.

If you then restart elog, and happen to access the partially deleted thread, elog will run into a loop.  You won't be able to access elog, and you will see it is burning up CPU time, and it probably will eventually crash, but normally I find what the process number is and kill it (with "kill -9 [process no]").  This is cause 2.  The reason is that elog is looking for an entry number in the thread that no longer exists (because elog has already deleted it).

There is a moderately convoluted way I have devised to completely delete the partially deleted thread, needing access to the yymmdda.log files.  Cause 2 can also occur if someone manually edits yymmdda.log files with insufficient care (that includes me on occasion).