Fixing 49564 - dependency/BC problem?

Ravikiran Rajagopal ravi at
Sun Mar 9 23:58:55 GMT 2003

Hash: SHA1

On Saturday 08 March 2003 08:31 pm, Waldo Bastian wrote:

> kconfig could emit a signal that was caught by kapplication. kapplication
> then needs to show a dialog without linking to kdeui. That in itself is a
> solvable problem. Probably the easiest solution would be to exec kdialog
> for that. We may want to limit this to the moment at which kapp->config()
> gets created. At this moment we can be pretty certain that no GUI elements
> are visible who could be deprived from paint-events by using exec. Using
> anything other than exec is probably a bad idea since that would involve
> the event loop which may lead to unexpected reentrancy problems.

Actually, there seems to be an easier way. Tracing through the code for 
setting up the global configuration object, here is what we need to add to 
the KApplication constructor (the first two lines are already present):

  KConfig* config = KGlobal::config();
  d->actionRestrictions = config->hasGroup("KDE Action Restrictions" );
#ifdef Q_WS_X11
  // Here the user's local config file is not writable.
  if (!(d->actionRestrictions) && config->isReadOnly())
    WarnTheUserSomehow("Cannot save config. Ask sysadmin.");

Now, how do I go about warning the user in a portable manner? I cannot use a 
QMessageBox (even though it is supposed to have its own private event loop) 
because it leads to problems with KUniqueApplication. At this point, the 
QApplication has been created already. So should I fork, show a QMessageBox 
in the child (or do some sort of execve("kdialog",...)) and then exit in the 
child? Unix process handling is not an area I am familiar with. Can someone 
suggest an alternative?

Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list