Sooo, I implemented the two tickets noted as missing in my last blog entry. Since all that's left now is waiting on other SoC students, I had to move to something else. My branch was merged into trunk (the main development tree for svn-impaired), which should help adaption and testing.
If anybody reading this is using XMPP frequently, likes living on the edge and writing bug reports, please check out the latest development version of Adium, compile it and use it for a while! If you encounter any bugs or have suggestions, take a look at ReportingBugs. Any input in valuable! If your ticket concerns XMPP, please assign it to "am" (myself), so I get a notification for it.
EDIT: We get a discount on our per-ticket-fees on trac, so please open one separate ticket per request! We can afford that. Thank you for the valuable input I've received so far!
Do not post bugs or requests to the comments! Use Trac.
Wednesday, July 11, 2007
Comments:
it would be sooo cool if you could post a binary somewhere as those people who already moved to the next major os version are still having problems compiling adium, even if they are using xcode 2.x ;-)
hi andreas,
that all sounds really great, thanks for all your work. i'm really looking forward to see your work in a final version of adium.
i also got one question: now that adium fully supports transports, is there an option to hide them?
i already use transports in adium (i previously configured them with psi) and i don't like the fact, that they are shown like regular contacts on the roster. it would be great to have an option in the view-menu to show/hide transports (like there is such an option for offline contacts).
that all sounds really great, thanks for all your work. i'm really looking forward to see your work in a final version of adium.
i also got one question: now that adium fully supports transports, is there an option to hide them?
i already use transports in adium (i previously configured them with psi) and i don't like the fact, that they are shown like regular contacts on the roster. it would be great to have an option in the view-menu to show/hide transports (like there is such an option for offline contacts).
Wow, that's fast. Some of the SoC 2006 code is still not in the trunk. Like the Super Menu Duck (or whatever the name was).
Great news! One question.
If I'm not mistaken you've implemented a lot of XMPP related things in Adium's own LibPurple implementation. Are those changes going to show up upstream in the original LibPurple?
It would be great if I could use the new features with friends using PidGin.
If I'm not mistaken you've implemented a lot of XMPP related things in Adium's own LibPurple implementation. Are those changes going to show up upstream in the original LibPurple?
It would be great if I could use the new features with friends using PidGin.
anonymous1:
I'll look into it. Things have become a bit complicated here since I moved to the Leopard Beta.
meandcat:
My original plan was to move the gateways to the service menu. Unlike the Smack plugin, this isn't implemented yet for libpurple. Would that be a good idea for you?
anonymous2:
Those projects never got finished. All usable code of SoC 2006 will be part of Adium 1.1.
anonymous3:
They're already in the pidgin monotone repository in the branch im.pidgin.soc.2007.xmpp. I've been talking to them for a few days about propagating the features to im.pidgin.pidgin, but that will have to wait until the current development version has been released.
I'll look into it. Things have become a bit complicated here since I moved to the Leopard Beta.
meandcat:
My original plan was to move the gateways to the service menu. Unlike the Smack plugin, this isn't implemented yet for libpurple. Would that be a good idea for you?
anonymous2:
Those projects never got finished. All usable code of SoC 2006 will be part of Adium 1.1.
anonymous3:
They're already in the pidgin monotone repository in the branch im.pidgin.soc.2007.xmpp. I've been talking to them for a few days about propagating the features to im.pidgin.pidgin, but that will have to wait until the current development version has been released.
@andreas:
for me every solution is perfect, as long as it gives me the possibiltiy to hide transports from the contact list...
for me every solution is perfect, as long as it gives me the possibiltiy to hide transports from the contact list...
@am:
(i am anonymous1) ;-)
i just saw a ticket that is concerned with the same issue i am experiencing (impossible to compile adium with xcode 2.5.x on 10.5).
maybe you could help there, too as you are on 10.5, too.
its this ticket:
http://trac.adiumx.com/ticket/7311
(i am anonymous1) ;-)
i just saw a ticket that is concerned with the same issue i am experiencing (impossible to compile adium with xcode 2.5.x on 10.5).
maybe you could help there, too as you are on 10.5, too.
its this ticket:
http://trac.adiumx.com/ticket/7311
Fantastic. But merging to trunk means your work will be in 1.1, am I right? That would be pretty fast for a SOC project!
@Andreas:
concerning the "hide transports from contact list thing":
it would be really cool if the transports would appear in the file menu and in the adium menu bar icon like normal accounts and would behave like normal accounts. then the user could easily connect and disconnect the transports like normal accounts.
this would really rock! :-)
concerning the "hide transports from contact list thing":
it would be really cool if the transports would appear in the file menu and in the adium menu bar icon like normal accounts and would behave like normal accounts. then the user could easily connect and disconnect the transports like normal accounts.
this would really rock! :-)
1.1 has already branched and is in beta at the moment.
I believe it's been announced that Andreas' work will be in 1.2.
XMPP is my protocol of choice, so i'm very excited.
I believe it's been announced that Andreas' work will be in 1.2.
XMPP is my protocol of choice, so i'm very excited.
anonymous5 aka anonymous1:
I'm using Xcode 3.0 on Leopard, and it works fine.
anonymous6: (it'd be nice if everybody would get some identity ;)
There's still some kind of dependency between XMPP acocunts and gateways. When you change your status on the XMPP account, the gateways change it, too (including going offline/online), so displaying them at the same level would be misleading.
btw, I implemented this feature a few minutes ago, you can get it by compiling trunk.
anonymous7 is correct, it will be part of 1.2. Adium 1.1 is the release where the finished code from SoC2006 will be integrated.
I'm using Xcode 3.0 on Leopard, and it works fine.
anonymous6: (it'd be nice if everybody would get some identity ;)
There's still some kind of dependency between XMPP acocunts and gateways. When you change your status on the XMPP account, the gateways change it, too (including going offline/online), so displaying them at the same level would be misleading.
btw, I implemented this feature a few minutes ago, you can get it by compiling trunk.
anonymous7 is correct, it will be part of 1.2. Adium 1.1 is the release where the finished code from SoC2006 will be integrated.
jay. thats nice.
what you said "when you change your status, the gateway will change status, too":
i think this is not necessarily the case. some gateways support special commands to set the individual gateway status.
when finally invisibility would be supported the case "gateway1 -> online" & "jabber -> offline" would equal to:
jabber -> invisible
gateway1-> online
what about some discussion here:
http://trac.adiumx.com/ticket/7328
what you said "when you change your status, the gateway will change status, too":
i think this is not necessarily the case. some gateways support special commands to set the individual gateway status.
when finally invisibility would be supported the case "gateway1 -> online" & "jabber -> offline" would equal to:
jabber -> invisible
gateway1-> online
what about some discussion here:
http://trac.adiumx.com/ticket/7328
unfortunately its not possible to reopen tickets.
http://trac.adiumx.com/ticket/7319#comment:3
shouldn't we show the account status in the menu duck, too if we already show it in the service menu?
Post a Comment
http://trac.adiumx.com/ticket/7319#comment:3
shouldn't we show the account status in the menu duck, too if we already show it in the service menu?