From: Felipe C. <al5...@ma...> - 2002-11-07 21:49:06
|
Hi all, First I want to say that I think that its important to know the nick of your buddies, if you change your nick in irc you want other people to know it (sometimes). It all depends on the person and the instant messenger, but for a lot of people in msn the nick you set is very important. That's why I think that if the protocol supports something like a remote nick, then we should have the chance to know which is the nick our buddy has set for himself. Currently there is a patch made by robot101 that automatically changes the msn friendly names if you want to, but I don't like that approach. I think you should have the chance to decide for which buddies to update automatically, and for which you set a static alias. On either case, you should have some way to check the friendly name your buddy set, for example in a tooltip. I did a patch a while ago that worked fairly well, but my lap got screwed and I didn't keep hacking gaim. I will try to make the best patch I can to allow this behavior but I'll like to know if you guys will like this approach. Cheers. -- Felipe Contreras |
From: Luke S. <lsc...@gm...> - 2002-11-08 02:06:34
|
Doing things on a per-buddy basis will be far easier when the xml blist is in place. untill then, it would have to be added by adding fields to the existing format, and re-writting the parser only to re-write it again as we move to the xml based blist. luke On Thu, Nov 07, 2002 at 03:51:11PM -0600, Felipe Contreras wrote: > Hi all, > > First I want to say that I think that its important to know the nick of > your buddies, if you change your nick in irc you want other people to know > it (sometimes). It all depends on the person and the instant messenger, but > for a lot of people in msn the nick you set is very important. > > That's why I think that if the protocol supports something like a remote > nick, then we should have the chance to know which is the nick our buddy > has set for himself. > > Currently there is a patch made by robot101 that automatically changes the > msn friendly names if you want to, but I don't like that approach. I think > you should have the chance to decide for which buddies to update > automatically, and for which you set a static alias. On either case, you > should have some way to check the friendly name your buddy set, for example > in a tooltip. > > I did a patch a while ago that worked fairly well, but my lap got screwed > and I didn't keep hacking gaim. I will try to make the best patch I can to > allow this behavior but I'll like to know if you guys will like this > approach. > > Cheers. > > -- > Felipe Contreras > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
From: Robert M. <rob...@de...> - 2002-11-08 14:56:17
|
On Thu, Nov 07, 2002 at 09:06:27PM -0500, Luke Schierer wrote: > Doing things on a per-buddy basis will be far easier when the xml blist > is in place. untill then, it would have to be added by adding fields to > the existing format, and re-writting the parser only to re-write it > again as we move to the xml based blist. > luke I disagree with this on principle. I like the way that currently, Gaim keeps next to no state about my buddies other than who they are, and what I call them. If lots of options, especially useful ones, become associated with each buddy, it will become increasingly confusing, time-consuming and unintuitive to get the correct behaviour by setting an option for each and every buddy. I would rather see an option per account with 'Display remote names' or such. But not per buddy. Please! I also don't see the need to have a local name if you've opted to use the remote one, but I see the benefit of showing the remote name if you've opted to use a local one. I'd prefer that to changing the local alias, or even displaying the remote name, because I'd find that intensely annoying. My patch is just the least evil way to implement this functionality for people who are used to having MSN do it. As an aside, why is all of Oscar's capability stuff implemented in the blist and not the Oscar prpl? Can someone move that? It will make the blist code quite a bit simpler. =) Regards, Rob |
From: <lsc...@re...> - 2002-11-08 15:42:53
|
On Fri, Nov 08, 2002 at 02:55:43PM +0000, Robert McQueen wrote: > On Thu, Nov 07, 2002 at 09:06:27PM -0500, Luke Schierer wrote: > > Doing things on a per-buddy basis will be far easier when the xml blist > > is in place. untill then, it would have to be added by adding fields to > > the existing format, and re-writting the parser only to re-write it > > again as we move to the xml based blist. > > luke > > I disagree with this on principle. I like the way that currently, Gaim > keeps next to no state about my buddies other than who they are, and > what I call them. If lots of options, especially useful ones, become > associated with each buddy, it will become increasingly confusing, > time-consuming and unintuitive to get the correct behaviour by setting > an option for each and every buddy. I would rather see an option per > account with 'Display remote names' or such. But not per buddy. Please! I agree. And even if we did allow per-buddy options, we'd want a way to set the default behavior, precisely so that you do not have to set the same behavior for several hundred buddies. that being said, the amount of information stored per-buddy has to increase in some way. icq and jabber allow you to over-ride your global status on a per-buddy basis, and this would be a nice feature, BUT IT SHOULD WAIT. it should wait precisely because extending the current blist format will make things more confusing, and because the xml blist will allow us to add this sort of detail with a minimal amount of increased confusion in the text file and also because the increased delay while we work out the ui issues in the move to gtk2 cannot help but contribute to our ability to come up with a decent ui for this latter. right now the move to gtk2 is a HUGE part of gaim's current development. it is introducing a HUGE number of bugs (we have had as many bugs opened since gtk2 as were left open from before it total). the last thing we need to be doing is trying to introduce a large number of new features before we have replicated the functionality we had before gtk2. > > I also don't see the need to have a local name if you've opted to use > the remote one, but I see the benefit of showing the remote name if > you've opted to use a local one. I'd prefer that to changing the local > alias, or even displaying the remote name, because I'd find that > intensely annoying. My patch is just the least evil way to implement > this functionality for people who are used to having MSN do it. given how evil msn friendly names can be, i can see why someone might want to see the friendly name but not set their alias to it. > > As an aside, why is all of Oscar's capability stuff implemented in the > blist and not the Oscar prpl? Can someone move that? It will make the > blist code quite a bit simpler. =) this is probly a good idea. luke -- -This email is made of 100% recycled electrons. |
From: Rob F. <ro...@fa...> - 2002-11-08 16:48:50
|
> > >>As an aside, why is all of Oscar's capability stuff implemented in the >>blist and not the Oscar prpl? Can someone move that? It will make the >>blist code quite a bit simpler. =) >> >> > >this is probly a good idea. > > Because plugins didn't exist when Oscar was introduced into gaim... =) |
From: Felipe C. <al5...@ma...> - 2002-11-08 16:18:22
|
On Thu, Nov 07, 2002 at 09:06:27PM -0500, Luke Schierer wrote: > Doing things on a per-buddy basis will be far easier when the xml blist > is in place. untill then, it would have to be added by adding fields to > the existing format, and re-writting the parser only to re-write it > again as we move to the xml based blist. > luke I'm not talking about a lot of per-buddy functionality. This is the way I touhgt it should be done: If I have an alias specified in my .blist file, then that alias should be used, if not, then the nick should be automatically updates. As easy as that. That is talking about automatic nick updates, but independently of that I think a tooltip showing the remote nick whould help a lot. -- Felipe Contreras |
From: <lsc...@re...> - 2002-11-08 16:22:57
|
On Fri, Nov 08, 2002 at 10:20:07AM -0600, Felipe Contreras wrote: > On Thu, Nov 07, 2002 at 09:06:27PM -0500, Luke Schierer wrote: > > Doing things on a per-buddy basis will be far easier when the xml blist > > is in place. untill then, it would have to be added by adding fields to > > the existing format, and re-writting the parser only to re-write it > > again as we move to the xml based blist. > > luke > > I'm not talking about a lot of per-buddy functionality. This is the way I > touhgt it should be done: > > If I have an alias specified in my .blist file, then that alias should be > used, if not, then the nick should be automatically updates. As easy as > that. > > That is talking about automatic nick updates, but independently of that I > think a tooltip showing the remote nick whould help a lot. that friendly name goes into the alias feild. if you auto-update it once, you will then have an alias, and it will not be updated again. how then would this add anything? luke -- -This email is made of 100% recycled electrons. |
From: Felipe C. <al5...@ma...> - 2002-11-08 17:00:39
|
On Fri, Nov 08, 2002 at 11:22:54AM -0500, lsc...@re... wrote: > On Fri, Nov 08, 2002 at 10:20:07AM -0600, Felipe Contreras wrote: > > On Thu, Nov 07, 2002 at 09:06:27PM -0500, Luke Schierer wrote: > > > Doing things on a per-buddy basis will be far easier when the xml blist > > > is in place. untill then, it would have to be added by adding fields to > > > the existing format, and re-writting the parser only to re-write it > > > again as we move to the xml based blist. > > > luke > > > > I'm not talking about a lot of per-buddy functionality. This is the way I > > touhgt it should be done: > > > > If I have an alias specified in my .blist file, then that alias should be > > used, if not, then the nick should be automatically updates. As easy as > > that. > > > > That is talking about automatic nick updates, but independently of that I > > think a tooltip showing the remote nick whould help a lot. > > that friendly name goes into the alias feild. if you auto-update it once, you > will then have an alias, and it will not be updated again. how then would this > add anything? That has to be changed, the friendly name should go on another field, let's say 'remote_alias', the 'alias' is never auto-updated, you specify it or not. -- Felipe Contreras |
From: Rob F. <ro...@fa...> - 2002-11-08 17:05:50
|
> > >That has to be changed, the friendly name should go on another field, let's >say 'remote_alias', the 'alias' is never auto-updated, you specify it or >not. > > > This is where thing start to get messy. I don't want to have five million different fields for a user's alias... |
From: Felipe C. <al5...@ma...> - 2002-11-08 17:49:08
|
On Fri, Nov 08, 2002 at 12:00:57PM -0500, Rob Flynn wrote: > > > > > >That has to be changed, the friendly name should go on another field, let's > >say 'remote_alias', the 'alias' is never auto-updated, you specify it or > >not. > > > > > > > > This is where thing start to get messy. I don't want to have five > million different fields for a user's alias... Not millions, just two, and I don't think it's bad, if in reality you have an alias for your buddy and your buddy have it's own nick why not have both somewhere? Anyway, if we don't have the remote_alias then we are suposing there is only one alias, and what if I don't want to change the alias I gave to my buddy, but I want to check which remote alias he has set? What if suddenly a lot of my friends use huge remote aliases, but my girl friend has a very special nick for me... I whould like to have an alias for those buddies, and the nick of my girl friend to be auto-updated. Which are the other purposals that fit those situations? -- Felipe Contreras |
From: Robert M. <rob...@de...> - 2002-11-09 14:26:43
|
On Fri, Nov 08, 2002 at 11:02:00AM -0600, Felipe Contreras wrote: > That has to be changed, the friendly name should go on another field, let's > say 'remote_alias', the 'alias' is never auto-updated, you specify it or > not. > > -- > Felipe Contreras Now I understand what you want - I agree. This is ideal. We need to add a field to the buddy struct to hold the remote name if we want to put it into the tooltip anyway. Then we need the same kind of logic we have for aliases to consider the fields. Could I suggest adding a function such as display_name that takes a *buddy and returns a pointer to the correct one, then we won't ever have to do this big run of replacing lots of references to screennames with alias|screen-name, and now alias|remote-name|screen-name. This centralised function should be easy to modify in the advent of persistent/XML/etc buddy lists and will make it easy to get the right name out of a buddy pointer, without repeating identical logic all over the place like we do now. Regards, Rob p.s. Note the implicit change of paradigm from buddies-as-names to buddies-as-entities which we need in the long run to do things like person support properly. It's necessary. Nobody said it would be easy. :P |
From: Felipe C. <al5...@ma...> - 2002-11-09 20:49:33
Attachments:
aliasing_renaming.diff
|
On Sat, Nov 09, 2002 at 02:26:03PM +0000, Robert McQueen wrote: > On Fri, Nov 08, 2002 at 11:02:00AM -0600, Felipe Contreras wrote: > > That has to be changed, the friendly name should go on another field, let's > > say 'remote_alias', the 'alias' is never auto-updated, you specify it or > > not. > > > > -- > > Felipe Contreras > > Now I understand what you want - I agree. This is ideal. We need to add > a field to the buddy struct to hold the remote name if we want to put it > into the tooltip anyway. Then we need the same kind of logic we have for > aliases to consider the fields. Ok, what do you think of this logic: Instead of just 'show' there are 3 things: show: what will be displayed alias: local alias, what we set nick: remote nick, what the server says Whenever we set an alias, show is that alias, if not, then show is the remote nick, if there is no remote nick, well, then it's the just the name. Sure, we might not really need the show field. > Could I suggest adding a function such as display_name that takes a > *buddy and returns a pointer to the correct one, then we won't ever have > to do this big run of replacing lots of references to screennames with > alias|screen-name, and now alias|remote-name|screen-name. This > centralised function should be easy to modify in the advent of > persistent/XML/etc buddy lists and will make it easy to get the right > name out of a buddy pointer, without repeating identical logic all over > the place like we do now. Hmm, I don't know how that will work, but anyway I think we don't need to wait if there is someone (me) that wants to make this work cleanly now, and whenever the new buddy lists are implemented to update the code. I'm attaching a patch that doesn't change much, just make all aliasing and renaming of buddies more cleaner. BTW. prpls (msn, jabber) shouldn't be using struct buddy, right? -- Felipe Contreras |
From: Luke S. <lsc...@gm...> - 2002-11-10 00:15:27
|
On Sat, Nov 09, 2002 at 02:51:58PM -0600, Felipe Contreras wrote: > On Sat, Nov 09, 2002 at 02:26:03PM +0000, Robert McQueen wrote: > > On Fri, Nov 08, 2002 at 11:02:00AM -0600, Felipe Contreras wrote: > > > That has to be changed, the friendly name should go on another field, let's > > > say 'remote_alias', the 'alias' is never auto-updated, you specify it or > > > not. > > > > Now I understand what you want - I agree. This is ideal. We need to add > > a field to the buddy struct to hold the remote name if we want to put it > > into the tooltip anyway. Then we need the same kind of logic we have for > > aliases to consider the fields. > > Ok, what do you think of this logic: > > Instead of just 'show' there are 3 things: > show: what will be displayed > alias: local alias, what we set > nick: remote nick, what the server says > > Whenever we set an alias, show is that alias, if not, then show is the > remote nick, if there is no remote nick, well, then it's the just the name. > Sure, we might not really need the show field. > > > Could I suggest adding a function such as display_name that takes a > > *buddy and returns a pointer to the correct one, then we won't ever have > > to do this big run of replacing lots of references to screennames with > > alias|screen-name, and now alias|remote-name|screen-name. This > > centralised function should be easy to modify in the advent of > > persistent/XML/etc buddy lists and will make it easy to get the right > > name out of a buddy pointer, without repeating identical logic all over > > the place like we do now. > > I'm attaching a patch that doesn't change much, just make all aliasing and > renaming of buddies more cleaner. > > BTW. prpls (msn, jabber) shouldn't be using struct buddy, right? I do not think that the prpls can avoid using struct buddy and struct group. i know oscar uses them. luke -- -This email is made of 100% recycled electrons. |
From: Nathan W. <fac...@fa...> - 2002-11-10 00:46:48
|
On Sat, Nov 09, 2002 at 02:51:58PM -0600, Felipe Contreras wrote: <snip> > BTW. prpls (msn, jabber) shouldn't be using struct buddy, right? <snip> No. PRPLs are part of the core, so they have every right to look at buddy and group structs. =20 Nathan --=20 Nathan Walp || fac...@fa... GPG Fingerprint: || http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E |