[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