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

List:       kde-core-devel
Subject:    Re: Dedicated KControl app still needed?
From:       Daniel Molkentin <molkentin () kde ! org>
Date:       2002-02-16 17:31:57
[Download RAW message or body]

On Saturday 16 February 2002 15:06, Chris Howells wrote:
>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?

Yepp.

[snipp]

>
>> 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 only had rough contact with kio-slaves so far so I need to get it a bit 
deeper. I will surely use kio_print as an entry point.

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

Won't happen anymore with my approach :)

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

Being used to booth Unix and Windows I still think the "My Computer" metaphor 
is rather confusing. In my optionion, the sidebar and the K-Menu should be a 
guide for the user.

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

That was exactly my idea :)

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

Due to the fact that Konquerors framework is quite fast and that many users 
already have an open instance of Konqueror I think we'd be on the safe side.

[snip]

Cheers,

</daniel>

-- 
Daniel Molkentin | The K Desktop Environment | http://www.kde.org
KDE 3.0 - Konquer your Desktop!
[prev in list] [next in list] [prev in thread] [next in thread]