Fixing 49564 - dependency/BC problem?
ravi at ee.eng.ohio-state.edu
Sun Mar 9 23:58:55 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
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" );
// 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel