> > ok, i've downgraded my request then ...
> > 
> > it will be still useful to have the possibility of expland selectively a single thread :-)
> 
> That you can do by clicking on the thread and look at the thread at the top of the page (;-))
> 
> That's exactly the same number of clicks as you would need to expand a thread (:-)))

LOL ..this way I can't see the list of other threads .. so il my goal is to inspect the thread
looking for something I have to:
- open the 3d
- return to 3d list
- open another 3d ..
[loop]

my wish would be to reduce it to
- open the 3d
- open another 3d ..
[loop]

of course I'm thinking to a big number of entries in a short number of 3ds .. making ugly to
simply expand everything .. :-)

Ok, fixed. I do however not evaluate the conditional attribute, but just remove any
empty attribute, I guess that makes more sense.

> ok, i've downgraded my request then ...
> 
> it will be still useful to have the possibility of expland selectively a single thread :-)

That you can do by clicking on the thread and look at the thread at the top of the page (;-))

That's exactly the same number of clicks as you would need to expand a thread (:-)))

> > A way may be using cookies, otherwise one can implement a kind o session mechanism
> > (using cookies or QS to pass sessid and storing user data on the server for a limited
> > time...)
> > the session method may be useful, but more difficult to implemnet, of course
> 
> The concept of a session ID is not present in elog, so implementing it would be harder
> than writing elog from scratch. Keeping the thousand 'expansion' flags in cookies is bad
> as well, because your browser will send them all each time you request a page, which can
> then slow down things considerably over slow lines.

ok, i've downgraded my request then ...

it will be still useful to have the possibility of expland selectively a single thread :-)

> A way may be using cookies, otherwise one can implement a kind o session mechanism
> (using cookies or QS to pass sessid and storing user data on the server for a limited
> time...)
> the session method may be useful, but more difficult to implemnet, of course

The concept of a session ID is not present in elog, so implementing it would be harder
than writing elog from scratch. Keeping the thousand 'expansion' flags in cookies is bad
as well, because your browser will send them all each time you request a page, which can
then slow down things considerably over slow lines.

> > When I define 2 attributes, by default and the second one has to be showed
> > depending on the first one value the elog correctly handle the thing, but
> > the rss feed shows an empty comma separeted field corresponding to the
> > conditional attribute not filled ...
> 
> Can you send me the part of your config files with those things so that I can
> reproduce it?

it is attached

> > of course elog should remember the choice, so it will be possible to expand
> > N threads over the M total ones..
> 
> How should elog remember that? If you put this into the URL like
> 
> http://<elog-host>/<logbook>/?exp=12&exp=14&exp=18
> 
> to expand the entries 12, 14 and 18, it might work fine. But imagine that some uses
> have very long list with thousands of entries. This would make the URL very long,
> everything very slow and could even crash some browsers.
> 
> What I usually do is to not expand the list. If I click on an individual entry, I
> see then the expanded thread for that entry above that entry. But you probably
> realized this possibility already.

:-) yes I do 

A way may be using cookies, otherwise one can implement a kind o session mechanism
(using cookies or QS to pass sessid and storing user data on the server for a limited
time...)
the session method may be useful, but more difficult to implemnet, of course

> Is it possible to have last runtime filtering and viewing method to be
> stored in a cookie in order to make them permanent across navigation ?

Sounds like a good idea. Will put it on the wishlist.