[Kexi] Using Kexi databases/queries in KWord (or other KOffice apps)

[Sebastian Sauer]

On Friday 28 July 2006 23:47, Matija Šuklje wrote:
> > That may possible with KWord's mail-merge. You are able to e.g. store the
> > KexiDB at a MySQL database and then use KWord's mail-merge to merge those
> > data into your document using QtSQL to access the MySQL database.
> > Another way may to use dcop (dbus with kde4/Koffice 2.0) from within a
> > Kexi script to control KWord or/and KSpread. So, it should be possible to
> > iterate e.g. with a simple Python or Ruby script through the database,
> > format the data and then insert the data e.g. at KSpread. KSpread from
> > the 1.6-branch (according to the releaseplan 1.6 alpha1 will be published
> > next days/weeks) does contain the ScriptEditor which has some example
> > python-scripts that demonstrate how to import data from a KexiDB into a
> > KSpread document or how to access KWord with dcop). But while it's
> > possible, I would not see it as optimal or as nice solution. It's just a
> > "it works that way, but will maybe change in future releases since it's
> > not the best solution" thing :-)
>
> hmmm ...sounds like A LOT of coding that sadly I just don't have time to
> learn right now. I knew I should have studied Python when I still had time
> this year!

It still depends on what you like exactly to do and how complex it is at the 
end. Well, if it's only to push data from one app to another, then I could 
write such a script with just ~10 lines of code :)

> > I Would really recommed to use KSpread without Kexi for that task. From
> > my point of view it looks as that may the better, easier and even more
> > lighter solution. But since I don't try to convince here and since you
> > are the one who knows best what your needings are, I could at least try
> > to help you to get some steps forward :)
>
> I've though about it a bit ...and I still think that the ideal solution
> should be to just enter stuff with Kexi into a DB and then have/make a
> template in KWord with some spreadsheets in that would do the queries "by
> itself".

yeah. Auto-generated reports (so, such simple as our current "simple prints") 
would be really _the_ ideal solution. The report-engine is still one of our 
biggest TODOs (IMHO) and may eat a lot of time. So, something for Kexi 
2.0 :-)

> > Those both are simple SQL select-statements. But since they depend strong
> > on how you designed your tables...
>
> That's another problem that I see in Kexi (I know it's an early version)
> ...I imagine that Kexi is supposed to be suitable also for users who don't
> know SQL commands by heart. Therefore I think it would be very helpful if
> at some time there would be a suggestion/completion tool in Kexi like it is
> for example in KDevelop - it would suggest and/or complete commands (with
> help?) according to the database backend that is currently in use. Such a
> feature would most probably benefit Kexi very much ...but I imagine it's a
> lot of work to put in.

Well, the query-designer has 3 modes; the dataviewmode, the designmode and the 
textmode. I normaly work by myself in the textmode cause I just know SQL. 
Others are for sure able to use the designmode to simple "click the query 
together".
Your porposal goes a step future. So, wizards that help the user and suggest 
solutions. Again I agree here and afaik it's also on our TODO (but I fear it 
doesn't have that high priority currently cause there are still things like 
reports :-)

> > dcop with Kross or mail-merge as outlined above...
>
> mhm ...Kross is not implemented yet AFAIK, but seems to be the optimal
> solution in the long shot. For now I think I'll just have to do with a
> temporary solution, until the exam season ends.

It is implemented since version 1.5 and Kexi comes with complete bindings for 
all of the database-functionality. So, in fact, you are even able to e.g. 
write a little python-script that uses reportlab.org to create very complex 
statistics and reports. With questions about Kross you may even got the 
perfect partner here cause I wrote Kross + the bindings and if, what I don't 
believe yet, some functionality is missing, I am able to add that 
functionality within a short time :-)

> > hehe... yes, for your special case it really seems simpler. Not only to
> > design, but also to maintain and work with.
>
> As I said - I'll make it in KSpread now (probably even manually copy-paste
> for now), but still keep the option open to use Kexi with it.

Sounds great. If you like, just mail me your work done on KSpread/Kexi, so 
that I am able to get a more detailed impression of how you tried to solved 
the task, what may be needed to do, etc.

> > And that's where I agree absolutly. So, to sum it up; the integration
> > between the apps could be improved much more to allow such workflows (or
> > other workflows where no way around using a database does exist). It
> > sounds as you should really try to create a wishreport for this at
> > http://bugs.kde.org to be sure that wish doesn't got lost on the one hand
> > and to allow others to agree with your wish too and to vote for the wish
> > or even extend it with there own usage-scenarios.
>
> Think so? A wish report for an integration for Kexi commands with other
> KOffice apps or the specific scenario?

Looking through those bugs at bugs.kde.org related to KOffice, there is 
currently no item which deals with the integration between the applications. 
Also there are no usage-scenarious dealing with that question. Well, since we 
are currently dealing with how to solve it, we could also wait till it's more 
clear what exatcly need to be done at the KOffice-front (so, from the 
technical point of view which I am able to provide). Once we know them, it 
could help to write down the whole scenario + the tech-details, so that 
others may are able to read it + extend it or even get an impression for what 
we could need it. As developer it's always nice to have such kind of 
user-feedback cause it helps to went into the right direction and to see 
where problems may are located or what users really expect.

> > Yes, we arn't around fulltime and as you may see with this mail, it cost
> > some time to write a nice answer to such a nice question :-)
>
> heh ...sorry again ...it's just that I'm used to quick answers on lists (in
> Cyberpipe we have a project/org list where you're expect to reply in a
> matter of minutes - it takes up more space in my mailbox then all the other
> boxes put together - including the inbox, kde-i18n and reports from diverse
> bugzillas) I'm not trying to assault you, I'm merely trying to explain
> myself :]

For such cases we have IRC as realtime-medium. But mailinglists are for sure a 
bit better to deal with longer messages / more text and to be able to think 
twice about something someone else wrote. I guess the biggest disadvantage 
mailinglists have is, that it just eats so much times to read and reply with 
more then one single sentence. Would be wonderfull to be someday able to just 
write mails by thinking, so without the needing to hack into a keyboard.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org