Skip Menu |

This queue is for tickets about the Prima CPAN distribution.

Report information
The Basics
Id: 83229
Status: resolved
Priority: 0/
Queue: Prima

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: focus steal from other apps
Date: Sat, 09 Feb 2013 10:09:54 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Under X and fvwm in click-to-focus mode, if a prima program is badly lagged it can steal the keyboard focus from another application. With the program foo.pl below, run foo.pl click "Sleep" # it prints "sleeping" click "Dummy" # while it's sleeping click to focus on a different app => when the sleep ends prima steals the focus back to itself Nosing around the code it seems Widget_focused() calls apc_widget_set_focused() with guts.currentFocusTime == 0, ie. CurrentTime, thus taking the focus no matter what subsequent user action has done. The fix might be as simple as putting the mouse click time into guts.currentFocusTime. Or maybe use guts.last_time whenever currentFocusTime is 0 -- which might be always except for responding to WM_TAKE_FOCUS. I struck this in a slow drawing program. When it catches up from its lag it tended to steal the focus from where I'd switched away.
use strict; use Prima; use Prima::Buttons; use Prima 'Application'; my $main = Prima::MainWindow->new (size => [100,100]); $main->insert ('Button', text => 'Sleep', pack => { side => 'top' }, onClick => sub { my ($button) = @_; print "sleeping\n"; sleep 3; print "awake again\n"; }); $main->insert ('Button', text => 'Dummy', pack => { side => 'top' }, onClick => sub { my ($button) = @_; print "dummy button\n"; }); Prima->run; exit 0;
Hi Kevin, I'm reluctant to mess with the time argument, because it indeed means set the focus NOW. The programmer might want to focus a widget just for the sake of it, without a referred mouse click or anything else. Generally, sleep(3) is guaranteed to break something because X is asynchronous ... I cannot reproduce your problem, but as a workaround I can propose a $::application->yield call before sleep, could help. Or possibly using Prima::Utils::post. Hope that helps /dk
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 23 Mar 2013 08:47:21 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > I'm reluctant to mess with the time argument, because it indeed means > set the focus NOW. The programmer might want to focus a widget just > for the sake of it, without a referred mouse click or anything else.
You might note the ICCCM spec under "Input Focus" prohibits current time, Clients that use a SetInputFocus request ... Note that clients must not use CurrentTime in the time field. Presumably a programmatic focus change from a timer or whatever ought still to give some recent relevant timestamp. Show quoted text
> Generally, sleep(3) is guaranteed to break something because X is > asynchronous ...
It's supposed to be mostly safe against lags, whether sleeping or gone away number crunching (like my program) or network slowness. The passive focus style is a touch easier, though you then have to manage focus among the application's sub-windows or widgets.
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Fri, 22 Mar 2013 23:21:12 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> You might note the ICCCM spec under "Input Focus" prohibits current > time, > > Clients that use a SetInputFocus request > ... > Note that clients must not use CurrentTime in the time field. > > Presumably a programmatic focus change from a timer or whatever ought > still to give some recent relevant timestamp.
Hmmm yes, you are right actually, now I do remember that paragraph. But I don't think still I'm sure that recording the last mouse event time is the correct solution for the problem, because how would semantics of "set focus now" would be then implemented? ICCCM manual doesn't address this question. -- Sincerely, Dmitry Karasik
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 23 Mar 2013 11:44:15 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > how would semantics of "set focus now" would be then implemented? > ICCCM manual doesn't address this question.
I suppose it presumes focus changes are the result of user interaction, so there's always an originating mouse or key. Within the toolkit I imagine focus change is normally in response to the last button or key etc. Or at least unless a program says otherwise it's probably helpful to assume that. The only genuinely random or externally driven focus change I can think of might be an alert window forcibly taking the focus to itself. Not sure how to cleanly distinguish that from a more usual interaction. At any rate the problem I had was a button press case. The button press in the "Dummy" widget doesn't have its even timestamp propagate to the SetInputFocus.
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 23 Mar 2013 08:19:15 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> I suppose it presumes focus changes are the result of user interaction, > so there's always an originating mouse or key. > > Within the toolkit I imagine focus change is normally in response to the > last button or key etc. Or at least unless a program says otherwise > it's probably helpful to assume that. > > The only genuinely random or externally driven focus change I can think > of might be an alert window forcibly taking the focus to itself. Not > sure how to cleanly distinguish that from a more usual interaction. > > At any rate the problem I had was a button press case. The button press > in the "Dummy" widget doesn't have its even timestamp propagate to the > SetInputFocus.
My point exactly. The real problem here is Prima's abstraction level, which doesn't distinguish between "set focus as a result of user interaction" and "set focus now". That's inheritance from Windows and OS/2 API; if programming X directly, one explicitly tells that. OTOH I'm thinking that Prima can localize (i.e. similar to perl's "local") last event timestamp, and if whatever focus request is being issued inside an event that is X-driven (i.e. mouse, keyboard, etc), that timestamp can be used. If the requiest is f.ex. inside Timer event or not inside event handler at all, then it falls back to CurrentTime. What do you think? -- Sincerely, Dmitry Karasik
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 30 Mar 2013 11:45:48 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > OTOH I'm thinking that Prima can localize (i.e. similar to perl's "local") last > event timestamp, and if whatever focus request is being issued inside an event > that is X-driven (i.e. mouse, keyboard, etc), that timestamp can be used. If > the requiest is f.ex. inside Timer event or not inside event handler at all, > then it falls back to CurrentTime. What do you think?
Maybe. Usually toolkit focus setting is only within the top-level application window, not forcibly taking the focus to the application. I'd be tempted to have a special method on Prima::Window for forcibly taking the focus, if it's in fact possible to do so on all platforms. But focus stuff seems to be one of the most complicated toolkit areas.
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 30 Mar 2013 11:51:37 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
On Fri, Mar 29, 2013 at 08:46:18PM -0400, Kevin Ryde via RT wrote: Show quoted text
> Queue: Prima > Maybe. Usually toolkit focus setting is only within the top-level > application window, not forcibly taking the focus to the application. > I'd be tempted to have a special method on Prima::Window for forcibly > taking the focus, if it's in fact possible to do so on all platforms. > But focus stuff seems to be one of the most complicated toolkit areas.
Forced focus is ok on win32, and as I think is also ok on x11, as long as WM (or its user-specified policy) has nothing against it. One thing is sure, Prima's focus model definitely was build to support forced focus. I'll try later to implement that change and we'll see if it was a good idea. -- Sincerely, Dmitry Karasik
Hi Kevin, I've committed a changed that to stop stealing the focus, at least in my default Ubuntu environment. I'd like to ask you if you could take look at the latest github snapshot if that works in your setup as well. Thanks! /dk
Hi Kevin, I've committed a change that seems to stop stealing the focus, at least in my default Ubuntu environment. I'd like to ask you if you could take look at the latest github snapshot if that works in your setup as well. Thanks! /dk
Subject: Re: [rt.cpan.org #83229] focus steal from other apps
Date: Sat, 06 Apr 2013 09:47:44 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > if that works in your setup as well.
Yes, works for me :).