Disabling search type changes in kiten
Sun 26 Sep 2010 by mskala Tags used: kde, softwareThe Japanese-English dictionary program "kiten" has an annoying misfeature whereby if you do a search that has no results, instead of saying there are no results it will automatically change the search type to try to get more results for you. For instance, an "Exact Match" search might be changed to a "Match Anywhere" search. Google does that sometimes (for instance, changing phrase searches to bag-of-words searches) and that's annoying too, but at least Google warns you when it does it, and the stateless nature of Google searches means that the change is local to a single search. With kiten, the search type change is permanent (even saved in the config file when you exit). That's a problem if you are doing many searches successively, for instance during translation, and you have to keep resetting the search type. It's an even bigger problem if you have the ill-advised, but default and encouraged, "Automatically Search Clipboard Selections" feature turned on: because then just selecting text in some other application can permanently change your kiten configuration.
The solution (as of kiten 1.2, shipped with KDE 4.5.1) requires recompiling kiten from source, but it's otherwise simple. The code that implements the search-type-change behaviour is in the file kdeedu-4.5.1/kiten/app/kiten.cpp, lines 345 to 382. You can just remove that block of code. There is even a comment from the author mentioning as a "TODO" item that it should check whether the user actually wants to be annoyed in this way before proceeding. Why yes, actually it should check that! Or just assume that the user isn't an idiot, and not override the user-selected search type at all!
17 comments
Sorry, I don't have an RPM-based system and am not familiar with how to build RPM packages. I have posted a copy of my kiten binary (v4.5.1, compiled on a Slackware 32-bit AMD system) at https://ansuz.sooke.bc.ca/temporary/kiten . In theory, if your installation is binary-compatible with mine, you may be able to overwrite your /usr/bin/kiten with that and have it work, but compiling your own is much more likely to succeed. If you've already got a source tree unpacked, which I would think you must have in order to have the cpp file, then you can probably run "cmake ." from the kdeedu-4.5.1 directory, then "make", and then (as root) "make install" You will need to have KDE development libraries, but I assume your package manager already provides those. There is no doubt also a more RPM-friendly way to do "compile this package with local changes" but I have no idea what it would be.
Matt - 2011-07-10 19:37
Matt - 2011-07-10 19:37
Hi,
Thank you so much. I was able to compile it and build it using 'sudo su - ; cmake . ; make ; make install;`.
However... after uncommenting the lines that the original post said and recompiling it (wiithout errors) it still behaves the same. Can you glance at the source code and see
how to... make it Always search "Any part of the word" regardless of the location?
kitenlover - 2011-07-11 03:20
Thank you so much. I was able to compile it and build it using 'sudo su - ; cmake . ; make ; make install;`.
However... after uncommenting the lines that the original post said and recompiling it (wiithout errors) it still behaves the same. Can you glance at the source code and see
how to... make it Always search "Any part of the word" regardless of the location?
kitenlover - 2011-07-11 03:20
Are we talking about the same thing?
I usually want to leave it set on "Exact Match" and NOT have it change to "Match Anywhere" except when I ask for that. It sounds like you want the opposite, for it to be on "Match Anywhere" most, if not all, of the time.
If you want "Match Anywhere" then I don't think you need to modify the code. If you just use the standard kiten and set the match type to "Match Anywhere" then you should get what you want. It will not automatically change from "Match Anywhere" to "Exact Match"; the automatic change only goes in the opposite direction. Then the modification I propose won't have any effect on you, because it disables the automatic change but only the automatic change.
But I'm not sure you made the same modification I proposed because you mention "uncommenting" lines, and that's not what I had in mind. I was talking about removing, or commenting lines - that is, taking them out of the program. If you uncommented something, putting it in where it was previously commented, then I don't know what you uncommented, because I don't know of any commented-out code at that point in the file.
Look at the "Match Type" submenu on the "Search" menu and make sure it is set to what you want. It may also be adjustable through a drop-down box in the toolbar, but I don't remember whether that's my own config or the default toolbar. (If it's not on your toolbar and you want it there, you can use "Configure Toolbars..." under "Settings".) The code modification should only have the effect of preventing the software from changing that setting automatically in response to empty search results. You still have to set it to what you want in the first place; but if what you want is "Match Anywhere" then I'm confused, because the software never would have auto-changed away from that and you shouldn't need the code modification.
Matt - 2011-07-11 08:55
I usually want to leave it set on "Exact Match" and NOT have it change to "Match Anywhere" except when I ask for that. It sounds like you want the opposite, for it to be on "Match Anywhere" most, if not all, of the time.
If you want "Match Anywhere" then I don't think you need to modify the code. If you just use the standard kiten and set the match type to "Match Anywhere" then you should get what you want. It will not automatically change from "Match Anywhere" to "Exact Match"; the automatic change only goes in the opposite direction. Then the modification I propose won't have any effect on you, because it disables the automatic change but only the automatic change.
But I'm not sure you made the same modification I proposed because you mention "uncommenting" lines, and that's not what I had in mind. I was talking about removing, or commenting lines - that is, taking them out of the program. If you uncommented something, putting it in where it was previously commented, then I don't know what you uncommented, because I don't know of any commented-out code at that point in the file.
Look at the "Match Type" submenu on the "Search" menu and make sure it is set to what you want. It may also be adjustable through a drop-down box in the toolbar, but I don't remember whether that's my own config or the default toolbar. (If it's not on your toolbar and you want it there, you can use "Configure Toolbars..." under "Settings".) The code modification should only have the effect of preventing the software from changing that setting automatically in response to empty search results. You still have to set it to what you want in the first place; but if what you want is "Match Anywhere" then I'm confused, because the software never would have auto-changed away from that and you shouldn't need the code modification.
Matt - 2011-07-11 08:55
Thank you so much for your feedback. Yes, typo on my part. (Commenting those lines meant removing them completely and recompiling).
My goal was to allow the Auto-Highlight-Lookup (where you highlight a kanji word in your browser, and then kiten auto searches what you highlighted) to always show results "Match Anywhere". This is the same as highlighting, then selecting "Match Anywhere" from the drop down and pressing the enter button.
Can you show me how to do that? (Im so sorry for your time and sincerely appreciate your help very much).
kitenlover - 2011-07-14 18:34
My goal was to allow the Auto-Highlight-Lookup (where you highlight a kanji word in your browser, and then kiten auto searches what you highlighted) to always show results "Match Anywhere". This is the same as highlighting, then selecting "Match Anywhere" from the drop down and pressing the enter button.
Can you show me how to do that? (Im so sorry for your time and sincerely appreciate your help very much).
kitenlover - 2011-07-14 18:34
Okay, I see what you mean. I hadn't noticed it because I don't use the clipboard-search option myself, but it looks like you're right, it also changes the search type (but in the opposite direction) on clipboard searches.
Ideally, it wouldn't change it at all. Unfortunately, I'm not sure that's easy to do because it looks like what happens is when it does a clipboard search it creates a new "search" object with an internal default search type - so unlike the manual searches where it was explicitly overriding the user's choice, with clipboard searches it just doesn't look at the user's choice at all. I don't know how to extract the current setting from the user-preferences and use that, which would be best.
But I think it's possible to change the internal default, which would actually give the behaviour you asked for of *always* doing match-anywhere on clipboard searches. Try editing kdeedu-4.5.1/kiten/lib/DictQuery.cpp line 36, which currently reads " Private() : m_matchType(DictQuery::matchExact) {}" to say matchAnywhere instead of matchExact. Be aware that with that change it will *always* do match-anywhere on clipboard searches regardless of the configuration setting you choose; as I say, it would be better to follow the configuration, but that would be harder and this is what you literally asked for. I just tested it and it seems to work. I can't promise it won't have other unpredictable side effects.
Matt - 2011-07-14 19:02
Ideally, it wouldn't change it at all. Unfortunately, I'm not sure that's easy to do because it looks like what happens is when it does a clipboard search it creates a new "search" object with an internal default search type - so unlike the manual searches where it was explicitly overriding the user's choice, with clipboard searches it just doesn't look at the user's choice at all. I don't know how to extract the current setting from the user-preferences and use that, which would be best.
But I think it's possible to change the internal default, which would actually give the behaviour you asked for of *always* doing match-anywhere on clipboard searches. Try editing kdeedu-4.5.1/kiten/lib/DictQuery.cpp line 36, which currently reads " Private() : m_matchType(DictQuery::matchExact) {}" to say matchAnywhere instead of matchExact. Be aware that with that change it will *always* do match-anywhere on clipboard searches regardless of the configuration setting you choose; as I say, it would be better to follow the configuration, but that would be harder and this is what you literally asked for. I just tested it and it seems to work. I can't promise it won't have other unpredictable side effects.
Matt - 2011-07-14 19:02
Hi,
Wow! Thanks so much. For some reason I can't get it to compile (my rpmbuild is acting wierd). If you would be so kind as to compile it with the cpp change (DictQuery.cpp line 36) you mentioned and post your executable like before that would be wonderful.
Thank you so much for your help.
kitenlover - 2011-07-25 03:18
Wow! Thanks so much. For some reason I can't get it to compile (my rpmbuild is acting wierd). If you would be so kind as to compile it with the cpp change (DictQuery.cpp line 36) you mentioned and post your executable like before that would be wonderful.
Thank you so much for your help.
kitenlover - 2011-07-25 03:18
Okay, I've posted https://ansuz.sooke.bc.ca/temporary/libkiten.so and https://ansuz.sooke.bc.ca/temporary/kiten . I'm not sure which one of those actually contains the change, nor whether it'll really be binary-compatible with your system. But putting those in instead of your current versions of them should at least be worth a try.
Matt - 2011-07-25 18:33
Matt - 2011-07-25 18:33
For greater clarity: the filename on that first link is libkiten.so . It looks like my Web log software abbreviated it for display.
Matt - 2011-07-25 18:34
Matt - 2011-07-25 18:34
Hi,
Thank you so much for all of your help. I apologize for all of these questions. Thank you, I believe my platform is working well with your executables :)
I checked the files you posted, but the behaviour is still the same. Upon running ./kiten and then highlighting a kanji with my mouse, it automatically searches but the results are only "beginning with".
===============================
For example: Highlighting the "ichi" kanji and searching it results in:
一 いち (num,pref) (1) one; (suf) (2) best in; the most (...) in (where an adjective follows)
一 ひと (num,pref) (1) one
一 ひとつ (io) (n) (1) one; (2) for on....
When it should be resulting in:
一 いち (num,pref) (1) one; (suf) (2) best in; the most (...) in (where an adjective follows)
一々 いちいち (adv,n) one by one; separately
一つ ひとつ (n) (1) one; (2) for one thing (often used in itemized lists); (3) (after a noun) only; (4) (with a verb in negative form) even; (n-adv) (5) just (i.e. "just try it")
一つ一つ ひとつひとつ (n) one-by-one;....
...
渾然一体 こんぜんいったい (exp) in complete harmony
渾然一体となる こんぜんいったいとなる (exp) to form a complete whole; to be joined together
...
...list continuing.
===========================================
Thanks so much for your help!
kitenlover - 2011-07-25 21:16
Thank you so much for all of your help. I apologize for all of these questions. Thank you, I believe my platform is working well with your executables :)
I checked the files you posted, but the behaviour is still the same. Upon running ./kiten and then highlighting a kanji with my mouse, it automatically searches but the results are only "beginning with".
===============================
For example: Highlighting the "ichi" kanji and searching it results in:
一 いち (num,pref) (1) one; (suf) (2) best in; the most (...) in (where an adjective follows)
一 ひと (num,pref) (1) one
一 ひとつ (io) (n) (1) one; (2) for on....
When it should be resulting in:
一 いち (num,pref) (1) one; (suf) (2) best in; the most (...) in (where an adjective follows)
一々 いちいち (adv,n) one by one; separately
一つ ひとつ (n) (1) one; (2) for one thing (often used in itemized lists); (3) (after a noun) only; (4) (with a verb in negative form) even; (n-adv) (5) just (i.e. "just try it")
一つ一つ ひとつひとつ (n) one-by-one;....
...
渾然一体 こんぜんいったい (exp) in complete harmony
渾然一体となる こんぜんいったいとなる (exp) to form a complete whole; to be joined together
...
...list continuing.
===========================================
Thanks so much for your help!
kitenlover - 2011-07-25 21:16
When I turn on auto-search and highlight the "ichi" kanji, with my most recent compilation (which I thought was the one I posted), I get the results you list as "should be".
I've re-uploaded it to make sure I didn't somehow post my older version (since this change isn't something I'd normally want for my own use). Something to check might be that you're really using the copy you think you are, of both the executable and the library. The "locate" command may help you find any other copies that could be hanging around on your system; I don't know exactly how KDE searches for these files, but on my own system the "live" copies seem to be in /usr/lib/libkiten.so.4.5.0 and /usr/bin/kiten . The filename of the library might be another thing to look at - I said libkiten.so because I thought that was what it was called in the build directory, but the actual installed copy seems to be named libkiten.so.4.5.0 with a couple of shortened versions of the name as symlinks pointing to that. Probably the safest thing to do is name it libkiten.so.4.5.0 and then run "ldconfig" as root to update the symlinks.
Matt - 2011-07-25 21:45
I've re-uploaded it to make sure I didn't somehow post my older version (since this change isn't something I'd normally want for my own use). Something to check might be that you're really using the copy you think you are, of both the executable and the library. The "locate" command may help you find any other copies that could be hanging around on your system; I don't know exactly how KDE searches for these files, but on my own system the "live" copies seem to be in /usr/lib/libkiten.so.4.5.0 and /usr/bin/kiten . The filename of the library might be another thing to look at - I said libkiten.so because I thought that was what it was called in the build directory, but the actual installed copy seems to be named libkiten.so.4.5.0 with a couple of shortened versions of the name as symlinks pointing to that. Probably the safest thing to do is name it libkiten.so.4.5.0 and then run "ldconfig" as root to update the symlinks.
Matt - 2011-07-25 21:45
Thank you very much! Your 'kiten' and 'libkiten.so' files worked perfectly. I appreciate your help so much, as I am using kiten to search for words (1 at a time) to add rare kanji for my RTK3 book. This executable helped me avoid carpel tunnel syndrome by just highlighting the kanji card from anki then highlighting the definition from kiten and middle click pasting (taking a matter of seconds, avoiding pressing ctrl + c).
Thank you so much for your contribution and our class appreciates your help very much. Have a wonderful week.
kitenlover - 2011-07-26 03:43
Thank you so much for your contribution and our class appreciates your help very much. Have a wonderful week.
kitenlover - 2011-07-26 03:43
Thank you again for the kiten compilation, I have already learned 2500 new words with your Kiten file (by studying with Anki, Firefox; and having Kiten on the right side. This is the best way to study with auto-highlighting and searching on all combinations). I have to thank you very much.
Now, I have a new request; can you please compile this "Patched-DisabledSearchType" version of Kiten for the CYGWIN/X? I want to use it to study on windows as well; and CYGWIN/X or PortableUbuntuSLIM4 both run on windows using cygwin.dll; so if we can get kiten to work on cygwin as well; it will help the windows users as well. Thank you so much!
kitenlover - 2011-10-19 21:59
Now, I have a new request; can you please compile this "Patched-DisabledSearchType" version of Kiten for the CYGWIN/X? I want to use it to study on windows as well; and CYGWIN/X or PortableUbuntuSLIM4 both run on windows using cygwin.dll; so if we can get kiten to work on cygwin as well; it will help the windows users as well. Thank you so much!
kitenlover - 2011-10-19 21:59
Sorry, I don't think I can do that. I don't have a Cygwin system to compile on; in fact I don't think I've ever *seen* a Cygwin system myself, although I basically know what one is. Maybe if you can find a Cygwin users' group or Web forum, there'd be someone there who could help you. Compiling the modified version of kiten shouldn't be difficult for someone who has a Cygwin system and regularly compiles things on it.
Matt - 2011-10-20 08:54
Matt - 2011-10-20 08:54
Thanks Matt,
I was wondering do you know how to make kiten work with EPWING dictionaries? Or a script that converts EPWING to a edict like kiten-compatible format? As always thank you for your help.
kitenlover - 2011-12-07 02:14
I was wondering do you know how to make kiten work with EPWING dictionaries? Or a script that converts EPWING to a edict like kiten-compatible format? As always thank you for your help.
kitenlover - 2011-12-07 02:14
Is documentation for the EPWING format available in English? I just took a brief look on the Web, and although it looks interesting, it appears all the technical material about this format is written in Japanese and I'm just not, realistically, proficient enough to read it yet.
Just from skimming the source code of some of the software I found (it is a strange experience to look at a piece of code and realize that I understand the computer's language better than the humans'...), it looks to me like EPWING is a pretty complicated structured format mixing graphics, text, and semantic annotation material, on the level of PDF or OTF, with a lot of specific support for Japanese things like gaiji, and all of it binary-compressed. It's not going to be a Perl one-liner to change that into something like EDICT.
I found several utilities for converting in the other direction - from simple text or XML-style EDICT files into EPWING - as well as ready-converted EPWING versions of EDICT - but it's clear that to go in the EPWING to EDICT direction, first of all you'll necessarily lose all the special features, and second it may require a fair bit of work in the converter program to comprehend the structured data and generate something EDICT (hence Kiten) can handle. All in all it looks to me like it might be an interesting project, but a big one, and it's one I can't realistically attempt myself until I have a couple more years of language learning under my belt.
There are some GNOME and KDE dictionary programs designed to read EPWING directly without a conversion. One of those might be a better idea than Kiten. You've maybe already seen it but there seems to be a good list of software links at http://www.hloeffler.info/epwing/epwing_format.html - that page is in English but most of the things it links to are Japanese-only. I haven't tried any of the packages but some of them look similar in nature to Kiten, but with EPWING input. I also see on that page a link to some command-line utilities in the "EB library" at http://www.sra.co.jp/people/m-kasahr/eb/ (page is in Japanese) which look like they're able to extract at least some metadata from EPWING format into simple text. Maybe one of those could be used to get dictionary entries as text, that could be fed into Kiten.
You might think of approaching the Kiten developers and letting them know that EPWING input would be really nice to have; it might work better as a feature added natively to Kiten than as a separate conversion program. However, just looking at the list of names my guess is that none of them are native Japanese speakers, and I don't know if they'll be able to read the EPWING docs any better than I can, let alone having the time for writing what would be a substantial amount of new code.
Let me know if you find a good answer to this, because access to EPWING files, in either direction if it's documented well, might be useful for some of my other projects.
Matt - 2011-12-07 10:13
Just from skimming the source code of some of the software I found (it is a strange experience to look at a piece of code and realize that I understand the computer's language better than the humans'...), it looks to me like EPWING is a pretty complicated structured format mixing graphics, text, and semantic annotation material, on the level of PDF or OTF, with a lot of specific support for Japanese things like gaiji, and all of it binary-compressed. It's not going to be a Perl one-liner to change that into something like EDICT.
I found several utilities for converting in the other direction - from simple text or XML-style EDICT files into EPWING - as well as ready-converted EPWING versions of EDICT - but it's clear that to go in the EPWING to EDICT direction, first of all you'll necessarily lose all the special features, and second it may require a fair bit of work in the converter program to comprehend the structured data and generate something EDICT (hence Kiten) can handle. All in all it looks to me like it might be an interesting project, but a big one, and it's one I can't realistically attempt myself until I have a couple more years of language learning under my belt.
There are some GNOME and KDE dictionary programs designed to read EPWING directly without a conversion. One of those might be a better idea than Kiten. You've maybe already seen it but there seems to be a good list of software links at http://www.hloeffler.info/epwing/epwing_format.html - that page is in English but most of the things it links to are Japanese-only. I haven't tried any of the packages but some of them look similar in nature to Kiten, but with EPWING input. I also see on that page a link to some command-line utilities in the "EB library" at http://www.sra.co.jp/people/m-kasahr/eb/ (page is in Japanese) which look like they're able to extract at least some metadata from EPWING format into simple text. Maybe one of those could be used to get dictionary entries as text, that could be fed into Kiten.
You might think of approaching the Kiten developers and letting them know that EPWING input would be really nice to have; it might work better as a feature added natively to Kiten than as a separate conversion program. However, just looking at the list of names my guess is that none of them are native Japanese speakers, and I don't know if they'll be able to read the EPWING docs any better than I can, let alone having the time for writing what would be a substantial amount of new code.
Let me know if you find a good answer to this, because access to EPWING files, in either direction if it's documented well, might be useful for some of my other projects.
Matt - 2011-12-07 10:13
I really want to do this, but I dont know how to rebuild kiten. i found the cpp file, changed the lines, but I dont know how to rpmbuild it so that i can install it on fedora or ubuntu. Can you explain how to do this or perhaps rebuild it and post it as a download link?
kitenlover - 2011-07-10 19:11