audacity-devel

[Audacity-devel] Possible keyboard issue on Linux

[Leland <le...@au...>]

Can anyone confirm this?

1)  Start Audacity
2)  Generate a tone
3)  Press the spacebar (or ANY shortcut like CTRL+N or CTRL+O)

Do you get any reaction at all?

The only way I've found around it is to click one of the toolbar buttons 
and then all the shortcuts work fine.

Leland

Re: [Audacity-devel] Possible keyboard issue on Linux

[Richard A. <ri...@au...>]

On Sun, 2009-01-04 at 22:01 -0600, Leland wrote:
> Can anyone confirm this?
> 
> 1)  Start Audacity
> 2)  Generate a tone
> 3)  Press the spacebar (or ANY shortcut like CTRL+N or CTRL+O)
> 
> Do you get any reaction at all?
> 
> The only way I've found around it is to click one of the toolbar buttons 
> and then all the shortcuts work fine.

Confirmed. There was a thread related to this about the 22nd of November
entitled "Keyboard input bug in Audacity 1.3.6" which decided it did
exist but was linux-only. I've certainly been seeing it for a while, but
not had the courage to work out what was going on.

Anything with a text entry area seems to work to clear the issue, e.g.
the amplify effect or the Edit Labels dialogue. On the other hand, you
can't type text into labels whilst the bug is in effect (shortcuts not
working).

Richard

Re: [Audacity-devel] Possible keyboard issue on Linux

[Leland <le...@au...>]

Richard Ash wrote:
> On Sun, 2009-01-04 at 22:01 -0600, Leland wrote:
>> Can anyone confirm this?
>>
>> 1)  Start Audacity
>> 2)  Generate a tone
>> 3)  Press the spacebar (or ANY shortcut like CTRL+N or CTRL+O)
>>
>> Do you get any reaction at all?
>>
>> The only way I've found around it is to click one of the toolbar buttons 
>> and then all the shortcuts work fine.
> 
> Confirmed. There was a thread related to this about the 22nd of November
> entitled "Keyboard input bug in Audacity 1.3.6" which decided it did
> exist but was linux-only. I've certainly been seeing it for a while, but
> not had the courage to work out what was going on.
> 
It has to do with the ProgressDialog, or more correctly, it has to
do with wxWindowDisabler.

The ProgressDialog uses wxWindowDisabler to block events to all top 
level windows so that when the progress dialog is active (whether shown 
or not), the user can't interact with the rest of Audacity.

The way we used to use wxProgressDialog actually had a 1/2 second window 
  between the time the action (effect, import, ...) started and the time 
the wxProgressDialog was actually created and shown.  Of course, this 
was to keep from showing it for short actions, but it opened the 
exposure since the app wasn't blocked until the progress dialog was 
created...1/2 a second into the action.

Now, the progress dialog is created at the beginning of the action which 
blocks the rest of the app right away.  If it continues for longer than 
the 1/2 second delay, then it will be shown.

However, OSX and GTK seem to lose focus when the wxWindowDisabler is 
used.  At least, everything is just happy if it isn't created at all. 
And it "seems" to matter if the progress dialog actually gets shown or not.

But, remember...this is all just guesswork and observation.  I traced 
wxGTK for about 3 hours tonight to see if I could figure out where the 
focus was going and why.  I finally happened upon a workable solution 
(a.k.a workaround, a.k.a. hackage) that makes both OSX and GTK happy.

Anyway, give it a try and see if it works better now.

Leland

Re: [Audacity-devel] Possible keyboard issue on Linux

[Richard A. <ri...@au...>]

On Wed, 2009-01-07 at 23:46 -0600, Leland wrote:
> It has to do with the ProgressDialog, or more correctly, it has to
> do with wxWindowDisabler.
Well done!

> However, OSX and GTK seem to lose focus when the wxWindowDisabler is 
> used.  At least, everything is just happy if it isn't created at all. 
> And it "seems" to matter if the progress dialog actually gets shown or not.
> 
> But, remember...this is all just guesswork and observation.  I traced 
> wxGTK for about 3 hours tonight to see if I could figure out where the 
> focus was going and why.  I finally happened upon a workable solution 
> (a.k.a workaround, a.k.a. hackage) that makes both OSX and GTK happy.
> 
> Anyway, give it a try and see if it works better now.
It works fine for me on a quick test. Looks like we have a viable
solution for the moment, although we probably need to keep an eye on it
in future.

Richard