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

List:       kde-usability
Subject:    Re: kcontrol
From:       Joseph Manojlovich <josephm () mail ! sis ! pitt ! edu>
Date:       2002-07-09 20:42:15
[Download RAW message or body]

On Tue, 9 Jul 2002, Daniel Molkentin wrote:

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

The KControl of my latest checkout still has the Information subtree.
Also, I believe what the original poster meant was to put the output of
the sections on the appropriate tabs, i.e., the Sound control panel
would contain the sound information section, not have it seperated into
an Information tree.

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

I thought the main problem with code was that most developers don't
bother to work out the usability aspects before coding.

Did I say something wrong here? Or are you just having a bad day?

--
Joe Manojlovich
josephm@sis.pitt.edu
http://www2.sis.pitt.edu/~josephm
"I'm sorry, but I cannot divulge information about
 that customer's secret illegal account."


_______________________________________________
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