Forum Replies Created
-
Posts
-
In 3.1, a lot of the slowdown was in the skin /engine/. In 4.0, the amount of glitz/flash in the skin itself determines speed. Cordonata should be reasonably fast on a moderate-level machine, but Cobalt (for instance) which is also installed will be much, much faster.
If you find Cobalt is running slower for you than 3.1, it *really* should not be; if so, PLEASE log into Bugzilla with your alpha account and log a bug with some performance and system info? It’s conceivable there are situations that affect skin performance which we haven’t found or fixed, but we’ll need info to track those down. This is why it’s an alpha, after all. 🙂
A lot of the right-click contact options will be returning; due to it being alpha (and the mediums having been restarted from scratch), stuff’s still being fleshed back out.
Really, I’m pretty sure it’s only the most recent version that has file transfer.
(Also, right now, file transfer doesn’t work with all other Jabber clients, since Google Talk defined their own file transfer system atop of their Jingle streaming library. As other clients implement that system, file transfer will work with other clients.)
Augh. Put a break after the images in the article, please! 😉 That said…
Most other things didn’t really change much, I’ll give Cerulean that it is only in Alpha, but I would have much preferred it to be rewritten entirely, instead of adding/changing Trillian 3.x.I’m a little puzzled by this comment. It… pretty much /is/ a complete rewrite. That’s why it took so long, and is in alpha right now. We spent all that time more or less starting over: now it takes up far less memory, it’s faster and smaller.
Just as one example, every medium has been redone from scratch around a new system called ‘IMCore’ — rather than each medium being responsible for its own networking, encryption, profile management, etc., IMCore handles that for all mediums. Thus each medium just has to implement the protocol parser and generator, and IMCore handles much of the work for you. If we find a bug in SSL code or add support for a new proxy system, IMCore is changed and all mediums immediately pick it up.
Sure, things like the preferences panel, things like that, have been kept as much like 3.1 as possible in appearance (even where settings inside those have changed), specifically to keep things familiar to users.
It’s still an under-development alpha, so a lot of things (audio/video chatting, etc.) aren’t back in as we flesh out the IMCore implementations of things. But, given that we entirely redid most of the core codebase over the course of a year and a half or so… thus the long release… while trying to keep it backwards compatible as much as possible in terms of skinning language and plugin API… I’m not sure how much more we could’ve done in the way of rewriting it! 🙂
But, yes, many of the new features are built around the Astra profile, as the write-up at the Trillian Astra preview
shows. For instance, you can log onto a Trillian copy in a ‘guest mode’ which then pulls down your contact list and any other stuff you’ve stored on the Astra servers, runs a session, and — when you log out — cleans up the files again afterwards. Useful for logging in on a friend’s computer when at someone else’s house! Things like that.I notice that these screenshots don’t seem to be logged into the Astra service itself, which is one of the most significant changes to the system in this alpha. You can make social information available about yourself in the Trillian Astra program, and the Astra service shares this information out in a number of different ways. (And, of course, each element of the information can be locked down to specific security levels, like ‘everyone’ or ‘just my friends’ and so on.) Widgets exist that can be shared right in your Astra message windows, as well as on websites, to share status and mood and so on.
It’s a little disappointing to see a ‘preview’ which didn’t even bother to look at one of the more unique/interesting features of Astra, the social presence integration and the account synchronization.
Right. Right now, we’re only using Astra internally. There are 50 people scheduled for the first beta round, once we feel it’s ready for limited beta. There are a LOT of changes this time, so we want to make sure it’s rock-solid. 🙂
Logitech’s newer cameras sometimes require that irritating Logitech Messenger systray thing running (and ‘turned on’), or the driver is disabled. That’d be my best bet; my roommate had that problem with his Logitech driver, and we found we had to fiddle with that silly systray tool or else the driver showed up (even in the hardware manager for Windows!) as a disabled camera.
The Qnext folks are providing something a lot more like a more-easily-controlled and more friendly Gnutella, albeit crossed with something sort of like Rhapsody.
They’ve been pretty up-front that they don’t view Qnext as primarily an IM client, nor do they have any intention of making it such. It seems really quite cool for what it is, though!
MiamiGuy — generate a debug XML log (check ‘Display debug XML’ in your connection preferences, under the Misc tab) and submit a ticket to the Trillian Pro support system; Glenn or Don will assign it over to me.
That said, if you’re not using the interim test builds (i.e. the ones leading up to the new release I’m doing shortly), go pick one up. The latest is always in one place, and it’s linked from a thread in the support forums on the Cerulean boards. 🙂
Yes, sorry, that’s a good clarification. In short, it seems they intend to export the VoIP portion as SIP (just like the messaging stuff is XMPP). But the current voice-over-XMPP portion is non-standard. 🙂
No, on the calls. Google’s using their own (not yet documented) VoIP system, and it’s not been picked apart by anyone else quite yet.
If you’re on a client that supports the older Jabber protocol (Trillian Pro 2.x, Pandion, etc.), you may need to connect to 5223 — 5222 requires XMPP. Newer, XMPP compliant clients (Trillian Pro 3.x, Gaim, Exodus, iChat, etc.) will connect on 5222 just fine.
Jabber and XMPP are usually considered the same thing, but they’re not; consider it like the difference between HTTP 1.0 and HTTP 1.1 — an HTTP 1.1 browser can connect to sites that use HTTP 1.0, but an HTTP 1.0 browser cannot connect to sites requiring HTTP 1.1. (Not that there really are any HTTP 1.0 browsers in use out there anymore, but…)
FWIW, there’s going to be a Trillian Jabber update soon that supports the Google Talk extensions (a few folks are already testing it for me as of today) such as Gmail mail notifications and so on. There’s also a workaround that, if you have gmail.com as the server and there’s no host override set, it will connect to talk.google.com for the server. (No Google Talk VoIP in that update, though, before anyone asks.)
I’m also looking into taking the Trillian Pro 3.x XMPP plugin and converting it back to Trillian Pro 2.x, to give the Pro 2.x folks Google Talk support, as well as XMPP in general, MU-C, and bytestreams or server-proxied file transfer. That, however, will happen after the Google Talk enhanced 3.x Jabber plugin comes out.
gary1 wrote:Is this feature available with AIM? Sorry if this is a rudimentary question, I didn’t see it on the common questions area. Thanks for your help.Not without installing something like DeadAIM or AIM+. AIM itself has no logging capability, so you need one of the things that modifies AIM or runs as a background process to hook into it.
Many AIM add-ons have the ability to add logging, though, so almost any of the ‘extended functionality’ tools for AIM will do what you need.
Really cool! In Trillian-only, there’s a few ‘hidden’ ones (i.e. not in the smiley template) which you omitted. Just off the top of my head, a few are:
(bounce) (woot) (worship) (cheer) :D/ (h5) (hug) (poke)
Also a few we use when discussing protocol issues, such as (puke), are in there. 😉
Can’t really talk about biz stuff, I’m afraid. But suffice it to say Trillian will continue to connect to MSN. 🙂
As Jim pointed out, once we have Trillian Pro 2.0 out, we’re going to do a Trillian 2.0 free edition derived from Trillian Pro 2.0. Free’s never been dead, but we seriously needed to rearchitect things — witness making everything Unicode compliant, rewriting the windowing code, and so on — and wanted to focus on doing that in Pro first, and making a resuable code base between the two versions.
The MSN changes will therefore propagate to the Trillian free release, too. As for MSN’s motives, they’re actually quite reasonable. They’re not ‘blocking third party clients,’ they’re merely removing the expensive legacy support for really old-and-outdated versions of the MSN protocol to simplify their servers; any third-party client is still welcome to connect as long as they’re using the more recent versions of the protocol.
