summaryrefslogtreecommitdiffstats
path: root/twin/README
diff options
context:
space:
mode:
authorTimothy Pearson <[email protected]>2013-01-20 00:17:06 -0600
committerTimothy Pearson <[email protected]>2013-01-20 00:17:06 -0600
commite4e0479220e9e9616b68b2a11e42cff7a8af7b3d (patch)
tree8e01571cdd132dad34ebec38b12c2dbc37d05bd9 /twin/README
parentd41050ea3f6904e5156d35f664346b816b9e4d12 (diff)
downloadtdebase-e4e0479220e9e9616b68b2a11e42cff7a8af7b3d.tar.gz
tdebase-e4e0479220e9e9616b68b2a11e42cff7a8af7b3d.zip
Rename KApplication to TDEApplication to avoid conflicts with KDE4
Diffstat (limited to 'twin/README')
-rw-r--r--twin/README6
1 files changed, 3 insertions, 3 deletions
diff --git a/twin/README b/twin/README
index 3e4e49219..652fa83ae 100644
--- a/twin/README
+++ b/twin/README
@@ -189,10 +189,10 @@ from Konsole as 'dcop kdesktop KDesktopIface popupExecuteCommand" will lead
to showing the minicli, but the last user activity timestamp gained from events
sent by X server will be older than user activity timestamp of Konsole, and
would normally result in minicli not being active. Therefore, before showing
-the minicli, kdesktop needs to call KApplication::updateUserTimestamp().
+the minicli, kdesktop needs to call TDEApplication::updateUserTimestamp().
However, this shouldn't be done with all DCOP calls. If a DCOP call is not
-a result of direct user action, calling KApplication::updateUserTimestamp()
+a result of direct user action, calling TDEApplication::updateUserTimestamp()
would lead to focus stealing. For example, let's assume for a moment
that KMail would use this DCOP call in case it detects the modem is not
connected, allowing to you to start KPPP or whatever tool you use. If KMail
@@ -201,6 +201,6 @@ possibly suddenly showing up at every check. Basically, doing the above change
to kdesktop's minicli means that the popupExecuteCommand() DCOP call is only
for user scripting. (TODO write about focus transferring?)
- Simply said, KApplication::updateUserTimestamp() should be called only
+ Simply said, TDEApplication::updateUserTimestamp() should be called only
as a result of user action. Unfortunately, I'm not aware of any universal
way how to handle this, so every case will have to be considered separately.