Rudolf, use Alt+F6 to get focus to the ssl dialog.

This seems to be one of those Linux things.  For instance, if you get into Gedit, then press Control+F to get into the Find dialog, then Alt+Tab out of Gedit and back to it, focus will be in the document and not the Find dialog.  There, too, you have to use Alt+F6 to move focus back to it.  

Please confirm that with the patch and after using Alt+F6 to get focus back to the dialog, things work as you'd expect.   Thanks!

Hi,
Yes, I can confirm, that pressing alt+f6 focusses the window and everything is fine again.
I still think, this is a problem, because totally blind people cannot know, that there's a dialog there, which just doesn't have focus. 
Is this a problem of the window manager or something else in gnome? Then we could file a bug against that.

Cheers, Rudolf

> I still think, this is a problem, because totally blind people cannot know,
> that there's a dialog there, which just doesn't have focus. 

I happen to be sighted and I also think it's a problem because if I Alt Tab out of something and Alt Tab back into it, I think things should be put back the way they were when I left (i.e. focus restored to the dialog that had focus).  This feature/behavior/whatever of always restoring focus to the application frame is something I've gotten used to over time, but is nonetheless annoying IMHO.

But looking at the issue strictly from the perspective of users who are blind and Orca, I wonder if we should be speaking something under the following circumstances:

1. An application frame just claimed focus, and
2. The previous locusOfFocus was not that application, and
3. A dialog box that is a child of that application is present but not focused

That would at least give users who are blind access to the same information that sighted users have i.e. that the silly dialog that should have focus is indeed present, but not focused. <smile>

Rudolf, would that help?  Mike, Will:  Thoughts?

> Is this a problem of the window manager or something else in gnome? Then we
> could file a bug against that.

I'm guessing the window manager, but I'm not sure.  Mike, Will:  Thoughts on this as well please.

In the meantime, I'm renaming the summary of the bug to reflect the broader issue.

> I happen to be sighted and I also think it's a problem because if I Alt Tab out
> of something and Alt Tab back into it, I think things should be put back the
> way they were when I left (i.e. focus restored to the dialog that had focus). 
> This feature/behavior/whatever of always restoring focus to the application
> frame is something I've gotten used to over time, but is nonetheless annoying
> IMHO.

Agreed.  I don't like it, either, because I always forget the key combination to cycle through the application's windows (Alt+F6?).
 
> But looking at the issue strictly from the perspective of users who are blind
> and Orca, I wonder if we should be speaking something under the following
> circumstances:
> 
> 1. An application frame just claimed focus, and
> 2. The previous locusOfFocus was not that application, and
> 3. A dialog box that is a child of that application is present but not focused

Sounds like an interesting idea. Maybe something like "m of n windows" if n > 1?

> > Is this a problem of the window manager or something else in gnome? Then we
> > could file a bug against that.

I'm not sure where the bug lies.  I suspect it might be the application?  I notice that when I do something like F7 (spell check) in gedit, it seems to do the right thing when I Alt+Tab away/back from it: the spell check window gets focus.

 
 
> I'm not sure where the bug lies.  I suspect it might be the application?  I
> notice that when I do something like F7 (spell check) in gedit, it seems to do
> the right thing when I Alt+Tab away/back from it: the spell check window gets
> focus.

The spell check dialog is modal.  Therefore, by definition, when gedit regains focus via Alt+Tab, the spell check dialog regains focus automatically.  Try your gedit experiment but use the Find dialog instead of spell check.

Another example would be in OpenOffice:  The Navigator window.  Give it focus, then Alt+Tab out of OpenOffice and back to it.  Your document will have focus and you'll then have to Alt+F6 back to Navigator.

One more example -- that doesn't mean there aren't others (far from it!); merely that I'm going to stop listing them here. :-)

In Rhythmbox, choose Import File from the Music menu.  Alt Tab out and then back.  Guess what dialog box does NOT have focus. ;-)

Well, let's think of a way to let people know about this.  I think it needs to be brief and informative for speech, perhaps in the context for braille, and maybe part of the WhereAmI information.  Here's a quick proposal:

For speech, what about something like "m of n windows" (if n > 1) right after the title is spoken.

For braille context, maybe "(m of n windows)" included after the window title in the braille context if n > 1.

For WhereAmI, add the "m of n windows" info to the results of Insert + KP_Enter.

I like your proposal.  Should we always do this or only when the Window is not Alt+Tab'able?  For instance, in Evolution most Windows seem to be in the Alt+Tab order.

Minor proposed adjustments:  With whereAmI we speak "role m of n" (row 2 of 22, item 3 of 5).  Therefore...

> For speech, what about something like "m of n windows" (if n > 1) right after
> the title is spoken.

What about "window m of n"?
 
> For braille context, maybe "(m of n windows)" included after the window title
> in the braille context if n > 1.

I'd leave this one as you have it so that the "m of n" has a better shot of being displayed without scrolling.
 
> For WhereAmI, add the "m of n windows" info to the results of Insert +
> KP_Enter.

Again, what about "window m of n"?

(In reply to comment #9)
> I like your proposal.  Should we always do this or only when the Window is not
> Alt+Tab'able?  For instance, in Evolution most Windows seem to be in the
> Alt+Tab order.

I dunno.  Mike -- what would you prefer?

> Minor proposed adjustments:  With whereAmI we speak "role m of n" (row 2 of 22,
> item 3 of 5).  Therefore...
>
> > For speech, what about something like "m of n windows" (if n > 1) right after
> > the title is spoken.
> 
> What about "window m of n"?

Sounds good.
 
> > For braille context, maybe "(m of n windows)" included after the window title
> > in the braille context if n > 1.
> 
> I'd leave this one as you have it so that the "m of n" has a better shot of
> being displayed without scrolling.

Maybe just "(m of n)" would be better.  It would take up less space and the user should be able to imply what it means.

> > For WhereAmI, add the "m of n windows" info to the results of Insert +
> > KP_Enter.
> 
> Again, what about "window m of n"?

Sounds good.

(In reply to comment #10)
> (In reply to comment #9)
> > I like your proposal.  Should we always do this or only when the Window is not
> > Alt+Tab'able?  For instance, in Evolution most Windows seem to be in the
> > Alt+Tab order.
> I dunno.  Mike -- what would you prefer?
Only when a window isn't alt+tabbable.
> > Minor proposed adjustments:  With whereAmI we speak "role m of n" (row 2 of 22,
> > item 3 of 5).  Therefore...
> >
> > > For speech, what about something like "m of n windows" (if n > 1) right after
> > > the title is spoken.
> > 
> > What about "window m of n"?
> Sounds good.
> > > For braille context, maybe "(m of n windows)" included after the window title
> > > in the braille context if n > 1.
> > 
> > I'd leave this one as you have it so that the "m of n" has a better shot of
> > being displayed without scrolling.
> Maybe just "(m of n)" would be better.  It would take up less space and the
> user should be able to imply what it means.
> > > For WhereAmI, add the "m of n windows" info to the results of Insert +
> > > KP_Enter.
> > 
> > Again, what about "window m of n"?
> Sounds good.
I'm quite happy with everything in this proposal

> Only when a window isn't alt+tabbable.

So we need to be able to identify not just unfocused dialogs but also frames that are not in the Alt+Tab order.  Using Accerciser to compare items that are in the Alt+Tab order with those that are not, nothing is jumping out at me.  While I'm not certain about this, I suspect window type hints have something to do with it.... (e.g. frames with a type hint of a dialog or notification probably wouldn't be in the Alt+Tab order; frames with a type hint of normal probably would).

I've opened bug 468122 against atk/gail requesting type hints be exposed. 

Just had a quick look at this one. 

I don't understand how it can be "m of n windows". In other words,
how do you know this is the m'th window as opposed to the m+1'th window?

Aren't you going to have to braille/speak something like:

"This application has n windows."


Until bug #468122 is fixed, it looks like it's blocked.

Or...

In the meantime, we could speak/braille that simpler message:

"This application has n windows."

when a new application gets focus.

(In reply to comment #13)
> Just had a quick look at this one. 
> 
> I don't understand how it can be "m of n windows". In other words,
> how do you know this is the m'th window as opposed to the m+1'th window?

Good point.  Maybe add "(1 of n)" after the window title for both speech and braille iff n > 1?

Also marking this as future now that string freeze has arrived and this really isn't that high priority of a problem to request a freeze break.

First coarse pass at GNOME 2.24 planning.

Created attachment 110927 [details] [review]
Revision #1

Here's a first cut at a patch which implements this (apart from
the "only when the Window is not Alt+Tab'able" part which is 
blocked by bug #468122).

Some notes. 

1/ We no longer need to have a special SpeechGenerator class for gedit to
   override the _getSpeechForFrame() method. The patch removes that code.
   Note that the change to call self._getDefaultSpeech() in 
   the _getSpeechForFrame() method in the default speechgenerator.py was
   a separate previous change and so this code has been redundant since
   Orca 2.22.0. This patch further changes the default _getSpeechForFrame()
   mathod to add in the new functionality.

2/ The getAppWindowCount() routine currently does:

    def getAppWindowCount(self, obj):
        app = obj.getApplication()
        winCount = len(self.findByRole(app, pyatspi.ROLE_FRAME))
        winCount +=  len(self.findByRole(app, pyatspi.ROLE_DIALOG))
        return winCount

  Those two findByRole()'s could be expensive (i.e. slow down Orca) on
  applications like oocalc.

  Can we assume that frames and dialogs are going to be immediate 
  children of the app object? If so, then this routine can be rewritten
  to make it much faster. If they are not (i.e. a frame or dialog object
  could be buried deep in the object hierarchy), then this is probably 
  the best we can get.

Please test.

(In reply to comment #16)
> Created an attachment (id=110927) [edit]
> Revision #1
>   Those two findByRole()'s could be expensive (i.e. slow down Orca) on
>   applications like oocalc.

Agreed.

>   Can we assume that frames and dialogs are going to be immediate 
>   children of the app object? If so, then this routine can be rewritten
>   to make it much faster. If they are not (i.e. a frame or dialog object
>   could be buried deep in the object hierarchy), then this is probably 
>   the best we can get.

I think we can safely assume that the windows will be immediate children of the app object.  As such, we probably could look at the child count of the app object as a means to determine how many windows it is showing.

However, the plot thickens...let's look at gnome-terminal.

Each terminal window is treated as a child of a single gnome-terminal application.  When one brings up "Edit->Current Profile..." for gnome-terminal, the new window appears as a direct child of the application as well.  Now...try this:

1) Bring up three instances of gnome-terminal.  These show up as separate
   frames that are children of a single gnome-terminal application.
2) Open the Edit->Current Profile... from one of the terminals.  This shows
   up as a dialog that is a child of the gnome-terminal application.
3) Alt+Tab to another terminal window.
4) Press Alt+F6 to try to give the preferences dialog focus.

You cannot give the preferences dialog focus via Alt+F6 until you give focus to the gnome-terminal frame that was used to open the dialog.

For what to do in this case, I dunno.  The user will hear "1 of 4" windows when doing step 3 above, but will only be able to Alt+Tab to 3 of the windows and will only be able to Alt+F6 to the 4th window if they have Alt+Tab'ed to the right gnome-terminal window.  I also don't see any AT-SPI relations between the preferences dialog and the gnome-terminal frame that owns it.

Mike, Joanie, what are your thoughts on what should be done in this gnome-terminal case?

Created attachment 110968 [details] [review]
Revision #2.

Rewritten getAppWindowCount() routine that just looks at
the children of the app object. Much faster.

Here are a couple situations where I think this feature is overly verbose and shouldn't be kicking in.  
Have several windows open:  Two of which being pidgin and a chat room window.  
Notice that when you alt+tab to the chat window you hear "one of two".  I don't think this is what we want as chat windows aren't dialogs.

Open again several windows two of which being thunderbird and a thunderbird mail message that you are reading.  Notice that when you alt+tab to the message you again hear one of two.  

I'm not sure everyone is going to have the same opinion on this one. 

A possibility is to have YA setting on the General pane 
of the Orca preferences dialog that is a checkbox that 
says whether or not "(1 of <n>)" should be spoken and 
brailled.

Just a thought.

I thought the purpose of this feature was to alert the user that dialogs existed that did not have focus?  How is a mail message or a chat room a dialog?  

> I thought the purpose of this feature was to alert the user that dialogs
> existed that did not have focus?  How is a mail message or a chat room a
> dialog?  

Mike, the problem as I recall is that there are instances where the non-focused dialog isn't actually a dialog but is a frame.  The OOo Navigator window is a good example.

That said....

Rich, I was looking at all of the cases I mentioned (and a few others) and -- with the exception of OOo -- the windows in question seem to have a role of dialog or of alert.  We also have the open bug to get the hint info.  So, what about this:

1.  We only make the announcement for things which claim to be dialogs and alerts.

2.  We only make it when the thing making this claim does not have focus.

3. In order to be consistent ("hey, why did you say 1 of 3 windows here, but didn't say it there?!?"), we could switch the message to indicate the presence of an unfocused dialog/alert.

??

As for the gnome-terminal issue that Will brought up.  That one is a bit trickier. :-(  No matter what, if presented with a complicated scenario, we're probably going to have to take a guess.  And we might guess wrong. Working in Geckoland, I've learned to live with this reality. :-) But...

It seems like new objects get tacked onto the end of the hierarchy.  So the dialog Will mentions belongs to the frame that precedes it.  Create YA terminal window after the dialog appears.  It gets tacked on after the dialog.  Edit profiles in that new window, and the original dialog is killed and the new one (associated with terminal window 4) gets tacked on after terminal window 4. *shrugs*

In terms of OOo, this is a bit hacky but...

If we just present unfocused dialogs and alerts, then on a case-by-case, app-by-app basis, perhaps we could add in support for the fake dialogs.

The default script could have a method called isAFakeDialog which would return False.  Then the soffice script would override that method and return True if the potentially fake dialog is the Navigator frame.  Perhaps we could use isDesiredFocusedItem as a way to check??

Created attachment 111010 [details] [review]
Revision #3.

The new revision makes the following change:

If the current application has one or more alert or dialog
windows and the currently focused window is not an alert or a dialog, 
speak or braille '(<unfocused> of <total>)', where <unfocused is a count       a count of the number of alert and dialog windows and <total> is the
total window count. If the currently focused window is an alert or dialog,
then nothing extra is spoken (or added to the braille context).

I'm not sure I followed all your latest comments above Joanie, so 
let's use this as a starting point to describe further changes and
tweaks that are needed.

Thanks.

Rich, I like this.
 
> If the current application has one or more alert or dialog
> windows and the currently focused window is not an alert or
> a dialog,
 
I think that cuts down on the verbosity and increases the relevancy of the information we're providing. Nice change.

> If the currently focused window is an alert or dialog,
> then nothing extra is spoken (or added to the braille context).

Makes sense to me.

> speak or braille '(<unfocused> of <total>)'

I can certainly live with this.  Although I might be tempted to move the role before the count.

Currently:  "Buddy List 1 of 3 frame"
Perhaps:    "Buddy List frame 1 of 3"

I'm wondering if we want the full count, however.  What if instead it were: "Buddy List frame, 1 unfocused dialog"?

Something else that occurred to me, perhaps we either want to make this an optional setting or have it be based on the verbosity level.  If I'm a clever user and get into a dialog and then Alt Tab away without closing it, I know that stupid thing is still lurking about and needs Alt+F6'ing into.  If so, regardless of setting/level, I'd still keep the announcement in the whereAmI info. (i.e. the change would just apply to a window getting focus)

> I'm not sure I followed all your latest comments above Joanie, 
 
Well.... One of them turns out to be bogus upon further investigation. ;-) (Namely what I was tossing out about the gnome-terminal issue).  I have some more thoughts on that front, but they need more consideration before I type them. :-)  Also that is an edge case.  If you have three gnome terminal windows going, open a dialog from one of them, and then give some other app focus, you deserve to have to hunt around for the wayward dialog upon your return. ;-) So never mind on that for the moment.

As for the OOo comment, let me play with it some.  The basic stuff (what do we say; when do we say it?) probably should get tackled first.  Perhaps I can hack together a proof of concept patch to illustrate what I'm thinking.

> I'm wondering if we want the full count, however.  What if instead it were:
> "Buddy List frame, 1 unfocused dialog"?

That's a lot of space in the braille context. Do we want the spoken
form to be different from the braille form? If so, perhaps the long
version is spoken and the short one is brailled.

Mike, it looks like this is another one where you'll need to spec. 
out what should be done.

Thanks.

Created attachment 111020 [details] [review]
proof of concept patch re comment 23

So the attached illustrates (as a proof of concept) what I was talking about in comment 23.  If I use it, and modify your getUnfocusedAlertAndDialogCount() ever so-slightly, your new functionality kicks in when the OOo Navigator window is present but not focused.

The ever-so-slight changes are:

        if window.getRole() != pyatspi.ROLE_ALERT and \
           window.getRole() != pyatspi.ROLE_DIALOG and \
           not self.isFunctionalDialog(window):            <----
            for child in app:
                if child.getRole() == pyatspi.ROLE_ALERT or \
                   child.getRole() == pyatspi.ROLE_DIALOG:
                    alertAndDialogCount += 1
                    totalWinCount += 1

                if child.getRole() == pyatspi.ROLE_FRAME:
                    if self.isFunctionalDialog(child):     <----
                        alertAndDialogCount += 1           <----
                    totalWinCount += 1

In other words, perhaps we should build in the ability for a script to define what it's "dialogs" (that aren't really dialogs) are.

Just a thought.... Hope this makes some sense. :-)

How about for speech we speak: "m unfocused alert dialogs"

For braille: "m alerts" 

I think this will give both types of users enough information.   

Created attachment 111241 [details] [review]
Revision #4.

New patch makes the changes suggested by Mike.

Remaining questions to be answered:

1/ Are the additions for speech and braille occuring in the
   correct place?

2/ Do we want to do as Joanie suggests in comment #23 and 
   comment #27

I think the idea in 23 is a good one.  I think I already answered 26 in my previous comment.  

Created attachment 111242 [details] [review]
Revision #5.

Incorporates changes suggested by Joanie in comment #23 and
comment #27.

Remaining question to be answered:

1/ Are the additions for speech and braille occuring in the
   correct place?

When I attempt to apply this latest patch to trunk I'm running into a conflict with a previously applied patch.  

Rich, when getting the unfocused count, I think you also need to check to see if the child is a functional dialog.

I also had a question about the new phrasing.  More often than not the thing in question is not an alert; it's a preferences dialog, or a find dialog, or the Navigator frame, or something else along those lines. I think automatically stating x unfocused alert dialog(s) might be confusing/misleading.  Plus it's one more word that (IMHO) doesn't need speaking.  Given that an alert is for all intents and purposes a type of dialog, mightn't we just want to refer to these unfocused creatures as "dialogs"?

> I also had a question about the new phrasing.  More often than not the thing in
> question is not an alert; it's a preferences dialog, or a find dialog, or the
> Navigator frame, or something else along those lines. I think automatically
> stating x unfocused alert dialog(s) might be confusing/misleading.  Plus it's
> one more word that (IMHO) doesn't need speaking.  Given that an alert is for
> all intents and purposes a type of dialog, mightn't we just want to refer to
> these unfocused creatures as "dialogs"?
>
 This sounds like a good idea to me.   

> When I attempt to apply this latest patch to trunk I'm running into a 
> conflict with a previously applied patch.

The problem here is that we no longer need
.../src/orca/scripts/apps/gedit/speech_generator.py

When I create the patch with "svn diff > patch-463646-n"
what it generates is something that doesn't want to work
with "patch -p0 <patch-463646-n".

So I suggest you try applying the patch. When it tells you
it thinks it's reversed, just say "no". When it asks to
"apply anyway", just say "yes". It'll fail with that chunk, 
but the rest should patch correctly. After that you can removed
.../src/orca/scripts/apps/gedit/speech_generator.py by hand, 
or just ignore it.

> Rich, when getting the unfocused count, I think you also need to 
> check to see if the child is a functional dialog.

Am I not doing that in patch revision #5? I just took your
suggested code and added it in.

>> I also had a question about the new phrasing.  More often than not the thing in
>> question is not an alert; it's a preferences dialog, or a find dialog, or the
>> Navigator frame, or something else along those lines. I think automatically
>> stating x unfocused alert dialog(s) might be confusing/misleading.  Plus it's
>> one more word that (IMHO) doesn't need speaking.  Given that an alert is for
>> all intents and purposes a type of dialog, mightn't we just want to refer to
>> these unfocused creatures as "dialogs"?
>
> This sounds like a good idea to me. 

I'll generate yet another patch to change this.

Created attachment 111249 [details] [review]
Revision #6.

Changes "<m> unfocused alert dialogs" as per the previous comment
(assuming I've interpreted the previous comment correctly. ;-)

Created attachment 111251 [details] [review]
Revision #7

Fixes up getUnfocusedAlertAndDialogCount(). Thanks Joanie.

I'm noticing a problem here with gedit.  
1.  open gedit and type some text and press enter.
2.  be sure that several apps are also opened.  In my case, thunderbird and pidgin.  
3.  From the gedit text window press ctrl+f to bring up the find.  
4.  alt+tab around a little bit and then land back on gedit.  
Notice that the find nolonger has focus but we don't hear the message telling us about the unfocused dialog.  

Currently, brailling "<m> dialogs" occurs as part of
_getBrailleRegionsForFrame() in braillegenerator.py and
speaking "<m> unfocused dialogs" is part of 
getSpeechForFrame() in speechgenerator.py, 

so it'll braille/speak it wherever the we get the braille/speech
for a Frame. 

For a "window:activate" event, we get:

OBJECT EVENT: window:activate                          detail=(0,0)
             app.name='gedit' name='Unsaved Document 1 - gedit' role='frame' state='active enabled resizable sensitive showing visible' relations=''

BRAILLE LINE:  'gedit Application Unsaved Document 1 - gedit (1 dialog) Frame'
     VISIBLE:  'Unsaved Document 1 - gedit (1 di', cursor=1

SPEECH OUTPUT: 'Unsaved Document 1 - gedit 1 unfocused dialog frame'
^^^^^ PROCESS OBJECT EVENT window:activate ^^^^^

But for an "object:state-changed:focused" event, the event you get 
when you Alt-Tab to return to the gedit window, we get:

OBJECT EVENT: object:state-changed:focused             detail=(1,0)
    app.name='gedit' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations=''

BRAILLE LINE:  'gedit Application Unsaved Document 1 - gedit (1 dialog) Frame TabList Unsaved Document 1 Page ScrollPane  $l'

SPEECH OUTPUT: 'Unsaved Document 1 page'
SPEECH OUTPUT: 'text '

So this all comes back to where do we want this "<m> unfocused dialogs"
to occur?

Created attachment 111258 [details] [review]
Revision 8.

This patch moves the frame role before brailling/speaking the
"<m> unfocused dialogs". Patch committed. Moving to "[pending]".

Just ran the Gtk+ regression tests. These changes have not affected
any of them.

Oowriter and oocalc tests still to do.