On Mon, Mar 24, 2014 at 12:24 AM, Jürgen Schmidt <jogischm...@gmail.com>wrote:
> On 3/22/14 12:27 AM, Kay Schenk wrote: > > On Fri, Mar 21, 2014 at 4:05 PM, Andrea Pescetti <pesce...@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. > This makes sense and generally what I would think of when I think about "extensions". > > And my experience showed also that often core changes are necessary to > make specific extensions possible. > hmmm...not something I would have thought. OK. > 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 > Rest of your comments duly noted. > > > > > > > > > >> > >> > >> * 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-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- ------------------------------------------------------------------------------------------------- MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
