b19 message style problems

Matthew mneedham at ei8ht.us
Thu Oct 21 17:59:29 UTC 2010


This appear to work perfectly. I will point out a few places where
user may still experience what would (falsely) appear to be preference
changes:

1) When a previous style has been removed.  This is most likely to be
seen with Renko Naked. We *do* failover to Renkoo and *do* carry over
the preferences to the new style, but it seems reasonably to assume
that people who chose Renkoo Naked over Renkoo might notice that their
style is suddenly using smooth scroll and fading in new messages.

2)  When previous style didn't fully respect user preferences.  Gone
Dark ignored the user-specificd font family and Renkoo ignored the
user-specified font size. If either was changed from the default, the
user will face a situation where chats no longer look the same.

3) When there is a change in a styles default variant and the user has
never explicitly selected a variant for that style. This could crop up
with Smooth Operator. While I tend to agree with those that have said
that it's good to use one of the non-classic SO variants as the
default, it would make a less jarring experience for previous SO users
if their migration used the classic variant. Can we make the
com.adiumx.smooth.operator.style -> im.adium.Smooth Operator.style
failover also select the Classic variant? This should allow a
different default variant for those who are new to SO while making for
an easier transition for those that are currently using SO.

4) When the xtras version of a style is also installed. One situation
I ran across is that if a user has the xtras version of yMous
installed and updates to 1.4rc1, they will continue to use the yMous
from xtras rather than the version bundled with 1.4rc1. This isn't
necessarily a problem, and may even be desirable. I don't believe it
was possible in some previous version, and the documentation (which I
added) reflects this. Having both styles does complicate support a bit
since there's no clear way for a user to distinguish between the
selection of a bundled version and the xtras version.


Matthew


On Wed, Oct 20, 2010 at 19:44, Evan Schoenberg, M.D. <evan.s at dreskin.net> wrote:
>
> On Oct 19, 2010, at 8:47 PM, Matthew wrote:
>
> With Evan's fix for the message style bundle path issue and the
> additional CFBundleIdentifier failovers I committed yesterday, things
> are greatly improved. However, there are still some lingering issues
> due to limitations in how the existing CFBundleIdentifier failover
> works.
>
> I basically just added more if-thens to the existing failover code.
> Now Adium will correctly select the appropriate message style based on
> the user's previous selection of any bundled message style.
> Unfortunately, the failover doesn't cover every place that
> CFBundleIdentifier is used, so some user preferences will be lost.
>
> Retained are the checkboxes for show user icons, show header, show
> received message fonts, and show received message colors. Lost are the
> variant, custom background, font face, and font size.
>
> There may be other things tied to CFBundleIdentifier, I only checked
> the prefs in the messages prefpane.
>
> Only the PREF_GROUP_WEBKIT_REGULAR_MESSAGE_DISPLAY group is tied to the
> message style identifiers.
> I disliked us discarding users' preferences - you'd be amazed how upset some
> people get when, for no reason they can discern, an update resets their
> settings! I've watched my wife declare she'd never use an application again
> because of it - so implemented a more thorough upgrade path in
> [0e061cd60338]. Thanks for pointing out that previous arguably-minor
> deficiency in the code path.
> Cheers,
> Evan
>
>
>
> Matthew
>
>
> On Mon, Oct 18, 2010 at 12:38, Matthew <mneedham at ei8ht.us> wrote:
>
> My testing was complicated by an xtras-sourced message style where the
>
> CFBundleName had been changed, but CFbundleIdentifier conflicted with
>
> Mockie. However, now that this confusion has been resolved, I can say
>
> that The latest fix does appear to resolve the problems with Adium
>
> loading message style bundled form the wrong place.
>
> Now I need to test, commit, and push my updated failovers for the old
>
> CFBundleIdentifiers.
>
>
> Matthew
>
>
> On Thu, Oct 14, 2010 at 22:33, Evan Schoenberg, M.D. <evan.s at dreskin.net>
> wrote:
>
> Matthew,
>
> On Oct 12, 2010, at 7:24 PM, Matthew wrote:
>
> Not only was this my first download of 3355, it was a completely new
>
> profile. Sorry I forgot to include the profile creation step.
>
> I can't reproduce any problems with a first-time upgrade with adium-1.4. A
> quick perusal of hg's log shows that I failed to transplant this to the
> adium repository, though, which would explain its failure on your side.
>
> A new profile wouldn't change anything with the current implementation,
> since this is using NSUserDefaults to track the status of the upgrade which
> is app-specific not profile-dependent.
>
> Further evaluation: This is currently fragile; it's feasible a user could
> launch 1.4, relaunch 1.3, then launch 1.4 again, and then be faced with the
> same rather odd-appearing bug.
>
> I've corrected this fragility and pushed the change to both adium-1.4 and
> adium.  Please recheck and let me know if you can still reproduce any
> problems in this department :)
>
> Thanks as always for your help!
>
> Cheers,
>
> Evan
>
>
>
> Matthew
>
> On Tue, Oct 12, 2010 at 18:30, Evan Schoenberg, M.D. <evan.s at dreskin.net>
> wrote:
>
> Had you launched hgr3355 (or any after my changeset) before testing as you
> wrote below?  I wrote the upgrade code to only trigger once.
>
> -Evan
>
> On Oct 12, 2010, at 6:01 PM, Matthew wrote:
>
> I don't see any change from the old behavior. Here's what I did:
>
> 1) Launch 1.3.10, and open the messages prefpane so that "Current
>
> Style Path" gets set in WebKit Message Display.plist.
>
> 2) Quit 1.3.10, launch 1.5hgr3355, and check WebKit Message
>
> Display.plist. "Current Style Path" is still set to
>
> "/Users/mneedham/Applications/Adium
>
> 1.3.10/Adium.app/Contents/Resources/Message
>
> Styles/Stockholm.AdiumMessageStyle", so I'd expect any saved chat
>
> windows will load with the incorrect message style.
>
> 3) Open the messages prefpane, and verify visually, that the preview
>
> is still for the version of Stockholm in 1.3.10. (In the old version,
>
> there the status message timestamp has a grey background.) I verified
>
> that "Current Style Path" is still set to the message style inside the
>
> 1.3.10 app bundle.
>
>
> Matthew
>
>
>
> On Mon, Oct 11, 2010 at 13:23, Matthew <mneedham at ei8ht.us> wrote:
>
> I'll try to work though my test cases later today or tomorrow.
>
>
> Matthew
>
> On Mon, Oct 11, 2010 at 12:52, Evan Schoenberg, M.D. <evan.s at dreskin.net>
> wrote:
>
> On Sep 22, 2010, at 9:07 AM, Matthew wrote:
>
> 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.
>
> I've fixed this in http://hg.adium.im/adium-1.4/rev/7eced108f702
>
> -Evan
>
>
>
>
> --
>
> Matthew
>
>
>
>
> --
>
> Matthew
>
>
>
>
>
>
>
> --
>
> Matthew
>
>
>
>
>
>
>
> --
>
> Matthew
>
>
>
>
> --
>
> Matthew
>
>
>



-- 

Matthew



More information about the devel mailing list