[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Developer manual for KOffice
From:       Raphael Langerhorst <raphael.langerhorst () kdemail ! net>
Date:       2005-10-26 13:36:29
Message-ID: 200510261536.29491.raphael.langerhorst () kdemail ! net
[Download RAW message or body]

Am Mittwoch 26 Oktober 2005 13:42 schrieb Inge Wallin:
> On Wednesday 26 October 2005 12.27, Raphael Langerhorst wrote:
> > Inge wrote:
> > > But on the other hand, we might need a developer manual for KOffice
> > > (separated from the user manual).  I didn't think that we would need it
> > > until we introduced scripting, but it seems that I was wrong.
> >
> > Well, there could be two developer manuals - one for the KOffice
> > developers themselves, and one for people that use KOffice and develop
> > their own add-on stuff (plugins, Scripts, Kugar reports, ...).
>
> I don't think we need a developer manual for the KOffice developers
> themselves.  Of course, we need documentation, but I don't think that a
> docbook manual would be the right way to do it.

Ok, so I take it that some DESIGN files in the source code and the API 
reference, plus some docs on developer.kde.org should be enough for the 
"KOffice developers". Well... that saves me probably a LOT of work.

>
> On the other hand, if we want to spread KOffice usage, I think that a
> manual for people who want to script KOffice would be a very good thing. 
> It's often a lack of knowledge about already existing features that keep
> people from using them.  In fact, I think this happens almost as often as
> the features not existing at all.

Yes, you convinced me on IRC on that... (see further below)

>
> > Still, for now I would like to find out if there is demand for such a
> > thing. I was at last able to put a developers handbook together for the G
> > System, so I guess the KOffice devbook would look similiar (but of course
> > adapted). This approach combines both variants. You can find it here:
> > http://www.g-system.at/doc/latest/dochome.html  (it's the devbook)
>
> Yes, something like this.  When we discussed this on IRC, you had a number
> of ideas yourself:
>  - KOffice scripting with DCOP
>  - creating custom plugins
>  - reports with kugar
>
> Kexi is also a natural subject for this, but since Kexi is so much a
> developers tool from the beginning, it would be logical to produce a manual
> for Kexi alone.

I agree that there are a couple of things that better should go into a general 
"hacking koffice to your meet your needs" document. So this would target a 
rather new user-base (in terms of documentation). These things are now 
probably under-used as there is not much information available.

I think components like Kugar (and maybe parts of Kexi?) as a whole fit into 
such a document (not necessarily "one" document), while for other components 
we still have the usual user manuals. That developer manual can then also 
cover KOffice automation and scripting with DCOP, some Kexi scripting and 
plugin writing.

ok... so that's the idea. As time permits I will look into more details.

>
> > Do you generally want/require/desire a developers handbook like this? I
> > certainly see the benefit especially for new contributors... but also for
> > users that extend KOffice for their own needs.
>
> I think it would be good.  However, I don't think that the target should be
> KOffice core developers.  Instead it should be people who want to customize
> KOffice for their own needs, but don't want to touch the C++ classes.

Yes.

>
> 	-Inge

Raphael

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]