Proposal: New module "kdecore"

Thiago Macieira thiago at kde.org
Wed Apr 19 11:47:31 BST 2006


David Faure wrote:
>> > - apps: other apps, needed by users but not by other apps
>>
>> How about moving these out of kdebase?
>
>And where? I don't see the point; as I said it's only confusion.

I don't know. Which applications are these?

>> Also, where is Konqueror? I would consider it part of Workspace,
>> because no environment is full without a file manager. On the other
>> hand, even if I were in TWM, I'd like to use Konqueror...
>
>Konqueror is -definitely- not part of workspace. Workspace == "X11
> only". The logic is not "kde is not full without xyz"; that's the logic
> for kdebase itself, and that's why I don't think we should "move those
> apps out of kdebase".

Makes sense.

Let me see if I understood correctly:

1) A complete KDE environment should run and be usable with just kdelibs + 
kdebase, as it is right now. 

2) Running KDE applications outside KDE requires kdelibs + 
kdebase-coreapps

3) Compiling KDE applications requires kdelibs only

For the sake of the argument, let me propose a complete radical approach:

a) Move kdebase-corepps to kdelibs
b) Move the non-central KDE libraries to kdeapplibs or whatever other 
name. This would include the PIM libraries Cornelius proposed in the 
start of this thread, as well as convenience libraries like kdnssd, 
kwallet, kspell2/sonnet, kutils, knewstuff.

We'd end up with:
1) A complete KDE environment should run and be usable with kdelibs + 
kdebase.

2) Running KDE applications outside KDE requires just kdelibs.

3) Compiling KDE applications always requires kdelibs, but also optionally 
kdeapplibs, depending on which application it is.

This adds some other constraints, like: can any kdebase application depend 
on kdeapplibs? We also get the question more often whether a 
class/library should be moved upstream from the application to the app 
library to the core library...

>> >coreapps would contain
>> > - drkonqi
>>
>> drkonqi is almost kdelibs...
>
>That's the point. Everything that I listed in coreapps is "the stuff
> that is needed alongside kdelibs although it's not libs". The runtime
> dependencies of kde apps, as opposed to compile-time dependencies.

Then kdeinit moves out of kdelibs into kdebase-coreapps?

The way I see it, dependencies are dependencies, no matter if run-time or 
compile-time, so these apps should be in kdelibs.

>> > - kioslaves (I know they're not really apps, but let's not name the
>> > directory "core")

kio_http and kio_ftp are in kdelibs, a couple of other important ones are 
in kdebase. We should merge, I think.

>> > - kdesu
>> > - kdebugdialog? maybe this one belongs in kdesdk?
>>
>> Yes. Applications don't need to run kdebugdialog. Normal users will
>> never know about it either.
>
>Yes; OTOH telling a user "install all of kdesdk just to tell me the
> debug output from area 1245" seems a bit overkill (and might raise the
> bar for meaningful debug output logs).

1) Why are debug areas shipped disabled?

2) Applications are shipped with debugging disabled, so installing 
kdebugdialog may be futile.

Then again, if my second assumption is wrong, #1 makes sense...

>> > - kreadconfig, kdialog, kstart (all potentially needed by scripts)
>> > - khelpcenter
>> > - kcontrol? or only kcmshell?
>>
>> kcmshell, probably, with kcontrol being part of workspace.
>
>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.

Bear with me here: what in the KDE Control Center has to be configured in 
GNOME, Windows and MacOS X?

- Appearance & Themes
   Partially: the inside-the-window stuff like widget styles, colours, 
icons has to be configured; the out-of-the-window stuff like window 
decorations, splash screen, background, screensaver cannot.
Exception: theme manager spans the two areas.

- Desktop:
  No: purely KDE Workspace.

- Internet & Network:
  Partially, as it stands. It configures the web browser -- no, it 
configures Konqueror. It configures several network-related applications 
(krdc, kdnssd, kmldonkey, lisa) as well as the system (wireless) and 
KDE-wide settings (proxy, connection settings).

- KDE Components:
  Partially: it configures kresources (KDE-wide), Konqueror, MIME types 
and file associations (Workspace once we use the XDG database), Session 
(Workspace), Components (Workspace if we use XDG/Portland), kded 
(KDE-wide) and the spellchecker (KDE-wide)

- Peripherals:
  No: purely KDE Workspace.

- Power Control:
  No: purely KDE Workspace.

- Regional & Accessibility:
  Partial: Accessibility and Keyboard Layout are Workspace. The rest is 
global (khotkeys, default and global shortcuts). Exception: Country & 
Language.

- Security & Privacy:
  Partial: Password & User Account are KDE Workspace; the rest is KDE-wide 
(KSSL, KWallet and cleanups).

- Sound & Multimedia:
 Can't say. That depends on what configurations Phonon and the 
notification subsystem come up with. Also note that System Notifications 
allows you to change the notifications for any app.

- System Administration:
  By definition, Workspace, except for the kdm configuration (because kdm 
is not part of the Workspace).

-- 
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/fde5c4b7/attachment.sig>


More information about the kde-core-devel mailing list