KIcon API replacement (Re: patches on kcolors)

[Kevin Ottens]

On Thursday 15 March 2012 21:21:07 David Faure wrote:
> On Thursday 15 March 2012 19:53:36 Kevin Ottens wrote:
> > Looks good to me. We probably want also an overload without the iconLoader
> > parameter I guess.
> 
> It default to 0, so I assume you mean for the case where someone wants to
> specify overlays and use the default iconloader, and a ,0 would look ugly?

Yes exactly.
 
> > ***
> > As a bonus, the crazy idea of the day:
> > What about making an exception to the casing rule for naming in cases like
> > that (not excluding there's more than K/QIcon matching that pattern) and
> > going for:
> > namespace KDE {
> > 
> >     QIcon Icon(...);
> > 
> > }
> > 
> > Client code would then look like:
> > QIcon i = KDE::Icon("foo");
> > instead of:
> > QIcon i = KDE::loadIcon("foo");
> > 
> > (I personally think it conveys better the idea as it makes it feel almost
> > like a prototype object)
> 
> Well, it's not so crazy. After I send the mail I thought, icon() would be
> better than loadIcon(), especially since the loading doesn't happen at that
> point, but on demand.
> I was thinking icon() lowercase though, Icon() is a little bit crazier
> indeed.

Right icon() would work nicely as well. Breaks less of our customs, but as I 
pointed I like the "almost prototype object" idea that Icon() would convey.
 
> But I'm not necessarily against crazy ideas ;-)

Well, I'll let you pick between icon() and Icon() then. ;-)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120315/28513f27/attachment.sig>