This would appear to be a duplicate of bug #343897.
Joanie, are using using a late enough version of pygtk
(pygtk 2.9 or later) to have this fix included?

Sorry about that!  I didn't check closed bugs....

I have 2.9.6 installed.

Strange. That should certainly be late enough to include
the new binding we needed. 

One way to test this is to uncomment the

orca.debug.debugLevel = orca.debug.LEVEL_ALL

line in your ~/.orca/user-settings.py file and rerun Orca
and startup the Preferences dialog (Insert-Space).

If it didn't get focus, check the debug log to see if
an AttributeError as generated in _showGUI() in 
orca_gui_prefs.py.

I'm not seeing the AttributeError....

Okay. That means you are definitely running with a version of pygtk that
has the required binding. Hmmm. Let's try to track this one down after
we've got Orca released for GNOME 2.16.

(PS: It's working for me, but that's small consolation :-) ).

Joanie, are you seeing this with Orca in Ubuntu Edgy?

I am.

Okay, thanks. I'll add this one near the top of my list
of bugs to look at. 

On Ubuntu Edgy, I see the following:

The first time I bring up the preferences dialog using Insert+Space, the preferences dialog appears on top.  If I dismiss it with Escape, it goes away just fine.  If I then press Insert+Space again, I see the following error message in the shell where I ran Orca:

/usr/lib/python2.4/site-packages/orca/orca_gui_prefs.py:725: GtkWarning: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed
  self.orcaSetupWindow.show()

I also see an "Orca Preferences" icon in the panel, but no window seems to appear *and* when try to Alt+Tab to it in metacity, Orca says it is inaccessible.  This may be a separate bug.

I just was able to bring up the prefs dialog several times with other apps running with out any problems.  Every time, the dialog got focus as I would expect.  

When I start Orca from the Applications menu, Insert+Space causes the dialog to appear but it does not get focus.  Subsequent presses result in the behavior you described (no window appears, "inaccessible" when you Alt+Tab to it), but that's relatively new (read: I don't know when that behavior showed up, but it wasn't the case when I reported it a few weeks ago). :-)

Okay, thanks everyone. I'm in the process of cutting
an Edgy Eft Knot-2 CD, and I'll install that and try to
recreate what you are seeing (Joanie and Will). Currently
on Solaris, I'm getting what Mike is getting.

Aha!  I see the same thing as Joanie iff I launch Orca from the applications menu.  If I launch it from a command line prompt, however, I see the experience I previously noted.

Okay, thanks for the update. Hopefully I should be able track 
this down now, and finally put it to bed.

I now have Ubuntu Edgy Eft (Knot-2) running on one of my PC's.
I do the following:

* Login to the desktop as myself and enable accessibility.
* Reboot (I tried just logging out), but when the desktop comes
  back and I try to start something, nothing appears on the desktop).
* I made sure that I did not have a ~/.orca directory.
* I started Orca from the gnome-panel Application->Accessories panel.

The Preferences dialog comes up. It has focus. Orca nicely speaks
where it is. In other words, I'm not seeing a focus problem.

Will, Joanie, so what am I doing differently from you?

If I'm following you Rich, the Preferences dialog appeared because you launched Orca for the first time and didn't have a ~/.orca directory.  Having set up Orca/caused the creation of the ~/.orca directory, what happens when you press Insert+Space to return to the Preferences dialog?

> If I'm following you Rich, the Preferences dialog appeared because 
> you launched Orca for the first time and didn't have a ~/.orca directory.

Correct.

> Having set up Orca/caused the creation of the ~/.orca directory, what 
> happens when you press Insert+Space to return to the Preferences dialog?

The first time it comes up and it gets focus automatically.
If I then dismiss it with Escape, and hit Insert-Space again,
it doesn't vome up again.

Is this the problem you are seeing?

Ahh, it apparently does bring up an Orca Preferences dialog.
It's really really small (about 1/8th inch by 3/8 inch) and 
appears near the top left corner of the desktop. It's impossible 
to resize or navigate.

That's the latest -- and most significant -- problem that I'm seeing in this regard.  

The originally-reported problem of launching Orca, then pressing Insert+Space, and  having the dialog appear normally (but without focus) is still present.

Created attachment 72639 [details] [review]
Patch to fix the mini-mini-preferences window.

When Calum Benson's HCI changes were incorporated in rev 1.21 of
the orca-setup.glade file, the handler for the "destroy" event for the main
Preferences window was lost. This patch reinstates.

Okay, that patch has been checked into CVS HEAD. Joanie, could
you build this latest version, and tell me what problems you still
see please.

There's definitely still something wrong because when I dismiss the
Preferences GUI, it's getting the following warnings:

** (-c:15355): CRITICAL **: file gailnotebook.c: line 555: assertion `obj' failed

** (-c:15355): CRITICAL **: file gailnotebook.c: line 555: assertion `obj' failed

** (-c:15355): CRITICAL **: file atkrelationset.c: line 176: assertion `ATK_IS_RELATION_SET (set)' failed

** (-c:15355): CRITICAL **: file atkrelationset.c: line 176: assertion `ATK_IS_RELATION_SET (set)' failed

** (-c:15355): CRITICAL **: file atkrelationset.c: line 176: assertion `ATK_IS_RELATION_SET (set)' failed

I'm looking at that next.

Sometimes it gets focus automatically; sometimes it does not.  But I can always get into the dialog now which is nice. :-)

I think I now understand when it does and when it doesn't.
Could you please confirm (or deny) whether you are seeing the
following. Assume you've already setup your Orca preference
and you've already launched Orca and it's running.

* The first time you bring up the Preference dialog, it gets focus.

* If you dismiss it via the Cancel button and then bring it up
  again with Insert-Space, it gets focus.

* If you dismiss it by hitting the Esc key, and then bring it up
  again with Insert-Space it does not get focus.

I just tried the following:

1. Launched Orca
2. Launched Evolution
3. Pressed Insert + Space

---
* The first time you bring up the Preference dialog, it gets focus.
---

It did not get focus.

---
* If you dismiss it via the Cancel button and then bring it up
  again with Insert-Space, it gets focus.
---

Confirmed

---
* If you dismiss it by hitting the Esc key, and then bring it up
  again with Insert-Space it does not get focus.
---

Confirmed.

Thanks Joanie. I now realize, I left open two possibilities
for the first one. When you initially:

1. Launched Orca

did you do it via the gnome-panel menu item or by typing
Orca in a terminal window. I did the latter, then typed
Insert-Space and the Preferences window got focus. I suspect
you did the former.

I can now also see that if I initially launch Orca from the
gnome-panel menu and type Insert-Space, the Preferences window
doesn't get focus. This is with Ubuntu Edgy Eft Knot-2.

I've added Elijah Newren to the cc: for this bug as I think we
are going to need his help in resolving the differences here.

So here is a summary of the current situation:

If Orca is initially started from a terminal window and the
user brings up the Preferences dialog by typing Insert-Space,
then the Preferences dialog window gets focus.

If the Preferences dialog window is showing and the user
dismisses it via the Cancel button and then redisplays it
by typing Insert-Space again, then the new Preferences dialog
window will get focus.

If Orca is initially started via the gnome-panel Application
menu and the user brings up the Preferences dialog by typing
Insert-Space, then the Preferences dialog window does not get
focus.

If the user dismisses the Orca Preference dialog by just hitting
the Esc key, and then redisplays it by typing Insert-Space again,
then the new Preferences dialog window will not get focus.

By adding print statements to the Orca code, I've verified that

 self.orcaSetupWindow.window.set_user_time(\
               orca_state.lastInputEventTimestamp)

is being called in all cases, and that orca_state.lastInputEventTimestamp
is the timestamp of the last keyboard accessibility event.

One other difference. When it works and gets focus, the Orca
Preferences dialog is correctly displayed directly in the middle
of the screen. When it doesn't work (no focus), the dialog is
shown on the screen is a "random" position.

Created attachment 72724 [details]
The Orca Preferences Glade GUI file.

See comment in next attachment.

Created attachment 72725 [details]
Standalone Python program to try to reproduce the problem.

I cobbled together a small standalone Python script to try to reproduce
the problem. Save this script and the previous orca-setup.glade file in
a new directory and follow the instructions at the beginning of bug_351797.py
to run.

In attempting to try to isolate this, I've made this small example work
just fine. I'm not sure what that proves exactly. One difference is that
in Orca, when the Preferences dialog comes up, the _init() methods does
lots of things which take 3-4 seconds on my Ferrari. I tried adding a
time.sleep(4.0) in _init() in this script, but things still worked fine.

Still looking...

Well I've found what's causing the problem, but I don't know why.
In _initGUIState() in orca_gui_prefs.py, there are three lines:

        self.voiceType.set_active(0)
        voiceType = self.voiceType.get_active_text()
        self._setVoiceSettingForVoiceType(voiceType)

If I comment them out, everything seems to work fine. In other words,
if you dismiss the Orca Preferences dialog with the Esc key, then
show it again, it'll now come up centralized and with focus. Same
for dismissal via the Cancel button and then showing again with 
Insert-Space.

Note that these three lines used to be:

        voiceType = self.voiceType.get_active_text()
        self.voiceType.set_active(0)
        self._setVoiceSettingForVoiceType(voiceType)

That was a bug. I had to swap the order the get a correct initial
default item for the voice type. I've checked that small change into
CVS HEAD.

Either order though, and the problem goes away if I comment out these
three lines.

I'll continue to investigate later this morning when I've had some sleep.

Joanie, I need a sanity check here (no jokes please).
Could you check out the latest Orca from CVS and
comment out the three lines:

        self.voiceType.set_active(0)
        voiceType = self.voiceType.get_active_text()
        self._setVoiceSettingForVoiceType(voiceType)

in .../src/orca/orca_gui_prefs.py (lines 207-209), rebuild
and reinstall it.

Then try the various scenerios listed in comment #27 above and
tell me what you get.

I want to see if this works on other peoples machines besides mine.
(Note that you will need to be running GNOME 2.16 - Ubuntu Edgy Eft
should be just fine).

Thanks.

It appears that a gtk+ application has to be focused in order for Insert+Space to work?  At least on my machine...  Anyway, I added a 
  print "About to show window with timestamp ", orca_state.lastInputEventTimestamp
line near the beginning of orca/src/orca/orca_gui_prefs.py:_showGUI(), and also ran with my metacity debug-focus-light patches.  When the orca window was not focused, I got the following output from orca:

  About to show window with timestamp  3038216953

(along with a zillion gail_container_ref_child critical warning assertions) and from Metacity I got:

  Window 0x2e004ae (X-Chat [2.) has _NET_WM_USER_TIME of 3038216516
  Window 0x22007b7 (Orca Prefe) has _NET_WM_USER_TIME of 3038201592
  COMPARISON:
    net_wm_user_time_set : 1
    net_wm_user_time     : 3038201592
    initial_timestamp_set: 0
    initial_timestamp    : 0
  COMPARISON (continued):
    focus_window             : 0x2e004ae (X-Chat [2.)
    fw->net_wm_user_time_set : 1
    fw->net_wm_user_time     : 3038216516

The thing to notice here is that 3038201592 < 3038216516 < 3038216953; meaning that the timestamp metacity has for orca is less than the timestamp for X-Chat (my focused window) which is less than the timestamp orca thought it was setting for its window (which metacity apparently did not end up with).

Haven't tracked down the reason for that yet, but thought this much info might help you save some debugging time if you're also working on it right now...

Thanks Elijah. The timestamp I'm setting in _showGUI() in orca_gui_prefs.py
should be the timestamp from the last accessibility keyboard event as the
user types Insert-Space. This is set in _processKeyboardEvent() in orca.py
(about line 650). I added debug statements to those routines and the timestamp
values match.

Like I mentioned above, I can just comment out three lines in _initGUIState()
and this all starts working fine for me. Also that standalone Python script
I added works fine too, and that has similar logic to the way that Orca is
doing this.

You're mapping the window *before* _showGUI gets called, which causes this bug.  Figure out where you are mapping/showing it and stop doing that (or updating the timestamp there instead of later), and it'll fix this bug.

In gory detail:

Adding a little debug spew to gdk/x11/gdkwindow-x11.c in addition to the debug spew I mentioned that I added to orca, the first time I press Insert+Space, I see (removing the critical warnings coming from GAIL):

  Updating timestamp to 0......and mapping window too!
  About to show window with timestamp  3040624331
  gdk_x11_window_set_user_time called with timestamp of 3040624331

The first line was debug spew added to gtk+/gdk/x11/gdkwindow-x11.c:show_window_internal(), showing that the window is getting mapped and that no timestamp was available (not surprising since I launched orca from the terminal).  There would have been an additional line before the first line due to my debug spew in gdk_x11_window_set_user_time() (since show_window_internal() calls gdk_x11_window_set_user_time() if the timestamp is not 0), but the timestamp was 0.  The second line comes from the debug spew I put at the beginning of orca/src/orca/orca_gui_prefs.py:_showGUI().  Note that the window is *already* mapped.  The third line comes from debug spew added to gdk_x11_window_set_user_time(), showing that orca's call to set_user_time really did make it to gtk+.

At this point, I press the Escape key on orca and see

  gdk_x11_window_set_user_time called with timestamp of 3040640484

due to the fact that the Escape key counts as user interaction and gtk+ is automatically updating the timestamp for you.  The I press Insert+Space again, and I see

  gdk_x11_window_set_user_time called with timestamp of 3040640484
  Updating timestamp to 3040640484......and mapping window too!
  About to show window with timestamp  3040654903
  gdk_x11_window_set_user_time called with timestamp of 3040654903

The first two lines again come from my debug spew in show_window_internal() and gdk_x11_window_set_user_time() (with the former calling the latter and producing both lines).  Since gtk+'s knowledge of the most recent user interaction with the application was the escape key, it is the timestamp used there when the window is mapped.  Metacity gets the map command and compares timestamps, obviously using "the wrong one."  *After* this is done, orca's _showGUI is finally called and updates the timestamp but too late.

You set the window to be visible in the .glade file, meaning that it would automatically be mapped as soon as gtk.glade.XML() was called (in GladeWrapper::__init__), rather than waiting for your call to self.orcaSetupWindow.show().  That's the cause of this bug.  I'll attach a patch in a second that fixes this.

Created attachment 72823 [details] [review]
Fix the bug; don't map the window until the timestamp is updated

Created attachment 72825 [details] [review]
Hopefully a final fix for this problem.

Thanks Elijah! New patch attached. I ended up having to set the
timestamp in two places. One is the path when the GUI is being
created out of the Glade file. The other is just before showing
it again after it had been hidden because the user has pressed the
Cancel button. It seems to work fine for me.

I'll now check it into CVS HEAD and sic Joanie on it.

Arrgh! I missed your patch (which is cleaner than mine).
Taking mine back, and putting yours in. Sorry about that!

Okay, I've backed out my changes and used Elijah's much nicer ones.
Joanie (or anybody else who'd like to try it), could you check out
Orca from CVS HEAD, and let us know if the bug if finally dead. Thanks.

"Sic" me on it, eh Rich?  After I report my results, I'm going to start working on  "sanity check" jokes. ;-) 

Things seem to be working properly now.  Thanks much!!

Hehe, no problem.  There was only one minute between patches according to the timestamps on this bug; it's no surprise that you missed it.  I'm actually surprised that you created it so fast after comment 35.

On a side note, though, it seems odd and error prone for pygtk to require the call to realize() when it allows GdkWindow functions to be called on GtkWindow objects (such as set_user_time).  I've filed bug 356033 about that.

Just tried it having launched Orca from a terminal (before I had done it via the Applications menu).  It still works as expected, though I am seeing the warnings you referred to earlier:

** (-c:12506): CRITICAL **: atk_relation_set_get_n_relations: assertion `ATK_IS_RELATION_SET (set)' failed

** (-c:12506): CRITICAL **: atk_relation_set_get_n_relations: assertion `ATK_IS_RELATION_SET (set)' failed

** (-c:12506): CRITICAL **: atk_relation_set_get_n_relations: assertion `ATK_IS_RELATION_SET (set)' failed

Yeah, I'm seeing those occasionally too. Plus:

** (-c:15425): CRITICAL **: file gailnotebook.c: line 555: assertion `obj' failed

** (-c:15425): CRITICAL **: file gailnotebook.c: line 555: assertion `obj' failed

When I was debugging Gtk+ C programs, I could bring the app up in
a debugger, then do:

dbx> run --g-fatal-warnings

U wonder if there is something similar in Python...

I'll see if I can get to the bottom of these messages, before I close the bug.

Thanks for the testing.

(In reply to comment #43)
> U wonder if there is something similar in Python...

My IRC conversation in #pygtk may be of use to you...

<yosh> elijah: well you can break on that line in gtk+ ...
<yosh> python comes with some gdb macros to get python backtraces out of gdb
<elijah> So, I'd run python under gtk+, then set a breakpoint, then load up my program and run it?
<jdahlin-home> elijah: there's a gdbinit file in the python distribution, copy the pystack command from there

I didn't actually try it out since most of this (very-laggy) conversation didn't occur until after I had already tracked the bug down with print statements.  So you'll have to ask them for more details.

Cool. I'll work on it tomorrow. Thanks (again) Elijah.

I worked out a nice way of getting the stack trace for one of those
CRITICAL messages:

** (-c:15425): CRITICAL **: file gailnotebook.c: line 555: assertion `obj'
failed

I started Orca on my Solaris box. I then rlogged into it from my Ubuntu
box and attached the debugger to the running Orca Python process:

% dbx /usr/bin/python <running python orca pid>

When it had loaded and stopped at a "dbx>" prompt I did:

dbx> stop in g_log_default_handler
dbx> cont

and then back on my Solaris machine, bought up the Orca Preferences
dialog and then dismissed it with the Esc key.

On the Ubuntu machine, the debugger was at my break point.

Here's the stack at that point:

(dbx) where
current thread: t@1
=>[1] g_log_default_handler(0x0, 0x8, 0x88aa540, 0x0), at 0xfec0182c 
  [2] g_logv(0x0, 0x8, 0xfbf3db3c, 0x80443a8), at 0xfec0118a 
  [3] g_log(0x0, 0x8, 0xfbf3db3c, 0xfbf3db2c, 0x22b, 0xfbf3da64), at 0xfec01265 
  [4] gail_notebook_real_remove_gtk(0x8777618, 0x885ed40, 0x85380b0), at 0xfbf26485 
  [5] gail_container_remove_gtk(0x8777618, 0x885ed40, 0x85380b0), at 0xfbf1d2c5 
  [6] g_cclosure_marshal_VOID__OBJECT(0x8780070, 0x0, 0x2, 0x804457c, 0x80444dc, 0x0), at 0xfec8f718 
  [7] g_closure_invoke(0x8780070, 0x0, 0x2, 0x804457c, 0x80444dc), at 0xfec7a6b6 
  [8] signal_emit_unlocked_R(0x840c550, 0x0, 0x8777618, 0x0, 0x804457c), at 0xfec8e658 
  [9] g_signal_emit_valist(0x8777618, 0x46, 0x0, 0x80447f4), at 0xfec8d95d 
  [10] g_signal_emit(0x8777618, 0x46, 0x0, 0x885ed40), at 0xfec8daf9 
  [11] gtk_container_remove(0x8777618, 0x885ed40), at 0xfe49454e 
  [12] gtk_widget_dispose(0x885ed40, 0x885ed40, 0xfe6b3010, 0x8044864, 0x8044868, 0x804486c), at 0xfe5fa085 
  [13] g_object_run_dispose(0x885ed40), at 0xfec7c7a5 
  [14] gtk_object_destroy(0x885ed40), at 0xfe52ed80 
  [15] gtk_widget_destroy(0x885ed40, 0x0), at 0xfe5f3dec 
  [16] gtk_notebook_forall(0x8777618, 0x0, 0xfe5f3dbc, 0x0), at 0xfe52927c 
  [17] gtk_container_foreach(0x8777618, 0xfe5f3dbc, 0x0), at 0xfe494ca2 
  [18] gtk_container_destroy(0x8777618), at 0xfe494104 
  [19] gtk_notebook_destroy(0x8777618, 0x8210d40), at 0xfe526b5a 
  [20] g_cclosure_marshal_VOID__VOID(0x8407270, 0x0, 0x1, 0x8044adc, 0x8044a3c, 0xfe526b28), at 0xfec8edd9 
  [21] g_type_class_meta_marshal(0x8407270, 0x0, 0x1, 0x8044adc, 0x8044a3c, 0x4c), at 0xfec7a9b1 
  [22] g_closure_invoke(0x8407270, 0x0, 0x1, 0x8044adc, 0x8044a3c), at 0xfec7a6e4 
  [23] signal_emit_unlocked_R(0x8248598, 0x0, 0x8777618, 0x0, 0x8044adc), at 0xfec8ebb5 
  [24] g_signal_emit_valist(0x8777618, 0x6, 0x0, 0x8044d48), at 0xfec8d95d 
  [25] g_signal_emit(0x8777618, 0x6, 0x0), at 0xfec8daf9 
  [26] gtk_object_dispose(0x8777618), at 0xfe52ee1a 
  [27] gtk_widget_dispose(0x8777618, 0x8777618, 0xfe6b3010, 0x852f268, 0x8044db8, 0x8044dbc), at 0xfe5fa0c5 
  [28] g_object_run_dispose(0x8777618), at 0xfec7c7a5 
  [29] gtk_object_destroy(0x8777618), at 0xfe52ed80 
  [30] gtk_widget_destroy(0x8777618, 0x0), at 0xfe5f3dec 
  [31] gtk_box_forall(0x86e8df0, 0x0, 0xfe5f3dbc, 0x0), at 0xfe460bbc 
  [32] gtk_container_foreach(0x86e8df0, 0xfe5f3dbc, 0x0), at 0xfe494ca2 
  [33] gtk_container_destroy(0x86e8df0, 0x8210d40), at 0xfe494104 
  [34] g_cclosure_marshal_VOID__VOID(0x8407270, 0x0, 0x1, 0x804500c, 0x8044f6c, 0xfe4940bc), at 0xfec8edd9 
  [35] g_type_class_meta_marshal(0x8407270, 0x0, 0x1, 0x804500c, 0x8044f6c, 0x4c), at 0xfec7a9b1 
  [36] g_closure_invoke(0x8407270, 0x0, 0x1, 0x804500c, 0x8044f6c), at 0xfec7a6e4 
  [37] signal_emit_unlocked_R(0x8248598, 0x0, 0x86e8df0, 0x0, 0x804500c), at 0xfec8ebb5 
  [38] g_signal_emit_valist(0x86e8df0, 0x6, 0x0, 0x8045278), at 0xfec8d95d 
  [39] g_signal_emit(0x86e8df0, 0x6, 0x0), at 0xfec8daf9 
  [40] gtk_object_dispose(0x86e8df0), at 0xfe52ee1a 
  [41] gtk_widget_dispose(0x86e8df0, 0x86e8df0, 0xfe6b3010, 0x852f268, 0x80452e8, 0x80452ec), at 0xfe5fa0c5 
  [42] g_object_run_dispose(0x86e8df0), at 0xfec7c7a5 
  [43] gtk_object_destroy(0x86e8df0), at 0xfe52ed80 
  [44] gtk_widget_destroy(0x86e8df0, 0x0), at 0xfe5f3dec 
  [45] gtk_box_forall(0x86e8f30, 0x0, 0xfe5f3dbc, 0x0), at 0xfe460bbc 
  [46] gtk_container_foreach(0x86e8f30, 0xfe5f3dbc, 0x0), at 0xfe494ca2 
  [47] gtk_container_destroy(0x86e8f30, 0x8210d40), at 0xfe494104 
  [48] g_cclosure_marshal_VOID__VOID(0x8407270, 0x0, 0x1, 0x804553c, 0x804549c, 0xfe4940bc), at 0xfec8edd9 
  [49] g_type_class_meta_marshal(0x8407270, 0x0, 0x1, 0x804553c, 0x804549c, 0x4c), at 0xfec7a9b1 
  [50] g_closure_invoke(0x8407270, 0x0, 0x1, 0x804553c, 0x804549c), at 0xfec7a6e4 
  [51] signal_emit_unlocked_R(0x8248598, 0x0, 0x86e8f30, 0x0, 0x804553c), at 0xfec8ebb5 
  [52] g_signal_emit_valist(0x86e8f30, 0x6, 0x0, 0x80457a8), at 0xfec8d95d 
  [53] g_signal_emit(0x86e8f30, 0x6, 0x0), at 0xfec8daf9 
  [54] gtk_object_dispose(0x86e8f30), at 0xfe52ee1a 
  [55] gtk_widget_dispose(0x86e8f30, 0x86e8f30, 0xfe6b3010, 0xfec95d49, 0x8045818, 0x804581c), at 0xfe5fa0c5 
  [56] g_object_run_dispose(0x86e8f30), at 0xfec7c7a5 
  [57] gtk_object_destroy(0x86e8f30), at 0xfe52ed80 
  [58] gtk_widget_destroy(0x86e8f30, 0x0), at 0xfe5f3dec 
  [59] gtk_bin_forall(0x8707800, 0x0, 0xfe5f3dbc, 0x0), at 0xfe45d5c3 
  [60] gtk_container_foreach(0x8707800, 0xfe5f3dbc, 0x0), at 0xfe494ca2 
  [61] gtk_container_destroy(0x8707800), at 0xfe494104 
  [62] gtk_window_destroy(0x8707800, 0x8210d40), at 0xfe600931 
  [63] g_cclosure_marshal_VOID__VOID(0x8407270, 0x0, 0x1, 0x8045a7c, 0x80459dc, 0xfe6008a8), at 0xfec8edd9 
  [64] g_type_class_meta_marshal(0x8407270, 0x0, 0x1, 0x8045a7c, 0x80459dc, 0x4c), at 0xfec7a9b1 
  [65] g_closure_invoke(0x8407270, 0x0, 0x1, 0x8045a7c, 0x80459dc), at 0xfec7a6b6 
  [66] signal_emit_unlocked_R(0x8248598, 0x0, 0x8707800, 0x0, 0x8045a7c), at 0xfec8ebb5 
  [67] g_signal_emit_valist(0x8707800, 0x6, 0x0, 0x8045ce8), at 0xfec8d95d 
  [68] g_signal_emit(0x8707800, 0x6, 0x0), at 0xfec8daf9 
  [69] gtk_object_dispose(0x8707800), at 0xfe52ee1a 
  [70] gtk_widget_dispose(0x8707800), at 0xfe5fa0c5 
  [71] gtk_window_dispose(0x8707800, 0x8707800, 0xfe6b3010, 0x8707800, 0x8045d78, 0x8045d7c), at 0xfe5fe2ad 
  [72] g_object_run_dispose(0x8707800), at 0xfec7c7a5 
  [73] gtk_object_destroy(0x8707800), at 0xfe52ed80 
  [74] gtk_widget_destroy(0x8707800), at 0xfe5f3dec 
  [75] gtk_main_do_event(0x89a0d48, 0x8707800, 0x8702bd0, 0xfecb2b98, 0x852f268, 0x8045e14), at 0xfe511bc8 
  [76] gtk_dialog_close(0x8707800, 0x82b0a90), at 0xfe4a3cbf 
  [77] g_cclosure_marshal_VOID__VOID(0x8702bd0, 0x8045ff0, 0x1, 0x8b15228, 0x8045f1c, 0xfe4a3c74), at 0xfec8edd9 
  [78] g_type_class_meta_marshal(0x8702bd0, 0x8045ff0, 0x1, 0x8b15228, 0x8045f1c, 0x1cc), at 0xfec7a9b1 
  [79] g_closure_invoke(0x8702bd0, 0x8045ff0, 0x1, 0x8b15228, 0x8045f1c), at 0xfec7a6b6 
  [80] signal_emit_unlocked_R(0x87613e8, 0x0, 0x8707800, 0x8045ff0, 0x8b15228), at 0xfec8e81d 
  [81] g_signal_emitv(0x8b15228, 0x86, 0x0, 0x8045ff0), at 0xfec8cf2b 
  [82] gtk_binding_entry_activate(0x876c680, 0x8707800), at 0xfe45e01a 
  [83] binding_match_activate(0x8b177d0, 0x8707800, 0x9, 0x82af3d8, 0x8b16690), at 0xfe45ed30 
  [84] gtk_bindings_activate_list(0x8707800, 0x8b177c8, 0x0), at 0xfe45ef7f 
  [85] gtk_bindings_activate_event(0x8707800, 0x89a0c58), at 0xfe45f15a 
  [86] gtk_widget_real_key_press_event(0x8707800, 0x89a0c58), at 0xfe5f5e53 
  [87] gtk_window_key_press_event(0x8707800, 0x89a0c58, 0x8211e28), at 0xfe6016a3 
  [88] _gtk_marshal_BOOLEAN__BOXED(0x8409f60, 0x8046270, 0x2, 0x804632c, 0x804628c, 0xfe60165c), at 0xfe513f21 
  [89] g_type_class_meta_marshal(0x8409f60, 0x8046270, 0x2, 0x804632c, 0x804628c, 0xcc), at 0xfec7a9b1 
  [90] g_closure_invoke(0x8409f60, 0x8046270, 0x2, 0x804632c, 0x804628c), at 0xfec7a6b6 
  [91] signal_emit_unlocked_R(0x8409990, 0x0, 0x8707800, 0x80464ac, 0x804632c), at 0xfec8e81d 
  [92] g_signal_emit_valist(0x8707800, 0x22, 0x0, 0x80465a0), at 0xfec8d6f3 
  [93] g_signal_emit(0x8707800, 0x22, 0x0, 0x89a0c58, 0x80465c4), at 0xfec8daf9 
  [94] gtk_widget_event_internal(0x8707800, 0x89a0c58), at 0xfe5f62be 
  [95] gtk_widget_event(0x8707800, 0x89a0c58), at 0xfe5f5f4d 
  [96] gtk_propagate_event(0x8707800, 0x89a0c58), at 0xfe512b35 
  [97] gtk_main_do_event(0x89a0c58, 0x0), at 0xfe511ad4 
  [98] gdk_event_dispatch(0x838e630, 0x0, 0x0), at 0xfeb3e27a 
  [99] g_main_dispatch(0x8385ca0), at 0xfebf9690 
  [100] g_main_context_dispatch(0x8385ca0), at 0xfebfa779 
(dbx) 


So if I'm reading this correctly, the problem is occuring as I'm
desroying the Orca Preferences dialog GUI hierarchy.

What I'd really like to do is, from withing my windowDestroyed()
handler in orca_gui_prefs.py, just hide() that dialog rather than
destoy it. That would save me having to rebuild it again.

I wonder if there is any way to do that...

Here's the stack trace for the

** (-c:12506): CRITICAL **: atk_relation_set_get_n_relations: assertion
`ATK_IS_RELATION_SET (set)' failed

messages:

(dbx) where
current thread: t@1
  [1] g_log_default_handler(0x0, 0x8, 0x8a9b0a0, 0x0), at 0xfec0182c 
  [2] g_logv(0x0, 0x8, 0xfc0c1be4, 0x804523c), at 0xfec0118a 
  [3] g_log(0x0, 0x8, 0xfc0c1be4, 0xfc0c1bd0, 0xb0, 0xfc0c1bb4), at 0xfec01265 
  [4] atk_relation_set_get_n_relations(0x0, 0x8c18000, 0x8530228, 0xfbd9478c, 0x1, 0x80452a0), at 0xfc0bbf3d 
  [5] impl_accessibility_accessible_get_relation_set(0x8bfb444, 0x8045424), at 0xfbe0971d 
  [6] _ORBIT_skel_small_Accessibility_Accessible_getRelationSet(0x8bfb444, 0x8bcf1f0, 0x0, 0x0, 0x8045424, 0xfbe096e0), at 0xfbe06c5e 
  [7] ORBit_POAObject_handle_request(0x8c18000, 0x843a069, 0x8bcf1f0, 0x0, 0x0, 0x0, 0x8045424), at 0xfbd6efeb 
  [8] ORBit_small_handle_request(0x8c18000, 0x843a069, 0x8bcf1f0, 0x0, 0x0, 0x0, 0x8045424), at 0xfbd73039 
  [9] ORBit_small_invoke_stub(0x8c18030, 0x8439df4, 0x8bcf1f0, 0x0, 0x0, 0x8045424), at 0xfbd60354 
=>[10] pycorba_method_call(self = 0x852dbc0, args = 0x87437ec, kwargs = (nil)), line 327 in "pycorba-method.c"
  [11] pycorba_bound_method_call(self = 0x85f10f0, args = 0x87437ec, kwargs = (nil)), line 503 in "pycorba-method.c"
  [12] PyObject_Call(0x85f10f0, 0x814d02c, 0x0), at 0x806371d 
  [13] do_call(0x85f10f0, 0x8045580, 0x0, 0x0), at 0x80ad3c5 
  [14] call_function(0x8045580, 0x0), at 0x80acc77 
  [15] PyEval_EvalFrameEx(0x86efb4c, 0x0), at 0x80a8f4e 
  [16] fast_function(0x85588ec, 0x8045690, 0x1, 0x1, 0x0), at 0x80ad0c1 
  [17] call_function(0x8045690, 0x0), at 0x80acc92 
  [18] PyEval_EvalFrameEx(0x8c430e4, 0x0), at 0x80a8f4e 
  [19] PyEval_EvalCodeEx(0x8504c38, 0x84ffbdc, 0x0, 0x82fdb78, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x80abdb6 
  [20] function_call(0x8558b54, 0x82fdb6c, 0x0), at 0x80e5a54 
  [21] PyObject_Call(0x8558b54, 0x82fdb6c, 0x0), at 0x806371d 
  [22] PyEval_CallObjectWithKeywords(0x8558b54, 0x82fdb6c, 0x0), at 0x80aca60 
  [23] instance_getattr(0x8916b8c, 0x85028b8), at 0x8065771 
  [24] PyObject_GetAttr(0x8916b8c, 0x85028b8), at 0x8080999 
  [25] PyEval_EvalFrameEx(0x86ef9ac, 0x0), at 0x80a8f80 
  [26] fast_function(0x85789cc, 0x8045960, 0x1, 0x1, 0x0), at 0x80ad0c1 
  [27] call_function(0x8045960, 0x1), at 0x80acc92 
  [28] PyEval_EvalFrameEx(0x86ef824, 0x0), at 0x80a8f4e 
  [29] fast_function(0x86abbc4, 0x8045a70, 0x2, 0x2, 0x0), at 0x80ad0c1 
  [30] call_function(0x8045a70, 0x1), at 0x80acc92 
  [31] PyEval_EvalFrameEx(0x86ef534, 0x0), at 0x80a8f4e 
  [32] PyEval_EvalCodeEx(0x86475c0, 0x863d46c, 0x0, 0x86ef1cc, 0x2, 0x86ef1d4, 0x0, 0x86a1558, 0x1, 0x0), at 0x80abdb6 
  [33] fast_function(0x86b43e4, 0x8045bf0, 0x2, 0x2, 0x0), at 0x80ad121 
  [34] call_function(0x8045bf0, 0x1), at 0x80acc92 
  [35] PyEval_EvalFrameEx(0x86ef02c, 0x0), at 0x80a8f4e 
  [36] fast_function(0x86b4374, 0x8045d00, 0x4, 0x4, 0x0), at 0x80ad0c1 
  [37] call_function(0x8045d00, 0x3), at 0x80acc92 
  [38] PyEval_EvalFrameEx(0x86eeebc, 0x0), at 0x80a8f4e 
  [39] fast_function(0x86b55dc, 0x8045e10, 0x4, 0x4, 0x0), at 0x80ad0c1 
  [40] call_function(0x8045e10, 0x3), at 0x80acc92 
  [41] PyEval_EvalFrameEx(0x86eed3c, 0x0), at 0x80a8f4e 
  [42] PyEval_EvalCodeEx(0x81c00b0, 0x81c5cec, 0x0, 0x86f4374, 0x2, 0x86f437c, 0x0, 0x85cbcf8, 0x1, 0x0), at 0x80abdb6 
  [43] fast_function(0x85cfae4, 0x8045f90, 0x2, 0x2, 0x0), at 0x80ad121 
  [44] call_function(0x8045f90, 0x2), at 0x80acc92 
  [45] PyEval_EvalFrameEx(0x86f421c, 0x0), at 0x80a8f4e 
  [46] fast_function(0x86b441c, 0x80460a0, 0x2, 0x2, 0x0), at 0x80ad0c1 
  [47] call_function(0x80460a0, 0x1), at 0x80acc92 
  [48] PyEval_EvalFrameEx(0x86ec5fc, 0x0), at 0x80a8f4e 
  [49] fast_function(0x86b1e64, 0x80461b0, 0x2, 0x2, 0x0), at 0x80ad0c1 
  [50] call_function(0x80461b0, 0x1), at 0x80acc92 
  [51] PyEval_EvalFrameEx(0x86e9f24, 0x0), at 0x80a8f4e 
  [52] fast_function(0x86b54c4, 0x80462c0, 0x2, 0x2, 0x0), at 0x80ad0c1 
  [53] call_function(0x80462c0, 0x1), at 0x80acc92 
  [54] PyEval_EvalFrameEx(0x86e980c, 0x0), at 0x80a8f4e 
  [55] PyEval_EvalCodeEx(0x8640380, 0x863d3e4, 0x0, 0x86b71b8, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x80abdb6 
  [56] function_call(0x86b5534, 0x86b71ac, 0x0), at 0x80e5a54 
  [57] PyObject_Call(0x86b5534, 0x86b71ac, 0x0), at 0x806371d 
  [58] instancemethod_call(0x86b5534, 0x86b71ac, 0x0), at 0x80687fd 
  [59] PyObject_Call(0x8724b1c, 0x814d02c, 0x0), at 0x806371d 
  [60] PyEval_CallObjectWithKeywords(0x8724b1c, 0x814d02c, 0x0, 0x8046624, 0x80c355c, 0x814ca20), at 0x80aca60 
  [61] PyObject_CallObject(0x8724b1c, 0x814d02c), at 0x80636fb 
  [62] pyg_handler_marshal(0x82f402c), at 0xfeccbf39 
  [63] g_idle_dispatch(0x8b9d808, 0xfeccbe88, 0x82f402c), at 0xfebfc6d7 
  [64] g_main_dispatch(0x8385ca0), at 0xfebf9690 
  [65] g_main_context_dispatch(0x8385ca0), at 0xfebfa779 
  [66] g_main_context_iterate(0x8385ca0, 0x1, 0x1, 0x83df268), at 0xfebfab99 
  [67] g_main_loop_run(0x86e7458), at 0xfebfb19e 
  [68] bonobo_main(0x84706ac, 0x8046890, 0x86e7b5c, 0x816e640, 0x8046814, 0x80acee4), at 0xfbcef3b2 
  [69] _wrap_bonobo_main(0x0, 0x0), at 0xfbaa88b1 
  [70] call_function(0x8046890, 0x0), at 0x80acee4 
  [71] PyEval_EvalFrameEx(0x86e7a1c, 0x0), at 0x80a8f4e 
  [72] fast_function(0x8550f44, 0x80469a0, 0x1, 0x1, 0x0), at 0x80ad0c1 
  [73] call_function(0x80469a0, 0x0), at 0x80acc92 
  [74] PyEval_EvalFrameEx(0x8654c04, 0x0), at 0x80a8f4e 
  [75] fast_function(0x85d309c, 0x8046ab0, 0x1, 0x1, 0x0), at 0x80ad0c1 
  [76] call_function(0x8046ab0, 0x1), at 0x80acc92 
  [77] PyEval_EvalFrameEx(0x820a994, 0x0), at 0x80a8f4e 
  [78] fast_function(0x85d3224, 0x8046bc0, 0x0, 0x0, 0x0), at 0x80ad0c1 
  [79] call_function(0x8046bc0, 0x0), at 0x80acc92 
  [80] PyEval_EvalFrameEx(0x819ac5c, 0x0), at 0x80a8f4e 
  [81] PyEval_EvalCodeEx(0x8188f98, 0x8166934, 0x8166934, 0x0, 0x0, 0x0), at 0x80abdb6 
  [82] PyEval_EvalCode(0x8188f98, 0x8166934, 0x8166934), at 0x80a7fa6 
  [83] run_mod(0x8208a60, 0x8103294, 0x8166934, 0x8166934, 0x8046d9c, 0x818f420), at 0x80c5226 
  [84] PyRun_StringFlags(0x814c988, 0x101, 0x8166934, 0x8166934, 0x8046d9c), at 0x80c515d 
  [85] PyRun_SimpleStringFlags(0x814c988, 0x8046d9c), at 0x80c4642 
  [86] Py_Main(0x4, 0x8046dec, 0xfeffa840, 0x8046da8, 0x8046f08, 0x8046de0), at 0x805e478 
  [87] main(0x4, 0x8046dec, 0x8046e00), at 0x805db7d 

Even those these messages are "CRITICAL", they are occuring at a time
when the Orca Preferences dialog is being destroyed so I don't think 
they are failures that are going to adversly affect how Orca runs.

Having said that, it would be nice to make them go away. I wonder if
I'm not doing the right thing in the windowDestroyed() handler. I'll
have to see if I can find some similar code to compare it against.

I see that the:

** (-c:15425): CRITICAL **: file gailnotebook.c: line 555: assertion `obj'
failed

message is happening for gtk-demo on my system, so I suspect that is a Gtk+
problem and not something specific to the way that the Orca Preference dialog
code is written.

As the other warning occurs as the user is destroying the Preferences GUI
dialog, and nothing adverse is happening when if it's reinstated, I'm
closing this bug out as FIXED.

If we find other new problems with the Preferences dialog, new bugs can be
filed.