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