--nextPart1561575.nZSGhMciJu
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
names. They're all prefixed with kcm_. So all Makefiles have to be changed=
=20
accordingly.

> I really loathe when=20
> 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=20
I didn't want to look into that before I know that others would like to see=
=20
the rename as well.

To make everybody aware of what big a change this really is. After renaming=
=20
the classes about 120 KCMs have to be adjusted:
=2D change makefiles to use ksettings_ prefix instead of kcm_
=2D change kcmshell and kcminit programs (ksettingsshell and ksettingsinit?)
=2D probably rename directories and filenames so they don't have kcm in the=
ir=20
name anymore (not required but better for consitency)
=2D change all .desktop files to servicetype KSettingsModule
=2D 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 men=
u=20
name we use already.

=2D-=20
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

--nextPart1561575.nZSGhMciJu
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEv1Ksyg4WnCj6OIoRAj2hAJ4yEVmFf8hA0bEY5FlhviSpyPbNJACgzX57
CRoKDBDf6eD24PHi6xQf5YQ=
=xDhN
-----END PGP SIGNATURE-----

--nextPart1561575.nZSGhMciJu--