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