Removing C++ SDK examples, clearly encouraging Python extensions

[Stephan Bergmann]

On 04/02/2013 11:33 AM, Bjoern Michaelsen wrote:
> 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

Note that <http://api.libreoffice.org/> links to both the examples that 
come bundled with the SDK (mainly for traditional reasons) 
<http://api.libreoffice.org/examples/examples.html> and the new 
"Additional Examples" repo, 
<https://gerrit.libreoffice.org/gitweb?p=sdk-examples.git;a=blob;f=README;hb=HEAD>.

It would be great if somebody stepped up as maintainer of all those 
SDK-related 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

Can you be more specific here?  Are you talking about building 
extensions against the LO SDK, in both the C++ and the Python case?

Because, in my experience, it is setting up the SDK that is hard (but is 
necessary in either case).  (And even building the existing C++ examples 
on Windows works, once you have set up the SDK.  I verified that the 
other day.)  But, of course, coming up with working makefiles for new 
examples, rather than just trying to build existing examples, is a 
different story---esp. if you want to actually understand what's going 
on in your new makefile, and not just be a happy cargo-culter and 
copy/paste from an existing one.

>    - 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

Just to mention it:  In general and for the long-term vision, I favor a 
core with clean extension points, sufficient to write each conceivable 
extension as an actual extension, over a model that considers the 
extension mechanisms as some sort of rapid development test-bed for 
future core components.

Stephan