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 <[email protected]>: > 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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
