[kplato] Re: Google's Summer of Code - KOffice proposals

[Raphael Langerhorst]

On Thursday 09 June 2005 13:24, Dag Andersen wrote:
> On Onsdag 08 juni 2005 21:44, Raphael Langerhorst wrote:
> [snip]
>
> > I have been a bit active on IRC and right now Adriaan, Lauri and
> > I planned to do a summer of code project about KPlato - after all
> > it should be included in the next release (IMO). In the process
> > of implementing desired functionality I will write down my notes
> > on development - thus creating a developers handbook as a side
> > effect - an important one ;)
> >
> > Anyway, if there is anything particular you want implemented in
> > KPlato (fitting for a summer of code project) please let me know
> > ASAP. Right now I'm thinking of better integration with the rest
> > of KOffice, but I'll take a closer look before submitting any
> > proposal.
>
> Yes, koffice integration is allmost totally missing. The framework
> is there, since our KPTPart is a KoDocument and KPTView is a
> KoView, but the crucial KPTPart::paintContent() is totally empty
> and zoom is not implemented at all.
> AFAICS the main problem is that our views are doing the painting
> while it should have been the document. I suspect this can't easily
> be fixed, but please, someone, tell me I'm wrong :)
>
>
>
> A totally different thing: It would have been great to have a
> framework for exchanging *data* between koffice apps. An example is
> reports in kplato. Atm i've looked at kugar which is ok as far as
> it goes. What it's lacking though (from my point of view) are
> possibillities like proper header/footers, graphics (ie kchart,
> gantt), pics (logos) and the possibility to add/edit text. You
> probably noticed kword fits the bill for the additional stuff :)
>
> I've had some initial thoughts of how to implement reports in
> kword, but I've not dug into it, and I'm not really a programmer so
> there is probably vastly superior ways to implement this ;)
>
> Anyway, here are my ideas:
> It's based on a combination of a new type of kword variable and
> plugins. The variable will tell kword which plugin to call and with
> what data, the plugin will know how to fetch data from file or
> application.
>
> When kword starts up it will look for and load available plugins.
> This will result in new entries in the Insert->Variable menu, eg if
> there is plugins for kplato and kspread:
> KPlato->Project name
>         Project manager
>  Task info...
> KSpread->Some variable
>      Another variable
>
> When selecting a menu item, the plugin will be called with the
> choise and it will respond with the data that shall be attached to
> the variable. This can be simple, as with the Project Manager
> choise or more complex, as with the Task info... choise. In the
> latter case the plugin will come up with a dialog enabling the user
> to select which tasks/properties to include.
>
> Designing a 'report template' will then be a question of entering
> variables into a kword document.
>
> When creating the report, kword will feed each variables data to
> the appropriate plugin, the plugin will fetch the data from file or
> application (somehow the plugin must know where to get it) and
> return it to kword which will present the data in place of the
> variable.
>
> When creating reports, I see 2 ways to use it:
> . Start kword and 'mine' data from one or more file, or
> . open kword embedded into eg kplato and have kword fetch data from
> the running kplato.

This sounds good, and it makes me think of sth additional (or a 
requirement for the above):

Currently there is no way to tell an embedded document _what_ to show, 
right? (please correct me if I'm wrong)

Now, what we need is a way to tell an embedded document a certain 
configuration for what to present. This "configuration" can then be 
set for example through configuration dialog that can pop up when 
right clicking on an embedded document (RMB -> presentation options   
[or whatever]). This must be possible through an interface in the 
core libraries and every component must implement this interface - 
maybe just one call: configurePresentationOptions()

When this is called it's the embedded document's responsibility to 
show a configuration dialog and render according to these settings. 
The dialog can be anything since it's not specified by the interface.

Then, KPlato can be embedded in a KWord document and can be configured 
to show for example the list of resources, or the gantt chart (or 
parts of it) and so on and so on. Also it would be possible to tell a 
spreadsheet which sheet actually should be shown or at which offset - 
and whether zooming should be applied to fit the sheet on the 
available space, etc... I think such things are important in the long 
run. THEN, KWord could gain lot's of importance as a desktop 
publishing application since it can contain arbitrary data through 
document embedding (since there is better control over the displayed 
content).

Document embedding already works with external documents! Which makes 
me think about files... we would need to save the presentation 
settings in the parent document. Anyway, this way the report 
generation would already work (almost?) the way you suggested, since 
the variables are sth like the presentation configuration. Although 
this isn't as suitable to access one-string data like creation date, 
etc. (that is, what variables are representing at the moment), so 
maybe this plugin system is an additional/different topic. I would 
suggest to implement THIS through DCOP calls to embedded documents... 
which gets difficult if the document embedding is not desired and 
only that very variable is needed... hmmm, difficulties...


What do you think about creating the described infrastructure for 
presentation options of embedded documents? And the good news is also 
that I would have to deal with the internals of KOffice as such and 
could produce a good cookbook while working on this... and improve 
the API docs.


> --
> PS. This isn't restricted to koffice apps, of course. Data could be
> fetched from anywhere dependent on the plugin.

hmmm, a plugin that allows/uses DCOP calls?

-- 
Raphael Langerhorst
http://raphael.g-system.at/blog