Re: [api-dev] UNO wrapper project
Alexandro Colorado wrote: A feature that might make IDE better is integrated to Xray or PyXray on a way that can autocomplete the methods however basic itself is limited within the UNO framework. This is an oversimplification and an overcomplication at the same time. :-) Wether you can have autocompletion or not is not a matter of the language or their binding to UNO or not, it's a matter of the type system. Autocompletion needs static typing, means: you must know the type of an object to be able to autocomplete written code to the methods of the object. So if you want autocompletion in a programming language you must integrate static typing into it. This is possible with *every* programming language, even with OpenOffice.org Basic. OTOH exactly Basic programmers don't like static typing (means: they don't like typing their variables at all ;-)), so you have to make a choice. As I already suggested in [EMAIL PROTECTED]: offering *optional* static typing would allow us to implementing autocompletion in the BasicIDE for all developers that take this option, means something like dim doc as com.sun.star.textTextDocument doc = StarDesktop.loadComponentFomURL(...) instead of dim doc doc = StarDesktop.loadComponentFomURL(...) would enable the IDE to autocomplete the code if the user starts to type doc. 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]
Re: [api-dev] UNO wrapper project
Roberto Battistoni wrote: Ok, but how far is this future? OpenOffice is a great editor, but its SDK with API and UNO framework is too complex as compare to Winword environment with .NET and C#. I like OpenOffice, but productivity is an important factor for enterprises that want to invest in OpenOffice. of course your are right productivity is important and as Stephan pointed out we are working on improvements. But changing existing APIs will probably take longer because the pure functionality is already available. We have to find a compromise between new features, new APIs and adapting existing API areas. We will first adapt often used APIs (document APIs) and will go deeper to other APIs. We will also define some high level APIs for often used functions but we will definitely not create any language specific wrapper. Our approach is to make use of the UNO ease of use features to make APIs more intuitive and easier in the future. This has the advantage that all language bindings will benefit from this improvements. The biggest problems with the current API are missing examples, documentation and maybe tools support. When you compare our API with the MS API you will see that our API is not so bad ;-). But for MS you can find thousands of books, examples and you have great tools/IDE support making the development easier. Cedric is working in an Eclipse plugin, we are working on a NetBeans integration and other tool support will probably coming as well. Juergen Thanks all Our vision of the future is that the OOo UNO API will improve so much (using multiple-inheritance interfaces and new-style services, and offering high-level APIs) that developers will feel no need for a wrapper for the UNO Java language binding. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[api-dev] UNO wrapper project
Is there any UNO wrapper Java project in the future? Thanks Roberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] UNO wrapper project
http://ubion.ion.ag/plonesoftwarecenter/004niceofficeaccess/ Tom Roberto Battistoni wrote: Is there any UNO wrapper Java project in the future? Thanks Roberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [api-dev] UNO wrapper project
Roberto Battistoni wrote: Is there any UNO wrapper Java project in the future? Our vision of the future is that the OOo UNO API will improve so much (using multiple-inheritance interfaces and new-style services, and offering high-level APIs) that developers will feel no need for a wrapper for the UNO Java language binding. ;) -Stephan Thanks Roberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] UNO wrapper project
Ok, but how far is this future? OpenOffice is a great editor, but its SDK with API and UNO framework is too complex as compare to Winword environment with .NET and C#. I like OpenOffice, but productivity is an important factor for enterprises that want to invest in OpenOffice. Thanks all Our vision of the future is that the OOo UNO API will improve so much (using multiple-inheritance interfaces and new-style services, and offering high-level APIs) that developers will feel no need for a wrapper for the UNO Java language binding. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] UNO wrapper project
Roberto Battistoni wrote: Ok, but how far is this future? There are people working on it, but I cannot offer you any concrete dates. -Stephan OpenOffice is a great editor, but its SDK with API and UNO framework is too complex as compare to Winword environment with .NET and C#. I like OpenOffice, but productivity is an important factor for enterprises that want to invest in OpenOffice. Thanks all Our vision of the future is that the OOo UNO API will improve so much (using multiple-inheritance interfaces and new-style services, and offering high-level APIs) that developers will feel no need for a wrapper for the UNO Java language binding. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
