Re: G-S-D support wireless/touchpad switch



Hi Jens,

Thanks for your comments.
The easiest way to get to the "correct" people usually is
to file a bug in bugzilla.

Or to write to the mailing list. g-s-d mostly co-uses the
gnome-control-center list which I have CC'ed as well.
These are helpful, thanks.


I see GSD has supported many media keys and XF86Display,
which means GSD has better supporting for laptops. While it
doesn't seem to support switch on/off wireless, touchpad
and bluetooth which are popular on laptops now.

The questions are:
Is GSD the best place to support to switch those devices on/off?

Depends. Please take into account that I'm not particularly
knowledgable concerning hardware integration issues, so
take what I'm going to say with a grain of salt. My feeling
is that most of the hardware support itself should go to
a separate program (though which one I am not sure of; g-p-m?
hald? DeviceKit? something else entirely?). Adding hotkey
support to g-s-d using interfaces exposed by those programs
then would be fine.
I will agree that the detail hardware support should go to a separate program. We know Hal, GPM or DeviceKit have covered lots hardware details up. I'm just inquiring a simple general function - enable/disable the hardware which are probably the exported interfaces of Hal, etc. I think introduce it into g-s-d could make sense like media-keys, randr plugin.

(Then there's the question how useful killing bluetooth via
hotkeys is, but since I don't have bluetooth I wouldn't know
anyway.)
I don't know either. It's probably the same way as killing wireless. Hal seems to support "software bluetooth killswitch for ThinkPads".

If yes, does anyone have the plan to implement those functions?

Not that I'm aware of. For better touchpad support there is
http://bugzilla.gnome.org/show_bug.cgi?id=154029, though
(tangentially related).
Thanks.

If you think the RFE makes sense. I would be glad to
work for that. My basic idea is to copy the existed OSD
window of sound of GSD, grab the related keys [1] and
invoke corresponding methods to switch those devices.

These OSDs should look like:
...
When users first press the key, then focus on Cancel
button, double press will change the focus and then
switch the devices.

My spontaneous response is we shouldn't add controls to
the OSD window. That's somewhat akin to the annoying
"do you really want to do that" dialogs.
I know, but there is a few difference. OSD only shows the next state of device. It will affect the device once users release the hotkey.
However, I'm
certainly no usability expert. If there is evidence to
the contrary I can be swayed. Initial reaction, though,
is "bad". (I can see the point that killing wireless
accidently might not be such a great thing, I just
don't much like the solution.)
Actually, I have the same point which force me to accept OSD window. Anyway it's just my very rough thought, I still need comments here.

I think I should consider the following things:
1) the device existence,
2) the state of the device,
3) the user's privilege.

How would the user's privileges figure into the OSD?
Just do not show the related icons if user doesn't have the privilege.

I probably will introduce a dependency of HAL into
GSD, I'm not sure if it is acceptable.

Only as an optional dependency. Now that DeviceKit
has been proposed as a HAL replacement I'm not sure
how wise this would be, though.
Yes, I know the coming changes. I don't know the release date of DeviceKit, but since every modules need time to migrate, I don't think it's a big issue for this feature.

What do you think? Welcome any suggestion, comments
or point me a correct way and a correct module to
implement those things for better supporting
laptops.  ;-)

As I said, I'm no expert, so I'd welcome additional
opinions.
Sure, welcome any opinitions.

Thanks,
lin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]