[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 <mattrogers () sbcglobal ! net>
Date:       2003-07-06 19:32:33
[Download RAW message or body]

On Sunday 06 July 2003 02:21 pm, Grzegorz Jaskiewicz wrote:
> On Sun, 6 Jul 2003, Martijn Klingens wrote:
> > On Sunday 06 July 2003 17:13, Grzegorz Jaskiewicz wrote:
> > > CVS commit by gj:
> > >
> > > Adding virtual QString fullAccountName() const; method to kopeteAccount
> > > class. This will, among probably other use - will be used as status
> > > icon tooltip text. It _DOESN'T_ break the API. By default (if not
> > > implemented) it returns accountId();
> > >
> > > (...)
> > >
> > > +QString KopeteAccount::fullAccountName() const
> > > +{
> > > +    return accountId();
> > > +}
> >
> > I still don't see why you want this.
> >
> > Why not use the same thing everywhere? Why would an account need to
> > provide its own implementation?
> >
> > Personally I'd rather see you revert this :(
>
> Does it do any harm ? It is very good thing, imho. Account can provide
> this way string that - in human readable form - gives full information
> about protocol, account ID and nickname.
>

I disagree here. While it doesn't do any harm, per se, I don't understand why 
we need this when we have the icon to tell them what protocol it is, and then 
we can have the tooltip be whatever is returned by accountID, eliminating the 
need for the fullAccountName method in the public API.

> This adds no harm to anything, and is needed to display information fe. in
> tooltip. And can be used by plugin it self to generate header of anything
> that requires that information.
>

It's another useless, unneeded public API method, IMO. 

> We can add callback for tooltip, that will ask application for string each
> time it want to be displayed. But do you want that ?
>

That would defeat the purpose. Besides, callbacks are not very C++ish. :P

> This does not break API.
> I have no reason to revert this, i even think it is very good idea to
> implement this function in each plugin. Small and do something usefull.
>

No, it doesn't break API, but it adds another unneeded function. I don't think 
it's a good idea to implement this in the each plugin. Give me two good 
examples of what we could use this for in plugins (other than the way you've 
used it in Gadu, which I don't see the point of).

> This is one step further to make kopete userfriendly
>

How would this be anymore user-friendly than what we already have?

Matt
_______________________________________________
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]