[Adium-devl] My status, and some 1.4 planning
catfish.man at gmail.com
Sat Aug 2 20:18:14 UTC 2008
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);"></
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,
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.
More information about the Adium-devl