ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68512
|
Fri Dec 16 14:44:19 2016 |
| Stefano Bonaldo | stefano.bonaldo.13@gmail.com | Bug fix | Mac OSX | 3.1.2 | Re: elogd crash on sorting the entries by an datetime attribute |
Bug FIXED! Many thanks Stefan and my warmest congratulations for the elog project.
Stefano
Stefan Ritt wrote: |
Ok I found it!
Was tricky. In my development environment (XCode) it worked fine. Only when I compiled elogd under Sierra on the command line, the probelm occured. That's why I did not see it earlier. It has to do with some functions Apple apparently changed ("strlcpy"). These function now have a new "functionality": When two parameters overlap, the function just aborts the process. This is specific to Sierre, so on any other Linux this does not happen. I changed now the soruce code to take care of the modified functions, and now it works fine. Please update to the newest GIT revision of elogd and recompile.
Stefan
|
|
69589
|
Fri Dec 2 14:12:35 2022 |
| Laurent Jean-Rigaud | lollspam@free.fr | Bug fix | Linux | 3.14 git | Buildrpm / copy .cxx in place of .c |
Hi Stefan,
It seems buildrpm should be updated to take care of cpp files. Plz replace "cp <blahblah>.c ..." by "cp <blahblah>.cxx ..." .
Also, uncomment the hostname test witch activates all authentification options by default. It should be done by adding options as follow : buildrpm ver rel -ldap -ker ...
By default, i can not build elog with LDAP.
After that mods, rpms are builded under EL7 (w/o LDAP support which is not useful for me).
Bye
Laurent |
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. |
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 |
69600
|
Wed Jan 4 09:39:38 2023 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | ELOG V3.1.4-493 | a hack around |
Ahh, now I remember. Well, the I put that in like 25 years ago ;-)
Let's assume the user write a very long line and relies on the wrapping of the text box. So the input might look like the
first attachment. Then the user hits submit and gets just one long line (second attachment) and has to scroll one kilometre
to the right to see the full line. So there is an inconsistency between the entry form and what the user sees after the
submission. Having "wrap=hard" tells the browser to put CRLF where the wrapping in the textarea happens, so the text looks
the same during entry and after submission. If we remove the "wrap=hard", we would be back to the situation below in the two
attachments.
Opinions?
Stefan |
Attachment 1: Screenshot_2023-01-04_at_9.38.51_.png
|
|
Attachment 2: Screenshot_2023-01-04_at_9.39.09_.png
|
|
69601
|
Wed Jan 4 10:05:38 2023 |
| Andrey Pashnin | kowaraj4stuff@gmail.com | Bug fix | All | ELOG V3.1.4-493 | editing on a smartphone |
oh! so, that's the cause of another problem I faced a while ago.
When people edited an ELOG page on a narrow screen device (a.k.a smartphone) it put the extra CRLF and made the page look like the attachment below
(it broke the original formatting).
I had to "fix" this by setting the width of the textarea to a huge number...
However, removing "wrap=hard" solves both these problems! ;) |
Attachment 1: Screenshot_2023-01-04_at_10.06.02.png
|
|
69602
|
Wed Jan 4 10:12:43 2023 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | ELOG V3.1.4-493 | editing on a smartphone |
Yepp, that's right. But without the "wrap=hard", you could get one single long line which is almost impossible to read. So there is no perfect solution for all cases. I see three options
1) Remove "wrap=hard" and let the user do as the user wants. This can lead to very long lines almost impossible to read.
2) Keep "wrap=hard" and rely on the browser to put in CRLF between lines according to the textarea box during input. The result will then be the same as during editing. Of course this might
require to make the textarea width wide enough on small screens not to get too many CRLFs. The default "Message width" is 78 chars, but on modern browsers some JavaScript code automatically sets
the width to equal the screen width which normally is wider.
3) Add artificial CRCL like every 40 or 80 chars. This is the "beautifying" K.O. mentioned and will never be perfect. Not sure if elog should touch the text the user enters.
Looking at the three options, I kind of conclude that 2) would still be the best.
Stefan |