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

List:       koffice-devel
Subject:    Re: For KWord: a mailmerge plugin for KexiDB
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2006-08-30 22:34:03
Message-ID: 44F6125B.3070006 () iidea ! pl
[Download RAW message or body]


Thanks for your work, Kai. Comments below.


Thomas Zander said the following, On 2006-08-30 19:14:

> I'm more concerned with packaging. Its a no-go that one of the main-3 
> office apps depend on another.
> 
> I've said it before, and I'll repeat it;  we need a mailmerge interface 
> (all pure virtual methods class) in the libs that different providers can 
> then implement. Where Kexi can be one of them. Preferably as a plugin via 
> the service provider mechanism.

This is one option.

Another could be that, assuming Kexi will delivers more data sources than 
curently, you can rely on the kexidb/kexidbui when choosing data sources. In 
addition richer API can be kept for mail merge if needed, but data access can 
come from kexidb.

This is all up for discussion and there are other related topics like a 
special kind of database reports that utilizes KWord's WYSIWYG features and 
OpenDocument-compatible variables.

> Depending on a specific database implementation for any usage is therefor 
> not useful and IMOHO plain wrong. So, don't suggest to move kexidb to 
> kofficelib. :-)

KexiDB is planned as a part of kofficelibs 2.0. For 1.6 it stays in Kexi.
Reasons: we didn't yet moved it to lib/ nor test such layout, especially for 
packaging; it's to late to do such things and test it;

Moreover, by looking at the screenshot I can see there are widgets for 
defining db connection that developed again, while Kexi delivers them, as well 
as complete dialogs - e.g. 
http://kexi-project.org/pics/0.9/connection_dialog.png. Such things will be 
probably a part of kofficelibs 2.0 too (as kexidbui or so), pushing unified 
data access to the 'extreme'. Of course Kai's code can be ported to using the 
GUI stuff  later.

Of course I appreciate Kai's work knowing he wasn't able to use the kexidbui 
components, as it's all Kexi's private API for 1.x.

Now, the question is what to do with the Kai's code that of course should not 
be kept in secret during 1.6's life span. My proposal is _the same_ as for 
recently introduced KSpread's database import dialog:

-> move the code to koffice/kexi/plugins/mailmerge/; as it implements 
KWMailMergeDataSource interface, and it is a plugin, there is only 
compile-time dependency, so it can be packaged within Kexi _without_ any 
dependencies on KWord (TODO: mention this in README.PACKAGERS).

For users there will be easy and _natural_ way to get the 'database' mail 
merge: just install Kexi. No problems with dependencies on database drivers 
too, as long as Kexi package has no such problems (and packages know how to 
play this game now).

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org
_______________________________________________
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]