Working example of kvp acess in Python

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Working example of kvp acess in Python

c.holtermann
Hello,

for my python latex invoice script I tried to access the owners data. I tried
to work my way to it and came across the kvp system. I made a rude
path through there with a working example to access the companies data.

If someone is interested in clarifying the swig qof_instance and kvp_frame
stuff for python it would be nice to cooperate.

My branch on github about this is
https://github.com/c-holtermann/gnucash/tree/python-kvp

regards,

Christoph Holtermann

--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

David Osguthorpe
On Mon, Jun 09, 2014 at 12:53:38AM +0200, Christoph Holtermann wrote:

> Hello,
>
> for my python latex invoice script I tried to access the owners data. I tried
> to work my way to it and came across the kvp system. I made a rude
> path through there with a working example to access the companies data.
>
> If someone is interested in clarifying the swig qof_instance and kvp_frame
> stuff for python it would be nice to cooperate.
>
> My branch on github about this is
> https://github.com/c-holtermann/gnucash/tree/python-kvp
>

Hi

I have been working with the python bindings but all my knowledge is from my human introspection
of the existing code

I have worked on adding the budget - as you have done you add the include files to the
swig interface file gnucash_core.i and most objects get a base swig interface

My analysis shows that the bindings then wrap the raw swig objects inside more pythonic classes
using GnuCashCoreClass as the base object

so eg in your your case you might want to define     class KvpFrame(GnuCashCoreClass):

you then add methods by calling the add_methods function

eg

KvpFrame.add_methods_with_prefix('kvp_frame_')

where any c function that starts with the string kvp_frame_ gets added to the class
This does add all methods that begin with this string - the only methods you can actually
use in the class though are those where the C kvpframe structure is the first argument

if methods return special objects the should use methods_return_instances
to add the return object type

I have messed a little with the Kvp stuff - one problem is that it tends to return multiple
types which is not so easy to handle - may have to follow the GList typemap as defined
in base-typemaps.i

David
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

John Ralls-2

On Jun 10, 2014, at 8:24 AM, David Osguthorpe wrote:

> On Mon, Jun 09, 2014 at 12:53:38AM +0200, Christoph Holtermann wrote:
>> Hello,
>>
>> for my python latex invoice script I tried to access the owners data. I tried
>> to work my way to it and came across the kvp system. I made a rude
>> path through there with a working example to access the companies data.
>>
>> If someone is interested in clarifying the swig qof_instance and kvp_frame
>> stuff for python it would be nice to cooperate.
>>
>> My branch on github about this is
>> https://github.com/c-holtermann/gnucash/tree/python-kvp
>>
>
> Hi
>
> I have been working with the python bindings but all my knowledge is from my human introspection
> of the existing code
>
> I have worked on adding the budget - as you have done you add the include files to the
> swig interface file gnucash_core.i and most objects get a base swig interface
>
> My analysis shows that the bindings then wrap the raw swig objects inside more pythonic classes
> using GnuCashCoreClass as the base object
>
> so eg in your your case you might want to define     class KvpFrame(GnuCashCoreClass):
>
> you then add methods by calling the add_methods function
>
> eg
>
> KvpFrame.add_methods_with_prefix('kvp_frame_')
>
> where any c function that starts with the string kvp_frame_ gets added to the class
> This does add all methods that begin with this string - the only methods you can actually
> use in the class though are those where the C kvpframe structure is the first argument
>
> if methods return special objects the should use methods_return_instances
> to add the return object type
>
> I have messed a little with the Kvp stuff - one problem is that it tends to return multiple
> types which is not so easy to handle - may have to follow the GList typemap as defined
> in base-typemaps.i

Note that in master, KVP is converted to a private implementation detail of the class that it's attached to, and once C++ conversion gets to the KVP-using classes it will probably get pushed even further down so that it's a persistence detail, existing only in the backends.

In other words, any KVP code you write will break in the next version.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Am 10.06.2014 18:02, schrieb John Ralls:

> On Jun 10, 2014, at 8:24 AM, David Osguthorpe wrote:
>
>> On Mon, Jun 09, 2014 at 12:53:38AM +0200, Christoph Holtermann wrote:
>>> Hello,
>>>
>>> for my python latex invoice script I tried to access the owners data. I tried
>>> to work my way to it and came across the kvp system. I made a rude
>>> path through there with a working example to access the companies data.
>>>
>>> If someone is interested in clarifying the swig qof_instance and kvp_frame
>>> stuff for python it would be nice to cooperate.
>>>
>>> My branch on github about this is
>>> https://github.com/c-holtermann/gnucash/tree/python-kvp
>>>
>> Hi
>>
>> I have been working with the python bindings but all my knowledge is from my human introspection
>> of the existing code
>>
>> I have worked on adding the budget - as you have done you add the include files to the
>> swig interface file gnucash_core.i and most objects get a base swig interface
>>
>> My analysis shows that the bindings then wrap the raw swig objects inside more pythonic classes
>> using GnuCashCoreClass as the base object
>>
>> so eg in your your case you might want to define     class KvpFrame(GnuCashCoreClass):
>>
>> you then add methods by calling the add_methods function
>>
>> eg
>>
>> KvpFrame.add_methods_with_prefix('kvp_frame_')
>>
>> where any c function that starts with the string kvp_frame_ gets added to the class
>> This does add all methods that begin with this string - the only methods you can actually
>> use in the class though are those where the C kvpframe structure is the first argument
>>
>> if methods return special objects the should use methods_return_instances
>> to add the return object type
>>
>> I have messed a little with the Kvp stuff - one problem is that it tends to return multiple
>> types which is not so easy to handle - may have to follow the GList typemap as defined
>> in base-typemaps.i
> Note that in master, KVP is converted to a private implementation detail of the class that it's attached to, and once C++ conversion gets to the KVP-using classes it will probably get pushed even further down so that it's a persistence detail, existing only in the backends.
>
> In other words, any KVP code you write will break in the next version.
>
> Regards,
> John Ralls
>
Even now i find it a bit difficult to get to the kvp layer. I tried to get to the transactions kvps
( https://github.com/c-holtermann/gnucash/commit/636631027d0f8833b3d1b7d8a8c1271ce5f8449e )
and ended up writing a function xaccTransGetFrame.

If i get the frame object I'm happy at the moment. Is it intentional that you put it private and which is
the intended way to get the kvps of an(y) object ?

regards,

Christoph Holtermann

--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

John Ralls-2

On Jun 12, 2014, at 2:17 PM, Christoph Holtermann <[hidden email]> wrote:
>>
> Even now i find it a bit difficult to get to the kvp layer. I tried to get to the transactions kvps
> ( https://github.com/c-holtermann/gnucash/commit/636631027d0f8833b3d1b7d8a8c1271ce5f8449e )
> and ended up writing a function xaccTransGetFrame.
>
> If i get the frame object I'm happy at the moment. Is it intentional that you put it private and which is
> the intended way to get the kvps of an(y) object ?

Very intentional. Having object state that’s effectively invisible to the object is an incredibly bad design and is largely to blame for the data integrity problems we’ve had with the SQL backend.

On master you can access all of the KVP data using gobject properties. Qof_instance_get() and qof_instance_set() essentially wrap g_object_get and set; in the latter case qof_instance_set also marks the object dirty. Some items also have getter and setter functions; some of those do the change in an edit/commit block, so you might find it a useful optimization to wrap multiple calls in its own edit/commit so that it’s all done at once.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Hello,

so KVPs should be accessed by objects they belong to and not from the outside.
Some questions:
* Is it legitimate to have KVP representation in Python at all or is this low-level und
should remain to the c-api ?
* The information that I'm interested in is the company data for invoices. As far as
I' ve seen there is just KVP access to that.
* It seems to me that there should be an object Company that is structured similar
to Customer and has an assigned object Address identical to Customer.
* When only the object should be able to access KVP, who is this object for the
company address ? At the moment it's book, I guess.
* I could create a python object Company and add getter functions that access the
KVPs. But it seems better to me to not introduce objects in python that do not exist
in c.
* On the other hand it can still be changed afterwards if an object is introduced in
c.

regards,

Christoph Holtermann

Am 12.06.2014 um 23:42 schrieb John Ralls:

> On Jun 12, 2014, at 2:17 PM, Christoph Holtermann <[hidden email]> wrote:
>> Even now i find it a bit difficult to get to the kvp layer. I tried to get to the transactions kvps
>> ( https://github.com/c-holtermann/gnucash/commit/636631027d0f8833b3d1b7d8a8c1271ce5f8449e )
>> and ended up writing a function xaccTransGetFrame.
>>
>> If i get the frame object I'm happy at the moment. Is it intentional that you put it private and which is
>> the intended way to get the kvps of an(y) object ?
> Very intentional. Having object state that’s effectively invisible to the object is an incredibly bad design and is largely to blame for the data integrity problems we’ve had with the SQL backend.
>
> On master you can access all of the KVP data using gobject properties. Qof_instance_get() and qof_instance_set() essentially wrap g_object_get and set; in the latter case qof_instance_set also marks the object dirty. Some items also have getter and setter functions; some of those do the change in an edit/commit block, so you might find it a useful optimization to wrap multiple calls in its own edit/commit so that it’s all done at once.
>
> Regards,
> John Ralls
>


--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Company data and KVP, was Re: Working example of kvp acess in Python

c.holtermann
Hello,

one thing I miss when creating an invoice is my bank information.
The company data doesn't have this information, does it ?

Having a look at the customer data shows that there is also no
bank account information. Wouldn't it be useful to have a preferred
bank account there, too ? Or did I miss that information ?

At least on invoices that I write I have a footline with my bank
account information.

regards,

Christoph Holtermann

Am 12.11.2014 um 18:46 schrieb Christoph Holtermann:

> Hello,
>
> so KVPs should be accessed by objects they belong to and not from the outside.
> Some questions:
> * Is it legitimate to have KVP representation in Python at all or is this low-level und
> should remain to the c-api ?
> * The information that I'm interested in is the company data for invoices. As far as
> I' ve seen there is just KVP access to that.
> * It seems to me that there should be an object Company that is structured similar
> to Customer and has an assigned object Address identical to Customer.
> * When only the object should be able to access KVP, who is this object for the
> company address ? At the moment it's book, I guess.
> * I could create a python object Company and add getter functions that access the
> KVPs. But it seems better to me to not introduce objects in python that do not exist
> in c.
> * On the other hand it can still be changed afterwards if an object is introduced in
> c.
>
> regards,
>
> Christoph Holtermann
>
> Am 12.06.2014 um 23:42 schrieb John Ralls:
>> On Jun 12, 2014, at 2:17 PM, Christoph Holtermann <[hidden email]> wrote:
>>> Even now i find it a bit difficult to get to the kvp layer. I tried to get to the transactions kvps
>>> ( https://github.com/c-holtermann/gnucash/commit/636631027d0f8833b3d1b7d8a8c1271ce5f8449e )
>>> and ended up writing a function xaccTransGetFrame.
>>>
>>> If i get the frame object I'm happy at the moment. Is it intentional that you put it private and which is
>>> the intended way to get the kvps of an(y) object ?
>> Very intentional. Having object state that’s effectively invisible to the object is an incredibly bad design and is largely to blame for the data integrity problems we’ve had with the SQL backend.
>>
>> On master you can access all of the KVP data using gobject properties. Qof_instance_get() and qof_instance_set() essentially wrap g_object_get and set; in the latter case qof_instance_set also marks the object dirty. Some items also have getter and setter functions; some of those do the change in an edit/commit block, so you might find it a useful optimization to wrap multiple calls in its own edit/commit so that it’s all done at once.
>>
>> Regards,
>> John Ralls
>>
>


--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
In reply to this post by c.holtermann
Hello,

for my part i answered some of the questions myself:

Am 12.11.2014 um 18:46 schrieb Christoph Holtermann:
> Hello,
>
> so KVPs should be accessed by objects they belong to and not from the outside.
> Some questions:
> * Is it legitimate to have KVP representation in Python at all or is this low-level und
> should remain to the c-api ?
It is legitimate but use should be restricted. Maybe warning docs or putting them in a submodule
called low_level.

> * The information that I'm interested in is the company data for invoices. As far as
> I' ve seen there is just KVP access to that.
> * It seems to me that there should be an object Company that is structured similar
> to Customer and has an assigned object Address identical to Customer.
> * When only the object should be able to access KVP, who is this object for the
> company address ? At the moment it's book, I guess.
> * I could create a python object Company and add getter functions that access the
> KVPs. But it seems better to me to not introduce objects in python that do not exist
> in c.
> * On the other hand it can still be changed afterwards if an object is introduced in
> c.
I decide to create an object Company.
https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/gncCompany.py

This I can easily be put to jinja in my invoice_export script.
I'm quite happy to be able to submit all the information by this simple call:
output = template.render(invoice=invoice, locale=locale, company=Company(book))

I posted a pull request for the jinja2 approach. The inclusion of access to the Company
data remains head of my development fork:
https://github.com/c-holtermann/gnucash

Maybe you can have a look and it and we can come to an agreement if the Company
and KVP approach is adequate or how it can be improved.

Further steps would be a closer integration into the GUI.

regards,

Christoph Holtermann

>
> regards,
>
> Christoph Holtermann
>
> Am 12.06.2014 um 23:42 schrieb John Ralls:
>> On Jun 12, 2014, at 2:17 PM, Christoph Holtermann <[hidden email]> wrote:
>>> Even now i find it a bit difficult to get to the kvp layer. I tried to get to the transactions kvps
>>> ( https://github.com/c-holtermann/gnucash/commit/636631027d0f8833b3d1b7d8a8c1271ce5f8449e )
>>> and ended up writing a function xaccTransGetFrame.
>>>
>>> If i get the frame object I'm happy at the moment. Is it intentional that you put it private and which is
>>> the intended way to get the kvps of an(y) object ?
>> Very intentional. Having object state that’s effectively invisible to the object is an incredibly bad design and is largely to blame for the data integrity problems we’ve had with the SQL backend.
>>
>> On master you can access all of the KVP data using gobject properties. Qof_instance_get() and qof_instance_set() essentially wrap g_object_get and set; in the latter case qof_instance_set also marks the object dirty. Some items also have getter and setter functions; some of those do the change in an edit/commit block, so you might find it a useful optimization to wrap multiple calls in its own edit/commit so that it’s all done at once.
>>
>> Regards,
>> John Ralls
>>
>


--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

John Ralls-2

> On Nov 12, 2014, at 3:56 PM, Christoph Holtermann <[hidden email]> wrote:
>
> Hello,
>
> for my part i answered some of the questions myself:
>
> Am 12.11.2014 um 18:46 schrieb Christoph Holtermann:
>> Hello,
>>
>> so KVPs should be accessed by objects they belong to and not from the outside.
>> Some questions:
>> * Is it legitimate to have KVP representation in Python at all or is this low-level und
>> should remain to the c-api ?
> It is legitimate but use should be restricted. Maybe warning docs or putting them in a submodule
> called low_level.

In 2.6 and before KVP is part of the public API and is accessed directly from all over the program. If you're working with 2.6 you have no alternative to using KVP directly if you need access to some items stored there because the classes that the KVP is associated with have no code that manipulates those KVP items.

In master, KVP is a private implementation detail. The KVP accesses outside of src/engine have been assigned GObject Properties on their associated objects and should be accessed that way (except for one: I discovered a KVP access done in Scheme that had escaped my notice and which is still on the loose). Since the API is going to change rather a lot as we convert to C++ you probably want to ignore all of that and stick with the 2.6 API until we start the 2.7 releases.

>> * The information that I'm interested in is the company data for invoices. As far as
>> I' ve seen there is just KVP access to that.
>> * It seems to me that there should be an object Company that is structured similar
>> to Customer and has an assigned object Address identical to Customer.
>> * When only the object should be able to access KVP, who is this object for the
>> company address ? At the moment it's book, I guess.
>> * I could create a python object Company and add getter functions that access the
>> KVPs. But it seems better to me to not introduce objects in python that do not exist
>> in c.
>> * On the other hand it can still be changed afterwards if an object is introduced in
>> c.
> I decide to create an object Company.
> https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/gncCompany.py
>
> This I can easily be put to jinja in my invoice_export script.
> I'm quite happy to be able to submit all the information by this simple call:
> output = template.render(invoice=invoice, locale=locale, company=Company(book))
>
> I posted a pull request for the jinja2 approach. The inclusion of access to the Company
> data remains head of my development fork:
> https://github.com/c-holtermann/gnucash
>
> Maybe you can have a look and it and we can come to an agreement if the Company
> and KVP approach is adequate or how it can be improved.
>
> Further steps would be a closer integration into the GUI.

To date our policy on the Python bindings is that they're for users to query the GC database for their own use. We're don't accept Python extensions of GnuCash into GnuCash itself and have no intention or interest in adding Python interpreters to the Mac and Windows AIO bundles. I don't see any reason to change that policy. I haven't yet looked at your pull request, but if it conflicts with that policy you can do me a favor and withdraw it.

My intention for KVP is to make it a backend implementation detail for storage only and completely invisible to the rest of the program. There are quite a few chunks of KVP that don't fit very well with the objects they're currently associated with. I expect that in the course of the C++ rewrite we'll be creating new classes to deal with them. Company data is one of those, the import account matching data is another, and there are more that don't come immediately to mind.

Regards,
John Ralls




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Hello,

Am 13.11.2014 um 03:05 schrieb John Ralls:

>> On Nov 12, 2014, at 3:56 PM, Christoph Holtermann <[hidden email]> wrote:
>>
>> Hello,
>>
>> for my part i answered some of the questions myself:
>>
>> Am 12.11.2014 um 18:46 schrieb Christoph Holtermann:
>>> Hello,
>>>
>>> so KVPs should be accessed by objects they belong to and not from the outside.
>>> Some questions:
>>> * Is it legitimate to have KVP representation in Python at all or is this low-level und
>>> should remain to the c-api ?
>> It is legitimate but use should be restricted. Maybe warning docs or putting them in a submodule
>> called low_level.
> In 2.6 and before KVP is part of the public API and is accessed directly from all over the program. If you're working with 2.6 you have no alternative to using KVP directly if you need access to some items stored there because the classes that the KVP is associated with have no code that manipulates those KVP items.
>
> In master, KVP is a private implementation detail. The KVP accesses outside of src/engine have been assigned GObject Properties on their associated objects and should be accessed that way (except for one: I discovered a KVP access done in Scheme that had escaped my notice and which is still on the loose). Since the API is going to change rather a lot as we convert to C++ you probably want to ignore all of that and stick with the 2.6 API until we start the 2.7 releases.
>
>>> * The information that I'm interested in is the company data for invoices. As far as
>>> I' ve seen there is just KVP access to that.
>>> * It seems to me that there should be an object Company that is structured similar
>>> to Customer and has an assigned object Address identical to Customer.
>>> * When only the object should be able to access KVP, who is this object for the
>>> company address ? At the moment it's book, I guess.
>>> * I could create a python object Company and add getter functions that access the
>>> KVPs. But it seems better to me to not introduce objects in python that do not exist
>>> in c.
>>> * On the other hand it can still be changed afterwards if an object is introduced in
>>> c.
>> I decide to create an object Company.
>> https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/gncCompany.py
>>
>> This I can easily be put to jinja in my invoice_export script.
>> I'm quite happy to be able to submit all the information by this simple call:
>> output = template.render(invoice=invoice, locale=locale, company=Company(book))
>>
>> I posted a pull request for the jinja2 approach. The inclusion of access to the Company
>> data remains head of my development fork:
>> https://github.com/c-holtermann/gnucash
>>
>> Maybe you can have a look and it and we can come to an agreement if the Company
>> and KVP approach is adequate or how it can be improved.
>>
>> Further steps would be a closer integration into the GUI.
> To date our policy on the Python bindings is that they're for users to query the GC database for their own use. We're don't accept Python extensions of GnuCash into GnuCash itself and have no intention or interest in adding Python interpreters to the Mac and Windows AIO bundles. I don't see any reason to change that policy. I haven't yet looked at your pull request, but if it conflicts with that policy you can do me a favor and withdraw it.
No. It's clean outside GnuCash's GUI. So no policy violation here ;-)
It's just some additions to the already existing script to export invoices to LaTeX using templating engine jinja2.
So I think there should be no problem with this.

The 2nd pull request will be to access the Company data for which KVP access is necessary at the moment.
>
> My intention for KVP is to make it a backend implementation detail for storage only and completely invisible to the rest of the program. There are quite a few chunks of KVP that don't fit very well with the objects they're currently associated with. I expect that in the course of the C++ rewrite we'll be creating new classes to deal with them. Company data is one of those, the import account matching data is another, and there are more that don't come immediately to mind.
I'll put these bits of information into the documentation of the KVP access. Especially the thing about the API to change in 2.7.
>
> Regards,
> John Ralls
>
>
>
regards,

Christoph Holtermann

--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

Christian Stimming-4
In reply to this post by c.holtermann
From my understanding, there are two separate issues here:

1. You are proposing a new object "Company" because you have reasons for needing new data fields. I think that's a good idea. Why don't you prepare a patch to extend the existing objects?

2. You ask for kvp access from python. No, we prefer not to have kvp accessed from python. Instead, either use gobject properties (on master), or add a new object on the C side as mentioned above and add python wrappers for this.

Regards, Christian
--
Sent from mobile.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Am 13.11.2014 um 17:50 schrieb Christian Stimming (mobil):
> From my understanding, there are two separate issues here:
>
> 1. You are proposing a new object "Company" because you have reasons for needing new data fields. I think that's a good idea. Why don't you prepare a patch to extend the existing objects?
>
> 2. You ask for kvp access from python. No, we prefer not to have kvp accessed from python. Instead, either use gobject properties (on master), or add a new object on the C side as mentioned above and add python wrappers for this.
Surely adding an object on the C side would be the more robust approach. Can you tell me an object that already exists
and that could be taken as an example ?

I don't really understand the gobject concept though and what the difference to my approach is.

It seems some work until we have something we're all happy with, though ;-)
>
> Regards, Christian
> --
> Sent from mobile.
regards,

Christoph

--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Am 13.11.2014 um 18:55 schrieb Christoph Holtermann:
> Am 13.11.2014 um 17:50 schrieb Christian Stimming (mobil):
>> From my understanding, there are two separate issues here:
>>
>> 1. You are proposing a new object "Company" because you have reasons for needing new data fields. I think that's a good idea. Why don't you prepare a patch to extend the existing objects?
>>
>> 2. You ask for kvp access from python. No, we prefer not to have kvp accessed from python. Instead, either use gobject properties (on master), or add a new object on the C side as mentioned above and add python wrappers for this.
> Surely adding an object on the C side would be the more robust approach. Can you tell me an object that already exists
> and that could be taken as an example ?
I'll try gncAddress as a start.

>
> I don't really understand the gobject concept though and what the difference to my approach is.
>
> It seems some work until we have something we're all happy with, though ;-)
>> Regards, Christian
>> --
>> Sent from mobile.
> regards,
>
> Christoph
>


--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

John Ralls-2

On Nov 13, 2014, at 10:46 AM, Christoph Holtermann <[hidden email]> wrote:

> Am 13.11.2014 um 18:55 schrieb Christoph Holtermann:
>> Am 13.11.2014 um 17:50 schrieb Christian Stimming (mobil):
>>> From my understanding, there are two separate issues here:
>>>
>>> 1. You are proposing a new object "Company" because you have reasons for needing new data fields. I think that's a good idea. Why don't you prepare a patch to extend the existing objects?
>>>
>>> 2. You ask for kvp access from python. No, we prefer not to have kvp accessed from python. Instead, either use gobject properties (on master), or add a new object on the C side as mentioned above and add python wrappers for this.
>> Surely adding an object on the C side would be the more robust approach. Can you tell me an object that already exists
>> and that could be taken as an example ?
> I'll try gncAddress as a start.
>>
>> I don't really understand the gobject concept though and what the difference to my approach is.
>>
>> It seems some work until we have something we're all happy with, though ;-)

You needn't worry about GObject. We’re replacing it with C++, but we’re just starting out and it will be several months at least before we’re ready to start on the engine objects. If you must dive in now, sure, GncAddress should be a pretty good starting point, but I suggest reading up a bit on GObject [1] so that you have some understanding of what you’re doing. In particular, the memory management parts of almost all of the GObject-based classes in engine, including GncAddress, are implemented incorrectly. Make sure that you understand the right way to create and in particular destroy (the functions for the latter are dispose and finalize) your object and to use reference counting correctly to manage object lifetime.

Your Company class implements only getters, which for your report-writing code is all that you need. The corresponding C/C++ class will need setters as well. In the current implementation where it writes to the QofBook KVP, that would be all.

Regards,
John Ralls

[1] https://developer.gnome.org/gobject/stable/
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Working example of kvp acess in Python

c.holtermann
Hello,

Am 13.11.2014 um 19:56 schrieb John Ralls:

> On Nov 13, 2014, at 10:46 AM, Christoph Holtermann <[hidden email]> wrote:
>
>> Am 13.11.2014 um 18:55 schrieb Christoph Holtermann:
>>> Am 13.11.2014 um 17:50 schrieb Christian Stimming (mobil):
>>>> From my understanding, there are two separate issues here:
>>>>
>>>> 1. You are proposing a new object "Company" because you have reasons for needing new data fields. I think that's a good idea. Why don't you prepare a patch to extend the existing objects?
>>>>
>>>> 2. You ask for kvp access from python. No, we prefer not to have kvp accessed from python. Instead, either use gobject properties (on master), or add a new object on the C side as mentioned above and add python wrappers for this.
>>> Surely adding an object on the C side would be the more robust approach. Can you tell me an object that already exists
>>> and that could be taken as an example ?
>> I'll try gncAddress as a start.
>>> I don't really understand the gobject concept though and what the difference to my approach is.
>>>
>>> It seems some work until we have something we're all happy with, though ;-)
> You needn't worry about GObject. We’re replacing it with C++, but we’re just starting out and it will be several months at least before we’re ready to start on the engine objects. If you must dive in now, sure, GncAddress should be a pretty good starting point, but I suggest reading up a bit on GObject [1] so that you have some understanding of what you’re doing. In particular, the memory management parts of almost all of the GObject-based classes in engine, including GncAddress, are implemented incorrectly. Make sure that you understand the right way to create and in particular destroy (the functions for the latter are dispose and finalize) your object and to use reference counting correctly to manage object lifetime.
Having not yet looked at the GObject finetuning I wrote a gncCompany.c by modifying gncAddress.
It gets and sets the Companies information and can be accessed from Python.
First running version at https://github.com/c-holtermann/gnucash/compare/Company
Now I'll have to have the look at things that you suggested.

Maybe a dumb question, but anyway: Does the Company object need to store strings internally like Address does or can
the kvps be directly modified ? So do I need to have company->name etc. ?
>  
>
> Your Company class implements only getters, which for your report-writing code is all that you need. The corresponding C/C++ class will need setters as well. In the current implementation where it writes to the QofBook KVP, that would be all.
>
> Regards,
> John Ralls
>
> [1] https://developer.gnome.org/gobject/stable/

regards,

Christoph Holtermann

--
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel