Konqueror specific modules in KControl

[Frans Englich]

On Wednesday 18 February 2004 14:09, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed February 18 2004 13:15, Frans Englich wrote:
> > I would like to move some Konqueror specific(AFAICT) modules out from
> > KControl, so they are only available in Konqueror. Namely:
> >
> > * KDE Components/KDE Performance
> >
> > * Internet & Network/Web Browser
> >
> > * KDE Components/File Manager
> >
> > What do people think?
>
> Just like Microsoft I consider the browser and file-manager an essential
> part of the desktop 

And so do I. But tight integration must not come with customer lock in - the 
inability to switch to other browsers or promote unfairly one browser. That's 
what Microsoft does. And KDE, although it is possible to tangle oneself out 
of it - but the principle is there. This is perhaps one reason to why home 
brew solutions is preferred in front of KControl - selecting KControl means 
selecting Konqueror. 

Political aspects aside, Konqueror has an integral role of KDE and is central, 
and I think that's good. But when it comes to the /usability/ issue where to 
put the KCMs, that's a totally different question. I bet the user sees 
Konqueror as one logical part, one application - putting "KDE 
Performance"(which I of course will rename to Konqueror Performance) in 
Konqueror thus makes perfect sense. The same with "File Manager" and "Web 
Browsing" - the settings affects Konqueror - the need for the configuration 
functionality will arise while using Konqueror.

The technologies which the KCMs touches are integrated, and "belongs" more to 
KDE than specific applications - but that's a developers viewpoint. For 
example, while a user uses Quanta's VPL mode and needs to change its behavior 
he/she doesn't think the content of the VPL window is an independent part and 
used elsewhere - it is Quanta. There's no distinction between whatever 
kpart/technology in the application and the application itself. And that's 
why the user looks in Quanta for the VPL(khtml) settings, and not where 
global settings are kept. Thus, I suggest the relevant KCMs are loaded in 
Quanta, which also gets rid of a lot of settings which are irrelevant for 
Quanta, AFAICT.

One can look at it from another direction; KControl is over crowded, it is 
impossible to deny that the sheer amount of KCMs makes it more difficult to 
navigate and for that matter find a good navigation solution. Moving these 
two(save File Manager) KCMs makes a _big_ difference for KControl, as people 
have outlined.
Could someone elaborate on what situation the File Manager settings affects?

Keeping Konqueror Performance in KControl because there will perhaps be added 
generic performance options are not acceptable - KControl is way too critical 
for paying small code changes with usability "currency". 

BTW, this is KDE4 changes.


Cheers,

		Frans