diff options
author | Timothy Pearson <[email protected]> | 2013-01-20 00:17:06 -0600 |
---|---|---|
committer | Timothy Pearson <[email protected]> | 2013-01-20 00:17:06 -0600 |
commit | e4e0479220e9e9616b68b2a11e42cff7a8af7b3d (patch) | |
tree | 8e01571cdd132dad34ebec38b12c2dbc37d05bd9 /twin/README | |
parent | d41050ea3f6904e5156d35f664346b816b9e4d12 (diff) | |
download | tdebase-e4e0479220e9e9616b68b2a11e42cff7a8af7b3d.tar.gz tdebase-e4e0479220e9e9616b68b2a11e42cff7a8af7b3d.zip |
Rename KApplication to TDEApplication to avoid conflicts with KDE4
Diffstat (limited to 'twin/README')
-rw-r--r-- | twin/README | 6 |
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. |