[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Dedicated KControl app still needed?
From:       Chris Howells <chris () chrishowells ! co ! uk>
Date:       2002-02-16 14:06:13
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 16 February 2002 1:37 pm, Daniel Molkentin wrote:

<snip some stuff as I've already had a quick chat on IRC about it :) >

> My point was more that applets should not be embeeded. Thats often ugly and

Presumably you're referring to the current KControl design now?

> confusing IMO. Having seperate dialogs makes it not only easier for the
> user (e.g. his is able to open 2 or more dialogs at the same time without
> messing with the k-menu or kcmshell) but also for the author who doesn't
> need to care about how his applet might look when swallowed by kcontrol and
> resized to rediculous values.

Yes, good point.

> I wouldn't go and extend the kdeprint slave, I would go for a dedicated
> "control:/" slave (which might even call "print:/".)

Well, using the kdeprint ioslave as a starting place -- it already seems to do 
quite a lot of the stuff already, and without looking at the source, I'd 
presume that it could be modified without too much hassle. I'd certainly 
rename it to control:/ though.

> I like that approach very much, too. Being the maintainer for kcontrol I
> have to recognize that the current code seems to work for most people but
> it has some essential design flaws and it indeed dublicated lots of code
> from Konqueror.

Good point. One of the bad things I dislike about KControl is that one module 
crashing crashes the whole program. Although I'm not entirely sure what using 
Konqueror would solve this either.

> Another argument is that a typical windows user would expect the settings
> inside Konqueror, just as he knows it from Explorer (which might not really
> be an argument, but anyway it's important for newbies)

Yes, this is pretty much how I got the idea :) I think having a "My Computer" 
style metaphor in KDE would make things easier to use, and I think Konqueror 
could easily provide this since it already does most of what is requird.

Additionally, Konqueror provides the ability to use different icons view, etc, 
so you can have it look more how you want easily.

> - KControl was optimized for speed (see the discussions around the
> implementation of the splash and info screens), when we require to load
> Konqueror each time, it might get slower. OTOH, we get khtml (almost) for
> free.

Hmm, I'm not fully sure I understand how it will get slower. At its most basic 
level, it should just mean starting Konqueror, loading the control:/ ioslave, 
and pulling a few icons out, surely? Or am I missing the point?

> - The attempt to make the helpcenter a dedicated IO slave was only
> partitially successfull. While I think that might be different with
> kcontrol, we should ask people like coolo _why_ it failed as the slave
> itself survived.

Oh right, very interesting. Yes, I'd like to know why it failed.

However, I believe that the fact that the kdeprint ioslave already does quite 
a lot of what we want to do prooves that it can work.

- -- 
Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org
Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt
KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8bmdWF8Iu1zN5WiwRAsxMAJsH6K5u9cz+RMk2fH1M/pV6m5j13wCfTysw
RGQsDpLiIHSKm8weA/Fo4Qo=
=2xAq
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]