[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Patch: thesaurus using wordnet
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-05-28 13:36:33
[Download RAW message or body]

Yesterday I finished the KoDataTool support in KWord.
This means, it's now possible to write a separate service that provides entries
in the RMB popup, for replacing a word with another one, or the selection with any
replacement text. Currently the only available tool is the kspell tool, but this framework
can make it easy to add synonyms, antonyms, and whatever holonyms meronyms etc. are :)
without having to change anything in KWord itself.

On Saturday 19 May 2001 19:50, Daniel Naber wrote:
> Thanks. I just learned that there's also KDict which does maybe 50-%80% of 
> what my patch would do (and other things)... Now I'm not sure anymore what 
> to do at all.

Well, you noted that e.g. synonyms work much better in wordnet.
I would personnally suggest to make a KoDataTool that uses either wordnet
or kdict, whichever is available (has to be same tool, otherwise we'd end up
with duplicate menu entries...).

> I have a new version of my patch which does parse the output of "wn". This 
> way no compile time configuration is required.

Sounds good.

> If ispell isn't installed, how does KSpell handle that? Maybe the same 
> behaviour would be appropriate for wordnet, too. 

AFAIK KSpell works on top of ispell and aspell, and that's configurable by the user,
and if none is there, then, well, it can't do anything ;-)

> The fix for wordnet 1.6 is very simple, if we want to waste KDE's 
> bandwidth we could put "wordnet 1.6 kde" on our servers :-) Even if we use 
> the API I'd need help because you're getting back strange C data 
> structures.

But this isn't necessary if you parse wn's output, right ?
That solution (using the wn binary) is better in terms of dependencies
(wn can be installed afterwards, and never becomes a requirement even for
binary packages) .. but can lead to problems if the output of wn changes in
the future. Given the release frequency of wn I think there's not much risk there ;-)
And this way we also avoid dealing with the awful API, and with the bug in the lib.

Do you feel like making a kodatatool around your new code ?
You only have to inherit KoDataTool and implement run(), no need for
any digging-into-KWord's-code. I suppose the synonyms etc. would have to
appear in a dialog box. The popup menu itself contains one entry per tool,
it's currently not possible to have tools insert dynamic entries in the 
popupmenu.
Obviously you also need to look at the kspell tool, for instance for the fields
in the .desktop file.

If anyone (e.g. the KDict developers ? :) feel like extending this tool to also support
KDict, then we'll have the best of both worlds: using whichever dictionary is installed.

Personnally, kdict seems a bit too complex for the average user: All I get is
"Can't resolve hostname". I suppose there's a way to have a local server, but
all this is much more complex to set up than wordnet. Or, if it requires to be
connected, it's even worse.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]