b19 message style problems
mneedham at ei8ht.us
Thu Sep 23 02:37:26 UTC 2010
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
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
CFBundleName: Smooth Operator
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...
On Wed, Sep 22, 2010 at 12:43, Matthew <mneedham at ei8ht.us> wrote:
> 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.
> 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?
>> 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>
>>> 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. :)
More information about the devel