b19 message style problems

Thu Sep 23 22:33:21 UTC 2010

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.

-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 <mneedham at 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 <colin at 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
> 