[devel] Re: Criawips gconf support

[Sven Herzberg]

Hi Adrien,

  please write emails like this to the mailing list.

Regards,
  Sven

Am Mo, den 18.10.2004 schrieb Adrien Beaucreux um 0:12:
> I did my homework this week-end, about cleaning the GConf code in
> criawips:
> 
> What we actually want, is all the GConf-related code to be contained in
> the application. The concerned data are mainly the preferences
> (default_font), but also the ui-related values (slide_list_width).
> 
> For each of these data, there should be adequate geters/seters that will
> call (or not) our GConfClient, and some related code.
> 
> If I got it right the steps to achieve this should be:
> 
> 1. Create a PangoFontDescription as a property of CriaApplication.
>       - Declare it in the _CriaApplicationPriv struct.
>       - Add PROP_DEFAULT_FONT to the properties enumeration.
>       - Install the property during the class init.
>       - Initialize it in the instance init.

Correct.

> 2. Create the related geters/seters.
> - PangoFontDescription* cria_application_get_default_font_description():
> to be used by the rendering (?) code.
> 
> - void cria_application_set_default_font_description():
> I'm not sure you'll use this one. See if we need it.
> 
> - gchar* cria_application_get_default_font_name():
> to be able to initialize the PreferencesDialog font button and other
> informative ends.
> 
> - void cria_application_set_default_font_name():
> used by the PreferencesDialog to set the new font. Acts on GConf as well
> as on the default_font property.
> 
> - Modify cria_application_[get,set(?)]_property() to take the property
> into account. The get calls [...]_get_default_font_description()

  Yes, but please only implement methods that we'll be using. So if we
don't know whether we need a method in the future we just don't
implement it yet, maybe we should start a list containing mehtods that
we're unsure about.

> 3. Set CriaApplication to be notified of configuration changes.
>       - create notify_default_font_changed(), which modifies the property.

  Yep.

> 4. Set up a signal system of our own, that will be listened to by  
> the concerned parties (slide renderer, preferences dialog, ...).
> 
> The signal for "default_font_changed" should be emitted during the
> notify_default_font_changed().
> 
> I'm not sure about this signal story, but it sounds good. How it
> actually works is still unclear to me.

  I'm currently implementing some signal stuff on the Presentation and
the Slide classes to be able to notify the SlideListProxy of
presentation changes, which will be neccessary for proper updates of the
side bar.

> 5. Set up the concerned classes to manage these messages.
> 
> 6. Have a beer for a well done job ;)

  So we should meet on LWE next week and have a beer for that :)

> This process should of course be repeated for each preference we add.
> 
> Now the question : Where did I missed/blew something ?
> 
> That was the first part. Second thing is if we have the gconf client as
> a property, we must initialize it in the instance init, no problem.
> 
> To be clean, we should also clean it. This cleanup should be in a
> destructor. It works good without it, but I'd like to have clean code
> with no loose ends.
> 
> My problem is then : I have found about the class finalizer, the base
> finalizer. But there seem to be no _instance_ finalizer. I've seen on
> http://s1x.homelinux.net/documents/gtk/gobject-faq.html that there are
> finalizer, but they do not connect it anywhere. 

  They do:
G_OBJECT_CLASS(klass)->finalize=(GObjectFinalizeFunc)nature_human_finalize;

> There is another possibility, or so I was told on IRC, which is to get
> the GConfClient each time we need it, and free it after use. Would the
> notifiers still work in that case, I haven't tried yet. The execution
> speed would then be impacted.
> 
> I'm not sure which solution is the best in our case. If you have an
> advice, I would appreciate to know it.

  Well, if we don't have a GConfClient to listen to change signals, we
cannot update on changes one did via gconftool or the gconf editor. So
we should keep the single client.

Regards,
  Sven