8:24 a.m.
Old KDE config info continues to cause problems:
1) chromium-browser simply wouldn't work for me (as discussed on another
thread). The spinner span and browser said "Connecting ..." and nothing
ever happened.
2) I can't switch user sessions from my normal login. I get a grey
pop-up box with no message or selection list. The only thing I can so is
close it.
When I log in as a test user (also in KDE), both of these work
immediately with no issues. Clearly the problem is old config files, but
which ones? How is the user supposed to know?
This kind of thing has been a problem with KDE since I've been using it
-- many years now -- but it doesn't seem to happen with other desktops
such as Gnome (or am I being naive?).
We clearly need a way of dealing with this. I guess transparent updating
is a lot to ask, but at least detecting obsolete config files and
warning the user should be a high priority for future KDE releases.
Would it be too hard for each config file to include a comment line at
the beginning with the version of whatever KDE component created it, and
new versions of that component to check the line for compatibility?
poc
8:42 p.m.
Patrick O'Callaghan wrote:
We clearly need a way of dealing with this. I guess transparent
updating
is a lot to ask, but at least detecting obsolete config files and
warning the user should be a high priority for future KDE releases.
Would it be too hard for each config file to include a comment line at
the beginning with the version of whatever KDE component created it, and
new versions of that component to check the line for compatibility?
Well, in principle that's what kconf_update is for, but due to various
limitations:
1. Several KDE apps will keep settings in memory and write them out if
closed, not reloading changes made to the config file in the meantime. This
breaks if kconf_update runs while the application is running. (This is
particularly annoying with Plasma config files, kconf_update is basically
useless for those.)
2. Not all known configuration file changes have corresponding kconf_update
scripts.
3. Not all issues caused by old configuration files are known. Sometimes a
setting which used to be valid isn't anymore for whatever reason and this is
often very much non-obvious.
this doesn't always help.
For 1., either kconf_update or KConfig or both need fixing (I'd fix this in
KConfig by writing any changes to disk automatically and by setting a
KDirWatch on the config file to reload on-disk changes automatically, but at
least Aaron Seigo clearly expressed his dislike for that solution and
suggests having kconf_update talk to running applications over D-Bus
instead), for 2., upstream developers need to do a better job of adding
kconf_update scripts if they change the format of their configuration files
(but ideally they should just not change it!), 3. is the biggest problem (as
sometimes even the upstream developer of the application isn't aware of the
issue nor its cause).
Kevin Kofler
8:21 a.m.
On Fri, 2009-11-13 at 03:42 +0100, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
> We clearly need a way of dealing with this. I guess transparent updating
> is a lot to ask, but at least detecting obsolete config files and
> warning the user should be a high priority for future KDE releases.
> Would it be too hard for each config file to include a comment line at
> the beginning with the version of whatever KDE component created it, and
> new versions of that component to check the line for compatibility?
Well, in principle that's what kconf_update is for, but due to various
limitations:
1. Several KDE apps will keep settings in memory and write them out if
closed, not reloading changes made to the config file in the meantime. This
breaks if kconf_update runs while the application is running. (This is
particularly annoying with Plasma config files, kconf_update is basically
useless for those.)
2. Not all known configuration file changes have corresponding kconf_update
scripts.
3. Not all issues caused by old configuration files are known. Sometimes a
setting which used to be valid isn't anymore for whatever reason and this is
often very much non-obvious.
this doesn't always help.
For 1., either kconf_update or KConfig or both need fixing (I'd fix this in
KConfig by writing any changes to disk automatically and by setting a
KDirWatch on the config file to reload on-disk changes automatically, but at
least Aaron Seigo clearly expressed his dislike for that solution and
suggests having kconf_update talk to running applications over D-Bus
instead),
Maybe it doesn't need to get that complicated. I see this part of the
problem as a race condition between the update process and the running
component. If the running component wants to write to the config file it
should simply notice that it has changed since the component last read
it and either abort the write or ask the user what to do (I'd be more in
favour of aborting and telling the user why).
for 2., upstream developers need to do a better job of adding
kconf_update scripts if they change the format of their configuration files
(but ideally they should just not change it!), 3. is the biggest problem (as
sometimes even the upstream developer of the application isn't aware of the
issue nor its cause).
I understand that, but I ask again: "why does Gnome not seem to have
this problem?"
poc
12:24 p.m.
Patrick O'Callaghan wrote:
Maybe it doesn't need to get that complicated. I see this part of
the
problem as a race condition between the update process and the running
component. If the running component wants to write to the config file it
should simply notice that it has changed since the component last read
it and either abort the write or ask the user what to do (I'd be more in
favour of aborting and telling the user why).
That's no good, applications prompting for config file stuff when the user
just wants them to go away (i.e. when they're being closed, which is when
the issue usually comes up) is bad, and it also won't work if you're
shutting down the entire system.
Kevin Kofler
2:22 p.m.
On Fri, 2009-11-13 at 19:24 +0100, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
> Maybe it doesn't need to get that complicated. I see this part of the
> problem as a race condition between the update process and the running
> component. If the running component wants to write to the config file it
> should simply notice that it has changed since the component last read
> it and either abort the write or ask the user what to do (I'd be more in
> favour of aborting and telling the user why).
That's no good, applications prompting for config file stuff when the user
just wants them to go away (i.e. when they're being closed, which is when
the issue usually comes up) is bad, and it also won't work if you're
shutting down the entire system.
In that case I'd vote for the lesser of two evils: components shouldn't
overwrite an updated config file.
poc
6:51 a.m.
Kevin Kofler wrote:
Patrick O'Callaghan wrote:
> We clearly need a way of dealing with this. I guess transparent updating
> is a lot to ask, but at least detecting obsolete config files and
> warning the user should be a high priority for future KDE releases.
> Would it be too hard for each config file to include a comment line at
> the beginning with the version of whatever KDE component created it, and
> new versions of that component to check the line for compatibility?
Well, in principle that's what kconf_update is for, but due to various
limitations:
1. Several KDE apps will keep settings in memory and write them out if
closed, not reloading changes made to the config file in the meantime.
This breaks if kconf_update runs while the application is running. (This
is particularly annoying with Plasma config files, kconf_update is
basically useless for those.)
2. Not all known configuration file changes have corresponding
kconf_update scripts.
3. Not all issues caused by old configuration files are known. Sometimes a
setting which used to be valid isn't anymore for whatever reason and this
is often very much non-obvious.
this doesn't always help.
For 1., either kconf_update or KConfig or both need fixing (I'd fix this
in KConfig by writing any changes to disk automatically and by setting a
KDirWatch on the config file to reload on-disk changes automatically, but
at least Aaron Seigo clearly expressed his dislike for that solution and
suggests having kconf_update talk to running applications over D-Bus
instead), for 2., upstream developers need to do a better job of adding
kconf_update scripts if they change the format of their configuration
files (but ideally they should just not change it!), 3. is the biggest
problem (as sometimes even the upstream developer of the application isn't
aware of the issue nor its cause).
Kevin Kofler
If a setting in a conf file is invalid, there should be an error message
logged. This is IMO the biggest issue with kde debugging. Where is a
decent log file? There is ~/.xsession-errors, but it's almost useless. It
doesn't include 1) name of app logging message 2) time
7:40 a.m.
On Sat, 2009-11-14 at 07:51 -0500, Neal Becker wrote:
If a setting in a conf file is invalid, there should be an error
message logged. This is IMO the biggest issue with kde debugging.
Very true, though I don't know if some errors can arise from a change of
interpretation of a config entry, i.e. it's not "invalid", it just means
something subtly different. In any case, version info in the config file
would help.
poc
5271
days inactive
5273
days old
6 comments
3 participants
participants (3)
-
Kevin Kofler -
Neal Becker -
Patrick O'Callaghan