[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
> 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
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.
> 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  is a client for OpenERP/OpenObject 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. 
> > You can see some old screenshots here  and some more up to date
> > information in our blog .
> > 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!
> >  https://launchpad.net/openobject-client-kde
> >  http://www.openerp.com
> >  https://launchpad.net/openobject-server
> >  http://albert-nan.blogspot.com/2009/02/koo-in-pos-mode.html
> >  http://www.nan-tic.com/koo-platform
> >  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
Albert Cervera i Areny
Mòbil: +34 669 40 40 18
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kde-finance-apps