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

David Faure wrote:
>> For the sake of the argument, let me propose a complete radical
>> approach:
>>
>> a) Move kdebase-corepps to kdelibs
>
>This makes kdelibs huge. I often wish it was smaller, not bigger ;)

Only if you don't take step (b) and move the non-central libraries out of=20
kdelibs. Besides, aren't all of those apps small ones? The largest in=20
your list was khelpcenter, I think.

>I think dnssd is supposed to be part of kio -> can't move out

I don't see why. kio_zeroconf is in kdenetwork. Service discovery has=20
nothing to do with KIO. Service publishing is even more restricted, since=20
it makes sense for only a few apps.

>kwallet is used by khtml and kio (kpasswdserver) -> can't move out
>kspell2/sonnet is needed by KTextEdit and khtml -> can't move out
>kutils currently has find/replace stuff, used by khtml -> can't move
> out. (we could merge thart part of kutils into kdeui once kio and
> kparts are there too, anyway ;)

KHTML is a big question mark on where it should be. Being strict in the=20
definition, it isn't a core library, so it would be moved out to=20
kdeapplibs. Which, in turn, makes kdebase depend on kdeapplibs.

>knewstuff was the good example - it's not used inside kdelibs itself
> AFAIK. But the knewstuff developers will tell you that all KDE apps
> should use it, so there isn't any point in moving it to "kdeapplibs" or
> whatever;

Like downloading new skins for kcalc? New bugs report templates for=20
KBugBuster?

I'm trying to draw the line between libraries used by few or many=20
applications and libraries used by all or almost all applications.

> that's just splitting kdelibs in two without any purpose, if=20
> both modules become a compile-time dependency anyway.... I see your
> idea for a split, more generally, but drawing the line will always be
> tricky.

I said it was a radical approach. I'm trying to get the discussion going.

>> 3) Compiling KDE applications always requires kdelibs, but also
>> optionally kdeapplibs, depending on which application it is.
>
>This might be a solution; it's surely a more generic solution than
> "kdepimlibs".

True. But, as I said, I think some libraries in kdelibs qualify to move=20
downstream.

>> >I think that running kcontrol makes sense in gnome, windows, and Mac
>> > OSX as well. So IMHO it belongs to apps.
>>
>> kcontrol has to be reorganised along with the workspace - coreapps -
>> apps reorganisation.
>
>Sure; I wasn't talking about the modules, but about the kcontrol app
> itself.

The central question here, I think, is: should we have to force users to=20
have a KDE Control Center even if they just want to run Kate or Konqueror=20
in TWM?

In the list I posted, there were many KDE-wide settings. If you run only=20
KDE applications, they are global settings. But if you don't, you get=20
inconsistencies.

Example: you can change in KDE what the shortcuts for Undo, Cut, Copy,=20
Paste are, in all applications. Sorry, in all KDE applications:=20
OpenOffice.org, Firefox, Gimp, etc., aren't changed. So you end up with=20
an inconsistent environment, where Ctrl+C copies in some programs but not=20
in all, and your change doesn't apply to all the programs you use.

Unfortunately, there's no around it: if we allow users to customise=20
certain things, it will always only apply to KDE applications. The=20
alternative would be to disallow customisation if we can't make others=20
comply (lowest common denominator).

But I digress...

my point is that there are certain KDE-wide settings that should be global=
=20
and apply to other applications. There are also some power settings that=20
shouldn't have GUI (IMO), like changing the timeouts for sockets.

=2D-=20
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech AS
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway

--nextPart2878369.rU4Vek1cZg
Content-Type: application/pgp-signature

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

iD8DBQBERiyrM/XwBW70U1gRAtEbAJwKaQNg04VluajJ95S8W/Ul6aq6kgCgmFED
X3H5VdisFG8tyfmktTRA8bk=
=bfas
-----END PGP SIGNATURE-----

--nextPart2878369.rU4Vek1cZg--