khelpcenter+drkonqi -> kdelibs (Re: Refactoring KCM technology)

[Cornelius Schumacher]

On Tuesday 23 March 2004 09:37, David Faure wrote:
>
> Many KOffice users, for instance, want to use KOffice without having to
> install kdebase nor use KDE. The solution for this is quite simple: moving
> khelpcenter and drkonqi (useless, since koffice never crashes :) to
> kdelibs, and adding a combobox for selecting the language in koffice's own
> configure dialogs. Configuring other aspects of the application (like what,
> widget style?) is for KDE users, it's not necessary to use a KDE
> application.

Wouldn't it be especially important to be able to configure the widget style, 
if you run KDE programs under a non-KDE desktop? The default KDE style 
probably doesn't fit to well to a GNOME desktop. You would also need the 
color module, maybe more.

There are other kcontrol modules which you definitely need like locale and 
fonts, otherwise you are missing essential configuration options for KDE 
apps.

What about componentchooser? You also need that, especially if you want to use 
individual KDE programs on a non-KDE desktop, because you  have to set a 
non-KDE mail program etc.

What about knotify? I would hate to not being able to turn off sound 

There are other modules like email, spellchecking which are used by some KDE 
apps, so you would also need to move them.

> I have yet to see a good argument against moving khelpcenter and drkonqi to
> kdelibs, I'm currently very inclined to do so. kdebase shouldn't be
> required to run KDE apps, most of it isn't needed, only khelpcenter and
> drkonqi (and kcmshell for some apps, which I just moved as requested by
> Frans).

What is "running KDE apps"? If the app start without unresolved symbols? If 
you can use some of its functionality? If you can view the help? If you can 
configure its look? If you can configure its behaviour? If you can take 
advantage of the kioslave system and access remote files on a http or ftp 
server? On a Samba or NFS server? All of this? Only a subset?

> Imagine if openoffice forced people to install gnome just to get the help
> to appear :-)))

How much of the GNOME desktop do you have to install when you want to get help 
in a GNOME application (I mean a real GNOME app which is integrated with the 
desktop and uses the framework, not something like OpenOffice)?

There is a discussion ongoing on freedesktop.org to use a common 
desktop-independent scheme to describe documentation. This would make it 
possible to actually use the help broswer of the desktop for all applications 
independent of which framework the applications belongs to. Something like 
that would be a clean solution. Each app bringing its own help system is no 
clean solution.

> kioslaves are another problem; I think we all agreed that the pop and imap
> slaves should be moved to kdepim now that KDE-3.2 is out. Do I remember
> wrong, or should I proceed?

The problem is that with a separate kdepim release including the pop and imap 
slave there would be two packages containing the same kioslaves, kdebase-3.2 
and kdepim-3.3 which have to be used together.

> "khelpcenter needs a kioslave too" is a bad example since kio_help is in
> kdelibs...

It is not a bad example, because it requires at least the cgi, the man and the 
info kioslave from kdebase.

When you have external URLs in the help center a Konqueror is started. How 
would this work without kdebase installed? Does kdelibs make sure that a 
suitable app is started for viewing HTML pages, images, PDF or Postscript 
files, if kdebase isn't installed?

> Cornelius: please consider the koffice case; or kdepim once the kioslaves
> are moved. Requiring kdebase is a problem for non-kde users, and it's a
> problem that can be fixed, so let's fix it.

If you seriously want to fix that I'm fine with that, but this will require a 
lot of work, much more than just moving the khelpcenter directory from 
kdelibs to kdebase.

And I still think that moving applications and other run-time dependencies to 
kdelibs is wrong. I really don't want to compile all these for being able to 
compile other KDE modules. Having the libs in kdelibs and run-time 
dependencies in a new separate module might solve this problem, though.

-- 
Cornelius Schumacher <schumacher at kde.org>