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

[David Smith]

	Hi folks,

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

	What this does mean is that I have some time, most likely a few  
weeks, to work full time on Adium. I'd like to take advantage of that  
to the fullest extent by trying to tackle some "projects" that have  
been on my mind for a while. Obviously I won't be able to get to all  
of these, but I'd like feedback from people:

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.

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.

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?

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. I believe I'll probably have to keep the old wkmv around  
for existing message styles, which is less than ideal. As an example  
of the sort of things this will allow:

	<div style="background-image: var(adium-%senderScreenName%-icon);"></ 
div>

	we can create and update (for example) adium-catfishman42-icon to  
point to the correct url from objc, and all uses of it in the message  
style will automatically update. The current code iterates the list of  
<img> elements in the style and uses a heuristic to figure out which  
ones are buddy icons and update them manually. Slow, ugly, has been  
buggy at times, etc...

	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.

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

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

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.


																			David