Simplified Libreoffice API

[Noel Power]

On 12/03/13 09:15, Michael Meeks wrote:
> Hi Rodolfo,
[...]
>
> 	I think a better approach is to re-use the existing compatibility API
> that we implement and expose it into StarBasic in some pleasant way; it
> should be possible to do things like:
>
> 	ActiveSheet.Range("A1") = 3
>
> 	for example - and get something useful; currently it's necessary to
> enable a compatibility mode with a setting in each file to get that
> going, and then mixing in old-style UNO APIs for missing pieces is
> harder, but ...
>
> 	Re-using, extending and improving our interoperable API there makes
> much more sense (to me) than creating yet-another binding :-)
>
> 	How does that sound ?
I'm not convinced that I really agree with that, I mean no problem with 
improving the interoperable API, any help offered with that always 
welcome, I mean reusing that api for libreoffice wholesale, I feel there 
are a number of problems
a) More than setting a compatibility mode is required, some stuff will 
work with the compatability mode but alot of stuff wont, for technical 
reasons there are ( at least )  some temporary objects and associations 
created on import ( of a native Microsoft document ) that are needed for 
things to work correctly.
b) More than the above the main problem here is that while some objects 
and api do map well to libreoffice some don't, considering the main 
focus of the interoperability API is to behave like Excel that's not a 
surprise but trying to use that api for Libreoffice would cause 
problems, Libreoffice isn't Excel and in lots of places the model(s) and 
behaviours just dont match. We would end up trying to make the 
compatability API have sortof a 'Libreoffice' mode I feel ( which is as 
evil as creating another binding )

However I don't see such a 'Simplified' API as yet another binding but 
just an extension of the existing api. An easier to use more 
user-centric api could ( and would ) also be reused by the 
interoperatbility API ( and or any other scripting language/clients )

>   
> 	Failing that - IMHO we need to move away from a 'pure generic
> interface' approach with UNO, and move towards more of using interfaces
> to expose an object hierarchy
I think at least the ground blocks for this have been laid with Noel 
Grandins work to convert services to the new service specifications, 
that should at least for example in the future allow basic to define 
some stronger types ( than Object ), that would in turn allow the IDE to 
do some sort of primitive code-completion ( I intend to create a gsoc 
task for this ) - but... yes if the existing api/model sucks ( and it 
does ) then this wont help with that :-( But... maybe it will encourage 
people to create some less fine grained api ( built on top of the 
existing interface focused crud ) - that is my hope at least
>   - and annotating those interfaces with
> more information: defaults for parameters, default-methods, etc. to make
> the scripting bindings truly useful. That would make UNO
> object-interfaces more usable from other languages like C++ too since
> currently for optional / defaulting arguments we have to use the 'Any'
> type
of course such enhancements imho are welcome regardless

HTH ( but I fear it didn't )

Noel