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

List:       kde-usability
Subject:    Re: kcontrol
From:       Daniel Molkentin <molkentin () kde ! org>
Date:       2002-07-09 20:13:15
[Download RAW message or body]

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

Hi all!

On Tuesday 09 July 2002 21:51, Joseph Manojlovich wrote:
>On Tue, 9 Jul 2002, Simon Edwards wrote:
>> But, yeah, the hardware info modules need to be moved into tabs, and the
>> information category removed.

Sorry, but that proves that you talk around the topic. If you would have 
checked kde-cvs, you'd have noticed that the information section was 
outsourced to kinfocenter. No need for tabbing. It still lacks some vital 
features (like showing/printing a system status summary). Any takers?

>Has anyone ever tried to make a real GUI for this, a la the Windows
>Device Manager?

Nice idea, and you write the backends for all the mainstream plattforms KDE 
runs on? Hell, you cannot even even rely on the layout of the files in /proc 
(that's why we only read and dump them into ListViews). I've talked to Helge 
Deller, the current maintainer of the kcontrol info section (now kinfocenter) 
and he confirmed that it's real PITA to maintain the stuff.

Even if you define a nice API to gather system information (which will be a 
really non-trivial task), you'll need someone that writes the OS specific 
backends.

I agree that has to be done, but we need people that acutally *do* it. It's 
not anyone's job because you need specific hardware or software (think 
True64).

If you really want to approach that, you' need to:

0. Find someone, who does it (coordination)

1. Evaluate all options that can be shown / changed among the most common 
systems KDE runs on.

2. Ask for help on the kde-nonlinux list's. We need poeple with very specific 
knowledge about a system. For example, on the kde-solaris list, you'll find 
quite some people with an @sun.com addess, those might be especially 
helpfull.

Parallel (Linux only): Evaluate how to gather reliable informations across all 
kernel versions, check if there are APIs we can use alternatively to /proc 
parsing. If not, ask on the kernellists on how to ensure we get something 
that can be parsed / read (and written back) reliably. Contact distributors, 
they might be interested in supporting their specific distribution to avoid 
clashes with their propretary config tools (think YaST).

3. Define an API that allows backend implementation for read/write operations 
for a specific option on a system as well as a check for the availibilty, 
etc.

4. Implement the stuff

Given you start with that right now, you'll end up on a date somewhere in 2003 
until it runs halfway acceptable to be included in the KDE distribution 
packages. Of course we could also include it earlier and disable it on 
plattforms it can't cope with yet.

Sorry, I don't want to tear that nice idea down, but that's just the plain 
facts that I collected so far. Maybe I'm too pessimistic, but great ideas 
without someone translating them in code are wasted time.

Cheers,

</daniel>

- -- 
Daniel Molkentin <molkentin@kde.org> | The K Desktop Environment
KDE - Konqueror your Desktop!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9K0Pbu1Wkf8kBwz4RArTYAKDnxf9iyIoqlH9N3i31YrTK0CcY4wCcCwWy
xSxPr1xru5bS4AgUMY/c17E=
=k/gQ
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic