tomoe-devel Mailing List for Tomoe

Hi:

I'd like to use scim-tomoe on the Zaurus, under Angstrom (2.6.20 kernel).

I've read in the changelog of the SVN that scim-tomoe segfaulted before, so
that part of the code is commented out.

However I can't find exactly which part of code...

I built it on the Zaurus and it segfaults. Is it possible that the offending
code is still in? I pulled an SVN update yesterday, so should be fresh.

Best regards,

ShiroiKuma

On Fri, 27 Apr 2007 16:37:22 +0900
Takuro Ashie <as...@ho...> wrote:

> I think it is possible to add 4-corner code, but I don't show such a
> rare lookup method by default (It is rare, isn't it?).

Hi:

I just mentioned 4-corner method as an example. I wouldn't say it's rare, but
it's certainly not most common.

>From my experience, just a personal opinion, I would say that the most common
method is SKIP code:

http://www.basic-japanese.com/Hilfsdateien/skipCode.html

Would it be possible to implement this?

Best regards,

ShiroiKuma

It is done, see the svn :) As the 1.2 version.

I hope you can fix the candidates view width bug soon.

在 2007-04-27五的 11:56 +0900，Takuro Ashie写道：
> Hi.
> 
> On Fri, 27 Apr 2007 10:10:57 +0800
> Hu Zheng <zh...@re...> wrote:
> 
> > Some lines that you may notice are:
> > 464c464
> > <     <utf8>&#x65E7;&#x300C;&#x306D;&#x300D;</utf8>
> > ---
> > >     <utf8>&#x300D;</utf8>
> > 1656c1656
> > <     <utf8>&#x65E7;&#x300C;&#x5316;&#x300D;</utf8>
> > ---
> > >     <utf8>&#x300D;</utf8>
> > 1680c1680
> > <     <utf8>(^^)</utf8>
> > ---
> > >     <utf8>&#x28;</utf8>
> 
> Yes, we noticed it.
> 
> It seems a vague point of tomoe that it supports multiple characters per
> one entry or not.
> 
> But me and Kouhei are going to support it intentionally. Although the
> current candidates view of tomoe-gtk doesn't support it, it is only a
> bug. Old one supported it.
> 
> There are some reason for this issue:
> 
>   1. We are going to providing a registering feature to end users.
>      End users may want to register multiple characters.
>   2. There are some characters which consists by few code points.
>      For example, valiation selector of Unicode is a such case.
> 
> 
> > ps. As Inidc language are not one chracter only, so we are going to
> 
> I'm not sure about Indic, but is it also same case with 2?
> 
> > modify stroke editor to support more than one chracter as key word. I
> > have test tomoe, it support this internally too, we only need to fix the
> > width of the select word list problem.
> 
> Thanks, please support multiple characters :)
> 
> Regards,
> Takuro Ashie
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> tomoe-devel mailing list
> tom...@li...
> https://lists.sourceforge.net/lists/listinfo/tomoe-devel

On Fri, 27 Apr 2007 16:37:22 +0900
Takuro Ashie <as...@ho...> wrote:

> I think it is possible to add 4-corner code, but I don't show such a
> rare lookup method by default (It is rare, isn't it?).

 - I don't show
 + I don't want to show

Hi.

On Thu, 26 Apr 2007 16:44:38 +0200
"白い熊" <tom...@su...> wrote:

> I'm interested in Tomoe from the perspective of a learner of Japanese. Thus

In fact, most people who accesses to us seems such people.


> I'm wondering whether it's possible to implement other ways of Kanji lookup.

I want to add some lookup method to tomoe-gtk, but


> Would it be possible to implement alternate Kanji lookup methods, like the
> 4-corner code etc. With maybe also an "edit character" box, where you as a
> user could input the for instance 4-corner codes and later submit them to a
> central database, so that tomoe Kanji data database would grow?

I didn't know about 4-corner.

I think it is possible to add 4-corner code, but I don't show such a
rare lookup method by default (It is rare, isn't it?).

On the other hand, I don't want cut off such rare lookup method
completely, and most suitable lookup method for each language may be
different. 

This issue may become a reason that we introduce a plugin system which
we discussing at [tomoe-devel 38].

Regards,
Takuro Ashie

Hi.

On Fri, 27 Apr 2007 08:55:41 +0200
Mathieu Blondel <mbl...@ru...> wrote:

> Be it temporary or not, does it use gucharmap or not, I think it would 
> be worth having an option to disable this widget because in some cases 
> the only functionality that really matters is the handwriting recognition.

I agree with you.


> Of course it would be possible to build one's own window and add tomoe 
> internal widgets without adding the gucharmap widget. But the point is 
> you dont want to compile gucharmap related source code if you don't want 
> this feature and foremost if gucharmap is not installed on your system. 
> So one way or another we will need an option to disable the compilation 
> of the gucharmap widget. Just removing the "view" of the widget or hide 
> the widget is not enough.

Yes, that's right.
So I'm also going to add such option.


> Much the same way, if unihan support has been disabled in tomoe, the 
> "reading page" of the notebook should be removed in tomoe-gtk. From a 
> usability perspective, it is confusing to have a form that will always 
> give no result.

Oh, I didn't noticed it.
Although it is not so simple because an XML dictionary file provided by
user may have such data, we have to consider about this problem.

Thanks pointing out it.


> I have to agree that my patch was a dirty hack and understand that it 
> needs deeper work in order to get that job done in a clean way. I got 
> tomoe to work on Maemo with it though :-)

Thanks :)
I'll also try to find more clean way.

--
Takuro Ashie <as...@ho...>

Hi,
> If an application doesn't want it, it should create its own window
> instead of TomoeWindow using each essential widgets. Or you can hide it
> on the TomoeWindow using gtk_widget_hide().
>   
Be it temporary or not, does it use gucharmap or not, I think it would 
be worth having an option to disable this widget because in some cases 
the only functionality that really matters is the handwriting recognition.

Of course it would be possible to build one's own window and add tomoe 
internal widgets without adding the gucharmap widget. But the point is 
you dont want to compile gucharmap related source code if you don't want 
this feature and foremost if gucharmap is not installed on your system. 
So one way or another we will need an option to disable the compilation 
of the gucharmap widget. Just removing the "view" of the widget or hide 
the widget is not enough.

Much the same way, if unihan support has been disabled in tomoe, the 
"reading page" of the notebook should be removed in tomoe-gtk. From a 
usability perspective, it is confusing to have a form that will always 
give no result.

I have to agree that my patch was a dirty hack and understand that it 
needs deeper work in order to get that job done in a clean way. I got 
tomoe to work on Maemo with it though :-)

Mathieu

On Fri, 27 Apr 2007 12:40:04 +0900
Hiroyuki Ikezoe <poi...@ik...> wrote:

> Please use AM_CONDITIONAL.

It is right.

And I think generating a header file
like /usr/lib/gtk-2.0/include/gdkconfig.h is one of better solution for
detecting which features does the tomoe-gtk on your system have.

Regards,
Takuro Ashie

Hi.

On Fri, 27 Apr 2007 13:46:39 +0900
Takuro Ashie <as...@ho...> wrote:

> If an application doesn't want it, it should create its own window
> instead of TomoeWindow using each essential widgets. Or you can hide it

To allow it to application, we should add tomoe_gtk_init() to
initialize tomoe and gettext. Currently we do it at tomoe_window_init().

I'll fix it.

Hi.

On Fri, 27 Apr 2007 12:50:03 +0900
Hiroyuki Ikezoe <poi...@ik...> wrote:

> And tomoe-gucharmap should be modularize?

Hmm... introducing plugin system seems overkill only for this issue
because using gucharmap is a temporary solution. I want to replace it
with our own widget.

If an application doesn't want it, it should create its own window
instead of TomoeWindow using each essential widgets. Or you can hide it
on the TomoeWindow using gtk_widget_hide().

But plugin system may be needed for other purpose.

Regards,
Takuro Ashie

On Fri, 27 Apr 2007 12:20:53 +0900
Hiroyuki Ikezoe <poi...@ik...> wrote:

> What do you mean troublesome?

I mean "overkill".

Of course it is OK for me to use intltool if there is a obvious reason.
Tomoe has such reason as you pointed out.

On the other hand, recently intltool was also introduced to
uim-tomoe-gtk and scim-tomoe. I can't find such reason for these
softwares except "po/LINGUAS" issue at least at this time.

Furthormore, I don't have a plan which needs it, and I want keep it as
simple as possible for future maintenance. It is the background why I
request to kouhei to remove intltool dependecy of tomoe.

To tell the truth, it is OK for me either use it or not for such
purpose. But I wondered why Kouhei introduced it to uim-tomoe-gtk and
scim-tomoe although it may be a incidental work of minor maintenance.

Of course you don't need to revert it. > Kouhei
It is a really slight problem.

Regards,
Takuro Ashie

2007-04-27 (金) の 10:10 +0800 に Hu Zheng さんは書きました:
> ps. As Inidc language are not one chracter only, so we are going to
> modify stroke editor to support more than one chracter as key word. I
> have test tomoe, it support this internally too, we only need to fix the
> width of the select word list problem.

Please create trunk/branches/tags directories in SVN, if you have the
will to going on developing stroke-editor.

Thank you,
-- 
Hiroyuki Ikezoe

2007-04-27 (金) の 12:40 +0900 に Hiroyuki Ikezoe さんは書きました:
> 2007-04-27 (金) の 04:54 +0200 に Mathieu Blondel さんは書きました:
> > > "ENABLE_GUCHAMAP" is always undefined for client application so I can't
> > > commit the patch without modification (it has also some problems that we
> > > open current config.h to client applications). 
> > >
> > > Please wait for a while until I solve this problem.
> > > Of course improved patch is welcome :)
> > What about something like this ?
> 
> Please use AM_CONDITIONAL.

And tomoe-gucharmap should be modularize?

-- 
Hiroyuki Ikezoe

2007-04-27 (金) の 04:54 +0200 に Mathieu Blondel さんは書きました:
> > "ENABLE_GUCHAMAP" is always undefined for client application so I can't
> > commit the patch without modification (it has also some problems that we
> > open current config.h to client applications). 
> >
> > Please wait for a while until I solve this problem.
> > Of course improved patch is welcome :)
> What about something like this ?

Please use AM_CONDITIONAL.

-- 
Hiroyuki Ikezoe

On Fri, 27 Apr 2007 12:20:53 +0900
Hiroyuki Ikezoe <poi...@ik...> wrote:

> As you mentioned, intltool is needed for translation TOMOE XML data, so
> you already know that meanings in kanjidic2 should be translated. 

Oh, I didn't care about it.
Ok, we need intltool.

2007-04-27 (金) の 12:02 +0900 に Takuro Ashie さんは書きました:
> I think using intltool only for this purpose is a little troublesome.
> intltool is a tool for translating XML files, I think. But currnet
> tomoe doesn't use it for such purpose yet.
> So I requested to Kouhei to remove intltool dependency.

What do you mean troublesome?
The troublesome situation will be solved in the future? Yes, I know
intltool-0.33 has some bugs. But it has been solved in intltool-0.35
now. 

As you mentioned, intltool is needed for translation TOMOE XML data, so
you already know that meanings in kanjidic2 should be translated. 
I don't think intltool will be free from trouble(in your word) at the
time.

-- 
Hiroyuki Ikezoe

2007-04-27 (金) の 04:58 +0200 に Mathieu Blondel さんは書きました:
> Hiroyuki Ikezoe wrote:
> > Why don't you use intltool-0.35?
> > intltool-0.35 had been released one year ago. Meanwhile, the latest
> > TOMOE which requires intltool-0.35 has not been released yet.
> >   
> Because the scratchbox cross-compiling environment uses this version.

scratchbox should be upgrade its intltool.:-9

> > Moreover, intltool-0.35 includes a lot of bug fixes from 0.33. If
> > project uses po/LINGUAS, the project should require 0.35.
> >   
> I tested it with version 0.33 and it did not seem to complain but if you 
> think that the 0.35 version is required, feel free to leave the file as 
> it is :)

For example, see http://bugzilla.gnome.org/show_bug.cgi?id=341058
And there are other bugs fixed in intltool-0.35.

Thank you,
-- 
Hiroyuki Ikezoe

Hi.

On Fri, 27 Apr 2007 11:33:54 +0900
Hiroyuki Ikezoe <poi...@ik...> wrote:

> Moreover, intltool-0.35 includes a lot of bug fixes from 0.33. If
> project uses po/LINGUAS, the project should require 0.35.

I think using intltool only for this purpose is a little troublesome.
intltool is a tool for translating XML files, I think. But currnet
tomoe doesn't use it for such purpose yet.
So I requested to Kouhei to remove intltool dependency.

Hi.

On Fri, 27 Apr 2007 10:10:57 +0800
Hu Zheng <zh...@re...> wrote:

> Some lines that you may notice are:
> 464c464
> <     <utf8>&#x65E7;&#x300C;&#x306D;&#x300D;</utf8>
> ---
> >     <utf8>&#x300D;</utf8>
> 1656c1656
> <     <utf8>&#x65E7;&#x300C;&#x5316;&#x300D;</utf8>
> ---
> >     <utf8>&#x300D;</utf8>
> 1680c1680
> <     <utf8>(^^)</utf8>
> ---
> >     <utf8>&#x28;</utf8>

Yes, we noticed it.

It seems a vague point of tomoe that it supports multiple characters per
one entry or not.

But me and Kouhei are going to support it intentionally. Although the
current candidates view of tomoe-gtk doesn't support it, it is only a
bug. Old one supported it.

There are some reason for this issue:

  1. We are going to providing a registering feature to end users.
     End users may want to register multiple characters.
  2. There are some characters which consists by few code points.
     For example, valiation selector of Unicode is a such case.


> ps. As Inidc language are not one chracter only, so we are going to

I'm not sure about Indic, but is it also same case with 2?

> modify stroke editor to support more than one chracter as key word. I
> have test tomoe, it support this internally too, we only need to fix the
> width of the select word list problem.

Thanks, please support multiple characters :)

Regards,
Takuro Ashie

Hi.

On Fri, 27 Apr 2007 11:30:17 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> Could you explain 4-corner codes? Do they mean radical?
> If it's true, we can implement the lookup method.

I don't know about it, but you can find it from wikipedia, or Unihan
data base. I've found it just now.

  http://en.wikipedia.org/wiki/Four_corner_input

Hiroyuki Ikezoe wrote:
> Why don't you use intltool-0.35?
> intltool-0.35 had been released one year ago. Meanwhile, the latest
> TOMOE which requires intltool-0.35 has not been released yet.
>   
Because the scratchbox cross-compiling environment uses this version.
> Moreover, intltool-0.35 includes a lot of bug fixes from 0.33. If
> project uses po/LINGUAS, the project should require 0.35.
>   
I tested it with version 0.33 and it did not seem to complain but if you 
think that the 0.35 version is required, feel free to leave the file as 
it is :)

Mathieu

> "ENABLE_GUCHAMAP" is always undefined for client application so I can't
> commit the patch without modification (it has also some problems that we
> open current config.h to client applications). 
>
> Please wait for a while until I solve this problem.
> Of course improved patch is welcome :)
What about something like this ?

Mathieu

2007-04-26 (木) の 22:52 +0200 に Mathieu Blondel さんは書きました:
> tomoe.patch is a more minor patch. intltool 0.35 was required but 0.33 
> (which my environment has) seems to be enough.

Why don't you use intltool-0.35?
intltool-0.35 had been released one year ago. Meanwhile, the latest
TOMOE which requires intltool-0.35 has not been released yet.

Moreover, intltool-0.35 includes a lot of bug fixes from 0.33. If
project uses po/LINGUAS, the project should require 0.35.

-- 
Hiroyuki Ikezoe

Hi,

> Would it be possible to implement alternate Kanji lookup methods, like the
> 4-corner code etc. With maybe also an "edit character" box, where you as a
> user could input the for instance 4-corner codes and later submit them to a
> central database, so that tomoe Kanji data database would grow?

Could you explain 4-corner codes? Do they mean radical?
If it's true, we can implement the lookup method.


Thanks,
--
kou

Hi,

2007/4/27, Hu Zheng <zh...@re...>:

> I think Japanese key word should be only one character, so maybe you can
> fix them.

No. Tomoe should support multiple characters as keyword. There are no
reason why Tomoe should not support multiple characters as keyword.

We can use Tomoe with input method system. And we can input face mark
(e.g. (^^)) because Tomoe supports multiple characters as keyword.


BTW, stroke editor should not read/write XML directory. Stroke editor should
use Tomoe for accessing backend database.


Thanks,
--
kou