On Thursday 08 September 2011 09:36:41 todd rme wrote: > Several people have proposed moving to a separate module classes that > are needed for existing applications but pose a problem for new > developers, are no longer needed, or clutter the API. From what they > are saying, this seems to ease the porting efforts since KIcon will > not have to be changed to QIcon for any existing software, while > freeing the rest of the frameworks from dependence on this class and > making to clear to developers the QIcon should be used for any new > software. This, from my reading, does NOT involve deprecating any of > the classes placed in the module, they will continue to be supported.
Thanks for pointing that out. It's definitely the point that got missed in those threads about KIcon ATM. The plan in such a case is indeed 1) to introduce the new API replacing KIcon; 2) move KIcon in a new module (let's call it kde4support); 3) provide script to ease porting away from KIcon to the new API. So, you don't want to port existing code? Fine, just link on kde4support for the time being. It indeed ensures source compatibility. After some time you want to port to the new API? Fine as well, take your time, you won't loose any feature, it'll just go through factory methods instead of ctors. BTW, just to put things in perspective here, I'm already counting three/four people arguing for one hour on IRC on that topic, and more than 20 emails here in two threads... just for KIcon which is basically an empty class providing three convenience ctors. I'm not saying everybody should shut up and just walk in the same direction like robots, but I think there's far more valuable discussions to have than KIcon. They'll surely come at some point, and I'm looking forward to the feedback we'll get on those. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
