Revert the "never use last saved status" behavior. Re-fixes #6227.
The behavior was #ifdef'd out to appease MSN users, who wanted their status messages to propagate. Find some middle ground here: if a status message is currently set, a custom new-status window will retain it. Otherwise, it'll use the saved one. And we'll always use the last-saved status settings otherwise, so "autoreply" saving always works.
1.1 --- a/Frameworks/Adium Framework/Source/AIStatusMenu.m Mon Nov 23 16:38:26 2009 -0500
1.2 +++ b/Frameworks/Adium Framework/Source/AIStatusMenu.m Mon Nov 23 17:02:25 2009 -0500
1.3 @@ -400,7 +400,6 @@
1.4 baseStatusState = adium.statusController.activeStatusState;
1.5 }
1.6
1.7 -#ifdef USE_LAST_STATUS_OF_THIS_TYPE
1.8 /* If we are going to a custom state of a different type, we don't want to prefill with baseStatusState as it stands.
1.9 * Instead, we load the last used status of that type.
1.10 */
1.11 @@ -411,17 +410,16 @@
1.12 AIStatus *lastStatusStateOfThisType = (lastStatusStateData ?
1.13 [NSKeyedUnarchiver unarchiveObjectWithData:lastStatusStateData] :
1.14 nil);
1.15 -
1.16 - baseStatusState = [[lastStatusStateOfThisType retain] autorelease];
1.17 + if (lastStatusStateOfThisType) {
1.18 + // Restore the current status message into this last-saved variety, since users tend want to keep them.
1.19 + // If it doesn't exist, use the last-saved status message.
1.20 + if (baseStatusState.statusMessage.length) {
1.21 + lastStatusStateOfThisType.statusMessage = baseStatusState.statusMessage;
1.22 + }
1.23 +
1.24 + baseStatusState = [[lastStatusStateOfThisType retain] autorelease];
1.25 + }
1.26 }
1.27 -
1.28 - /* Don't use the current status state as a base, and when going from Away to Available, don't autofill the Available
1.29 - * status message with the old away message.
1.30 - */
1.31 - if (baseStatusState.statusType != statusType) {
1.32 - baseStatusState = nil;
1.33 - }
1.34 -#endif
1.35
1.36 [AIEditStateWindowController editCustomState:baseStatusState
1.37 forType:statusType