On Sep 23, 2010, at 5:33 PM, Colin Barrett wrote: > Part of the solution that was devised in #adium-devl is that built-in styles > shall have relative paths for the value of "Current Style Path". This should > prevent styles from breaking when people move their copy of Adium (or are > trying out a downloaded copy or something). > > There may be other aspects necessary (and some other potential improvements > to the fallback system that are nice to have), but that's pending further > investigation. > > Find me on IM or on #adium-devl if you've got any questions or corrections.
So what of this solution has been implemented? Does it fix the problem? Cheers, Evan > > -Colin > > On Sep 22, 2010, at 7:37 PM, Matthew wrote: > >> 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 <[email protected]> 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 <[email protected]> >>> 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 >> > >
