Fixing 49564 - dependency/BC problem?

Ravikiran Rajagopal ravi at
Sun Mar 9 01:39:14 GMT 2003

Hash: SHA1

On Saturday 08 March 2003 08:27 pm, George Staikos wrote:
> There is a virtual_hook there that you can use to add a virtual function
> without breaking BC.

The problem still exists. Suppose I do add a function (is there a Howto?). 
Then, _all_ apps need to check for the return value. I like this, but could 
we help older binaries somehow? I think not (without using #4, and adding 
some option in kdeglobals which says whether we are allowed to do it), but I 
am hoping that the collective brains trust can figure out some blessed 
approach :-)


> On Saturday 08 March 2003 19:55, Ravikiran Rajagopal wrote:
> > Hello,
> >   KConfigBackEnd::sync() returns nothing, and hence fails silently when
> > the user's local config file is not writable. As I understand it, we
> > cannot have kdecore dependent on kdeui. So we cannot use a UI element to
> > make the user aware of the situation.
> >   The only alternatives I can think of:
> >
> > 1. Add a sync() function which indicates success or failure - not
> > possible to due to BC issues as sync() is virtual. Don't know whether
> > changing a return type is BC though.
> >
> > 2. Emit a signal saying it failed, and let the app take care of it. Does
> > not help existing binaries, and _all_ apps need to be ported.
> >
> > 3. Add a function canWeSaveConfig(). This has the same problem as #2.
> >
> > 4. If the user's local config file is not writable, try to make it
> > writable. Very invasive, and I don't like it.
> >
> > Should I mark this bug as WONTFIX due to BC issues? If we do make a
> > change and #1 is ruled out, my inclination would be for #4. Why would
> > someone outside of the kiosk mode make use of read-only config files?
> >
> > Ravi
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list