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

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

Glad to hear that you've coming around Evan! ;)

(And you're right, replying in-line definitely takes some extra  
effort...)

>
>> 	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
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080805/f120936d/attachment-0001.html>