Hi Bruno,
> I would like to ask to you (both you and Thomas) some questions: > > Did you liked my proposal? If so, is something that need be changed? Which one? The one in your application for the Google SoC? Basically yes. But as I said we like to discuss more and likely extensive about the integration. Be it about what can be done now (let's say within the next 2-3 month) or what should be the final goal (which may take much(!) more time to implement depending on what we will agree should be the final goal). For the time of the SoC we surely can't solve and implement everything we want. For me it would already be perfect if we solve i.e. implement a solution for the actual problem of how a grammar checker can be enabled to mark the incorrect words and what our final goal regarding integration should be (of course without already having implemented the latter one). The actual implementation of the grammar checker would be of minor importance to me. If we provide the means for marking the words within the document someone will surely implement a full functional grammar checker sooner or later. Even if the SoC would be already over. ^_~ Well, but anything I said above is of course subject to discussion. We like to start discussion with you and others about this topic next week even though Oliver will be in vacation and the final decision about the projects and students to be accepted for the SoC is not yet done by Google. > I was expecting to deliver after the final of SoC program a open office > library, source code and documentation about this work, it is okay for you? Let's discuss what we like to get from you in the SoC's time frame with Mathias next week. It will probably sth about the size I listed above. The question at hand is the order of the issues. In the end we would of course like to have both a working implementation and a clear vision what the final stage of grammar checker integration should be and how we go there. But both will probably too much for the SoC. Currently it looks more like discussion about integration or maybe sth completely different. Like a other component (apart from both of the applications core and the grammar checker). Some component that may use API from the application to iterate through the text while using a grammar checkers API to check the text. And if problems were found to raise a dialog to allow user modification and use the applications API to write the new text back. This way the grammar checker can be allowed to have a very abstract view on the application without being required to have detailed knowledge about it (and thus not being required to be modified if some relevant application internals change). And also on the other hand the application would only need to supply some text processing API. It does not even need to know anymore about the existence of a grammar checker and related UI. That code could be outsourced from all applications! Well, this is just another possible approach that would clean up things on both sides, the grammar checker and the application. Thus first need to collect / think about all possible solutions for the problem of grammar checking. And than we have to discuss the pros & cons to make a reasonable choice. For the time being (until next week) it will be sufficient if you think about what kind of abstract view a grammar checker ideally likes to have on the application. (If possible, preferably a view that is independent of a specific application) (For example I think it does not really like to know of headers, text boxes, tables etc. if it can be avoided.) That is what does it like to know what not and what does it need to know? Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
