After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 164059 - wrapping for GConfEngine
wrapping for GConfEngine
Status: RESOLVED FIXED
Product: gnome-python
Classification: Deprecated
Component: gconf
CVS HEAD
Other Linux
: High normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2005-01-14 10:10 UTC by Mark McLoughlin
Modified: 2005-01-17 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GConfEngine wrapping (8.74 KB, patch)
2005-01-14 10:11 UTC, Mark McLoughlin 		none Details | Review
patch with changes (9.45 KB, patch)
2005-01-14 16:06 UTC, Mark McLoughlin 		none Details | Review

Description Mark McLoughlin 2005-01-14 10:10:33 UTC 
Attaching patch which:

 1. Wraps GConfEngine
 2. Removes some GConf internals from gconf.defs - they're wrapped
    be header guards in the GConf headers
Comment 1 Mark McLoughlin 2005-01-14 10:11:07 UTC 
Created attachment 36003 [details] [review]
GConfEngine wrapping
Comment 2 Gustavo Carneiro 2005-01-14 11:22:39 UTC 
Why would we need GConfEngine since we have GConfClient?  I always thought
GConfEngine vs GConfClient only existed from the times when Havoc wanted
non-GNOME programs to use GConf, and so he designed the library in two parts,
one pure CORBA/ORBit part, and layered on top of that a GObject based API.
Unless I'm missing something...
Comment 3 Mark McLoughlin 2005-01-14 12:43:28 UTC 
Basically, if you want (which I do) a GConfClient for a specific data source you
have to do

  engine = gconf.engine_get_for_address ("xml:readwrite:/tmp/foo")
  client = gconf.client_get_for_engine (engine)

Yeah, I know that sucks - there should just be a gconf_client_get_for_address()
in GConf.
Comment 4 Gustavo Carneiro 2005-01-14 13:44:18 UTC 
Then why not just push such API to GConf and then wrap it in python?

In any case, gnome-python is proposed for GNOME Bindings, so we have to obey the
API/feature freeze currently in effect.
Comment 5 Johan (not receiving bugmail) Dahlin 2005-01-14 13:53:45 UTC 
But it can (and should IMHO) go into the next release of gnome-python. 

An alternative is to ask (murray or the release team) to add this if it's
critical to any applications. Freezes are there to be broken!
Comment 6 Mark McLoughlin 2005-01-14 14:00:06 UTC 
Right, if you guys think the patch is okay - we can ask the release-team for
approval. Since its only a few days beyond the API freeze, there shouldn't be a
problem.
Comment 7 Gustavo Carneiro 2005-01-14 14:14:36 UTC 
Fine by me, I just don't like breaking the rules, but if we get permission...

Regarding the patch, I can spot some minor things I don't like so much:
  1. _pygconf_ prefix instead of pygconf_; I don't see why we need the leading
underscore;
  2. About _pygconf_register_engine_type, it seems it is never called anywhere,
and it's just a couple of lines that we might as well put them in the module
initialization function

I guess that's all.  I didn't try compiling it, though..
Comment 8 Mark McLoughlin 2005-01-14 16:06:16 UTC 
Created attachment 36016 [details] [review]
patch with changes

Okay, fixed up. I'll mail the release-team and cc pygtk list
Comment 9 Gustavo Carneiro 2005-01-14 17:05:07 UTC 
When you get approval, please do commit.  Then I'll try to make a release tonight...
Comment 10 Mark McLoughlin 2005-01-14 18:09:45 UTC 
Okay, I'm probably going to be without internet access until Sunday, so feel
free to go ahead yourself if the release team approves.

Thanks much for the quick response to all this ...
Comment 11 Mark McLoughlin 2005-01-17 10:28:57 UTC 
Committed to HEAD. Thanks much for all your help, guys