openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@gmail.com>
Subject Re: Extensions "wish list" placementt?
Date Mon, 24 Mar 2014 07:24:16 GMT
On 3/22/14 12:27 AM, Kay Schenk wrote:
> On Fri, Mar 21, 2014 at 4:05 PM, Andrea Pescetti <pescetti@apache.org>wrote:
> 
>> On 20/03/2014 Kay Schenk wrote:
>>
>>> Every once in a while a topic arises on this list and gets a response like
>>> "that might be a good idea for an extension".
>>>
>>
>> Right, but most of the times it is just a wish. The API available to
>> extension developers does not allow to do everything. So it is very
>> important to distinguish between responses that take into consideration
>> what can really be done with an extension and responses that don't.
> 
> 
> Of course, this is critical!
> 
> 
>>
>>  * Is is a good idea to steer new developers into extension development
>>> maybe as an introductory step?
>>>
>>
>> Probably it would be more effective to have more, well-defined and
>> verified (in the sense above, i.e., that someone with the needed knowledge
>> has verified them) easy tasks. Building an extension still requires skills.
> 
> 
> As far as "development" goes, creating an extension *might be* easier than
> coding changes to source. Of course, extension development is not as easy
> as some of our "easy tasks".

yes and no, you can make a lot mistakes with extension but the same is
true for core changes.

My experience from the past showed that extension are quite good for
features that are not interested for all in the same way. External
product integration for example where you need a commercial license. The
connector is free but make no sense without the other product. This can
help to grow the eco system.

And my experience showed also that often core changes are necessary to
make specific extensions possible.

In general I would always prefer new features directly in the core and
in ideally implemented in C++. And in the end it is easier to maintain.
Our bundled extension concept needs some rework ...

Volunteers should start with bug fixing, debugging existing code and
nail down a problem on the root cause can be of course a challenge and
motivation. You can learn a lot about the existing code  and do over
time more complicate things.

But better starting small and grow over time than starting big, failing
and lose motivation after some initial posts ;-)

Juergen


> 
> 
> 
>>
>>
>>  * and, assuming we can track down some of proposed extensions, where is a
>>> good place to record these for future reference?
>>>
>>
>> It seems we have https://wiki.openoffice.org/wiki/Extensions/Ideas ; but
>> looking at https://wiki.openoffice.org/w/index.php?title=Extensions/
>> Ideas/Calc&action=history I see no indications that we are using it the
>> right way (again: checking that it is possible with the current API to
>> implement those ideas). It would be good to ask the API list for a quick
>> validation of that page.
>>
> 
> Ok, thanks for this info -- I will check it out and confer with the API
> list as well. What occurred to me after I sent this would be to just log
> them into BZ under the "extension" category, and "enhancements". No need to
> create another special area.
> 
> 
>> Regards,
>>   Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message