[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    [Kopete-devel] Re: kdenonbeta/kopete/libkopete
From:       Matt Rogers <matt () matt ! rogers ! name>
Date:       2003-07-07 1:49:12
[Download RAW message or body]

On Sunday 06 July 2003 04:45 pm, Grzegorz Jaskiewicz wrote:
> Ok, i'll try to think about something that will satisfy both of as.
> Goals:
> * information with protocol name, ID and nick (in case their are not the
> same).
> * information with text status, in case protocol handles that
> * it should be changed if any of above is changed.
>

This is something that should probably be discussed. I recommend a new thread.

> Did i missed something ?
> If you will agree with that, i will write something.
> As for now , please leave it as it is.

IMHO, we should remove it until we find something better. The reason for this 
is if it's left in there, people may eventually use it. Once it gets used, 
people will expect it to be there. Until we find a better solution the 
current one should be removed, IMHO. Therefore, your commit that adds this as 
well as the pieces of Gadu should removed as well. 

I agree with Martijn in that I am also not opposed to the information you want 
to provide, but the way you currently do it. I'm also in agreement with 
Martijn on the other points so i won't repeat them here. 

Matt

> On Sun, 6 Jul 2003, Martijn Klingens wrote:
> > On Sunday 06 July 2003 21:46, Grzegorz Jaskiewicz wrote:
> > > I told you allready, becouse I want to display some more information !
> > > for god sake, there is need for that. Maybe not in your plugin, but in
> > > gadu for sure and in jabber fe.
> >
> > ***WHAT*** more information? "more information" to me is as generic as "i
> > don't know, but it might come in handy some day in the distant future for
> > Kopete 5.6.7". In other words, it's only MORE reason to revert...
> >
> > > I want to display reason beside of status, i want to give an
> > > information about nick name and protocol - becouse it is usefull
> > > information. Maybe not protocol name it self, but anyway.
> >
> > All this is already in libkopete. Can be called directly from your
> > tooltip code. No need for an extra method and *CERTAINLY* not a need for
> > a _virtual_ method.
> >
> > > It does not change anything, you don't have to use it.
> >
> > You add another virtual. Adding virtuals is BIC and as such I'd better
> > see a pretty darn good excuse for adding them while we're trying to
> > stabilize our API.
> >
> > Although we formally don't have BC yet (and can't have yet either) I at
> > least would like everyone to be aware of BC rules and think twice before
> > doing BIC changes. This one surely doesn't qualify in my rulebook. It
> > adds **NOTHING** that isn't already there, besides more confusion.
> >
> > > I hate callbacks, and this will be total disaster - that is why i did
> > > that with fullAccountName();
> >
> > Better explain the need for either of them. I don't see a need for either
> > callbacks or your fullAccountName().
> >
> > > Kopete can use this to display more information about account it self,
> > > fe in chat box or others (maybe some which don't exists yet).
> >
> > And why do you need a whole new virtual method to do all that?
> >
> > > Bullshit, one of the reasons i joined kopete team was lack of
> > > userfilendliness. And this is not only my opinion.
> >
> > And why is a virtual more userfriendly than a normal convenience method,
> > or even a simple i18n( "%1 %2 %3" ).arg( "1", "2", "3" ) at some
> > strategic places?
> >
> > I am *NOT* opposed to the _information_ you want to provide (not at all),
> > but I am *STRONGLY* opposed to the _way_ you want to provide it.
>
> _______________________________________________
> Kopete-devel mailing list
> Kopete-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kopete-devel
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]