[PATCH (partial)] Writer autocompletion feature

Nico Weyand nico.weyand at gmail.com
Wed Jul 25 09:49:46 PDT 2012

On 23.07.2012 15:24, Michael Meeks wrote:
> Hi Nico,
> On Mon, 2012-07-23 at 16:11 +0000, Nico Weyand wrote:
>> May I ask why it has been decided to switch from LGPL to MPL/LGPL
>> anyway ?
> 	Of course ! :-) there is a bit of blurb in the FAQ here:
> 	http://wiki.documentfoundation.org/Development/Relicensing
>>   As I see it, MPL does grant a much weaker protection for the
>> libreoffice code than LGPL, because one could simply take one of the
>> open source code files from libreoffice and include it within a closed
>> source project without having to release the source code of other
>> files of that project.
> 	Sure, right; it is a module-level license. On the other hand, this can
> also be achieved with the LGPL by simply adding misc. entry points and
> linking to the module instead of including it. For the strongest
> protections we'd want the GPL I guess.
>> For a lots of commits, this isn't a big issue, however for a
>> datastructure implementation (like the code I have committed), it is,
>> as it could be used without further changes in a lot of projects...
> 	At the moment, one factor is trying to win back IBM who have an
> outright allergy to anything with "GPLv3" on it; the MPLv2 they dislike
> too - perhaps because it forces them to release their bug-fixes as they
> ship, and makes it hard for them to compete on quality - but they can at
> least accept it. Clearly their ideal is the Apache license that is
> profoundly and unhelpfully weak all over :-) [ IMNSHO ]
> 	So; if you're really concerned by people using your data-structure
> without turning that one module into a "libDataStructure" and using it
> like that, then that's fine - but altering the whole project's license
> to suit your change is rather a big ask :-)
> 	I notice you spent a lot of time writing a new tree structure; is there
> some profile data or detail that explains why that is needed ? is it a
> space efficiency thing ? or a time / lookup issue ? in general all new
> pointer manipulation code contains plenty of bugs no matter how clever
> the author :-)
> 	Anyhow - sorry you're out of time to work on this, it looks
> interesting.
> 	All the best,
> 		Michael.

OK, arguments accepted (even if I am still not convinced 100% :D); I'll 
post something on the mailing list for dual licensing.

As for the reason of this new tree structure, it's quite simple:
1. The current implementation gives the first word that matches a given 
prefix, so the word you get as a suggestion is in many cases a little 
suboptimal. My tree gives the most probable answer.
2. I haven't looked into it very deeply, but currently the words seem to 
be stored within a list. This is inefficient (on a side note: I've got 
performance issues while typing when using libreoffice in the past on my 
netbook). This tree on the other hand is supposed to be efficient, 
especially as it stores both the current position within a word (so we 
don't need to start reading the tree on its root node each time the user 
types a new letter) and the most probable next char for each node (so we 
don't need to compare probabilities etc. to get the next letter in the 
chain leading to the most probable completion for a given prefix).
3. Currently, autocompletion word list is build each time Libreoffice 
opens a document and it doesn't seem to differ between the language of 
the requested word. There has been a request for making these word lists 
permanent and language dependent, which is why for example I've included 
a language property within the structure.

I hope these are enough arguments for you; they certainly were for me :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120725/36c54370/attachment.html>

More information about the LibreOffice mailing list