Hi everyone,
I'm the author of the draft spec linked to from the blog
entry, and
the current maintainer of Adium's webkit message view code,
so feel
free to fire any questions about it my way. I'm also looking
for
feedback on the draft spec, because I'd really rather not
discover
some horrible issue with it *after* investing time
implementing it in
Spark and Adium
The basic assumption I'm making is that whatever renderer
is being
used is a) capable of fairly up to date javascript and DOM
manipulation (webkit/gecko level, or close to it), and b)
has a
bridge to whatever the client is being written in. In
Adium's case
that's WebKit and the WebKit JS<->ObjC bridge, in
SparkWeb's case
it's JS<->JS, and in Spark's case it gets a bit
uglier, but there are
some gecko embedding APIs for java that can be found. I
haven't
talked to the Kopete folks yet, but they didn't have much
trouble
implementing the old way of doing themes on top of KHTML, so
I don't
expect it to be a problem.
The advantage of pushing more of the message view stuff
into
javascript than before (Adium does most of it in
Objective-C, then
hands a big chunk of HTML to webkit) is that the Template
files
should be able to be shared between clients implementing the
API,
which takes less effort than rewriting it each time, and
promotes
compatibility.
Davinessto
oh, and I definitely fall in the anti-IE camp. Most
existing styles
will simply not work, same goes for the current Template
file.
_______________________________________________
psi-devel mailing list
psi-devel lists.affinix.com
http://lists.affinix.com/listinfo.cgi/psi-devel-affin
ix.com
|