Removing C++ SDK examples, clearly encouraging Python extensions (was: LibreOffice prints on tuesdays)

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Tue Apr 2 02:33:53 PDT 2013


Hi,

On Mon, Apr 01, 2013 at 06:43:27AM -0400, Dan Lewis wrote:
>      What is the purpose of this extension? Why print only on Tuesdays?

The real purpose of this extension is to be an example on how to write a simple
extension:

 https://plus.google.com/101094190333184858950/posts/dpLf3s6C2r5

Being nonsensical actually help at being an example, because if you write an
example that is actually useful, it tends to feature-creep into something
complex and unwieldy.

As such, I would like to add this extension to:

 http://api.libreoffice.org/examples/examples.html#python_examples

Also -- and this is a proposal for the ESC to discuss: I would like to remove
the C++ examples there. Im not kidding, April fools is over in my time zone.

I tried hard to make them work and just couldnt get them to build (trying it on
Windows, just to make things more interesting).  Right now, it is orders of
magnitude easier to just work on core repo that to try write UNO-stuff against
a standalone SDK. As contributors might assume otherwise ('If building an
extension is this hard, working on the core product must be impossible') this
kills us possible contributors.

So right now:
- C++ extensions are essentially useless: they have a higher barrier to entry
  than the core product
- Python extensions have the lowest barrier to entry

So my proposal is:
- Remove the C++ example stuff until someone comes along and provides trivial
  to use ones that are easier to build than the core product on all platforms.
- Add more Python examples
- Encourage writing extensions in Python or hacking directly on the core
  product in C++:
  - building C++ extensions are a mightmare to set up right now
  - even Java is orders of magnitude more complex than Python because of the
    static typing and queryInterface() madness and the lack of Pythons mapping
    of getFoo() methods to properties
  - the migration path into the core product should a extension become part of
    the core product would be:
    - written as a Python extension in RAD mode
    - moved into the core product when qualifying
    - C++ified there, which is easier than doing it out of the product

Making sense?

Best,

Bjoern


More information about the LibreOffice mailing list