[Kde-finance-apps] Introducing Koo

Albert Cervera i Areny albert at nan-tic.com
Sun Mar 21 19:43:31 CET 2010

A Diumenge, 21 de març de 2010, Alvaro Soliverez va escriure:
> Hello Albert,
> welcome to the group. 


> I'm sure we will find common issues to help each
>  other.
> For the graphs, in KMyMoney we use libkdchart. It's a graph lib
> developed by KDAB and used in KOffice. It's a model-based lib, and
> it's fairly to get started with it. I can point you to the relevant
> class in our code if you are interested.

I must say that one of the problems we have is that we're using PyQt and we 
need the application to work properly on windows too. As for libkdchart we 
should make the bindings ourselves, which I'm sure is possible but complicates 
distribution quite a lot. However, I know we will have to face that problem 
sooner or later :-)

> Skrooge has graphics too, but I don't know what they are using.
> As for the calendar view, have you tried reusing the KOrganizer
> classes, or even providing a resource to open it straight in
> KOrganizer? I think you could even instance it as a KPart, and you
> would be good to go if that's the functionality you need.

Opening the data inside KOrganizer is not an option, we had considered reusing 
KOrganizer classes, but they're not in a separate library at the moment, 
though I'm sure that contribution would be welcomed by KDE PIM guys as I 
already discussed this with them. It's in my TODO list ;-) Here the problem is 
that we first need to create the library, and then the bindings, which will 
not probably be easy at all, given that PyKDE does not work on Windows. That's 
why we decided to create our own (even if limited) widget for that.

> Myself, I'm very interested in your integration with Nepomuk. It's one
> of our ideas for GSOC, and that would be very useful for all finance
> apps.

Our main problem is that Koo is not a KDE application, but a KDE interface for 
an application server. This means that storing semantic information should be 
handled on the application server, which we can not relay on having a KDE 
installed (and wouldn't probably be desirable either).

As OpenERP allows attaching files to any object in the database (orders, 
invoice, stock moves, whatever), when a user stores one attached file back to 
her filesystem, we save semantic information with it:
- We set an 'OpenERP' tag (indicating the file has been taken from the ERP)
- We set another tag indicating from which document it was extracted (Invoice, 
Sale Order, etc)
- We store the description with which the attachmend was stored in OpenERP
- If the attachment was related with a company or address, we try to find that 
contact in user's local addressbook and set a relation between that PIMO thing 
and the file.

Further integration  would be great, but given its client-server architecture 
is hard to find how to do that.

> See? We have more in common than you think. ;)
> Once again, welcome.
> Regards,
> Alvaro
> On Sun, Mar 21, 2010 at 9:37 AM, Albert Cervera i Areny
> <albert at nan-tic.com> wrote:
> > Hi,
> > I just wanted to introduce the Koo project to all kde-finance-apps
> > members.
> >
> > Koo [1] is a client for OpenERP[2]/OpenObject[3] based on PyQt. It uses
> > PyKDE if available, but by now, only for storing semantic information
> > using Nepomuk.
> >
> > Although the official client for OpenERP is GTK based, with Koo we have
> > some cool stuff, such as:
> >
> > - A model that can be used to access information on the application
> > server from any Qt widget using interview.
> > - Much better performance which allows using the client with a WAN
> > between the client and the server.
> > - Better API which makes creating new applications based on the platform
> > a breeze.
> > - Integrated full text search.
> > - A POS mode useful for touchscreen applications, while still having all
> > flexibility of OpenERP available. [4]
> >
> > You can see some old screenshots here [5] and some more up to date
> > information in our blog [6].
> >
> > I must admit that it seems hard we can find points in common with other
> > kde finance applications due to the fact that Koo uses a three-tier
> > architecture and Python instead of C++, but for example, one of the
> > things we're missing is an intuitive and powerful Charts API. We started
> > using matplotlib, then created our own, and we're considering matplotlib
> > again, but it's terrible API makes the decision pretty hard. We also had
> > to implement a minimal calendar view, which really lacks behind GTK and
> > Web based clients and it's something that would be nice KDE provided.
> >
> > Well, by now I'll be right here watching progress of kde-finance project,
> > and I hope we can help with some stuff in the future!
> >
> > [1] https://launchpad.net/openobject-client-kde
> > [2] http://www.openerp.com
> > [3] https://launchpad.net/openobject-server
> > [4] http://albert-nan.blogspot.com/2009/02/koo-in-pos-mode.html
> > [5] http://www.nan-tic.com/koo-platform
> > [6] http://albert-nan.blogspot.com/
> >
> > --
> > Albert Cervera i Areny
> > http://www.NaN-tic.com
> > OpenERP Partners
> > Mòbil: +34 669 40 40 18
> > _______________________________________________
> > Kde-finance-apps mailing list
> > Kde-finance-apps at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-finance-apps
> _______________________________________________
> Kde-finance-apps mailing list
> Kde-finance-apps at kde.org
> https://mail.kde.org/mailman/listinfo/kde-finance-apps


Albert Cervera i Areny
OpenERP Partners
Mòbil: +34 669 40 40 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100321/b8359520/attachment-0001.htm 

More information about the Kde-finance-apps mailing list