Bug 486279

Summary:	move shortcut settings to keyboard shortcuts capplet
Product:	[Fedora] Fedora	Reporter:	Matthias Clasen <mclasen>
Component:	control-center	Assignee:	Control Center Maintainer <control-center-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	18	CC:	control-center-maint, i18n-bugs, mkasik, petersen, rstrode, wtogami, yshao
Target Milestone:	---	Keywords:	FutureFeature, i18n, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-05 02:23:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	481098

Description Matthias Clasen 2009-02-19 06:42:57 UTC

Keyboard shortcuts: I would love to see these moved to the keyboard
shortcuts capplet, which has support for handling application-defined
shortcuts. As a bonus, you get automatic conflict handling. The one
restriction is that currently, only one key-combination per action is
possible. If having multiple is essential, you could either split it
into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or
file a bug and I'll look into enabling multiple shortcuts per action in
the keybinding capplet

Comment 1 Jens Petersen 2009-06-10 05:49:58 UTC

Would it be possible for ibus to read a key from there as a user custom config - though it gets a complicated.  ibus/scim have a lot of different hotkeys for different parts: I think it is going to be a challenge to map them all to gnome-keybindings-properties, and having a few there and the rest in ibus-setup may be more confusing for users?

Comment 2 Peng Huang 2009-06-11 02:17:54 UTC

I think keyboard shortcuts capplet depends on window manager (metacity). If you run other window manager, the keyboard shortcuts maybe do not work. So I will close this bug as wontfix.

Comment 3 Matthias Clasen 2009-06-11 02:26:50 UTC

You are thinking wrong. Keyboard shortcuts do not depend on the window manager (except for the window management shortcuts, of course.

Comment 4 Peng Huang 2009-06-11 23:53:56 UTC

Hi Matthias,

Which running process is responsible for those Keyboard shortcuts? I need do more investigation on it.

BTW, I just tried several shortcuts (lock screen, eject cdrom and Custom shortcuts added by self). If I kill the metacity process in gnome desktop session, those shortcuts will not work.

Comment 5 Jens Petersen 2009-07-14 23:47:36 UTC

(In reply to comment #4)
> Which running process is responsible for those Keyboard shortcuts? I need do
> more investigation on it.
> 
> BTW, I just tried several shortcuts (lock screen, eject cdrom and Custom
> shortcuts added by self). If I kill the metacity process in gnome desktop
> session, those shortcuts will not work.  

Matthias, can you shed any more like or pointers on this? :)

Comment 6 Jens Petersen 2009-07-14 23:51:02 UTC

<phuang> I have reviewed related packages for this bug, it depends on gconf
<phuang> You just need provide some xml files in specified dir.

Comment 7 Jens Petersen 2009-07-14 23:56:26 UTC

<phuang> and the capplet will have those configure items, when users change those items, ibus need read configure from gconf

Comment 8 Matthias Clasen 2009-07-15 01:30:36 UTC

> > BTW, I just tried several shortcuts (lock screen, eject cdrom and Custom
> > shortcuts added by self). If I kill the metacity process in gnome desktop
> > session, those shortcuts will not work.  
>
> Matthias, can you shed any more like or pointers on this? :)  

Sure. It is not true. metacity does not handle any of those shortcuts, and thus killing metacity cannot affect them...

Comment 9 Fedora Admin XMLRPC Client 2010-08-02 06:17:35 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 fujiwara 2012-09-05 02:23:04 UTC

This is fixed in f18 gnome-shell.