Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 41 of 806  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6445 Entries 
Goto page Previous  1, 2, 3 ... 40, 41, 42 ... 804, 805, 806   Next  
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  65719   Wed Jan 30 08:01:23 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux | Windows2.7.1.2007Re: Several attachement at the same time

stephane wrote:

I would like to make several attachement at the same time. I would be great cause I have lot of attachements to do every day. I try wiht CTRL or SHIFT key but I failed in.

Is it possible at this moment ?

Diogo Alves found a possibility, at least for firefox. Have a look here.

  65740   Fri Feb 15 03:16:45 2008 Idea Jeff Stonerjstoner@opsource.netRequestLinux2.7.2move mxml code into elog's src directory

The mxml source code should be moved into the elog-*/src directory. This requires changing the Makefile to:

MXMLDIR = src/mxml

Reason for change: if you want to build several versions of elog and you unpack the distributions in the same top-level directory, the most recently unpackaged version will overwrite the mxml directory contents, possibly introducing bugs.

 

  65741   Fri Feb 15 06:59:52 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux2.7.2Re: move mxml code into elog's src directory

Jeff Stoner wrote:

The mxml source code should be moved into the elog-*/src directory. This requires changing the Makefile to:

MXMLDIR = src/mxml

Reason for change: if you want to build several versions of elog and you unpack the distributions in the same top-level directory, the most recently unpackaged version will overwrite the mxml directory contents, possibly introducing bugs.

From your point of view that request is reasonable, but the reason of having mxml in a separate top level directory is that I use it in many different projects. If I would keep a copy of mxml in each project, I would have to update all of them manually if there is a bug. On the other hand the code of mxml changes very seldom. If you look at the history, it got ~5 changes last year, while elog itself had hundreds. And since I do not change the API, a bugfix in mxml should be to the benefit of all elog versions. It is like with other projects which depend on a number of packages. Like if you install Apache for example, you need a certain version of OpenSLL, a certain version of libcrypt, and so on.  So think of mxml like another package you have to combine with elog.

  65761   Thu Feb 28 19:07:19 2008 Idea Yoshio ImaiRequestLinux | All2.6.5#include statements and attachment visibility
Hi!

First of all, thank you again for the great software and all the support.

Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option.


Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like
#include /elog-archive/additional.config
in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.


Do you think it is possible (and preferable) to implement this?

Cheers

Y
  65768   Thu Mar 6 14:03:17 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux | All2.6.5Re: #include statements and attachment visibility

Yoshio Imai wrote:
Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option.


I made you something even better: I added a new option called Attachment lines. This number restricts the number of lines shown for any ASCII attachment. The default is 300, but you can set this to 10 maybe. This still shows you the first 10 lines of the attachment which might be handy. If you set this value to zero, no line at all is shown. The new feature is in SVN revision 2069.


Yoshio Imai wrote:
Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like
#include /elog-archive/additional.config
in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.


I will put this feature on the wishlist.
  65771   Thu Mar 6 18:19:48 2008 Cool Yoshio ImaiRequestLinux | All2.7.3Re: #include statements and attachment visibility
Thanks you! I just installed the new revision, and it works.

However, it does not seem to work in list mode (with attach=1 option): elog still shows all the lines of attached text files there.

I also noticed that the images referenced inline are also shown in the attachment list in list mode, although this post gave me the impression that in list mode, too, inline images should only be displayed inside the elog entry and not in addition as attachment.

Might this be a bug, or is there a particular reason why it is like that?
  65772   Fri Mar 7 08:01:44 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux | All2.7.3Re: #include statements and attachment visibility

Yoshio Imai wrote:
However, it does not seem to work in list mode (with attach=1 option): elog still shows all the lines of attached text files there.

I also noticed that the images referenced inline are also shown in the attachment list in list mode, although this post gave me the impression that in list mode, too, inline images should only be displayed inside the elog entry and not in addition as attachment.


I fixed both issues in revision #2072.
  65773   Fri Mar 7 13:07:34 2008 Agree Yoshio ImaiRequestLinux | All2.7.3Re: #include statements and attachment visibility
Thank you, works perfectly!
Goto page Previous  1, 2, 3 ... 40, 41, 42 ... 804, 805, 806   Next  
ELOG V3.1.5-3fb85fa6