Re: Re: Google's Summer of Code - KOffice proposals

On Torsdag 09 juni 2005 15:39, Raphael Langerhorst wrote:
> 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)
Yes, I've missed this too, see my other mail.
>
> 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.
I don't really have an opinion on implementation, probably David's 
brain is the one to pick :)
>
> 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).
Yes, this will be very useful.
>
> 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...
Yes, I think trying to combine embedding docs and reports are bit to 
much. Creating a good clean environment for embedded documents is the 
most important thing. In the light of a better component framework, 
maybe we should have another look at if embedding a clean report 
generator like kugar or the upcoming Kexi Report Designer (KRD) into 
kword could give good results.
>
>
> 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.
Go, go, go :)
>
> > --
> > 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?
Yes :) 

-- 
Mvh,
Dag Andersen