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

List:       kde-devel
Subject:    Call for ideas: KDE hardware extension tab in kcontrol
From:       Willi Richert <w.richert () gmx ! net>
Date:       2004-04-19 7:51:28
Message-ID: 200404190951.28433.w.richert () gmx ! net
[Download RAW message or body]

Hi all,

I need some input for a new section in kcontrol. The situation is as follows:

1) Certain Laptops have certain special function keys, which are not support 
by default. On Windows, every laptop manufacturer gives his own driver to 
leverage those functions. On KDE/Linux we have to support it by our own 
modules.

2) These modules are initialised in the System administration 
(Systemverwaltung) by individual dialogs (e.g. "Sony Vaio Notebook 
Hardware").

3) The problem: The more of such supporting modules exist, the more complex 
the overall design of kcontrol will get.

4) I've written a simple module (a plugin using kded::kmilo) which enables 
On-Screen display of vol up/vol down for generic supported laptop buttons (by 
X/Qt constants in qnamespace.h). There is no obvious possibility to turn this 
functionality off if you don't want it. I have to provide some kcontrol 
dialog, where you can turn it on/off.

QUESTION:
How should we organize the kcontrol special hardware functionality, so that it 
is obvious for every developer, where his features have to be set up?

The solution, with which I first came up was this: We add a "Special Hardware" 
dialog to the system administration entry in kcontrol, where you have a combo 
box showing all extensions that have been installed, but which is not 
necessarily set up for use. If you seelct one extension, the proper dialog is 
set up, where you have also an option box "enable" or so.

I'm a newbie in this section, and my only need is to fix 
http://bugs.kde.org/show_bug.cgi?id=75169 . What do you think, is this 
solution a good one? Are there other efforts in this area?

Many thanks,
wr
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]