Re: focus problem

Hi Yen-Ju,

I have played some more with Azalea and the focus problem.
The problem 
can easily be reproduced by adding a menu item to any
application and 
doing

- (void)test
{
     [[NSWorkspace sharedWorkspace] launchApplication:"TextEdit"];
}

in the corresponding method. I tried this with GNOME, Window
Maker and 
Azalea. With all three window managers I got the same
result. If the 
above method is called for the first time (TextEdit.app not
yet 
running), then the application is correctly started and gets
key focus. 
However, if the app is already running, then it is
activated, but it 
does not get key focus.

This seems to be a general problem in GNUstep, nothing
specifically 
related to Azalea.

Any ideas?

Regards,

   Andreas




_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Andreas Höschler wrote:
> Hi Yen-Ju,
> 
> I have played some more with Azalea and the focus
problem. The problem
> can easily be reproduced by adding a menu item to any
application and doing
> 
> - (void)test
> {
>     [[NSWorkspace sharedWorkspace]
launchApplication:"TextEdit"];
> }
> 
> in the corresponding method. I tried this with GNOME,
Window Maker and
> Azalea. With all three window managers I got the same
result. If the
> above method is called for the first time (TextEdit.app
not yet
> running), then the application is correctly started and
gets key focus.
> However, if the app is already running, then it is
activated, but it
> does not get key focus.
> 
> This seems to be a general problem in GNUstep, nothing
specifically
> related to Azalea.
> 


I think I finally found the reason for this problem and as
often it
turns out to be rather simple and actually the same problem
as the one I
already solved:
The time send along with the XSetInputFocus call is to old,
so the
request to set the focus is ignored by the X server.
For this last problem this was caused by the variable
generic.lastTime
not being set up properly, it was initialized with 1 and not
with
CurrentTime. In our new case the problem is more subtle. The
code tries
to keep the time of the last event to use this as the time
for the focus
change, based on the reasoning the any focus change must be
triggered by
an event and if we set the stored time for every event we
are always as
current as the focus change. This reasoning isn't true for
the case
where an application gets activated without an event. In our
case it was
activated by a DO call from another program. Now the last
event time for
the application that is to activate is older then the one at
the server
and the request gets ignored.
One simple workaround here is to always use CurrentTime as
the time for
the focus change. This of course has some risks, we work
around the
protection mechanism of the X server and may easily end up
with a race
condition, when a user switches focus too fast. But for the
moment this
is the best solution I see.

Any comments?

Fred


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

I took a look for the focus issue about "menu
disappears when last
document window is closed".
I found that when GNUstep receives a FocusOut event,
it immediately tries to see where is the current focus and
decide what to do.
It works fine when the focus is transfered from window A to
window B
with XSetInputFocus().
But when a window A is closed (Unmap), window manager has to
process
the unmap event first, then decide where to focus to.

So the sequence for window manager is:
(1) unmap event on old X window
(2) focus out event on old X window
(3) focus in event on new X window

There is a good chance that GNUstep try to
get the focused window between (2) and (3).
To prove that, I try this patch:

Index: Source/x11/XGServerEvent.m
============================================================
=======
--- Source/x11/XGServerEvent.m  (revision 25408)
+++ Source/x11/XGServerEvent.m  (working copy)
 -1013,7
+1013,7 
         {
           Window       fw;
           int          rev;

+usleep(1000000);
           /*
            * See where the focus has moved to -
            * If it has gone to 'none' or 'PointerRoot'
then

It waits a second so that window manager has time to
set the focus to new window and it works !
So I believe it is a racing issue between GNUstep and window
manager.
GNUstep try to get the focused window while window manager
haven't
have time to prepare it.
And it only happens during window closing because unmapping
also
generates FocusOut[1] event.
This document[2] describes the focus handling in great
details.

Currently, if the focus falls into None or PointerRoot,
GNUstep deactives itself, therefore, menu disappears.
While I haven't have a fix yet, here is the possible one
(a) if focus falls into None, GNUstep does not deactivates
because it means one of the GNUstep's window is closed
and focus is not transfers to any other window or background
(root window).
(b) if focus falls into PointerRoot,
it is more complicated and I have not idea yet. 

[1]htt
p://tronche.com/gui/x/xlib/events/input-focus/
[2]http://tronche.com/gui/x/xlib/events/inp
ut-focus/normal-and-grabbed.html

Yen-Ju

On 8/21/07, Fred Kiefer <fredkiefergmx.de> wrote:
> Andreas Höschler wrote:
> > Hi Yen-Ju,
> >
> > I have played some more with Azalea and the focus
problem. The problem
> > can easily be reproduced by adding a menu item to
any application and doing
> >
> > - (void)test
> > {
> >     [[NSWorkspace sharedWorkspace]
launchApplication:"TextEdit"];
> > }
> >
> > in the corresponding method. I tried this with
GNOME, Window Maker and
> > Azalea. With all three window managers I got the
same result. If the
> > above method is called for the first time
(TextEdit.app not yet
> > running), then the application is correctly
started and gets key focus.
> > However, if the app is already running, then it is
activated, but it
> > does not get key focus.
> >
> > This seems to be a general problem in GNUstep,
nothing specifically
> > related to Azalea.
> >
>
>
> I think I finally found the reason for this problem and
as often it
> turns out to be rather simple and actually the same
problem as the one I
> already solved:
> The time send along with the XSetInputFocus call is to
old, so the
> request to set the focus is ignored by the X server.
> For this last problem this was caused by the variable
generic.lastTime
> not being set up properly, it was initialized with 1
and not with
> CurrentTime. In our new case the problem is more
subtle. The code tries
> to keep the time of the last event to use this as the
time for the focus
> change, based on the reasoning the any focus change
must be triggered by
> an event and if we set the stored time for every event
we are always as
> current as the focus change. This reasoning isn't true
for the case
> where an application gets activated without an event.
In our case it was
> activated by a DO call from another program. Now the
last event time for
> the application that is to activate is older then the
one at the server
> and the request gets ignored.
> One simple workaround here is to always use CurrentTime
as the time for
> the focus change. This of course has some risks, we
work around the
> protection mechanism of the X server and may easily end
up with a race
> condition, when a user switches focus too fast. But for
the moment this
> is the best solution I see.
>
> Any comments?
>
> Fred
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustepgnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

On 8/21/07, Yen-Ju Chen <yjchenxgmail.com> wrote:
> I took a look for the focus issue about "menu
disappears when last
> document window is closed".
> I found that when GNUstep receives a FocusOut event,
> it immediately tries to see where is the current focus
and decide what to do.
> It works fine when the focus is transfered from window
A to window B
> with XSetInputFocus().
> But when a window A is closed (Unmap), window manager
has to process
> the unmap event first, then decide where to focus to.
>
> So the sequence for window manager is:
> (1) unmap event on old X window
> (2) focus out event on old X window
> (3) focus in event on new X window
>
> There is a good chance that GNUstep try to
> get the focused window between (2) and (3).
> To prove that, I try this patch:
>
> Index: Source/x11/XGServerEvent.m
>
============================================================
=======
> --- Source/x11/XGServerEvent.m  (revision 25408)
> +++ Source/x11/XGServerEvent.m  (working copy)
>  -1013,7 +1013,7 
>          {
>            Window       fw;
>            int          rev;
>
> +usleep(1000000);
>            /*
>             * See where the focus has moved to -
>             * If it has gone to 'none' or 'PointerRoot'
then
>
> It waits a second so that window manager has time to
> set the focus to new window and it works !
> So I believe it is a racing issue between GNUstep and
window manager.
> GNUstep try to get the focused window while window
manager haven't
> have time to prepare it.
> And it only happens during window closing because
unmapping also
> generates FocusOut[1] event.
> This document[2] describes the focus handling in great
details.
>
> Currently, if the focus falls into None or
PointerRoot,
> GNUstep deactives itself, therefore, menu disappears.
> While I haven't have a fix yet, here is the possible
one
> (a) if focus falls into None, GNUstep does not
deactivates
> because it means one of the GNUstep's window is closed
> and focus is not transfers to any other window or
background (root window).
> (b) if focus falls into PointerRoot,
> it is more complicated and I have not idea yet. 
>
> [1]htt
p://tronche.com/gui/x/xlib/events/input-focus/
> [2]http://tronche.com/gui/x/xlib/events/inp
ut-focus/normal-and-grabbed.html

After playing with focus a little bit,
I realize handling 'None' and "PointerRoot' does not
help.
The only way to work is to transfer focus to another window
(usually main menu)
before unmapping.
If there are two or more document windows and one of them is
closed,
the focus should be transfered to the other document
window.
GNUstep seems to use 'pull model of focus management'[3]
and I guess most window managers are 'push model'.
So it is not clear to me that such transfer of focus should
be
implemented in GNUstep or window manager.

[3] http://www.tronche.com/gui/x/xlib/IC
C/client-to-window-manager/wm-hints.html

Yen-Ju


>
> Yen-Ju
>
> On 8/21/07, Fred Kiefer <fredkiefergmx.de> wrote:
> > Andreas Höschler wrote:
> > > Hi Yen-Ju,
> > >
> > > I have played some more with Azalea and the
focus problem. The problem
> > > can easily be reproduced by adding a menu
item to any application and doing
> > >
> > > - (void)test
> > > {
> > >     [[NSWorkspace sharedWorkspace]
launchApplication:"TextEdit"];
> > > }
> > >
> > > in the corresponding method. I tried this
with GNOME, Window Maker and
> > > Azalea. With all three window managers I got
the same result. If the
> > > above method is called for the first time
(TextEdit.app not yet
> > > running), then the application is correctly
started and gets key focus.
> > > However, if the app is already running, then
it is activated, but it
> > > does not get key focus.
> > >
> > > This seems to be a general problem in
GNUstep, nothing specifically
> > > related to Azalea.
> > >
> >
> >
> > I think I finally found the reason for this
problem and as often it
> > turns out to be rather simple and actually the
same problem as the one I
> > already solved:
> > The time send along with the XSetInputFocus call
is to old, so the
> > request to set the focus is ignored by the X
server.
> > For this last problem this was caused by the
variable generic.lastTime
> > not being set up properly, it was initialized with
1 and not with
> > CurrentTime. In our new case the problem is more
subtle. The code tries
> > to keep the time of the last event to use this as
the time for the focus
> > change, based on the reasoning the any focus
change must be triggered by
> > an event and if we set the stored time for every
event we are always as
> > current as the focus change. This reasoning isn't
true for the case
> > where an application gets activated without an
event. In our case it was
> > activated by a DO call from another program. Now
the last event time for
> > the application that is to activate is older then
the one at the server
> > and the request gets ignored.
> > One simple workaround here is to always use
CurrentTime as the time for
> > the focus change. This of course has some risks,
we work around the
> > protection mechanism of the X server and may
easily end up with a race
> > condition, when a user switches focus too fast.
But for the moment this
> > is the best solution I see.
> >
> > Any comments?
> >
> > Fred
> >
> >
> > _______________________________________________
> > Discuss-gnustep mailing list
> > Discuss-gnustepgnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnustep
> >
>


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

As I said, the first half of the issue is that GNUstep
cannot find the
focused window while it is unmapped. So it deactivates
itself.
This patch transfers the focus to another window in the
same GNUstep application before it is unmapped,
therefore, fixes the problem.

The second half of the problem is that after the unmapping,
window manager tends to actively find another window to
focus on,
therefore, even GNUstep transfers the focus, it still loses
it.
So there is nothing GNUstep can do about it.
It has to be fixed on window manager.

This patch works for me, but may need to improvement.

Yen-Ju

On 8/21/07, Yen-Ju Chen <yjchenxgmail.com> wrote:
> On 8/21/07, Yen-Ju Chen <yjchenxgmail.com> wrote:
> > I took a look for the focus issue about "menu
disappears when last
> > document window is closed".
> > I found that when GNUstep receives a FocusOut
event,
> > it immediately tries to see where is the current
focus and decide what to do.
> > It works fine when the focus is transfered from
window A to window B
> > with XSetInputFocus().
> > But when a window A is closed (Unmap), window
manager has to process
> > the unmap event first, then decide where to focus
to.
> >
> > So the sequence for window manager is:
> > (1) unmap event on old X window
> > (2) focus out event on old X window
> > (3) focus in event on new X window
> >
> > There is a good chance that GNUstep try to
> > get the focused window between (2) and (3).
> > To prove that, I try this patch:
> >
> > Index: Source/x11/XGServerEvent.m
> >
============================================================
=======
> > --- Source/x11/XGServerEvent.m  (revision 25408)
> > +++ Source/x11/XGServerEvent.m  (working copy)
> >  -1013,7 +1013,7 
> >          {
> >            Window       fw;
> >            int          rev;
> >
> > +usleep(1000000);
> >            /*
> >             * See where the focus has moved to -
> >             * If it has gone to 'none' or
'PointerRoot' then
> >
> > It waits a second so that window manager has time
to
> > set the focus to new window and it works !
> > So I believe it is a racing issue between GNUstep
and window manager.
> > GNUstep try to get the focused window while window
manager haven't
> > have time to prepare it.
> > And it only happens during window closing because
unmapping also
> > generates FocusOut[1] event.
> > This document[2] describes the focus handling in
great details.
> >
> > Currently, if the focus falls into None or
PointerRoot,
> > GNUstep deactives itself, therefore, menu
disappears.
> > While I haven't have a fix yet, here is the
possible one
> > (a) if focus falls into None, GNUstep does not
deactivates
> > because it means one of the GNUstep's window is
closed
> > and focus is not transfers to any other window or
background (root window).
> > (b) if focus falls into PointerRoot,
> > it is more complicated and I have not idea yet.

> >
> > [1]htt
p://tronche.com/gui/x/xlib/events/input-focus/
> > [2]http://tronche.com/gui/x/xlib/events/inp
ut-focus/normal-and-grabbed.html
>
> After playing with focus a little bit,
> I realize handling 'None' and "PointerRoot' does
not help.
> The only way to work is to transfer focus to another
window (usually main menu)
> before unmapping.
> If there are two or more document windows and one of
them is closed,
> the focus should be transfered to the other document
window.
> GNUstep seems to use 'pull model of focus
management'[3]
> and I guess most window managers are 'push model'.
> So it is not clear to me that such transfer of focus
should be
> implemented in GNUstep or window manager.
>
> [3] http://www.tronche.com/gui/x/xlib/IC
C/client-to-window-manager/wm-hints.html
>
> Yen-Ju
>
>
> >
> > Yen-Ju
> >
> > On 8/21/07, Fred Kiefer <fredkiefergmx.de> wrote:
> > > Andreas Höschler wrote:
> > > > Hi Yen-Ju,
> > > >
> > > > I have played some more with Azalea and
the focus problem. The problem
> > > > can easily be reproduced by adding a
menu item to any application and doing
> > > >
> > > > - (void)test
> > > > {
> > > >     [[NSWorkspace sharedWorkspace]
launchApplication:"TextEdit"];
> > > > }
> > > >
> > > > in the corresponding method. I tried
this with GNOME, Window Maker and
> > > > Azalea. With all three window managers I
got the same result. If the
> > > > above method is called for the first
time (TextEdit.app not yet
> > > > running), then the application is
correctly started and gets key focus.
> > > > However, if the app is already running,
then it is activated, but it
> > > > does not get key focus.
> > > >
> > > > This seems to be a general problem in
GNUstep, nothing specifically
> > > > related to Azalea.
> > > >
> > >
> > >
> > > I think I finally found the reason for this
problem and as often it
> > > turns out to be rather simple and actually
the same problem as the one I
> > > already solved:
> > > The time send along with the XSetInputFocus
call is to old, so the
> > > request to set the focus is ignored by the X
server.
> > > For this last problem this was caused by the
variable generic.lastTime
> > > not being set up properly, it was initialized
with 1 and not with
> > > CurrentTime. In our new case the problem is
more subtle. The code tries
> > > to keep the time of the last event to use
this as the time for the focus
> > > change, based on the reasoning the any focus
change must be triggered by
> > > an event and if we set the stored time for
every event we are always as
> > > current as the focus change. This reasoning
isn't true for the case
> > > where an application gets activated without
an event. In our case it was
> > > activated by a DO call from another program.
Now the last event time for
> > > the application that is to activate is older
then the one at the server
> > > and the request gets ignored.
> > > One simple workaround here is to always use
CurrentTime as the time for
> > > the focus change. This of course has some
risks, we work around the
> > > protection mechanism of the X server and may
easily end up with a race
> > > condition, when a user switches focus too
fast. But for the moment this
> > > is the best solution I see.
> > >
> > > Any comments?
> > >
> > > Fred
> > >
> > >
> > >
_______________________________________________
> > > Discuss-gnustep mailing list
> > > Discuss-gnustepgnu.org
> > > http://lists.gnu.org/mailman/listinfo/discuss-gnustep
> > >
> >
>

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep