[Adium-devl] My status, and some 1.4 planning
edr1084 at gmail.com
Tue Aug 5 23:54:28 UTC 2008
On Aug 5, 2008, at 6:13 PM, Evan Schoenberg <evan.s at dreskin.net> wrote:
> On Aug 2, 2008, at 4:18 PM, David Smith wrote:
>> I've told many of you, but not all: I'm no longer with Jive
>> and am currently unemployed. I've got stuff in the pipe to change
>> that I'm pretty excited about, so don't feel too sorry for me ;)
> Glad you've got good stuff coming up... and also that there's some
> Adium hacking in your near future :)
>> 1) Make Adium 64 bit ( http://trac.adiumx.com/wiki/64BitConversion
>> and http://trac.adiumx.com/ticket/10001
>> ). This is what I'm working on currently; rgov and toby have been
>> making big contributions as well. It's basically manual labor at this
>> point. Run the tops script on a folder, run rgov's script, clean
>> build, go through the warnings one by one making changes as
>> In addition, there's some libpurple deps work that needs to be done,
>> which is way outside my area. I believe toby and durin42 have
>> expressed interest in getting that ready.
> Looks like a lot of commits went by on the 64-bit work - excellent.
> Is there a good way to check the status?
>> 2) Integrate & test Sparkle 1.5. This is pretty much done in the
>> branch, but it obviously needs a ton of testing. Can't risk breaking
>> the update system.
> Let's merge this to trunk as soon as we branch 1.3. I'm going to
> build a 1.3b11 and then make the branch this evening.
>> 3) Contacts in multiple groups ( http://trac.adiumx.com/ticket/500
>> probably http://trac.adiumx.com/ticket/5707 )
>> This is the big one. I've looked into it before and it's going to
>> require *major* rearchitecting of parts of Adium. There are also
>> conceptual problems; for example:
>> Metacontact Alice contains AIM contact Alice123 and XMPP contact alice at adium.org
>> . The user attempts to put Alice in the groups "Adium Devs" and
>> People". What group should Alice123 be in serverside, since AIM
>> doesn't support multiple groups for contacts?
> Actually, that particular example doesn't work - AIM and XMPP both
> support contacts in multiple groups serverside.
> In fact, I'm not sure offhand which services don't support that at
> this point.
> In any case, handling should exist. We could just pick the first
> group and ignore the second. Contacts in multiple groups is
> something that seems mostly to be done in corporate contexts, in
> which it is deliberate and supported serverside. In 5 years I can't
> recall ever seeing a request from a user who wanted to put contacts
> in multiple groups who wasn't using a protocol which supported it ;)
>> 4) Take advantage of CSS variables ( http://disruptive-innovations.com/zoo/cssvariables/
>> ) for the webkit message view. This should *greatly* simplify and
>> speed up a lot of code, but will be the biggest break in
>> we've had.
> This is a cool idea.
>> I believe I'll probably have to keep the old wkmv around
>> for existing message styles, which is less than ideal.
> Well, yeah... but that's what the versioning system is for. It
> shouldn't be a big deal to sequester off the processing that's
> needed only in the currently-existing styles into code we don't have
> to see - we'd want to continue to support such styles, anyways :)
>> Unfortunately this will only work with post-3.1 versions of Safari;
>> most likely Safari 4. Fortunately, Safari releases are no longer tied
>> to OS releases, so we can do this without being 10.6 only or
>> silly like that.
> Do you know what the expected timeframe on Safari 4 is?
>> 5) Drop as much old stuff as is reasonable. This is basically a
>> of looking at the probable release date of 1.4 vs OSX 10.6, and the
>> graphs on sparkle.adiumx.com, and deciding what's reasonable.
>> Tiger will let us delete at least 13000 lines of code, since we won't
>> need to statically compile expat in. Likely significantly more than
>> that. We'll also be able to use GCC 4.2, Xcode 3 features like
>> parallel target builds and xcconfig files, Objective-C 2 features,
> I've given this some thought... we're not doing our many users any
> favors by holding back on advancement to maintain 10.4
> compatibility, but more importantly, we're not doing ourselves any,
> either. If moving to 10.5+ would make development faster, more
> enjoyable, and a better learning experience, we should make the
> jump. I think that if we do so we should keep our 10.4 users in
> mind on the Adium 1.3.x branch, backporting key improvements which
> don't require massive rewrites to work there, such as a future
> MSNp15 switch. What do y'all think?
Glad to hear that you've coming around Evan! ;)
(And you're right, replying in-line definitely takes some extra
>> Longer term (or not, if the graphs say so. I'm hopeful...), dropping
>> PPC and x86-32 will begin to make sense. This will let us move
>> entirely to the new Objective-C runtime, with benefits for API
>> stability (non-fragile base classes) and speed. I've added 32/64 bit
>> tracking for Sparkle 1.5, so when it proves stable we may want to
>> introduce it in a 1.3.x revision and get some stats.
> I'm not up on the 32-bit vs. 64-bit CPUs; what's the newest chipset
> which is 32-bit?
>> 6) Responsiveness improvements. There are two candidates on my
>> right now. One is that sounds playing in critical paths (message
>> sends, contacts signing on, stuff like that) is absolutely killing
>> UI latency in some cases. Making this async would be a huge plus, but
>> I don't know enough about QT to say how doable it is. Moving it to
>> next runloop iteration might help a bit even if that's not possible.
> I bet that threading the QuickTime usage wouldn't be too difficult.
> http://developer.apple.com/technotes/tn/tn2125.html#TNTAG2 indicates
> that we can open the movie file (which I think is the bottleneck) on
> a thread, and then we can play it (which is nonblocking) on the main
>> The other candidate is the locking in the log viewer. Closing the log
>> viewer will often beachball Adium for upwards of 45 seconds, during
>> which it's waiting on a lock. That's... bad. Comments in the source
>> indicate that the paranoid locking is due to SearchKit issues.
> *grumbles about SearchKit*
>> 7) Polish and fix the IRC plugin. This means getting groupchat
>> bookmarks working with IRC, adding autoidentify support, making /msg
>> open a new window, fixing /me to show up properly, fixing nick change
>> handling, and making account setup more intuitive.
> Hear, hear. :)
> Adium-devl mailing list
> Adium-devl at adiumx.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Adium-devl