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

[David Faure]

On Tuesday 23 March 2004 10:44, Cornelius Schumacher wrote:
> 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.

Cosmetics. I can still use OO in KDE, even though it looks different,
and other people can still use KOffice in whichever desktop, even though it
looks different.
Having to install something new to do customizations is fine, it's not the same
thing as having to install something to read help - a very basic feature!

> There are other kcontrol modules which you definitely need like locale and 
> fonts, otherwise you are missing essential configuration options for KDE 
> apps.
Real end users don't configure fonts (unless something is REALLY broken,
which would be a bug).

> 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.
You're right about that one. (and it even affects koffice, for the 'File/Mail...' feature:)
I guess I'm withdrawing the idea for now; it can't be simply about moving
khc+drkonqi, the only way would be Alex's bigger restructuring, to have kcontrol
and the modules affecting all apps in 'kdeframework' - i.e. the modules that
configure kdelibs' behavior).

> What about knotify? I would hate to not being able to turn off sound 
Hmm, do we have any sounds activated by default for normal apps?

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

People expect: to start it, to use _most_ of its functionality, to view the help.
Not necessarily to configure all the fine details about it, and IMHO it's fine
to say "no samba support without kdebase", that's not in the most common
functionality (just compare with any other self-contained program out there,
like e.g. OpenOffice again).
But you're right that defining this isn't really obvious.

> 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)?
Honestly, no idea :)

> 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. 
Indeed. Sounds good.

> Each app bringing its own help system is no clean solution.
Sure.

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

Yes, Bo made me realize that. If the schedules match, releasing both kdebase-3.3
and kdepim-3.3 at the same time would solve this :)

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

Yes, the full khelpcenter does. But not to view the documentation from a single
KDE application (which is what this is about).

> 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?
No, all this requires kdebase, and isn't strictly necessary to view the help of
a single KDE app.

> > 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.
Only if you want khelpcenter to be truly standalone, i.e. that all its features
work without kdebase. But to view a single app's help, it seems to be all 
that's needed.
The other features would need to check for the presence of what they need,
indeed, and pop up a msg box "install kdebase" if necessary; I hadn't 
realized that before, and you would be right to ask that someone implements
this before moving khelpcenter.

> 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. 
See my suggestion of "make libs ; make install-libs" targets, which solve this.

> Having the libs in kdelibs and run-time  
> dependencies in a new separate module might solve this problem, though.
Yes (the kdeframework idea, or kdelibs-apps). But I don't think this is necessary
(and we already have lots of small helper binaries in kdelibs, which isn't a big
problem).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).