Re: Simplified Libreoffice API

Just to be clear:

for me, I don't want a 'simplified'/user-friendly API for, e.g., MS
Excel compability. I just want it to know how to use it, without these
so-long-and-not-so-comprehensible-detailed-and-not-clear steps needed
by now. Even if it wouldn't be so powerful UNO API seems to be.

Creating a new API (letting both coexist) or extending the current one
- I really don't care =) I'd just love to make any extensions, and -
even better - clear and readable ones. When I look at some UNO code -
"oh that creepy beast" is my first and only thought.

Regards,
Rodolfo

2013/3/12 Noel Power <nopower@suse.com>:
> 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