Menu
▾
▴
gaim-bnet-devel
|
From: Don S. <do...@se...> - 2005-01-26 17:00:36
|
I'd like to release gaim-bnet-0.1.0. We still have one RFE, #1101711, regarding handling of response for /where and /whois. Currently this is dumped to the debug log. Could we try and capture it like we do for /stats and present it in a dialog? Should we just release without this? Don. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-27 00:29:18
|
On 01/26/05 17:59:56, Don Seiler wrote: > I'd like to release gaim-bnet-0.1.0. >=20 > We still have one RFE, #1101711, regarding handling of response for > /where and /whois. Currently this is dumped to the debug log. Could > we try and capture it like we do for /stats and present it in a =20 > dialog? >=20 > Should we just release without this? Well, for our buddies those info are avaiable by tooltip text :) If you think we need a *check_if_online* feature, for people who aren't =20 in our buddy list, I can easily write it... cya |
|
From: Don S. <do...@se...> - 2005-01-27 14:42:16
|
On 00:36 Thu 27 Jan , Zilo wrote: > If you think we need a *check_if_online* feature, for people who aren't = =20 > in our buddy list, I can easily write it... Basically any functionality that is supported by battle.net we should have an interface for. We shouldn't have to ever use the "raw commands" interface. Also this sounds like a bug: I added myself to my buddy list, and it says I'm offline. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-27 14:58:43
|
On 01/27/05 15:41:58, Don Seiler wrote: > On 00:36 Thu 27 Jan , Zilo wrote: > > If you think we need a *check_if_online* feature, for people who > aren't > > in our buddy list, I can easily write it... >=20 > Basically any functionality that is supported by battle.net we should > have an interface for. We shouldn't have to ever use the "raw > commands" interface. I wrote it in my last patch. > Also this sounds like a bug: I added myself to my buddy list, and it > says I'm offline. This is why the server send a different reply to /where (or /whois) =20 messages directed to a generic user or to yourself... do I have to =20 consider this case too? There's no reason to add myself to my buddy list... I think. cya |
|
From: Don S. <do...@se...> - 2005-01-27 15:26:16
|
On 15:05 Thu 27 Jan , Zilo wrote: > This is why the server send a different reply to /where (or /whois) =20 > messages directed to a generic user or to yourself... do I have to =20 > consider this case too? >=20 > There's no reason to add myself to my buddy list... I think. Normally you are right. I just wanted to test a case where a buddy was online because none of my other buddies are online. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-27 15:43:42
|
On 01/27/05 16:25:55, Don Seiler wrote: > [...] > Normally you are right. I just wanted to test a case where a buddy > was online because none of my other buddies are online. Well you can take a look at Public Chat 1 :) cya |
|
From: Don S. <do...@se...> - 2005-01-27 16:18:50
|
On 15:49 Thu 27 Jan , Zilo wrote: > Well you can take a look at Public Chat 1 :) I don't get tooltips in chat room user list, and I didn't want to just add random people to my buddy list. But I did. I added a user in the Public Chat 1, and he showed up in my buddy list as offline as well. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-27 16:39:33
|
On 01/27/05 17:18:36, Don Seiler wrote: > On 15:49 Thu 27 Jan , Zilo wrote: > > Well you can take a look at Public Chat 1 :) >=20 > I don't get tooltips in chat room user list, and I didn't want to =20 > just add random people to my buddy list. But I did. I added a user =20 > in the Public Chat 1, and he showed up in my buddy list as offline as =20 > well. You got my last patch? It fix an error in one of your last commit (memmem() -> strstr()) =20 causing my parse function to stop to work... try again after =20 patching... Anyway, in the chat room user list tooltips doesn't work, they popup =20 only in the buddy list... but it's a gaim choice. cya |
|
From: Don S. <do...@se...> - 2005-01-27 17:03:57
|
On 16:46 Thu 27 Jan , Zilo wrote: > You got my last patch? > It fix an error in one of your last commit (memmem() -> strstr()) =20 > causing my parse function to stop to work... try again after =20 > patching... I was told using memmem() is not desirable. Can we do this with strstr()? > Anyway, in the chat room user list tooltips doesn't work, they popup =20 > only in the buddy list... but it's a gaim choice. That's what I figured. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-01-27 19:22:35
|
On 01/27/05 18:03:48, Don Seiler wrote: > On 16:46 Thu 27 Jan , Zilo wrote: > > You got my last patch? > > It fix an error in one of your last commit (memmem() -> strstr()) > > causing my parse function to stop to work... try again after > > patching... >=20 > I was told using memmem() is not desirable. Can we do this with > strstr()? char *strstr(const char *haystack, const char *needle); strstr() consider needle len =3D strlen(needle), but in my code this =20 isn't always true... so we must use memmem() instead :P cya |
|
From: Don S. <do...@se...> - 2005-02-03 15:26:21
|
Alright I applied the latest patch to fix the multiple-chan bug. Right now the only outstanding bug is #1111075, where I can add a buddy to my blist multiple times. This caused some crashing when I tried to load gaim-bnet account afterwards. What does protocol respond when trying to add friend again? I know that the friend was only in the friends list once. I'd like to fix this bug and kick out a release. We can do squelch/unsquelch privacy in 0.2.0. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Zilo <ko...@gm...> - 2005-02-03 19:24:17
|
On 02/03/05 16:25:54, Don Seiler wrote: > Alright I applied the latest patch to fix the multiple-chan bug. > Right now the only outstanding bug is #1111075, where I can add a =20 > buddy to my blist multiple times. This caused some crashing when I =20 > tried to load gaim-bnet account afterwards. What does protocol =20 > respond when trying to add friend again? I know that the friend was =20 > only in the friends list once. Yes, the server reply with an ERROR message and ignore the second =20 request; as what I see, is gaim who use a strange politic :/ Btw, as I wrote some day ago, I started to write a new plugin called =20 gaim-bnetg (the name is really similar, I know... but I didn't find =20 anything else)... today I created a new project on sourceforge and put =20 my src there. Before, I was thinking to upload gaim-bnetg in our repository(*) but to =20 improve my cvs experience I preferred to start a new project from the =20 beginning :P The code *simply* login to Battle.Net server for now, but I the hardest =20 is done, 'cause of now I don't have to think abount cdkey/hashing =20 functions anymore :) The GAMES protocol offers two new very useful commands: one to list =20 avaiable channels, and another one to create a new account. And I want you to join in my project also, this was just a proof to see =20 better how sourceforge works... don't think bad :) > I'd like to fix this bug and kick out a release. We can do > squelch/unsquelch privacy in 0.2.0. Sure. cya (*) During the import of gaim-bnetg I mistyped a char and used /cvsroot/=20 gaim-bnet root path instead of /cvsroot/gaim-bnetg... so by mystake I =20 created a copy also on our repository... (I didn't thinked to have =20 write access... ?) Anyway I tryied to remove it but I failed... maybe I don't have =20 permission to or don't know the right command... sorry I whouldn't make =20 this problem :P |
|
From: Don S. <do...@se...> - 2005-02-03 20:11:24
|
On 19:30 Thu 03 Feb , Zilo wrote: > Yes, the server reply with an ERROR message and ignore the second =20 > request; as what I see, is gaim who use a strange politic :/ Yeah then I'll look and see if I can fix this later. > Btw, as I wrote some day ago, I started to write a new plugin called =20 > gaim-bnetg (the name is really similar, I know... but I didn't find =20 > anything else)... today I created a new project on sourceforge and put = =20 > my src there. > Before, I was thinking to upload gaim-bnetg in our repository(*) but to = =20 > improve my cvs experience I preferred to start a new project from the =20 > beginning :P We can still create a separate repository for you to write to. Up to you. No need to have a separate project since these two seem pretty related. Doesn't matter to me though. Don. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Don S. <do...@se...> - 2005-02-03 20:50:56
|
On 19:30 Thu 03 Feb , Zilo wrote:
> Yes, the server reply with an ERROR message and ignore the second =20
> request; as what I see, is gaim who use a strange politic :/
Here is the problem I think. When I use gaim to add a buddy, it first
calls bnet_buddy_add(), which adds the buddy to the local list. It then
requests the remote friends list and compares. However in
bnet_buddy_add() I see this block of code:
if (!g_hash_table_lookup(conn->buddies, norm)) {
b =3D bnet_buddy_new(norm, buddy->name);
if (conn->welcome)
b->new_entry =3D TRUE;
g_hash_table_insert(conn->buddies, b->norm, b);
bnet_conn_request_friends_list(conn);
}
I may be reading this wrong, but this to me seems to be checking for the
existance of the buddy in the list, and only adding if it doesn't exist.
Why would this be failing?
Another issue is perhaps we should do the remote check first, and return
any error that comes from that. Although I can see the merit in doing a
local check first. Either way we are currently ignoring the results of
the /friends add attempt.
--=20
Don Seiler
do...@se...
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041
|
|
From: Zilo <ko...@gm...> - 2005-02-03 21:31:29
|
On 02/03/05 21:50:33, Don Seiler wrote:
> Here is the problem I think. When I use gaim to add a buddy, it =20
> first calls bnet_buddy_add(), which adds the buddy to the local list. =20
> It then requests the remote friends list and compares. However in
> bnet_buddy_add() I see this block of code:
>=20
>=20
> if (!g_hash_table_lookup(conn->buddies, norm)) {
> b =3D bnet_buddy_new(norm, buddy->name);
> if (conn->welcome)
> b->new_entry =3D TRUE;
> g_hash_table_insert(conn->buddies, b->norm, b);
> bnet_conn_request_friends_list(conn);
> }
>=20
> I may be reading this wrong, but this to me seems to be checking for
> the existance of the buddy in the list, and only adding if it doesn't
> exist.
> Why would this be failing?
This code checks the existance of the buddy in our conn->buddies list, =20
not in the Gaim one. The problem is that inside bnet_buddy_add we have =20
no way to block gaim to add the buddy to its list and so show it twice. =20
At least, I don't know how we can inform gaim that we want refuse to =20
add the buddy.
I see now that the MSN plugin, for an invalid buddy, let gaim add it, =20
and then remove it after it checked it doesn't exist: maybe we can do =20
the same thing with duplicated ones. I think it's the only way...
cya
|
|
From: Don S. <do...@se...> - 2005-02-03 21:48:20
|
On 21:38 Thu 03 Feb , Zilo wrote: > I see now that the MSN plugin, for an invalid buddy, let gaim add it, =20 > and then remove it after it checked it doesn't exist: maybe we can do =20 > the same thing with duplicated ones. I think it's the only way... That sounds fine to me as long as it works! --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Don S. <do...@se...> - 2005-02-04 19:20:11
|
Why are we calling gaim_blist_add_buddy() from bnet_buddy_hard_lookup()? --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
|
From: Don S. <do...@se...> - 2005-02-04 19:30:40
|
On 14:50 Thu 03 Feb , Don Seiler wrote:
> if (!g_hash_table_lookup(conn->buddies, norm)) {
> b =3D bnet_buddy_new(norm, buddy->name);
> if (conn->welcome)
> b->new_entry =3D TRUE;
> g_hash_table_insert(conn->buddies, b->norm, b);
> bnet_conn_request_friends_list(conn);
> }
>=20
> I may be reading this wrong, but this to me seems to be checking for the
> existance of the buddy in the list, and only adding if it doesn't exist.
> Why would this be failing?
It turns out that this block does indeed catch things, but the buddy is
still added to the list.
--=20
Don Seiler
do...@se...
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041
|
|
From: Don S. <do...@se...> - 2005-02-04 19:44:09
|
On 14:50 Thu 03 Feb , Don Seiler wrote:
> if (!g_hash_table_lookup(conn->buddies, norm)) {
> b =3D bnet_buddy_new(norm, buddy->name);
> if (conn->welcome)
> b->new_entry =3D TRUE;
> g_hash_table_insert(conn->buddies, b->norm, b);
> bnet_conn_request_friends_list(conn);
> }
I committed a fix. I added an "else" to this if block, and call
gaim_blist_remove_buddy(buddy) if the buddy already exists. Worked well
in my tests.
That was the last bug in our tracker. I have the privacy RFE that I
might try and do this weekend if I don't get sucked up in Diablo II.
--=20
Don Seiler
do...@se...
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041
|
|
From: Zilo <ko...@gm...> - 2005-02-04 22:35:12
|
On 02/04/05 20:42:50, Don Seiler wrote: > [...] > I committed a fix. I added an "else" to this if block, and call > gaim_blist_remove_buddy(buddy) if the buddy already exists. Worked > well in my tests. Perfect, it works also with me :) > That was the last bug in our tracker. I have the privacy RFE that I > might try and do this weekend if I don't get sucked up in Diablo II. Well I'm almost done with gaim-bnetg too, it login and do only a few =20 things now, but the big work is done. cya |
|
From: Don S. <do...@se...> - 2005-02-05 19:44:14
|
On 22:42 Fri 04 Feb , Zilo wrote: > Perfect, it works also with me :) Alright. If you guys have spare time, feel free to test the privacy functions. Otherwise I'm going to try and contact Daniel Atallah for the win32 build stuff and prepare for a release. Don. --=20 Don Seiler do...@se... Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xFC87F041 Fingerprint: 0B56 50D5 E91E 4D4C 83B7 207C 76AC 5DA2 FC87 F041 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X