organizing kdebase

[Benjamin Meyer]

[snip]
> divisions in kdebase
> ============
> i'm suggesting the following 4 sections to kdebase, 3 of which are already
> there but perhaps need a bit more definition:
>
> * runtime: portable applications used by kde apps for "infrastructure"
> tasks
How about: Runtime is for helper applications that can't stand on their own.  
For example you can't run kcmshell without a module.  keditbookmarks needs an 
bookmarks file etc.
> * workspace: the desktop shell, portability not a requirement nor 
> really necessary as other platforms provide these facilities already
> * apps: essential GUI applications, portability prefered
> * utils: basic apps that fit in well with the "starter kit" but which are
> probably not GUI oriented and certainly wouldn't be expected to have a
> launcher on the panel or desktop, or instance


Apps and utils are really the same thing.  They are applications that the rest 
of KDE will expect to be installed.  If that doesn't apply then they don't 
belong in kdebase.   As it stood in maliga apps would be the combination of 
runtime, apps and utils.  Pulling out runtime might be good, but separating 
utils and apps seems overkill, see the individual comments below.

[snip good reasoning I agree with on why we want organization, power to 
change]

> runtime
> =====
> drkonqi (crash dialog, visible on crashes)
> kcheckpass (password validator; we use it only in screensaver but google's
> code search showed it being used by 3rd party apps as well)
> kcmshell (loads control panels one at a time)
> kcontrol becomes settings-panels and includes only those panels that
> configure global, but not workspace-specific items

Below you list kcontrol in apps. Just want to make sure that there was kmail 
wrapping the line or something.  If we need a few things outside of embedding 
kcm's we can just do:

kcmshell audiocd arts

without requiring the full blown kcontrol.

> kdeeject (pops out media, used by the media mount helper for instance)

This isn't portable at all.  Shouldn't it really be an API and in kdelibs 
anyway?  Or even part of solid?

> kdesu (run command with other UID, used exensively)

Is this portable?

> keditbookmarks (bookmark editor, used e.g. from kio_bookmarks,
> konversation) khelpcenter (local user documentation, launched via app Help
> menu) kioslave (various ioslaves common to desktop usage)
> kuiserver (shows jobs)
> kurifilter-plugins (self-explanatory =)
> l10n (also self-explanatory)
> solid (backends for solid)

> workspace
> =======
[snip all good]

> libs:
[snip all good]

> ktip: the utility of this seems dubious
die die

> apps
[snip all good]

> utils
> ===
> kappfinder (find legacy apps and add them to your menu; maybe this moves
> out of base altogether?)

This is a workspace feature.  You never log into OS X or Windows or Gnome and 
then decide to run kappfinder...  This is a KDE *feature* <collage kid 
voice>Dude you just _have_ to run KDE, it has this super cool feature... 
kappfinder.</collage kid voice>

> kdialog (bring your scripts to life with kdialog[tm])
> kioclient (kio ops that were previously in kfmclient) 
> kquitapp (quit an application via IPC)
> solidshell (command line utility for interacting with hardware via solid)
Don't these belong in runtime?  They can't stand alone and needs input to 
exists, mostly used via scripts. 

> knewstuff (generic app for grabbing knewstuff data; might really be more
> suited to kdeutils or even extragear to be honest)

If it requires input and can't stand alone then it would go in runtime 
otherwise if it is a stand alone app then workspace (a core feature of KDE4?) 
or kdeutils.

> kstart  (handy utility to start applications in various states)
> kinstalltheme (install time pixmap cache creator; may be obsoleted before
> 4.0)

These two are workspace features.... they requires X11...  They are almost dev 
tools...

> kdebugdialog (set actions to take for output from the various debug areas)
> kreadconfig (read and write kconfig entries via the command line)

Both of these are not apps that other apps depend upon, nor apps that are 
really used by other apps (I think).  If anything they are developer tools.  
Perhaps they don't really belong in base, but in utils.  Almost like TweakUI 
in windows.

Overall I think this is a great effort and thank you for taking the time to 
continue this cleanup.

-Benjamin Meyer