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

List:       kde-core-devel
Subject:    Re: KCM rename
From:       Adam Treat <treat () kde ! org>
Date:       2006-07-20 14:18:09
Message-ID: 200607201018.09960.treat () kde ! org
[Download RAW message or body]

And rename all classes that inherit KCModule*  such as the recent ones in 
KDevelop ;)

On Thursday 20 July 2006 5:53 am, Matthias Kretz wrote:
> On Thursday 20 July 2006 11:43, Frans Englich wrote:
> > I think the rename is sensible, but there's just one thing: porting will
> > require a lot of work. There are many files which are named
> > "kcmsomething. {cpp,h}" so one would have to rename files too.
>
> One should rename those, yes. And it's not only that it's also the library
> names. They're all prefixed with kcm_. So all Makefiles have to be changed
> accordingly.
>
> > I really loathe when
> > someone tries to hinder what is the correct thing to do because it would
> > require an effort. So, I'm not saying this is a reason to not do it, I'm
> > just mentioning it.
>
> This is definetly a change that should only be made if a script can do it.
> But I didn't want to look into that before I know that others would like to
> see the rename as well.
>
> To make everybody aware of what big a change this really is. After renaming
> the classes about 120 KCMs have to be adjusted:
> - change makefiles to use ksettings_ prefix instead of kcm_
> - change kcmshell and kcminit programs (ksettingsshell and ksettingsinit?)
> - probably rename directories and filenames so they don't have kcm in their
> name anymore (not required but better for consitency)
> - change all .desktop files to servicetype KSettingsModule
> - and probably something I forgot
>
> > On Wednesday 19 July 2006 09:02, Matthias Kretz wrote:
> > > Hi,
> > >
> > > as KCModule and friends are not bound to KControl anymore I believe a
> > > rename of the classes is in order. In Trysil Aaron and Ben said to call
> > > everything KSettings:
> > > KCModule -> KSettingsModule or KSettingsPlugin
> >
> > I think I prefer "Module" here. "Plugin" would be more a focus on what it
> > physically is, as opposed the semantical part(that it is settings
> > modularized).
>
> /me agrees
>
> > > KCModuleInfo -> KSettingsInfo(rmation)
> > > KCModuleProxy -> KSettingsWidget
> > > KCMultiDialog -> KSettingsDialog
> > > KSettings::Dialog -> KSettingsDialog
> > > KSettings::CompontentsDialog -> KSettingsDialog
> > > KCModuleContainer -> KSettings(Module|Plugin)Container
> > > Another obvious name would be to use Config, but KConfig is already
> > > taken. I'm not satisfied with the name change yet and before I'd tackle
> > > such a drastic change I'd like to hear some more opinions.
> >
> > That Qt has QSettings, as Molketin mentions, I find a bit worrying. It is
> > an invite for future trouble. Perhaps "Settings" can be replaced with
> > "Options"? KOptionsModule, and so on.
>
> We won't have a KSettings class, though. And actually Settings fits the
> menu name we use already.
[prev in list] [next in list] [prev in thread] [next in thread]