Proposal: New module "kdecore"

[David Faure]

On Wed, Apr 19, 2006 at 12:47:31PM +0200, Thiago Macieira wrote:
> 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?

So you don't know what you're suggesting to move out? ;)
The apps are: konqueror, kate, kfind, konsole, (kmenuedit?), keditbookmarks, kwrite, and I think
  kcontrol, kdeprint and khotkeys are also user apps not needed at runtime by other apps
  but maybe I'm wrong about one of them.

> 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. 
I think this makes things simpler, yes; but of course that's not a hard requirement.

> 2) Running KDE applications outside KDE requires kdelibs + kdebase-coreapps
> 3) Compiling KDE applications requires kdelibs only
Yes.

> 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 ;)
>From a 3rd-party-kde-app developer it would make a lot of sense of course
(just one dependency). For a kdelibs developer it means a huge amount of code
to compile for every change... but well, if it makes sense... I'm not fundamentally opposed.

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

> as well as convenience libraries like kdnssd, 
> kwallet, kspell2/sonnet, kutils, knewstuff.
I think dnssd is supposed to be part of kio -> can't move out
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 ;)

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; 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.
 
> 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".

> This adds some other constraints, like: can any kdebase application depend 
> on kdeapplibs?
If one of them needs a lib from there, then the whole module has a dependency
on kdeapplibs :) But since it would be mostly pim libs in there for now, this
might not be the case at all.

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

Well... yes, but still there's a difference between a program that is launched
on app startup (kdeinit, when running a kde app in a non-kde environment)
and the menu that launches khelpcenter. At least that was the kde3 reasoning,
but I'd be fine with your reasoning (all binaries in kdebase-coreapps, or all
dependencies 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.
Yes.

> 1) Why are debug areas shipped disabled?
Because some are -very- verbose, like the KAction ones.

> 2) Applications are shipped with debugging disabled, so installing 
> kdebugdialog may be futile.
Well, not everyone uses binary packages. You're right for the users who do,
but not for those who compile kde.

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

> Bear with me here: what in the KDE Control Center has to be configured in 
> GNOME, Windows and MacOS X?
> [...]
Good work on the detailed analysis, but the point is that there are things that
need to be configured in other environments, like the language (the KDE set of
languages might not match the set of languages provided by the "hosting" environment).
Yes we'll need to split up the modules according to the app split, although for
many kde-wide things it won't be easy... I suggest postponing this until the
actual kdebase reorganization decision though.

--
David Faure
faure at kde.org