moji on seamonkey?
Hubert Cross
can i expect moji to work on seamonkey 1.0.2? if not, will it work on
mozilla or does it absolutely require firefox..?
thanks a lot
-hubert
Philip Chee
> can i expect moji to work on seamonkey 1.0.2? if not,
> will it work on mozilla or does it absolutely require
> firefox..?
Yes for SeaMonkey but only if you also install xSidebar:
<http://xsidebar.mozdev.org/>
which creates a firefox style sidebar that moji can use.
For Thunderbird you can use xSidebarTIG:
<http://xsidebar.mozdev.org/tsidebar/index.html>
Phil
Gerald Vogt
I have decided to officially release the next version of moji 0.9 soon.
It will be the 0.9a3 unless there is a major issue coming up. I
currently have little time to do all the localization work which is
pending at the moment. The code base itself should be O.K. I have been
using this version for a long time now on Windows and MacOS and don't
see any issues which would block a release. Just for those people who
choose the french or german gui there will be some parts still in
english (just like before...).
You have a separate XPI now for the tb sidebar. Is it O.K. if I remove
you sidebar code from moji and instead add the dependency to the
install.rdf? I think that is the proper way to do it instead of bundling
it into the moji.xpi.
I am currently assembling the new dictionaries with the latest edict
files from our various sources. Once I have done that can I send you the
links to the XPIs and you can check whether everything is O.K. for
seamonkey as well? Its been a long time since I have looked at seamonkey
and I suppose you are better into xpis for seamonkey then I am.
I have not tested the new version on FF or TB 1.5 or older. I will only
support the current 2.0 version.
Cheers,
Gerald
Philip Chee
> You have a separate XPI now for the tb sidebar. Is it O.K. if I remove
> you sidebar code from moji and instead add the dependency to the
> install.rdf? I think that is the proper way to do it instead of bundling
> it into the moji.xpi.
Yes. That would be fine.
> I am currently assembling the new dictionaries with the latest edict
> files from our various sources. Once I have done that can I send you the
> links to the XPIs and you can check whether everything is O.K. for
> seamonkey as well? Its been a long time since I have looked at seamonkey
> and I suppose you are better into xpis for seamonkey then I am.
No problem. Just let me know when they are ready.
> I have not tested the new version on FF or TB 1.5 or older. I will only
> support the current 2.0 version.
I'll do some testing for FF/TB 1.5 just in case and
I'll let you know.
Phil
Gerald Vogt
candidate is at
moji-0.9rc1 is moji
mojik{de,en,fr}-* are the kanji dictionaries
All others are the normal dictionaries.
"cn" means traditional chinese.
"scn" means simplified chinese.
The chinese dictionaries' entries always contain both, however you can
only search for entries defined by the dictionary, e.g. you can search
only for trad. chinese with the "cn" dictionary.
Most dictionaries have been updated with the latest version from the
internet.
Changes for moji will be in the release notes.
Gerald
Philip Chee
> moji-0.9rc1 is moji
chrome.manifest: You need to remove the following lines:
overlay chrome://messenger/content/messenger.xul
chrome://moji/content/tsbMessenger.xul
application={3550f703-e582-4d05-9a08-453d09bdfdc6}
overlay chrome://messenger/content/messageWindow.xul
chrome://moji/content/tsbMessageView.xul
application={3550f703-e582-4d05-9a08-453d09bdfdc6}
overlay chrome://messenger/content/messengercompose/messengercompose.xul
chrome://moji/content/tsbComposer.xul
application={3550f703-e582-4d05-9a08-453d09bdfdc6}
override chrome://contactssidebar/content/contactsSidebar.xul
chrome://moji/content/tsbContactsSidebar.xul
Phil
Philip Chee
> All others are the normal dictionaries.
> "cn" means traditional chinese.
> "scn" means simplified chinese.
mojiscnen-0.4.20071010.xpi
The install.rdf claims that this is the:
"Simplified Chinese-German Dictionary for Moji"
but it should be the
"Simplified Chinese-English Dictionary for Moji"
Phil
Philip Chee
> On 11/10/2007, Gerald Vogt <vo...@spamcop.net> wrote:
>> "cn" means traditional chinese.
>> "scn" means simplified chinese.
This is confusing since zh-CN is simplified and
zh-TW is traditional. But I guess it's too late
to change now.
Phil
Gerald Vogt
Well. It's never too late. I don't mind changing the names if it is into
a fully consistent schema. That may be a good idea anyway. Moji started
fairly simply with three Japanese dictionaries into english, german, and
french. But what if we get a dictionary which translated Japanese into
american-english, british-english, austrian-german, swiss-german,
german-german, ... Plus now the chinese as source in two variants. So I
suppose a full name fould be moji-jp-JP-de-DE-0.5.20071012.xpi for a
japanese german dictionary. But that will create pretty long file names.
And what would be if we'll find a dictionary for medieval japanese or
chinese? ;-)
Gerald
Gerald Vogt
thank you so much for looking at the xpis. I must admit I forot what
hassle it is building those xpis. The version number in the
install.{js,rdf} files is already automatically patched in from the
Makefile. I guess, I should also patch in the full and short name. That
way we have consistent naming in all those install, chrome, contents,
etc. files. That will also make it easier to rename a full package.
I have just uploaded two updates XPIs based on your two e-mails. scnen
should now be really english and the chrome.manifest is cleared.
mojiscnen-0.4.20071010.xpi
moji-0.9rc1.xpi
I tried to update everything on of my Macs by simply moving all XPIs
into the add-ons manager window. That kind of ended in the total
disaster. I don't know, yet, whether it was too much at a time or
something else. Firefox loaded all files. Said everywhere I have to
restart firefox. After restarting firefox the files where still in
"installed after restart". I restart again and again. No change. I tried
to uninstall the xpis. No way. Even after restart, no change.
Eventually I cleared out all packages from the extensions directory in
my profile, then did one more uninstall in the add-ons manager and after
the restart moji and all dictionaries disappeared from add-ons manager.
Then I installed the new xpis successfully.
I was quite shocked what a mess it was. I think I will have to make a
test install with all the old versions and then update a test update.rdf
to see how the update manager in firefox handles it. I don't want to see
people downloading the updates automatically and then ending up in a
mess like I did.
That reminds me I have to add the dependency to your thunderbird sidebar
package in the install.rdf of moji...
Once more: thank you a lot for your effort!! I really appreciate it. It
would take me hours to read back into the whole xpi layout stuff to find
all possible hicups there...
Gerald
Gerald Vogt
> That reminds me I have to add the dependency to your thunderbird sidebar
> package in the install.rdf of moji...
Haha. It is not possible to add requirements depending on the target
application. Thus either we will need a huge notice that the tbsidebar
xpi is requried on thunderbird or we have to pack two separate xpis,
one for firefox and one for thunderbird.
I have tested the update function on firefox 1.5 and it seems to work
nicely. Installed the current official release from the web site,
adjusted the updateurls in the extensions.rdf file in the firefox
profile, press find updates and all got updated and was successfully
updated after a restart. I did not make a thorough test on FF1.5 but
it seems to work correctly.
I have did the same tests on TB 2.0 and FF 2.0. The update through the
update manger goes through without problems. I have been using moji
0.9 with the latest dictionary for a couple of months now thus I think
there should not be any issues.
I have generated a new set of dictionaries. It now all scripted which
helps a lot to get correct dictionary files for moji. Before that is
was always a hassle to convert some of the files to UTF-8 and then
sort them, adjusting line endings if necessary. The new set has fixed
an issue which I never really noticed: in most dictionaries it was not
possible to find the first and maybe the second entry because all
edict files have the copyright line in the first line. That first line
obviously broke the sort order in the file and thus the binary search.
The first line in all dict files in the xpis starts now with a space
which basically means an empty word which is per default the string
which is first in any sorting order...
Do I have to make any changes for seamonkey?
Gerald
Philip Chee
> Do I have to make any changes for seamonkey?
Sorry I am away from home at the moment so I didn't
actually have a chance to test any of them. I just
did some code inspection before I had to leave.
I'll be back on Tuesday. Perhaps I can get some
testing done then.
Phil
Gerald Vogt
I have not found any issues on Firefox or Thunderbird, Win and Mac.
New installs should work. Updates should work, too. The only issue I
had was when I moved the XPIs for updates manually into the Extensions
Manager. But that looked more like some FF/TB bug.
Phil, did you check SeaMonkey? Is the install.js in the XPIs still
O.K. for SeaMonkey?
Thx, Gerald
Philip Chee
> Phil, did you check SeaMonkey? Is the install.js in the XPIs still
> O.K. for SeaMonkey?
Sorry relatives have just flown back home. So now I
have more time to look into this.
Phil
Philip Chee
> On 30/10/2007, Gerald Vogt <vo...@spamcop.net> wrote:
>> Phil, did you check SeaMonkey? Is the install.js in the XPIs still
> > O.K. for SeaMonkey?
I have downloaded the latest from http://www.gvogt.de/moji/
and every thing seems to work for SeaMonkey 1.1.6pre as
long as xSidebar is installed.
In the messagecompose window I get this error when I bring
up the context menu:
Error: gContextMenu has no properties
Source file: chrome://moji/content/tbmoji.xul
Line: 58
Phil
Gerald Vogt
> I have downloaded the latest from http://www.gvogt.de/moji/
> and every thing seems to work for SeaMonkey 1.1.6pre as
> long as xSidebar is installed.
>
> In the messagecompose window I get this error when I bring
> up the context menu:
> Error: gContextMenu has no properties
> Source file: chrome://moji/content/tbmoji.xul
> Line: 58
Does the context menu work in the standard message view window? That
would mean that the context menu in the messages compose is named
different from the other places.
Gerald
Philip Chee
> Philip Chee wrote:
>> In the messagecompose window I get this error when I bring
>> up the context menu:
>> Error: gContextMenu has no properties
>> Source file: chrome://moji/content/tbmoji.xul
>> Line: 58
> Does the context menu work in the standard message view window? That
> would mean that the context menu in the messages compose is named
> different from the other places.
Problem also occurs in TB 2.0 message compose. The context
menu works but |gContextMenu| doesn't exist in this window
so the Moji context items are not hidden if no text is
selected. This is a minor problem as the Moji menu items
are always shown. Not a release blocker.
Phil
Philip Chee
>> I have downloaded the latest from http://www.gvogt.de/moji/
>> and every thing seems to work for SeaMonkey 1.1.6pre as
>> long as xSidebar is installed.
Note: I have not tested the fr, de, and kr dictionaries.
Phil
Gerald Vogt
Ah, now I got it. It's in the error console. I kind of thought it was a
popup message. Thanks. I'll look into it. I guess they have changed it
in TB 2.0. Should not be to hard to fix...
I suppose for SeaMonkey we should be able to add some check for the
dependency on xSidebar in install.js. I would like to see this in the
release. I probably should install SeaMonkey to test this. Do you use
Windows or Mac or Linux? I could choose a different platform for to get
the dependency in and test moji on this platform at the same time...
Thanks,
Gerald
Philip Chee
> Ah, now I got it. It's in the error console. I kind of thought it was a
> popup message. Thanks. I'll look into it. I guess they have changed it
> in TB 2.0. Should not be to hard to fix...
I don't think this ever existed in message compose. And
since moji didn't work properly in Thunderbird before I
contributed some sidebar code it's not surprising you
didn't notice this.
See the attached .diff file for a quick fix. It seems to
work without causing errors in the other windows.
> I suppose for SeaMonkey we should be able to add some check for the
> dependency on xSidebar in install.js. I would like to see this in the
> release.
I'm not too sure how to test this in the install.js
There is no built in functionality. You could test
for the existence of the xsidebar.jar file in the
profile/chrome/ directory I suppose.
> I probably should install SeaMonkey to test this. Do you use
> Windows or Mac or Linux? I could choose a different platform for to get
> the dependency in and test moji on this platform at the same time...
WinXP at the moment.
Cheers.
Phil
Gerald Vogt
> On 31/10/2007, Gerald Vogt <vo...@spamcop.net> wrote:
>
>> Ah, now I got it. It's in the error console. I kind of thought it was a
>> popup message. Thanks. I'll look into it. I guess they have changed it
>> in TB 2.0. Should not be to hard to fix...
>
> I don't think this ever existed in message compose. And
> since moji didn't work properly in Thunderbird before I
> contributed some sidebar code it's not surprising you
> didn't notice this.
>
> See the attached .diff file for a quick fix. It seems to
> work without causing errors in the other windows.
Does this really work for you? On my Thunderbird it does not. The check
if (!gContextMenu)
will still cause the same error because the variable is not defined. If
I replace this with
if (typeof gContextMenu == 'undefined')
it causes an error somewhere in nsContextMenu.js
I now check for typeof undefined and skip over the whole showItem calls.
Maybe I should submit a bug for that on bugzilla...
>> I suppose for SeaMonkey we should be able to add some check for the
>> dependency on xSidebar in install.js. I would like to see this in the
>> release.
>
> I'm not too sure how to test this in the install.js
> There is no built in functionality. You could test
> for the existence of the xsidebar.jar file in the
> profile/chrome/ directory I suppose.
Really? There is no way to access the extensions manager from the
install.js? Or does Seamonkey even have the extensions manager?
I'll install SeaMonkey on my Mac here and see how it works. I'll look
into it whether I find something or not but won't spend too much time to
get it into it. If I don't find something quickly I'll just write
"requires xSidebar" in thick letters in the release notes. ;-)
Thanks a lot!
Cheers,
Gerald
Philip Chee
> Does this really work for you? On my Thunderbird it does not. The check
Seems to work in SeaMonkey. I don't know why. Initially
I tried if (!("gContextMenu" in window)) but that always
returned false. Perhaps I should try in a new profile
without too many extensions installed.
> Really? There is no way to access the extensions manager from the
> install.js? Or does Seamonkey even have the extensions manager?
There is no way of accessing the extensions manager because
it doesn't exist (unless you are using SeaMonkey 2.0a).
Phil
Gerald Vogt
>> Really? There is no way to access the extensions manager from the
>> install.js? Or does Seamonkey even have the extensions manager?
>
> There is no way of accessing the extensions manager because
> it doesn't exist (unless you are using SeaMonkey 2.0a).
O.K. Then I think I won't look for a way to check the dependency... ;-)
Gerald
Gerald Vogt
moji homepage http://moji.mozdev.org/ works on SeaMonkey as well? Or
do you have to select the individual xpis from the table below the
form?
I am updating the index.html for moji and I don't know if the
installation form works with SeaMonkey or not.
Thx, Gerald
Philip Chee
> Philip, can you tell me whether the scripted installation form on the
> moji homepage http://moji.mozdev.org/ works on SeaMonkey as well? Or
> do you have to select the individual xpis from the table below the
> form?
Well I tried this with SeaMonkey 1.1.6pre: Selected several
dictionaries and clicked install. I got an install dialog
"a website is requesting permission to install" followed
by a list of extensions: moji stable and the dictionaries
I selected. I selected cancel because I didn't want to
downgrade from 0.9 and the latest dictionaries.
> I am updating the index.html for moji and I don't know if the
> installation form works with SeaMonkey or not.
Looks like it.
Phil
Gerald Vogt
On Nov 4, 9:09 pm, "Philip Chee" <philip.c...@gmail.com> wrote:
> On 04/11/2007, Gerald Vogt <v...@spamcop.net> wrote:
>
> > Philip, can you tell me whether the scripted installation form on the
> > moji homepagehttp://moji.mozdev.org/works on SeaMonkey as well? Or
> > do you have to select the individual xpis from the table below the
> > form?
>
> Well I tried this with SeaMonkey 1.1.6pre: Selected several
> dictionaries and clicked install. I got an install dialog
> "a website is requesting permission to install" followed
> by a list of extensions: moji stable and the dictionaries
> I selected. I selected cancel because I didn't want to
> downgrade from 0.9 and the latest dictionaries.
I have uploaded the new index.html to the server. This should get you
the latest versions now.
Gerald