On 11/17/2015 11:40 AM, Avaneendra Alugupalli wrote:
> hi Cole
> Thanks for the response.
>>
>
>>The functions that add/remove/list the URIs in config.py are add_conn,
>> remove_conn, list_conn_uris respectively. They are called from engine.py
>
> From the code in virt-manager.py main handler, I find that the
> config object is getting created before the engine object?. Is that for the first
> time when I run the virt-manager app. config sees default values of connections/
> uris to none [] and then engine creates them. And even if the app is exited
> we still have non default values ("qemu:///sysmtem" and "lxc://") in the dconf?.
> perhaps not delete those values from dconf?.
>
Sorry, I'm not really following what you are saying. Can you describe the
problem you are hitting, step by step, and exactly what you are trying to
determine?
Also, take a look at dconf-editor, it's a UI tool for exploring dconf values.
Might explain what you are seeing.
- Cole
>
> On Mon, Nov 16, 2015 at 8:09 PM, Cole Robinson <crobinso@xxxxxxxxxx
> <mailto:crobinso@xxxxxxxxxx>> wrote:
>
> On 11/16/2015 02:17 PM, Avaneendra Alugupalli wrote:
> > hi
> > I am trying to understand the code for virt-manager and found that during the
> > config object create, gets the connections / uris using the Gsettings API. and
> > these are the entries in dconf database.
> >
> > forchild inself._settings.list_children():
> > childschema =self._root +"."+child
> > self._settingsmap[child] =Gio.Settings.new(childschema)
> >
> >
> > returns connections/uris as "qemu:///system" and "lxc:///". From the
> >
> > I can see that data
> >
> <https://github.com/virt-manager/virt-manager/tree/master/data>/org.virt-manager.virt-manager.gschema.xml
> > makes
> > default entry for these fields. How ever am unable to track who is updating
> > the connections/uris to "qemu:///system" and "lxc:///" strings.
>
> The functions that add/remove/list the URIs in config.py are add_conn,
> remove_conn, list_conn_uris respectively. They are called from engine.py
>
> > Also is there any architecture/ design document to understand the code at very
> > higher
> > level?.
>
> No unfortunately :/
>
> - Cole
>
>
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
