GNOME Bugzilla – Bug 540050
Make it gconf proof...
Last modified: 2008-12-15 20:35:30 UTC
Hello, Maybe it is just getting on my nerves and it's too late to be really constructive, but i've seen too many problem with gconf lately. Let's list them: 1- gconf test-age key got a wrong value. This is a classic. I saw it myself many times. I propose a button to just whippe the actual configuration in gconf out and install a default one. Something like that window: |----------------------------- |gconf test-age has bad value | | |Cancel| |Reset the conf| |----------------------------- 2- Codecs are disabled: People report Ekiga with no sound, in fact it is just the audio codecs are *all* disabled. Solution: provide feedback in the GUI: Either something in the status bar if there is no codecs selected for audio or video, or something more user friendlyt when you place a call, e.g.: "No audio codecs available - H261" "SPEEX - No video codec available" "Error no codecs available (audio or video)" 3- Codecs in the wrong place: At least 2 times people reported to me: audio codecs are in the video codec place in the conf window. 4- Audio device set to NULL/NULL/NULL Solution: either feedback in the GUI, either give some tips in the pref window: "If you don't know what to select, choose "PTLIB/ALSA/Default" (well i know this is temporary, but this details are stuff people get into when they try to test the software...) Best regards, Yannick
*** Bug 540046 has been marked as a duplicate of this bug. ***
The problem with your idea, Yannick... is that the gconf_test_age test proves that we don't have a correct configuration available! So if we don't have it, we can't reset to it, can we?
I'm aware of 2 cases which pop up this error about gconf_test_age: 1- There is a new and right configuration installed, but as the gconf daemon has not been restarted it probably cache the old version somewhere, thus lead to the error. Restarting gconf daemon fix this case. 2- There is an old configuration but a newer ekiga has been installed, nor restarting gconf or relaunching Ekiga will fix this. There is 2 views on this issue: - it is ekiga reponsibility to deal with it. - it is the maintener of the distro packages to deal with it. I think it is ekiga responsibility (I admit being a not good maintener at the moment). Mainly because: as it is ekiga which test this value, i think it will be better to handle this into ekiga, or we will need to coordinate our dev team and the mainteners on this issue. My idea is simple: This error only show when you try ekiga for the first time. Thus you can safely reset the config to default (new install). This follow the user requesting starting *this* version of the application. The algorithm might be something like this: If gconf_test_age error then Tell the user there is an error: the actual pop up with 2 buttons: * Ask the user to erase the old configuration (erase all keys concerning ekiga in gconf, i.e. all keys under this tree in gconf "/apps/ekiga/" This default label is probably configured at compile time I guess, maybe there is a way to retrieve the right label if it has been changed without hard coding it... Then reinstall a set of default keys, then restart the gconf deamon and finally restart ekiga) * Ask the user to leave it as it is -> close ekiga. Best regards, Yannick
We can't reset to default if we don't have the default!
I do not understand. From where it come in the first place?
The config comes from gconf... so if we see that the configuration which comes in doesn't correspond to the version we expected, then we cry...
Can someone explain (write a small algorithm) what happens wrt config when ekiga is reinstalled? I was told each time that test_age proves that the gconf config is erroneous. But what really happens? How does it realise that the config is erroneous? Do the key names change? Do their default values change? In fact, the config does not change every day, isn't it? So the config is the same for maybe one month, and during this month no test_age error should appear.
The age is embedded both in the gconf configuration file and the executable. This means that when an executable compiled with an age of 14 sees a configuration with age of 12, then something is wrong.
But who puts 12 in the configuration (while right after ekiga reinstallation it was 14, because ekiga worked)?
sorry: s/after/before/
The test age is set in configure.ac, which then puts it in both the code and the config file, so they always match. That is, if installation is correct, they'll match. If the installation is incorrect, they don't match and we detect.
In comment #8 you say that age might be different in executable and config. I suppose it's the line 5230 dsandras SCHEMA_AGE=61 in configure.ac. age 61 was last modified (svn annotate configure.ac) at revision 5230, which was done (svn log -r 5230) at r5230 | dsandras | 2007-07-07 15:49:39 +0200 (Sat, 07 Jul 2007) | 9 lines So the age has not been changed since one year ago. How does it happen that it is changed now? Do you think that gconf modifies it by error? Or do you think that it disappears? I remember a few months ago that the problem in my case came from the fact that test_age cannot be read (didn't exist it seems), see http://mail.gnome.org/archives/ekiga-devel-list/2008-April/msg00122.html Finally, what config file is the age stored in?
You mean which compile-time config? The schema file (which is pumped into GConf on installation time) and the configure.in file (to be available as macro to compile into the application). J.
We should now be GCONF-proof.