View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000364 | ardour | bugs | public | 2004-03-30 10:16 | 2008-11-21 00:31 |
| Reporter | hansfbaier | Assigned To | cth103 | ||
| Priority | normal | Severity | feature | Reproducibility | sometimes |
| Status | closed | Resolution | no change required | ||
| Summary | 0000364: Keyboard shortcuts sometimes don't work | ||||
| Description | I like using keyboard shortcuts, but sometimes the keyboard shortcuts won't work and I don't know why. | ||||
| Additional Information | I use the latest ardour package from planet CCRMA at home with RH9 | ||||
| Tags | No tags attached. | ||||
|
|
Also occurs whith built from source ardour. |
|
|
this is almost certainly caused by keyboard focus issues. it can either be a bug in ardour (keyboard focus left in some text entry area and so shortcuts don't work), or a pain-in-the-neck window manager that is not giving focus back to ardour even though you think it has. for the first case, a TAB key will generally move focus out of anywhere that its stuck. i'd be interested to hear if this helps any specific cases where this problem affects you. for the second case, you have to force the WM to give focus back an ardour window, typically by clicking on the window. this case also be caused by popup dialogs that are modal (ie. they take control of all keyboard/mouse input) being hidden. its worth checking the window list of your window manager to see if there any "hiding" anywhere. please let us have some feedback on this one, its important. |
|
|
WM = metacity (stable) gnome-desktop Hitting tab does nothing to restore focus. Clicking on the window does nothing to "restore focus". I can select regions, click track names, place automation points, mute and solo tracks, tweak scrollbars, click transport playback, all just fine, but slapping space with my thumb don't start no playback. Interestingly, clicking on tempo ruler, then closing the resulting tempo dialog restores shortcuts. |
|
|
ryan - if you can get a specific sequence of actions that lead to loss of focus, it would be very helpful. |
|
|
I see some of this too. With recent CVS. Ardour/GTK 0.514.5 running with libardour 0.814.2 It is hard too track down when the focus stops and when it comes back. The spacebar and the r(ecord) keep working but f.i. the mode changes o,g,z etc don't. When I started with an empty session everything seemed to work, but as it got past a certain point of complexity, it gets these "blackouts" more often. With my current big session, it doesn't work when loaded.After some editing it comes back. It might be WM related (i use ion) because I do a lot of window/desktop switching, but the fact that ardour keeps responding to the spacebar is weird. |
|
|
I just found out that I can always get it back by moving the cursor with the mouse from the ardour monitor to the other head ( I am using a dual head setup) and back. If I switch head or workspace using the WM keyboard shortcuts I loose some of the focus. Since ion is geared towards keyboard operation I do this a lot and I had never noticed cause and effect. Still strange that the spacebar keeps working. |
|
|
I enabled debug_keyboard and I got the following output doing this: the situation is that I am not able to set edit mode with o. Manually move mouse to other screen and move back Set object mode with keyboard. --snip snoop widget 0x8949cd0 key 111 type: 8 focus allowed? 0 current dialog = 0 STATE: 111 PRESS: not handled, delivering to default target 0x899d4c8 PRESS: handled ? 0 snoop widget 0x8949cd0 key 111 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to default target 0x899d4c8 clearing current target --this is where Is move the cursor clearing current target set current target to default set current target to editor snoop widget 0x896ff90 key 111 type: 8 focus allowed? 0 current dialog = 0 STATE: 111 PRESS: delivering to target 0x894b840 PRESS: handled ? 1 snoop widget 0x896ff90 key 111 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to target 0x894b840 RELEASE: delivering to default target 0x899d4c8 and now making it unresponsive again snoop widget 0x8949cd0 key 111 type: 8 focus allowed? 0 current dialog = 0 STATE: 111 PRESS: delivering to target 0x894b840 PRESS: handled ? 1 -- key is handled snoop widget 0x8949cd0 key 111 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to target 0x894b840 RELEASE: delivering to default target 0x899d4c8 snoop widget 0x8949cd0 key 65515 type: 8 focus allowed? 0 current dialog = 0 STATE: 65515 PRESS: delivering to target 0x894b840 PRESS: not handled, delivering to default target 0x899d4c8 PRESS: handled ? 0 snoop widget 0x8949cd0 key 65515 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to target 0x894b840 RELEASE: delivering to default target 0x899d4c8 snoop widget 0x8949cd0 key 65515 type: 8 focus allowed? 0 current dialog = 0 STATE: 65515 PRESS: delivering to target 0x894b840 PRESS: not handled, delivering to default target 0x899d4c8 PRESS: handled ? 0 clearing current target clearing current target -- here I just switched workspace with meta-leftarrow snoop widget 0x8949cd0 key 65361 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to default target 0x899d4c8 snoop widget 0x8949cd0 key 65515 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to default target 0x899d4c8 snoop widget 0x896ff90 key 103 type: 8 focus allowed? 0 current dialog = 0 -- and then switched back. STATE: 103 PRESS: not handled, delivering to default target 0x899d4c8 PRESS: handled ? 0 snoop widget 0x896ff90 key 103 type: 9 focus allowed? 0 current dialog = 0 RELEASE: delivering to default target 0x899d4c8 So it seems that moving the cursor with the mouse across screens sets and resets the targets, but switching with keyboard shortcuts doesn't Hope this helps to shed some light on the problem. |
|
|
OK I got down to the X protocol nitty gritty My window manager - right or wrong - sets the EventCrossing detail to GDK_NOTIFY_VIRTUAL when I switch workspaces back and forth with the keyboard, so the mouse never moves._and_ when I move the mouse between the workspace and the editor window. This type of crossing is ignored by ardour and can cause the editor-specific keybindings to be ignored depending on what I did in the other workspace/screen, but the global ones are still processed. So my question is: windowmanager bug or ardour bug? The spec says : "the pointer moves between an ancestor and an inferior of the window" |
|
|
Yet another bugnote If I understand this correctly, each gtk widget forms a child window for X. The crossing event callback is set on the toplevel window, but the cursor always enters some widget/container that is a child of the toplevel window. This means that crossing from the rootwindow into the editor will allways give a virtual-crossing detail to the toplevelwindow and would (if the callback was set) give the notify_ancestor detail only to the container/widget were the cursor actually is. Since setting the keyboard target to the editor is not done if the detail is set to notify_virtual, it will never be set if I enter the editor window via its parent. If I enter the window via some other window, I get notify_nonlinear_virtual crossing details, and the target _is_ set. All in all I can't think of any reason why the notify_virtual crossings are ingnored. |
|
|
I am having this problem as well, but _not_ with a dual head setup. I lose focus by clicking anywhere outside the frame with the tracks in it (eg. the zoom buttons, menu bar, etc.). Clicking on the track does not get the focus back but it does come back if I select something like Edit->Copy from the region context menu. |
|
|
N.B. I'm using gnome as well. |
|
|
just an extra little bit of reproducibility information: in gnome I don't need to select anything from the context menu to get the focus back, just bringing it up does the job, but in kde this doesn't work and I haven't found a way to do it in kde. |
|
|
The focusing method ardour uses has completely changed. Is this still an issue in ardour-2? |
|
|
No feedback on whether this is still an issue with ardour2, so I'm marking as resolved. Please leave a message on the bug if it's still an issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-30 10:16 | hansfbaier | New Issue | |
| 2004-03-30 10:16 | hansfbaier | => hansbaier@web.de | |
| 2004-03-30 10:16 | hansfbaier | Name | => Hans Baier |
| 2004-03-31 01:47 | ryanpg | Note Added: 0000587 | |
| 2004-03-31 01:57 | paul | Note Added: 0000588 | |
| 2004-03-31 01:58 | paul | Status | new => feedback |
| 2004-03-31 02:12 | ryanpg | Note Added: 0000591 | |
| 2004-03-31 02:13 | paul | Note Added: 0000592 | |
| 2004-06-08 14:56 | vandongen | Note Added: 0000995 | |
| 2004-06-08 15:04 | vandongen | Note Added: 0000996 | |
| 2004-06-08 15:36 | vandongen | Note Added: 0000997 | |
| 2004-06-09 14:37 | vandongen | Note Added: 0001000 | |
| 2004-06-27 09:29 | vandongen | Note Added: 0001120 | |
| 2004-08-20 14:18 | ndv | Note Added: 0001423 | |
| 2004-08-20 14:19 | ndv | Note Added: 0001424 | |
| 2004-09-13 17:01 | ndv | Note Added: 0001474 | |
| 2007-02-14 22:22 | taybin | Note Added: 0003272 | |
| 2007-04-07 12:18 | cth103 | Status | feedback => resolved |
| 2007-04-07 12:18 | cth103 | Resolution | open => no change required |
| 2007-04-07 12:18 | cth103 | Assigned To | => cth103 |
| 2007-04-07 12:18 | cth103 | Note Added: 0003752 | |
| 2008-11-21 00:31 | seablade | Status | resolved => closed |
