The SDK uno_skeletonmaker -t argument

[DavidL1]

According to https://api.libreoffice.org/docs/tools.html#uno-skeletonmaker the argument ‘-t’
“specifies a UNOIDL type name, e.g. com.sun.star.text.XText (can be used more than once)”. This was evidently taken from the uno-skeletonmaker command-line ‘help’ which has the same wording.

However this description fails to explain which entity the UNOIDL type name qualifies. For example, is it the type of the skeleton code to be generated (presumably not, since that’s defined by the ‘calc-add-in’ command), the type of each value returned by the Java methods implemented in this addIn, or what?

An article on GITHUB makes a brave attempt to comprehensively document use of the SDK tools, apparently in a MS Windows environment, but doesn’t list the CLI command line of each step. The author writes that they created some batch scripts, but I wasn’t able to find them.

The author does offer many useful tips in passing, for example:
“uno-skeletonmaker.exe requires a reference to the component’s RDB file, Office’s types.rdb, and a fully qualified Java interface name (i.e. org.openoffice.randonsents.XRandomSents).”
which I’ve done with ‘-l’ but again the question is why?

I’d greatly appreciate light anyone can shed on the ‘-t’ qualifier. What does it actually do for uno-skeletonmaker ?

I should add that I wrote two successful Java calc addIns using the old method of hand-coding the lot some years ago, but felt this time I’d use the development tools.

[DavidL1]

Has anyone on this list actually used uno-skeletonmaker? I can’t even find an example showing the CLI command which might offer a clue.

[mikekaganski]

Asking such things here wouldn’t be the best thing. Just join #libreoffice-dev, and ask there; or post a mail to developers’ mailing list. You may even get then an answer from people who actually implemented that.

(It always amazes me how people tend to ignore benefits of open-source, where it’s all transparent… You may even read the respective code.)

[DavidL1]

Thanks for your reply Mike, and for links to the sources. Consulting the source code had occurred to me as a last-ditch option and I’ll see if that brings enlightenment. But it’s many decades since I’ve been paid to cut code, and C was never my language anyway!

But here are some general comments.

In April 2021 ‘jimk’ and ‘gabix’ exchanged views on whether a question involving the use of C in SDK development is off-topic here or whether the Developer’s email list would be more appropriate; see https://ask.libreoffice.org/t/cant-compile-sdk-developersguide-c-examples-on-macos-big-sur/63944

The choice appears to be this forum, which deals with the LibreOffice standard package but not its SDK, or the Developer’s email list which is for SDK experts who have time available to assist in various LibreOffice support & development tasks. But this division seems to me to exclude many professionals who might otherwise write Calc addIns but are not software developers per se and not desperate enough to tackle the LibreOffice SDK.

They’re professional users in various fields (scientists, engineers, economists, experiment designers and evaluators, etc.) who find a spreadsheet useful as a framework for complex calculations, especially with LO’s array of statistical functions and other mathematical tools, curve-drawing tools, and so on. However cell formulae can then often become long, unwieldy, and bug-prone. But the same cell-logic implemented in Java as a functional addIn is often much clearer in its correctness, is easier and quicker to implement given proper tools, and of course it’s faster.

Regards, D.