Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Fri Feb 17 13:31:00 2006
|
| Steve Jones wrote: | If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris? |
Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Mon Feb 20 17:50:33 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris? |
The compiled version runs fine under Solaris9. When executing Subst Subject = $shell(uname) I got:
"SunOS" !!! ;->
So, short of the items I pointed out below I would say that you have successfully re-rendered eLog as a truly cross platform application once again! My hat is off to you!
thanks
Steve |
|
Re: CKeditor Settings Cant Be Changed , posted by Stefan Ritt on Wed Feb 1 11:31:10 2023
|
elogd checks for the "scripts/ckeditor/ckeditor.js" file to detect the presence of CKeditor.
| James Smallcombe wrote: |
|
I wanted to change some CKeditor settings so tried modifying elog/scripts/ckeditor to no avail.
I wiped elog/scripts/ and dropped a fresh download of CKeditor4, with only the basic extensions. But when I open the elog it still shows the full toolbar, with elog default style and with all extensions operational.
If I leave elog/scripts empty, I get "CKeditor NOT detected" when starting elogd and the HTML option is empty and shows nothing, all as expected.
Does anyone understand this? Is there some CKeditor configuration file elog is defering to that I've overlooked? I have tried system wide seaches just in case.
|
|
|
Re: CKeditor Settings Cant Be Changed , posted by James Smallcombe on Thu Feb 2 10:13:19 2023
|
So it was just a clearing cache issue. elogd was telling the browser to use/not use CKeditor based on the aformentioned, and browser was then using the cached version. Fixed now.
And FYI for anyone who reads this when trying to modify CKeditor themselves, it seems elog needs the iFrame Editing Area plugin included.
| Stefan Ritt wrote: |
|
elogd checks for the "scripts/ckeditor/ckeditor.js" file to detect the presence of CKeditor.
| James Smallcombe wrote: |
|
I wanted to change some CKeditor settings so tried modifying elog/scripts/ckeditor to no avail.
I wiped elog/scripts/ and dropped a fresh download of CKeditor4, with only the basic extensions. But when I open the elog it still shows the full toolbar, with elog default style and with all extensions operational.
If I leave elog/scripts empty, I get "CKeditor NOT detected" when starting elogd and the HTML option is empty and shows nothing, all as expected.
Does anyone understand this? Is there some CKeditor configuration file elog is defering to that I've overlooked? I have tried system wide seaches just in case.
|
|
|
|
Re: CKeditor Settings Cant Be Changed , posted by Antonio Bulgheroni on Thu Feb 2 10:23:45 2023
|
It means that you could replace the currently distributed CKeditor with a fresh vanilla installation of CKeditor?
| James Smallcombe wrote: |
|
So it was just a clearing cache issue. elogd was telling the browser to use/not use CKeditor based on the aformentioned, and browser was then using the cached version. Fixed now.
And FYI for anyone who reads this when trying to modify CKeditor themselves, it seems elog needs the iFrame Editing Area plugin included.
| Stefan Ritt wrote: |
|
elogd checks for the "scripts/ckeditor/ckeditor.js" file to detect the presence of CKeditor.
| James Smallcombe wrote: |
|
I wanted to change some CKeditor settings so tried modifying elog/scripts/ckeditor to no avail.
I wiped elog/scripts/ and dropped a fresh download of CKeditor4, with only the basic extensions. But when I open the elog it still shows the full toolbar, with elog default style and with all extensions operational.
If I leave elog/scripts empty, I get "CKeditor NOT detected" when starting elogd and the HTML option is empty and shows nothing, all as expected.
Does anyone understand this? Is there some CKeditor configuration file elog is defering to that I've overlooked? I have tried system wide seaches just in case.
|
|
|
|
|
Re: CKeditor Settings Cant Be Changed , posted by James Smallcombe on Thu Feb 2 10:35:38 2023
|
Yes replacing the CKeditor folder with a vanila download works without issue, provided you clean the cache.
For what I originally wanted to do (modifiying the toolbar) I could have just run elog/scripts/ckeditor/samples/toolbarconfigurator/index.html and edited the config file, but a clean cache is needed (on Chrome, Firefox and Edge).
| Antonio Bulgheroni wrote: |
|
It means that you could replace the currently distributed CKeditor with a fresh vanilla installation of CKeditor?
| James Smallcombe wrote: |
|
So it was just a clearing cache issue. elogd was telling the browser to use/not use CKeditor based on the aformentioned, and browser was then using the cached version. Fixed now.
And FYI for anyone who reads this when trying to modify CKeditor themselves, it seems elog needs the iFrame Editing Area plugin included.
| Stefan Ritt wrote: |
|
elogd checks for the "scripts/ckeditor/ckeditor.js" file to detect the presence of CKeditor.
| James Smallcombe wrote: |
|
I wanted to change some CKeditor settings so tried modifying elog/scripts/ckeditor to no avail.
I wiped elog/scripts/ and dropped a fresh download of CKeditor4, with only the basic extensions. But when I open the elog it still shows the full toolbar, with elog default style and with all extensions operational.
If I leave elog/scripts empty, I get "CKeditor NOT detected" when starting elogd and the HTML option is empty and shows nothing, all as expected.
Does anyone understand this? Is there some CKeditor configuration file elog is defering to that I've overlooked? I have tried system wide seaches just in case.
|
|
|
|
|
|
Re: CKEditor won't load under IE Compatibility Mode, posted by Stefan Ritt on Thu Jun 25 12:52:06 2015
|
I don't get your point. If you add the meta tag wiht the viewport, then the IE7 mode will load the CKEditor? The CKEditor home page says that IE7 is not supported any more, so I wonder if this simple tag might help. Can you turn off the compatibility mode on a per-URL basis?
If I try on my smatphone, the display is correct, so why you need the viewport tag? Can you shouw me examples?
If you have nice CSS features which are helpful for everybody, please send them to me and I can include it in the distribution, but only after you convince me that it works (almost) everywhere.
Best,
Stefan
| Ben Shepherd wrote: |
|
I just upgraded to 3.1.0 after many years using 2.9.2. Our eLogs are absolutely crucial for the operation of our accelerators, so first of all I'd like to say: thanks a lot for everything you've done! It's a rock-solid application that works really well.
The issue I'm having is a minor one. Some of our users are using Internet Explorer 11, which has a Compatibility Mode option that is enabled by default for intranet sites (of which our eLog is one). This mode emulates IE7, and this causes the CKEditor rich text box to fail to load. I can tell our users to disable the CM setting on their browsers, but it may be that a simple server-side fix is possible as well.
It would be nice if the eLog pages could have a <meta name="viewport" content="width=device-width, initial-scale=1.0"> tag, so that it displays nicely on smaller screens. I've been adding this myself in some Javascript code (see elogHelper.js on the above-linked website), but it doesn't appear on every page (the logbook selection page, for instance). I also made some modifications to the CSS so that the list display collapses down when the browser window is very narrow.
The new autosave functionality is really good. I hacked something together to do this for our log a while ago, but it's nice that it's inbuilt now.
Thanks again!
Ben
|
|
Re: CKEditor won't load under IE Compatibility Mode, posted by Ben Shepherd on Thu Jun 25 14:55:16 2015 
|
The viewport thing and the IE7 mode thing are separate issues.
OK, maybe it's a CKEditor thing then. I thought it might be. It seems pretty stupid that the default setting in IE is to emulate an older browser - although I guess a lot of people have very outdated intranet sites. Anyway, we have a fix here so I don't think you need to do anything. Just thought you might want to know.
The viewport tag issue - see attachments. The first two are the log selection page and the list page, both without the viewport tag. Obviously you can zoom in, but this is how they appear by default, as (apparently) Chrome tries to render the whole page width. The third one is how the list page appears when the viewport tag is added, and the fourth is with my custom CSS to put the columns on separate lines. It's probably very bad CSS, so I'm certain that it's not robust or cross-platform, but it works for me :)
/* 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;
}
}
| Stefan Ritt wrote: |
|
I don't get your point. If you add the meta tag wiht the viewport, then the IE7 mode will load the CKEditor? The CKEditor home page says that IE7 is not supported any more, so I wonder if this simple tag might help. Can you turn off the compatibility mode on a per-URL basis?
If I try on my smatphone, the display is correct, so why you need the viewport tag? Can you shouw me examples?
If you have nice CSS features which are helpful for everybody, please send them to me and I can include it in the distribution, but only after you convince me that it works (almost) everywhere.
Best,
Stefan
| Ben Shepherd wrote: |
|
I just upgraded to 3.1.0 after many years using 2.9.2. Our eLogs are absolutely crucial for the operation of our accelerators, so first of all I'd like to say: thanks a lot for everything you've done! It's a rock-solid application that works really well.
The issue I'm having is a minor one. Some of our users are using Internet Explorer 11, which has a Compatibility Mode option that is enabled by default for intranet sites (of which our eLog is one). This mode emulates IE7, and this causes the CKEditor rich text box to fail to load. I can tell our users to disable the CM setting on their browsers, but it may be that a simple server-side fix is possible as well.
It would be nice if the eLog pages could have a <meta name="viewport" content="width=device-width, initial-scale=1.0"> tag, so that it displays nicely on smaller screens. I've been adding this myself in some Javascript code (see elogHelper.js on the above-linked website), but it doesn't appear on every page (the logbook selection page, for instance). I also made some modifications to the CSS so that the list display collapses down when the browser window is very narrow.
The new autosave functionality is really good. I hacked something together to do this for our log a while ago, but it's nice that it's inbuilt now.
Thanks again!
Ben
|
|
|
|