ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69456
|
Fri Jan 28 17:37:55 2022 |
| Mariia Fedkevych | mariia.fedkevych@ge.infn.it | Question | All | 3.1.4-395e101 | Re: Adjustment of summary columns |
Thank you!
Stefan Ritt wrote: |
You can manually modify the CSS style to adjust column widths. Locate elog.css which resides under elog/themes/default/elog.css, then find the class “.listtitle”, and modify the line
width: 0%;
to something like
width: 10%;
you can play with the width until it suits your needs. After each change, you have to reload the page in the browser to see the effect.
If you only want to change the width of a specific column, add following lines to your elog.css:
.listtitle:nth-child(4) {
width:30%;
}
where ‘4” is for example the 4th column. You can have several of these statements for different columns.
To hide the text, use the option 'summary lines' as described in the manual.
Mariia Fedkevych wrote: |
Hi!
Is it possible to manage the column widths on a logbook's summary page one by one?
Also, is it possible to hide the Text column without actually hiding the text body in entries (as Show Text = 0 in elog.cfg does)?
Kind regards,
Mariia
|
|
|
69492
|
Wed Mar 9 16:25:31 2022 |
| Edmund Hertle | edmund.blomley@kit.edu | Request | All | 3.1.4 | Use different HTML class for drafts compared to not existing entries |
Right now a Draft shows a red error indication, that the entry is currently a draft. For the CSS styling it uses the HTML class="errormsg". The same class is also used if an entry does not exist.
Would it be possible for the draft version to use a different HTML class (for example class="draftmsg")? It can also use the same visual style (or making it yellow would probably also work)
The reason is that the py_elog Interface uses the class="errormsg" to determine if an entry does not exist ( https://github.com/paulscherrerinstitute/py_elog/blob/master/elog/logbook.py#L394 ) and refuses to return the content for this entry. One could possibly fix that also on the py_elog part, but it would probably at least require parsing of actual text (which might make problems for translated pages). Alternativley one could also look for the edit button, but maybe a small change on the elog server side is the simplest solution to this problem?
|
69594
|
Tue Dec 27 12:44:52 2022 |
| Andrey | kowaraj4stuff@gmail.com | Info | All | ELOG V3.1.4-493 | Duplicated \n in "plain" format with new WebKit |
Dear Stefan,
There is a problem with editing an Elog page in "plain" format with the following "User Agent" :
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15"
It duplicates the newline symbols such that "1<CRLF>2" becomes "1<CRLF><CRLF>2". If edited again - "1<CRLF><CRLF><CRLF><CRLF>2".
I blame the new version of the Apple WebKit.
It works fine with Chrome (user agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"). But fails with Safari.
Could you please have a look?
Thank you in advance,
Andrey Pashnin
AMS collaboration
|
69595
|
Wed Dec 28 16:09:30 2022 |
| Andrey | kowaraj4stuff@gmail.com | Info | All | ELOG V3.1.4-493 | bug report to webkit.org |
It shound't be a "bug report", sorry. I have changed the category to "Info".
It seems to be really a bug in the WebKit core. I have created a bug report there. For reference: https://bugs.webkit.org/show_bug.cgi?id=249923
I am going to try to patch the ELOG code to handle the content of the textarea in the "plain" format.... it doesn't seem possible though. |
69596
|
Thu Dec 29 20:26:11 2022 |
| Andrey | kowaraj4stuff@gmail.com | Bug fix | All | ELOG V3.1.4-493 | a hack around |
FYI.
Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);*/
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
|
69597
|
Fri Dec 30 00:46:03 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug fix | All | ELOG V3.1.4-493 | a hack around |
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
my vote is to remove "wrap=hard":
1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
3) this bug (introduced in recent safari, the best I can tell)
K.O. |
69598
|
Mon Jan 2 12:32:13 2023 |
| Andrey Pashnin | kowaraj4stuff@gmail.com | Info | All | ELOG V3.1.4-493 | webkit bug |
FYI
They seem to have accepted the bug report:
https://bugs.webkit.org/show_bug.cgi?id=249923 |
69599
|
Wed Jan 4 09:33:25 2023 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | ELOG V3.1.4-493 | a hack around |
> - rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
> + rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
>
> my vote is to remove "wrap=hard":
>
> 1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
> 2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
> 3) this bug (introduced in recent safari, the best I can tell)
>
> K.O.
I agree with K.O. Does anybody see a problem in removing "wrap=hard"?
It was there more for historical reasons. In the old days screens were not so wide and wrapping was more of an issue.
People tended to write longer lines and complained that the long lines got reformatted differently for different screen
sizes. So by adding hard CRLF the formatting looked the same on different screens. These days this is not such an issue
any more and I agree with 2) above. If the user wants a long line, the user should get it.
Stefan |