[Adium-devl] My status, and some 1.4 planning

Tue Aug 5 22:13:04 UTC 2008

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 Software,
> and am currently unemployed. I've got stuff in the pipe to change that
> 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 necessary.
> 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 and
> 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 "Nifty
> 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 compatibility
> 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 something
> 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 matter
> 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. Dropping
> 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,
> etc...

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?

> 	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 hitlist
> right now. One is that sounds playing in critical paths (message
> sends, contacts signing on, stuff like that) is absolutely killing our
> 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 the
> 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  
thread.

> 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. :)

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080805/339405cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080805/339405cb/attachment.sig>