[email protected] wrote: > Use MSO with some of the a11y tools, to discover just how much > functionality is gone. [Your a11y power user for MSO is not able to do > as much, functionally, as an intermediate non-a11y user.]
OK, I see where you're coming from. As you seem to know more about a11y than I do I will believe that an application that shall support a11y users as much as non-a11y users will need to be designed for this from the beginning. In this sense OOo needs a redesign and probably we could end up with rewriting larges parts of it (as obviously is also true for the competition). "Large parts" means that not everything needs to be rewritten as there is a lot of code that is not relevant for a11y - OOo is much more modular than a lot of people believe. But most probably the GUI code, the layout and parts of the document model are affected. OTOH our goal is not to provide such an application now. If you have limited resources your goal is not to create the "best everywhere" but something that fulfills the most important requirements in the best possible way. In case of a11y it seems that most affected people would be pleased already if we had the same support in OOo as they get from the competition. The reasons that we fall behind here are partially platform related or caused by the mentioned "handcrafted" tooling but admittedly also in our own product. >> throw out the current OOo GUI but you still can keep most of the code >> below it. > > There are a number of other reasons why the OOo code needs to be > rewritten -- Unicode 4.0 compliance and the removal of the duplicate > libraries being one of them. [And yes, I know those are related matters > that will be done "real soon now".] I don't know what you mean with "duplicate libaries" but you are right that we had to do quite a lot for UniCode 4 support. It wouldn't be a complete rewrite. It should be not more work than the switch from single byte characters to UCS-2 strings (unfortunately! I would have preferred UTF-8 strings) we did before the source code was released. The reason why we hesitate to make the switch is not that we are afraid of the effort, it would make our current C++ UNO binding incompatible and so we must have *very* good reasons to do this. Until now it's unclear wether this is the case here. But times may change and requirements also. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
