Konqueror specific modules in KControl

[Frans Englich]

On Thursday 19 February 2004 10:26, Frans Englich wrote:
> 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.

Ok. I wrote a mail, suggesting all kind of crazy things, a couple of dozen 
replied, and I counter replied where I laid out arguments, trying to tackle 
the points brought up. And then, no one replied.
So, I'm doing my own guess work here. What reactions did my letter create? 
Some guesses:

* My message was so darn stupid it wasn't even worth replying too. I am of 
course, too stupid to realize that and one can only hope it is possible to 
explain it for me.

* My message was so right it just cleared the discussion, finito. And I should 
just realize it.

So, one might wonder what will happen when I in the future do the proposed 
changes to the to-become KDE4's KControl. Perhaps I will be told to revert. 
That will such that case come as a pleasent surprise.


		Frans