Further thoughts... I'm probably in the minority (among all users) in that I have several versions of Adium. I suspect that for most users the default message style path is something like /Applications/Adium.app/Contents/Resources/Message Styles/minimal_mod.AdiumMessageStyle, and after upgrading the path is identical. Perhaps this is the biggest reason this hasn't been a big problem with previous releases, since in normal cases nothing in the path will change. I just confirmed that if I manually "correct" the path in a text editor, Adium correctly loads the message style and I no problems are evident. I've still not tested extensively; this is using the default message style of Stockholm.
----- And for anyone who is wondering why I changed the Bundle ID for the updated styles, here's a somewhat long-winded explanation. A while back I downloaded every message style on Xtras and collected some data on different aspects: use of a custom template.html, bundle structures, etc. One of the things that I noticed is that some message style authors had simply duped an exiting style, changed the html/css, renamed the style bundle, and submitted the style to Xtras. There's nothing wrong with this, but they didn't change CFBundleIdentifier in info.plist, so anyone who had installed the original style *and* their modded style would only see one of them. Other issues would be caused by the fact that Adium requires that every loaded style have a unique value for CFBundleName and the OS requires a unique file name. I decided that "best practice" should be for CFBundleName to match the file name (sans extension), and for CFBundleIdentifier to end in <CFBundleName>.style. (Though really, is there any reason that CFBundleName couldn't be used in place of CFBundleIdentifier? Or for that matter, couldn't Adium just look at the style bundle name, trim the extension and use that?) When I applied this to the bundled styles, Smooth Operator went from: filename: Smooth Operator.AdiumMessageStyle CFBundleIdentifier: com.adiumx.smooth.operator.style CFBundleName: Smooth Operator to filename: Smooth Operator.AdiumMessageStyle CFBundleIdentifier: com.adiumx.Smooth Operator.style CFBundleName: Smooth Operator It's not a huge change, but I reasoned that it was one that could eventually allow this to be programatically checked as part of the Xtras approval process. While I was making changes, I figured this would also be a good time to change com.adiumx.* to im.adium.*, so that was done too. So at the moment, it should be possible for Adium to know the relative path to any style in the currently running version by looking at either CFBundleIdentifier or CFBundleName. Hopefully this will help resolve the current issue... Matthew On Wed, Sep 22, 2010 at 12:43, Matthew <mneed...@ei8ht.us> wrote: > Thanks. > > I've not been able to duplicate any font or color problems, but it > certainly seems possible that some font/color problems could occur. > One of the changes I made in the message style updates was to remove > places where a font face or color was fixed and unchangeable. There > are a *few* specific elements that are still fixed because the style > would break horribly with a different font size or because the point > of the variant was to use a specific color for something. Wherever > relative text sizing was needed I used em or ex units. > > All styles saw significant changes in the html and css, and in some > cases the whole style was completely rewritten. If Adium is doing any > mix and match between old and new parts, I'm not surprised to see > things break in a spectacular fashion. To be honest, I can't tell > exactly what's going on, except that 1) Adium is loading messages > styles bundled into a different version of Adium than is actually > running, and 2), the messages prefpane often previews one or more > setting that is different from what is specific elsewhere in the > prefpane (e.g. claiming to use Stockholm, but previewing Mockie). > > One additional issue here, is that most or all of the 1.4 bundled > styles are not compatible with 1.3. If Current Style Path gets set to > a b19 style and the user switches back to 1.3.x, Adium will beachball > and/or crash. This actually a known problem > (http://trac.adium.im/ticket/7438, maybe also > http://trac.adium.im/ticket/1147 and http://trac.adium.im/ticket/9577, > probably others), though I don't think anyone ever anticipated that > Adium would load the incorrect style bundle. I'm beginning to wonder > if this probably could be responsible for quite a few tickets of the > years that were closed because the problem wasn't reproducible. > > > Matthew > > > On Wed, Sep 22, 2010 at 11:49, Colin Barrett <co...@springsandstruts.com> > wrote: >> Great work, Matthew. >> >> So you're able to reproduce the font/color changing? I tried last night and >> wasn't able to. What were your STR? >> >> -Colin >> >> On Sep 22, 2010, at 9:07 AM, Matthew wrote: >> >>> It's been suggested that the changes I made to message style bundle >>> identifiers are causing the widely reported problems in b18. Based on >>> my testing thus far, I don't believe that they are the source of the >>> problem, though they they may be compounding the issues(*). I'm not >>> done with my testing, but I'm emailing the list because fixing the >>> root problem is beyond my ability, and I'd like to give other the >>> opportunity to use my findings while I collect more. >>> >>> I started with 1.3.10 with two clean profiles (one pristine, one where >>> the messages prefpane but unchanged). I then "upgraded" to 1.4b18, >>> first duping each profile to retain the old data. I then upgraded to >>> 1.4b19, again duping the profile. I then re-duped the 1.3.10 profiles >>> and upgraded directly from 1.3.10 to 1.4b19 just to see if that >>> upgrade jump was any different. It was not. >>> >>> 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. >>> >>> My conclusion is that the reason this problem hasn't surfaced before >>> is because message style changes have been sufficiently uncommon and >>> subtle that the standard troubleshooting step of switching/toggling >>> message styles served to resolve the issue. Since so few users >>> reported a problem, it was never perceived to be a recurring or >>> reproducible problem. >>> >>> >>> (*)My bundle ID changes, where I didn't add appropriate fallbacks, >>> *would* cause a user's message style to change. The old one is now >>> "missing", and Adium would select the "new" default. This was tested >>> and worked fine before the changes we pushed. One place I failed was >>> in adding every needed fallback. Before starting the detailed testing >>> above I reverted my changes to the style bundle identifiers and the >>> fallbacks, but it didn't actually resolve *any* of the issues. There >>> may be other message style issues besides the current style path and >>> the fallbacks, but I think they will be difficult to discern until >>> Adium stops reading to the wrong message style bundle. >>> >>> As I mentioned, I have more testing to do, but for the moment I need >>> to actually get back to the work my employer expects of me. :) >>> >>> >>> -- >>> >>> Matthew >>> >> >> >> > > > > -- > > Matthew > -- Matthew
