Proposal: New module "kdecore"

[Thiago Macieira]

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 
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
> whatever;

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

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
> 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 
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 
have a KDE Control Center even if they just want to run Kate or Konqueror 
in TWM?

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 
inconsistencies.

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
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060419/97f1587e/attachment.sig>