b19 message style problems

Sun Oct 10 20:53:24 UTC 2010

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 <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
>> 
> 
> 