organizing kdebase

[Aaron J. Seigo]

On February 22, 2007, David Faure wrote:
> > apps
> > ===
> > [...]
> > libs:
> > libkonq/ (file management goodies and guffaws)
>
> "belly laughs"? ;)
> Well libkonq is an issue in itself since it's used by kicker in a few
> places right now (for KonqBookmarkManager and KonqOperations::doDrop) but
> I'll be working on moving doDrop to kio, it seems to be widely needed.

ok, i'll hold off on moving libkonq for the time being until we see what 
becomes of it.

> > utils
> > ===
>
> I'm not convinced about the need to separate utils from runtime.
> The reason is: most of those could actually be runtime requirements of 3rd
> party apps or scripts. Just like you left kcheckpass in runtime, 3rd party
> apps and scripts need: kdialog, kioclient, kreadconfig, kstart...

scripts, yes. apps? i dunno... here's how i determined things:

- is there an API equivalent, making the application unnecessary to call?
- do applications call it (i'd check box lxr.kde.org and in some cases 
google's code search)?

i didn't count scripts (unless they are shipped as part of the desktop, i 
suppose?) as valid requirements for putting something into runtime. users and 
admins writing scripts to automate things can rely on kdebase being 
installed.

my thoughts are that runtime should be exactly that: the collection of 
applications we know that software relies on. this implies a larger burden of 
portability and maintenance in my mind.

> > kappfinder (find legacy apps and add them to your menu; maybe this moves
> > out of base altogether?)
>
> Yeah - nothing runs kappfinder automatically, right?

not that i could find, no. any thoughts on where to put it? kdeutils? i don't 
want that to become a dumping ground either though...

> > kdebugdialog (set actions to take for output from the various debug
> > areas)
>
> OK, that one fits with your definition of utils; but it's the only one :-)
>
> > kdialog (bring your scripts to life with kdialog[tm])
> > kioclient (kio ops that were previously in kfmclient)
> > kquitapp (quit an application via IPC)
> > kreadconfig (read and write kconfig entries via the command line)
> > kstart  (handy utility to start applications in various states)
>
> Those are all possible (and likely) runtime dependencies of many scripts.

yes, particularly kdialog, kreadconfig and kwriteconfig. the latter is used in 
an "more easily install amarok from svn" script for developers in the amarok 
source distribution, for instance, and i know admins who use those in their 
scripts extensively as well.

however, i didn't consider scripts a reason to put something into runtime/, 
which i kept specifically for application software (which can be written in 
python, ruby, etc.. but that's not a "script" in my mind). scripts can depend 
on kdebase/?

> > kinstalltheme (install time pixmap cache creator; may be obsoleted before
> > 4.0)
>
> Runtime dependency of themes?

hm ... yes, this probably is runtime/ material ... will shift it over there.

> > solidshell (command line utility for interacting with hardware via solid)
>
> Not sure if it is meant to be used by scripts or advanced users or just for
> debugging.

as kevin said, it could be used for any or all of that.

> Also, kutils vs kdeutils vs kdebase/utils gets confusing ;)

we just really like that word. =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070222/72c99ca4/attachment.sig>