K*Base -> KAbstract*

Andreas Hartmetz ahartmetz at gmail.com
Sat Mar 17 23:57:58 GMT 2007


Am Samstag, 17. März 2007 23:50:53 schrieb Aaron J. Seigo:
> On March 17, 2007, Andreas Hartmetz wrote:
> > Am Samstag, 17. März 2007 12:30:33 schrieb David Jarvie:
> > > On Saturday 17 March 2007 01:32:24 Andreas Hartmetz wrote:
> > > > Do we all agree that clarity beats brevity?
> > >
> > > Good idea.
> >
> > I'll make patches for kdelibs/pimlibs/base/other important modules(*)
> > ready for next monday then. If you have a good reason to not change the
> > names, please say so ASAP so I can avoid unnecessary work.
>
> i have a huge number of changes in kdecore, but fortunately the only *Base
> class in there that i have made changes to is KConfigBase. so if you could
> perhaps avoid kdecore/config/ for this monday, i'd appreciate that =)

I'll just postpone it to monday after next week. SadEagle objected to this 
change for khtml, kjs and kstyle, because it uglifies the documentation 
(true) and because it takes classes out of their group in lexical class lists 
(which I consider irrelevant, because browsers have an inline search function 
and hyperlinks).
I told SadEagle on IRC that I'd leave khtml, kjs and some style code alone, 
but now I have changed my mind because there is more time to discuss. 
Apologies to SadEagle.
Large parts of kdelibs don't actually "belong" to anybody, and it shows...
Now that there is more time, can we agree on a policy for ALL OF kdelibs and 
kdebase and then do it?
I am ready to give in (and leave parts of kdelibs unchanged) if it shows that 
we really really cannot agree.
Hey, I don't do this because I want to be the king of "lines of code changed" 
in the commit-digest but because kdelibs has been neglected in places and the 
API freeze is getting closer.




More information about the kde-core-devel mailing list