OS/2, eCS & ArcaOS - Technical > Programming

WebSite / HTML editor - what do we have?

<< < (3/4) > >>

Dave Yeo:
You might want raise your VIRTUALADDRESSLIMIT, otherwise no idea unless you have an old libc on your LIBPATH. Looking, I see it was compiled with GCC 3.3.5 and libc063 with no other dependencies and the code predates xul.dll.
distorm.dll is part of exceptq, which is now in libc IIRC.
Edit: Marking the DLL's high might be a mistake as well. I think the code is from before we started using high memory. For the same reason, it will need more low memory then current Firefox.

ivan:
Hi Dariusz,

My copy of Kompozer runs as it always has since I installed it - v0.8b3 and I work on the principle if it isn't broke don't fix it, but then I never chase the latest and greatest and never rub the RPM/YUM updater which might be the answer to your problem. 

Dariusz Piatkowski:
Dave,
All my libcxxx DLLs are sitting in the \usr\lib directory, no dups anywhere else. I did also try setting different load options for LIBC, but none of them resulted in any improvements.

Maybe VIRTUALADDRESSLIMIT is the key, worth a try I suppose...

Ivan,
The issue I'm seeing with Kompozer ONLY happens when FF is already loaded. Since I have Thunderbird deployed as well here, there are some pretty heavy resource demands, so I suspect I'm actually running into some kind of a conflict given that Kompozer is based on the Mozilla framework as well.

Jan-Erik Lärka:
I use version 0.8b4pre (20100331, Gecko 1.8.1) as well, and the css-editor make it more useful than SeaMonkey.
Switching directly between the source code- and wysiwyg view cause problems, most often add square characters but also disable the save button. But that occur on other os:es such as "blowing in the wind" as well. Switch between the three tabs at a slow pace from left to right, or right to left to overcome some problems.

KompoZer 0.8b4pre produce code compatible with our firefox as both was created from the same generation of the mozilla engine (as in Firefox: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0). The included css-editor make it quite useful compared to the newer Blue Griffon 1.1.1 from 2011 (the css editor wasn't included by default), but doesn't support new styles introduced with html5. The css editor may therefore remove code you add by hand that it (the mozilla engine) doesn't support, unless you avoid to touch the custom style.

I would have preferred the idea to have the various front ends (such as KompoZer, Firefox, SeaMonkey, Thunderbird etc.) use one (1) common mozilla engine, but other platforms however must have dictated how and what.

Dave Yeo:
Hi Dariusz, since everyone else is running it fine and it only fails for you when Firefox is open and you're using LIBPATHSTRICT, it seems the most likely is resource starvation, and memory makes sense.

Hi Jan-Erik, actually Kompozer is quite a bit older then our Firefox, Gecko 1.8.1, somewhere around Firefox 3.6 IIRC. So no where as capable as our Firefox but creates portable websites. The security stuff is likely too aged making it difficult to load HTTPS sites.

--- Quote ---I would have preferred the idea to have the various front ends (such as KompoZer, Firefox, SeaMonkey, Thunderbird etc.) use one (1) common mozilla engine, but other platsforms however must have dictated how and what.

--- End quote ---

At one point that was the plan. Used to be xul-runner.exe which would run Mozilla apps, "xul-runner firefox.ini" or such would start Firefox. Never caught on, never supported SeaMonkey and Mozilla moved away from the idea. It would have still taken compatible Gecko versions, which sm, ff and tb are, but not Kompozer.
Thanks for the hints to work around some deficiencies, I haven't really used it.



Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version