andré a écrit :
Hartmut Figge a écrit :
andré:
Hartmut Figge a écrit :
...
The reason is the missing junkcol.png which should reside in
omni.ja#chrome\classic\skin\classic\messenger\icons but is not there.
Verified by copying the .png to this location and restarting SM.
How did you succeed in copying a file to omni.ja ?
I've been replacing a file in omni.ja for years up to sm 2.17.1 ,
but with later versions it no longer works.
I know and i will not comment on the reasons for changing the behavior
to avoid the temptation of using censored words. *g*
understood.
The recommended way now is to use optimizejars.py which is sadly not
even in the source of SM. You can get it here
https://hg.mozilla.org/mozilla-central/file/f88a05e00f47/config/optimizejars.py
by using 'raw' to the right of the top. Invoke it using python and you
will get a help-screen how to use it. Under linux i used copying the
onmi.ja and the optimizejars.py to a temp folder and there
python /usr/local/share/optimizejars.py --deoptimize ./ ./ ./
after which the omni.ja is a normal zip. mc, the midnight commander,
works wonderfully for copying. :)
That was during testing. Now, during the build of my private SMs, the
omni.ja is automatically deoptimized and my SMs are satisfied with the
result.
Thanks for the detailed response. Really appreciated :)
For everyone's info :
The omni.ja file will load fine in standard zip format without changing
any SM code.
I didn't realise this at first, since when the omni.jar file was
introduced, it did not accept standard zip format.
If the omni.ja is recompressed in deflate mode, it loads at least as
fast as the distributed version, without the silly index in front.
Instead of introducing this omni.ja format, I think it would have been
much better to ship the contained .jar files in deflate mode instead of
uncompressed. It wouldn't have made the package size any bigger, and
everything would have loaded much faster.
Particularly for Seamonkey, which combines several different functions
(navigator, email, irc agent, html editor), and thus loading everything
would be slower than selective loading.
It shouldn't be too hard to revert, since combining these would be SM
specific.
Hartmut
my 2 cents :)
--
André
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
