Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EXPERIMENTAL] How to build our new candidate window. #145

Closed
GoogleCodeExporter opened this issue Apr 22, 2015 · 17 comments
Closed

[EXPERIMENTAL] How to build our new candidate window. #145

GoogleCodeExporter opened this issue Apr 22, 2015 · 17 comments

Comments

@GoogleCodeExporter
Copy link

We experimentally implemented an advanced candidate window for IBus.
If you want to use this native candidate window, you can make the binaries for 
them as follows.

Preparation:
% export MOZC_INSTALL_DIR=$HOME/mozc/  # path to mozc install directory
% export MOZC_WORKING_DIR=/tmp/mozc_workdir  # path to working directory

Get the Code:
% cd $MOZC_WORKING_DIR
% gclient config http://mozc.googlecode.com/svn/trunk/src
% gclient sync

Build Binaries:
% cd src
% python build_mozc.py gyp --enable_gtk_renderer --server_dir=$MOZC_INSTALL_DIR 
% python build_mozc.py build_tools -c Release
% python build_mozc.py build package renderer/renderer.gyp:mozc_renderer

Installation(You may need super user right to copy):
% cp out_linux/Debug/mozc_server $MOZC_INSTALL_DIR
% cp out_linux/Debug/mozc_renderer $MOZC_INSTALL_DIR

How to use:
% ./out_linux/Debug/ibus_mozc
(If you already use Mozc, you may need killing existing mozc processes.)

Knwon Issues:
I have some known issues about this candidate window.
- Can not select candidates by clicking.
- Does not work with editors which do not have capability to write pre-edit 
strings, like GNU Emacs 23.
- The candidate window position frequently jumped when using GNU Emacs 23.
- The candidate window is hidden on the edge of desktop.
- There are no delay to show an infolist window.

If you have any problems, please reply this issue.

Sorry but please remind we are not ready to accept any patches due to the 
corporate policy.
Please reply by native language or screen shots.

Original issue reported on code.google.com by n...@google.com on 26 Mar 2012 at 10:53

Attachments:

@GoogleCodeExporter
Copy link
Author

Original comment by yukawa@google.com on 26 Mar 2012 at 11:00

  • Added labels: Component-UI, OpSys-Linux, Usability

@GoogleCodeExporter
Copy link
Author

If you want to use this candidate window with GNU Emacs23 or xterm, please 
apply the attached patch file as follows.

% patch -p0 < emacs_patch.diff

Thank you.

Original comment by n...@google.com on 27 Mar 2012 at 10:31

Attachments:

@GoogleCodeExporter
Copy link
Author

I've tested the new renderer with the Emacs patch,
but it doesn't work properly.

I've added the lines to ~/.emacs
(load-file "/usr/share/emacs/site-lisp/emacs-mozc/mozc.el")
(setq default-input-method "japanese-mozc")

$ emacs test.txt
Press Ctrl+backslash
Status: [Mozc]
Type "kesiki", space, space
=> It shows candidates properly.

Type "aono", space, space
=> Emacs returns "Wrong response from the server".

Type "kiru", space, space
=> Emacs returns "Wrong response from the server".

I think emacs-mozc can't show the words that have "examples".

Mozc-1.4.1003.102 (not 1033) worked properly on Emacs.

I am not an Emacs user. This is my first test of emacs-mozc. :-)
I hope Emacs enthusiasts will test it later.

// Note:
// Mozc shows candidates and examples on leafpad properly.
// Problem: The font size is too small for 1920x1080 screen resolution.

Ubuntu 11.10
Mozc-1.4.1033.102
Emacs 23.3.1

Original comment by heathros...@gmail.com on 28 Mar 2012 at 6:17

@GoogleCodeExporter
Copy link
Author

> If you want to use this candidate window with GNU Emacs23 or xterm

Ah, maybe this is about an ibus-gtk window on Emacs, not about emacs-mozc.

$ emacs test.txt
Press Zenkaku/Hankaku
Type "aono", space, space
It shows a normal ibus candidate window.
(not a new candidate window)

Original comment by heathros...@gmail.com on 28 Mar 2012 at 7:59

Attachments:

@GoogleCodeExporter
Copy link
Author

Thank you for your report.

> I've tested the new renderer with the Emacs patch,
Sorry I assumed the case using Emacs with IBus. I reproduced this bug.

I accept this bug and I create new issue(issue 146) for trucking.

Original comment by n...@google.com on 28 Mar 2012 at 8:02

@GoogleCodeExporter
Copy link
Author

People will not need the example "会う" for "青の".

Original comment by heathros...@gmail.com on 28 Mar 2012 at 8:08

@GoogleCodeExporter
Copy link
Author

> People will not need the example "会う" for "青の".

Actually, "会う" is not displayed against the candidate "青の" (2nd 
candidate) in  http://code.google.com/p/mozc/issues/detail?id=145#c4
"会う" is displayed against the 7th candidate "会おの".

Of course we don't need such candidates like "会おの" for the given input 
"あおの" but it is a conversion quality issue, which should be handled as a 
different topic.

Original comment by yukawa@google.com on 28 Mar 2012 at 12:13

@GoogleCodeExporter
Copy link
Author

> which should be handled as a different topic.

I think you will handle this feature better.
When we type a noun, we need examples for nouns.
When we type a verb, we need examples for verbs.

When we selected "会おの", we need the examples of "合う, 会う".

When we selected "青の", we need the examples of "青い, 蒼い" 
(adjectives), 
not "会う" (verb).

Original comment by heathros...@gmail.com on 28 Mar 2012 at 12:58

@GoogleCodeExporter
Copy link
Author

See "test_leafpad.png" please.
When the cursor is on "2", mozc should show the examples of "青い, 蒼い" 
(adjectives).
When the cursor is on "7", mozc should show the examples of "会う, 合う" 
(verbs).

> Of course we don't need such candidates like "会おの"

I hope you will fix it too.

Original comment by heathros...@gmail.com on 28 Mar 2012 at 1:06

@GoogleCodeExporter
Copy link
Author

> I think you will handle this feature better.

Thank you for your suggestion but please file a different bug against Mozc 
issue tracker or Google Japanese Input product forum about how UsageRewriter 
should work because:
1. The goal of Issue 145 is porting mozc_renderer for Linux: mozc_renderer has 
been enabled on Windows and Mac and the issue you addressed has existed even in 
previous versions on Windows and Mac Mozc.
2. Improving the behavior of UsageRewriter is not the goal of Issue 145. The 
usage list is generated by the UsageRewriter 
http://code.google.com/p/mozc/source/browse/trunk/src/rewriter/usage_rewriter.h?
r=93 in mozc_server and mozc_renderer is just displaying its outputs.
So If you request to change the behavior of UsageRewriter, it should be handled 
as a different topic.

Original comment by yukawa@google.com on 28 Mar 2012 at 1:17

@GoogleCodeExporter
Copy link
Author

OK, moved to Issue 149

Original comment by heathros...@gmail.com on 28 Mar 2012 at 3:39

@GoogleCodeExporter
Copy link
Author

Comment 4
> (not a new candidate window)
I did a mistake. Now I can see the new window on Emacs.

But I can't see the selected string beside the cursor (?)
> ■ (blank)
> 蒼の
> 青の

Maybe Emacs users will test it later...

Original comment by heathros...@gmail.com on 28 Mar 2012 at 5:20

Attachments:

@GoogleCodeExporter
Copy link
Author

Now it works. Sorry for confusion.

Original comment by heathros...@gmail.com on 28 Mar 2012 at 11:40

@GoogleCodeExporter
Copy link
Author

When you are building mozc_render in Mozc r111 without google-test on Linux, 
you may see the following build error.

make: *** No rule to make target 
`out_linux/Release/obj.target/testing/third_party/gmock/src/gmock-cardinalities.
o', needed by `out_linux/Release/obj.target/testing/libtesting.a'.  Stop.
make: *** Waiting for unfinished jobs....

The attached patch may fix this issue.

Original comment by yukawa@google.com on 26 Apr 2012 at 10:04

Attachments:

@GoogleCodeExporter
Copy link
Author

Thanks for the info.
I've installed google-mock and libgtest-dev,
but still it shows the error.
> `out_linux/Release/obj.target/testing/libtesting.a'.  Stop.

Your patch works fine and I can build mozc-renderer.

I'm using ubuntu 12 beta.

Original comment by heathros...@gmail.com on 26 Apr 2012 at 12:23

@GoogleCodeExporter
Copy link
Author

Thank you for the report.

As for the build failure after "apt-get install google-mock libgtest-dev", it's 
an expected result. We stopped using system-installed google-mock and 
google-test even on Linux at r105 (1.4.1033.102). If you want to enable 
unittest support, you need to put the source code of google-mock and 
google-test under src/third_party/gmock and src/thrid_party/gtest respectively. 
The easiest way to do it is just using gclient as described in 
LinuxBuildInstructions. In other words, people who are using gclient to set up 
Mozc's build environment will not see this build error.

Anyway, the line removed by the patch is completely unnecessary and should be 
removed in the next release. Basically you can build product binaries such as 
mozc_server or mozc_renderer without google-test nor google-mock unless we make 
this kind of misconfiguration.

Original comment by yukawa@google.com on 26 Apr 2012 at 2:42

@GoogleCodeExporter
Copy link
Author

Thank you for testing this experimental feature.
In r115, this feature now becomes out of experimental, so I close this entry.
If you have any troubles about this feature, please create a new entry.

Thank you very much and have a good text inputting.

Original comment by n...@google.com on 30 May 2012 at 4:51

  • Changed state: Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant