On Oct 19, 2010, at 8:47 PM, Matthew wrote: > With Evan's fix for the message style bundle path issue and the > additional CFBundleIdentifier failovers I committed yesterday, things > are greatly improved. However, there are still some lingering issues > due to limitations in how the existing CFBundleIdentifier failover > works. > > I basically just added more if-thens to the existing failover code. > Now Adium will correctly select the appropriate message style based on > the user's previous selection of any bundled message style. > Unfortunately, the failover doesn't cover every place that > CFBundleIdentifier is used, so some user preferences will be lost. > > Retained are the checkboxes for show user icons, show header, show > received message fonts, and show received message colors. Lost are the > variant, custom background, font face, and font size. > > There may be other things tied to CFBundleIdentifier, I only checked > the prefs in the messages prefpane.
Only the PREF_GROUP_WEBKIT_REGULAR_MESSAGE_DISPLAY group is tied to the message style identifiers. I disliked us discarding users' preferences - you'd be amazed how upset some people get when, for no reason they can discern, an update resets their settings! I've watched my wife declare she'd never use an application again because of it - so implemented a more thorough upgrade path in [0e061cd60338]. Thanks for pointing out that previous arguably-minor deficiency in the code path. Cheers, Evan > > > Matthew > > > On Mon, Oct 18, 2010 at 12:38, Matthew <mneed...@ei8ht.us> wrote: >> My testing was complicated by an xtras-sourced message style where the >> CFBundleName had been changed, but CFbundleIdentifier conflicted with >> Mockie. However, now that this confusion has been resolved, I can say >> that The latest fix does appear to resolve the problems with Adium >> loading message style bundled form the wrong place. >> >> Now I need to test, commit, and push my updated failovers for the old >> CFBundleIdentifiers. >> >> >> Matthew >> >> >> On Thu, Oct 14, 2010 at 22:33, Evan Schoenberg, M.D. <eva...@dreskin.net> >> wrote: >>> Matthew, >>> >>> On Oct 12, 2010, at 7:24 PM, Matthew wrote: >>> >>>> Not only was this my first download of 3355, it was a completely new >>>> profile. Sorry I forgot to include the profile creation step. >>> >>> I can't reproduce any problems with a first-time upgrade with adium-1.4. A >>> quick perusal of hg's log shows that I failed to transplant this to the >>> adium repository, though, which would explain its failure on your side. >>> >>> A new profile wouldn't change anything with the current implementation, >>> since this is using NSUserDefaults to track the status of the upgrade which >>> is app-specific not profile-dependent. >>> >>> Further evaluation: This is currently fragile; it's feasible a user could >>> launch 1.4, relaunch 1.3, then launch 1.4 again, and then be faced with the >>> same rather odd-appearing bug. >>> >>> I've corrected this fragility and pushed the change to both adium-1.4 and >>> adium. Please recheck and let me know if you can still reproduce any >>> problems in this department :) >>> >>> Thanks as always for your help! >>> >>> Cheers, >>> Evan >>> >>>> >>>> >>>> Matthew >>>> >>>> On Tue, Oct 12, 2010 at 18:30, Evan Schoenberg, M.D. <eva...@dreskin.net> >>>> wrote: >>>>> Had you launched hgr3355 (or any after my changeset) before testing as >>>>> you wrote below? I wrote the upgrade code to only trigger once. >>>>> >>>>> -Evan >>>>> >>>>> On Oct 12, 2010, at 6:01 PM, Matthew wrote: >>>>> >>>>>> I don't see any change from the old behavior. Here's what I did: >>>>>> >>>>>> 1) Launch 1.3.10, and open the messages prefpane so that "Current >>>>>> Style Path" gets set in WebKit Message Display.plist. >>>>>> >>>>>> 2) Quit 1.3.10, launch 1.5hgr3355, and check WebKit Message >>>>>> Display.plist. "Current Style Path" is still set to >>>>>> "/Users/mneedham/Applications/Adium >>>>>> 1.3.10/Adium.app/Contents/Resources/Message >>>>>> Styles/Stockholm.AdiumMessageStyle", so I'd expect any saved chat >>>>>> windows will load with the incorrect message style. >>>>>> >>>>>> 3) Open the messages prefpane, and verify visually, that the preview >>>>>> is still for the version of Stockholm in 1.3.10. (In the old version, >>>>>> there the status message timestamp has a grey background.) I verified >>>>>> that "Current Style Path" is still set to the message style inside the >>>>>> 1.3.10 app bundle. >>>>>> >>>>>> >>>>>> Matthew >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 11, 2010 at 13:23, Matthew <mneed...@ei8ht.us> wrote: >>>>>>> I'll try to work though my test cases later today or tomorrow. >>>>>>> >>>>>>> >>>>>>> Matthew >>>>>>> >>>>>>> On Mon, Oct 11, 2010 at 12:52, Evan Schoenberg, M.D. >>>>>>> <eva...@dreskin.net> wrote: >>>>>>>>> On Sep 22, 2010, at 9:07 AM, Matthew wrote: >>>>>>>> >>>>>>>>>> Here's what I found: >>>>>>>>>> >>>>>>>>>> In the User profile, Webkit Message Display.plist is created when the >>>>>>>>>> messages prefpane is opened. It contains: >>>>>>>>>> >>>>>>>>>> <key>Current Style Path</key> >>>>>>>>>> >>>>>>>>>> <string>/Users/mneedham/Applications/Adium-1.3/Adium.app/Contents/Resources/Message >>>>>>>>>> Styles/Stockholm.AdiumMessageStyle</string> >>>>>>>>>> >>>>>>>>>> This key does not change when the user launches b18 or if the user >>>>>>>>>> launches b18 and opens the messages prefpane. Should it? When I open >>>>>>>>>> the messages prefpane of 1.4b19, I can see that Stockholm (the >>>>>>>>>> default >>>>>>>>>> style) is using the one bundled with 1.3.10/1.4b18, and *not* the one >>>>>>>>>> bundled with 1.4b19. I don't know if the Current Style Path key is >>>>>>>>>> responsible for pointing Adium to the correct message style bundle, >>>>>>>>>> or >>>>>>>>>> if another file is responsible for that (if so I can't find one) I >>>>>>>>>> think I've been told that Adium writes this value out to two places, >>>>>>>>>> so maybe I should be looking elsewhere. >>>>>>>> >>>>>>>> I've fixed this in http://hg.adium.im/adium-1.4/rev/7eced108f702 >>>>>>>> >>>>>>>> -Evan >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Matthew >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Matthew >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Matthew >>>> >>> >>> >>> >> >> >> >> -- >> >> Matthew >> > > > > -- > > Matthew >
