pidgin-devel — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel

Re: [Gaim-devel] Oscar FT update

[William T. M. <wt...@du...>]

On Sun, Nov 10, 2002 at 02:23:47PM -0500, Sean Egan wrote:
> I share Chip's concern.  When I first sat down to write the file
> transfer GUI was the first time I looked at the API and I noticed this
> right away.  Wouldn't it be better for the prpl to handle its sockets
> itself and have its own callback which can strip headers and stuff and
> then call a generic function with a pointer and a length?  That would
> seem to be the optimal solution.

I agree that this seems like a good generic solution, given the
situation Chip described.  This wasn't really an oversight in the API,
but rather an intentional assumption.  Although I admit it was a poor
one, as Paco and others have pointed out.

The main drawback to your method is that there will be some
duplication of code in each of prpls (the read/write while loops).  I
supppose it's worth it to have a simpler interface, though.  I'll work
on implementing something like what you suggest.

> Apart from writing gtkcellrendererprogress, I've not started the file
> transfer GUI--Rob may have started--either way changes to ft.c would not
> interfere with it much, I'm sure.

OK, I'll focus on these changes to the generic interface then, since
it seems to be most in need of work.

-- Wil
P.S.  Not to nag, but I hope someone remembers to apply my patch that
started this thread. :-)

Re: [Gaim-devel] Oscar FT update

[Ethan B. <ebl...@cs...>]

William T. Mahan spake unto us the following wisdom:
> On Sun, Nov 10, 2002 at 03:14:37AM -0800, Christian Hammond wrote:
> >
> > Basically, I need to be able to read in x amount of bytes, then say,
> > "Okay, you get 'y' many bytes and stick it in the file, and then call
> > me back when you're done and we'll continue this after I rest a bit."
>=20
> You're right, there's no easy way to do that using the current API.  I
> was hoping that no sane protocol would break up a file and send
> headers in the middle, since it's not necessary over TCP.  Apparently
> that was a bad assumption. :-(

=2E.. But what if you want to interleave FT and other info on the same
stream?  I can see this as being a very reasonable thing to do.

Ethan

--=20
And if I claim to be a wise man / it surely means that I don't know.
                -- Kansas, "Carry on Wayward Son"

Re: [Gaim-devel] Oscar FT update

[William T. M. <wt...@du...>]

On Sun, Nov 10, 2002 at 03:14:37AM -0800, Christian Hammond wrote:
>
> Basically, I need to be able to read in x amount of bytes, then say,
> "Okay, you get 'y' many bytes and stick it in the file, and then call
> me back when you're done and we'll continue this after I rest a bit."

You're right, there's no easy way to do that using the current API.  I
was hoping that no sane protocol would break up a file and send
headers in the middle, since it's not necessary over TCP.  Apparently
that was a bad assumption. :-(

It shouldn't be too hard to allow what you want (I'm thinking just add
another parameter to transfer_in_do() specifying the number of bytes
to _actually_ read).  But yes, an API change is necessary if this is
what you need.

> Oh, and while I'm here... the fprintf and fscanf calls in ft_callback
> seem... unnecessary. I'm tired, so please forgive any errors that may
> cause an endless loop of kernel panics, but wouldn't these be better?
> 
> read(xfer->file, buf, remain);

Yes, I'm aware that this would be much better than calling fscanf for
every byte, but as I mentioned I'm afraid making major changes to ft.c
would conflict with the GUI work.  Unless Sean says this wouldn't be a
problem?

-- Wil

Re: [Gaim-devel] Oscar FT update

[Christian H. <ch...@gn...>]

Off topic, but..

Got a question about your file transfer interface. I'm working on file
transfer for MSN, and MSN sends out little headers before each block
of data. The header is three bytes, and the 2nd and 3rd byte make up
the length of the data. So, the header is supposed to be read in and
then that number of bytes is supposed to be read in.

I'm not quite sure how to do this with the current API. It seems I can
setup a function that it will keep calling to do something with the
data, but I don't want to manually store the data in a buffer and
parse it myself. Maybe what I want can be done with the current API,
but I don't see how...

Basically, I need to be able to read in x amount of bytes, then say,
"Okay, you get 'y' many bytes and stick it in the file, and then call
me back when you're done and we'll continue this after I rest a bit."

Make sense? I hope so, because I'm not repeating it!

.. Unless it didn't make sense, in which case I'll say it again, only
differently.

Oh, and while I'm here... the fprintf and fscanf calls in ft_callback
seem... unnecessary. I'm tired, so please forgive any errors that may
cause an endless loop of kernel panics, but wouldn't these be better?

write(xfer->file, buf, rt);

and

read(xfer->file, buf, remain);

That would cut out the loops and the overly (for this case) expensive
calls to fprintf and fscanf.

And I want a puppy.

Christian

-- 
Christian Hammond         <>  The GNUpdate Project
ch...@gn...      <>  http://www.gnupdate.org/
   "My brothers and sisters all hated me cause I was an only child."
      -- Weird Al Yankovich

[Gaim-devel] Oscar FT update

[William T. M. <wt...@du...>]

Hi,

This patch makes a few minor changes to Oscar file transfer.  They
should all be uncontroversial; please apply.

* Add some comments I inadvertently left out of my last patch.
* Fix a double-free that occurs when connections time out.
* Correct a bug causing filenames to be truncated by 4 characters on
  some clients.
* Preserve directory structure when sending multiple files.
* Handle (throw away) resource forks sent by Mac clients.

BTW, there is still stuff to be done for file transfer--I'll try to
work on them as time permits, but here's my list for now:
* Reverse connections for receiving from behind a firewall (reverse
connections for sending should work)
* Connections through ars.aol.oscar.com:5190 when both sides are
behind a firewall (I have the protocol for this)
* Support non-ASCII filenames--it seems they are sent over the network
as UCS-2 so we need to convert to/from UTF-8
* Either implement getfile support or rip out all the obsolete code in
ft.c (I'm leaning toward the latter :)
* Rewrite the generic FT code--I think the interface is OK, but my
current implementation has some race conditions.  To avoid conflicts I
don't plan to touch this until the FT GUI is finished.

-- Wil

Re: [Gaim-devel] Automatic friendly name update

[Nathan W. <fac...@fa...>]

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

Re: [Gaim-devel] Automatic friendly name update

[Luke S. <lsc...@gm...>]

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.

Re: [Gaim-devel] Automatic friendly name update

[Felipe C. <al5...@ma...>]

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

Re: [Gaim-devel] CVS gaim 0.60 crash on receipt of certain message - buffer overflow?

[Ka-Hing C. <ja...@ja...>]

On Sat, 2002-11-09 at 03:37, Alistair Phipps wrote:
> Hi all,
> 
> Using a CVS version of gaim 0.60 from about a week ago, gaim crashes 100% reproducibly whenever I receive a message with too many bits of text that get automatically turned into "URLs".  I haven't looked at the code, but am assuming that a buffer must be getting overflowed.  The message that first triggered the crash for me is attached to this email (it's the email filters from a webmail application).  It crashes gaim when sent via ICQ - other protocols not tested.
> 
> Sorry for not reporting this bug via the normal mechanism, but the bugs forum seems to be full of bugs that haven't been looked at/assigned and I figure a buffer overflow could be potentially important.
> 
> Note that Gaim 0.59.x has been tested and found to not crash - it's only 0.60.
> 
> I'm not subscribed to this list, so please cc me or respond to me directly with any questions.
> 
> Thanks,
> 
> Alistair
> ----

Next time please post it to sf bugtracker, preferably with a backtrace.
It is constantly checked, but sometimes the bugs are not reproducible
and so cannot be fixed. I created a bug report for you this time:

http://sourceforge.net/tracker/index.php?func=detail&aid=635979&group_id=235&atid=100235

Ka-Hing Cheung

Re: [Gaim-devel] Automatic friendly name update

[Robert M. <rob...@de...>]

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

[Gaim-devel] CVS gaim 0.60 crash on receipt of certain message - buffer overflow?

[Alistair P. <da...@th...>]

Hi all,

Using a CVS version of gaim 0.60 from about a week ago, gaim crashes 100% reproducibly whenever I receive a message with too many bits of text that get automatically turned into "URLs".  I haven't looked at the code, but am assuming that a buffer must be getting overflowed.  The message that first triggered the crash for me is attached to this email (it's the email filters from a webmail application).  It crashes gaim when sent via ICQ - other protocols not tested.

Sorry for not reporting this bug via the normal mechanism, but the bugs forum seems to be full of bugs that haven't been looked at/assigned and I figure a buffer overflow could be potentially important.

Note that Gaim 0.59.x has been tested and found to not crash - it's only 0.60.

I'm not subscribed to this list, so please cc me or respond to me directly with any questions.

Thanks,

Alistair

Re: [Gaim-devel] Automatic friendly name update

[Felipe C. <al5...@ma...>]

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

Re: [Gaim-devel] Automatic friendly name update

[Rob F. <ro...@fa...>]

>
>
>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...

Re: [Gaim-devel] Automatic friendly name update

[Felipe C. <al5...@ma...>]

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

Re: [Gaim-devel] Automatic friendly name update

[Rob F. <ro...@fa...>]

>
>
>>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... =)

Re: [Gaim-devel] Automatic friendly name update

[<lsc...@re...>]

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.

Re: [Gaim-devel] Automatic friendly name update

[Felipe C. <al5...@ma...>]

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

Re: [Gaim-devel] Automatic friendly name update

[<lsc...@re...>]

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.

Re: [Gaim-devel] Automatic friendly name update

[Robert M. <rob...@de...>]

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

[Gaim-devel] [patch] configure.ac versus perl, last time

[<ma...@cs...>]

One last time, my last revision of a now fully-tested (:P) patch to properly
detect libperl.

It's now in the tracker as
https://sourceforge.net/tracker/index.php?func=detail&aid=635375&group_id=235&atid=300235

I submit this a final time only because I just saw someone else run into this
exact problem elsewhere
(http://www.livejournal.com/talkread.bml?journal=debian&itemid=75214)
and I thought I should follow up on it.  From here, I'm done, and I will
stop bothering you guys. :)

-- 
      Evan Martin
ma...@cs...
  http://neugierig.org

Re: [Gaim-devel] Automatic friendly name update

[Luke S. <lsc...@gm...>]

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.

[Gaim-devel] Automatic friendly name update

[Felipe C. <al5...@ma...>]

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

[Gaim-devel] [Fwd: [Gaim-commits] Gaim Win32 Build and Aspell installers]

[Rob F. <ro...@fa...>]

-------- Original Message --------
Subject: [Gaim-commits] Gaim Win32 Build and Aspell installers
Date: Wed, 6 Nov 2002 12:07:58 -0800 (PST)
From: Herman Bloggs <her...@ya...>
To: gai...@li...



Hi,

Anyone building Win Gaim should install the updated
aspell-15.tar.gz and any dictionary installers that
you may have been using (update as of 3pm EST, Nov 6).
 The old installers used the PROGRAMFILES env var to
determine the aspell install path, which in the case
where PROGRAMFILES was anything other than C:\Program
Files, aspell would not be able to find its own
dictionaries.

Thanks Phroggie for bringing it up.

-Herman

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/


-------------------------------------------------------
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-commits mailing list
Gai...@li...
https://lists.sourceforge.net/lists/listinfo/gaim-commits

Re: [Gaim-devel] [patch] configure.ac and perl, try 2

[Evan D. <ev...@ca...>]

On Wed, 2002-11-06 at 00:01, ma...@cs... wrote:
> 
> Hey, me too.  I usually neglect users and accept patches.  It tends to
> alienate the users, but I figure I'd rather keep the people sending
> patches happy.  ;)

LogJam looks great. You keep doing what you're doing. :)

-- 
Evan Doughty
ev...@ca...

Re: [Gaim-devel] [patch] configure.ac and perl, try 2

[<ma...@cs...>]

On Tue, Nov 05, 2002 at 11:49:28PM -0500, Luke Schierer wrote:
> we are VERY baddly backloged. all of us have lives outside of gaim, most 
> of us are students, and have school taking up a majority of our time. so 
> gaim is reglegated to our free time, and in that time we are trying to 
> stuff in answering support issues, coding to fix bugs, coding to get 
> stuff done, and evaluating patches. the patches have suffered the worst 
> in the time crunch. 

Hey, me too.  I usually neglect users and accept patches.  It tends to
alienate the users, but I figure I'd rather keep the people sending
patches happy.  ;)

-- 
      Evan Martin
ma...@cs...
  http://neugierig.org