Proposal: New module "kdecore"
thiago at kde.org
Wed Apr 19 13:27:15 BST 2006
David Faure wrote:
>> For the sake of the argument, let me propose a complete radical
>> 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
kdelibs. Besides, aren't all of those apps small ones? The largest in
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
nothing to do with KIO. Service publishing is even more restricted, since
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
definition, it isn't a core library, so it would be moved out to
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
Like downloading new skins for kcalc? New bugs report templates for
I'm trying to draw the line between libraries used by few or many
applications and libraries used by all or almost all applications.
> that's just splitting kdelibs in two without any purpose, if
> both modules become a compile-time dependency anyway.... I see your
> idea for a split, more generally, but drawing the line will always be
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
True. But, as I said, I think some libraries in kdelibs qualify to move
>> >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
The central question here, I think, is: should we have to force users to
have a KDE Control Center even if they just want to run Kate or Konqueror
In the list I posted, there were many KDE-wide settings. If you run only
KDE applications, they are global settings. But if you don't, you get
Example: you can change in KDE what the shortcuts for Undo, Cut, Copy,
Paste are, in all applications. Sorry, in all KDE applications:
OpenOffice.org, Firefox, Gimp, etc., aren't changed. So you end up with
an inconsistent environment, where Ctrl+C copies in some programs but not
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
certain things, it will always only apply to KDE applications. The
alternative would be to disallow customisation if we can't make others
comply (lowest common denominator).
But I digress...
my point is that there are certain KDE-wide settings that should be global
and apply to other applications. There are also some power settings that
shouldn't have GUI (IMO), like changing the timeouts for sockets.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel