<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="FreeSerif">I was working on a change to the prefs dialog
      today. I had previously merged 2 PRs without incident, and then
      made changes to a few files, including ui/prefs.* and several
      src/gnome2/*.c. Built, ran...and the prefs dialog won't open.<br>
      <br>
      mod.mgr and adv.search open fine.<br>
      <br>
      I backed out changes, rebuilt, no difference. I backed out my git
      tree several ways, including "git reset --hard HEAD~~" to get to
      the point before the merges. Rebuilt, no difference. Did a bunch
      of other things, trying to understand how and where I lost the
      ability to open prefs. This makes no sense to me because I built
      yesterday and have been toying with biblesync, via prefs of
      course. I did git reset to a point before the double arrows were
      fixed a week ago, rebuilt, no difference. Prefs will not open.
      Completely reboot the whole machine, rebuilt from a totally clean
      tree, no difference.<br>
      <br>
      The worst/best part is that Xiphos *thinks* it opened prefs. After
      quitting Xiphos, settings.xml shows
      &lt;prefsopen&gt;1&lt;/prefsopen&gt;. When I ask for prefs to
      open, and noting that I use MATE desktop, the taskbar stops
      showing the Xiphos window itself as having focus...but nothing
      else does, either. No new window has come into existence, but the
      Xiphos window has lost focus.<br>
      <br>
      Approaching desperation, I breakpointed
      create_preferences_dialog() in gdb, and what I get is at the
      bottom.<br>
      <br>
      Big question: What in the world are
      org.gtk.vfs.UDisks2VolumeMonitor and g_unix_volume_monitor_init(),
      and why are they involved in creation of a prefs dialog, and why
      are they failing when (if they were involved yesterday) they
      didn't fail until today?<br>
      <br>
      You can't tell from the simple copy/paste below, but after hitting
      the last 'n', Xiphos simply...went away. For perhaps a minute. And
      then the "Error calling ..." message, at which point I hit ^C and
      backtraced.<br>
      <br>
      Seriously, what has happened here? I have literally zero
      understanding of what sort of "volume monitoring" has tried to
      take place or why it has begun just now, or why (if it has been
      going on before) it failed to be started today. Googling the
      "Error calling Start..." has been uninformative, search results
      being anywhere from 2 to 5 years in the past, and related to
      things like gvfs, yet my environment has had no changes lately so
      that the state of things like gvfs would change.<br>
      <br>
      Life theme of mine: I love puzzles, I hate mysteries. This is
      total mystery.<br>
      <br>
      I am in serious need of a huge clue. Anyone?<br>
      <br>
      --karl<br>
      <br>
      (gdb) n<br>
      2915        gxml = gtk_builder_new();<br>
      (gdb) <br>
      2916        gtk_builder_add_from_file(gxml, glade_file, NULL);<br>
      (gdb) l<br>
      2911        g_return_if_fail(glade_file != NULL);<br>
      2912    <br>
      2913    /* build the widget */<br>
      2914    #ifdef USE_GTKBUILDER<br>
      2915        gxml = gtk_builder_new();<br>
      2916        gtk_builder_add_from_file(gxml, glade_file, NULL);<br>
      2917    #else<br>
      2918        gxml = glade_xml_new(glade_file, NULL, NULL);<br>
      2919    #endif<br>
      2920        g_free(glade_file);<br>
      (gdb) n<br>
      Error creating proxy: Error calling StartServiceByName for
      org.gtk.vfs.UDisks2VolumeMonitor: Timeout was reached
      (g-io-error-quark, 24)<br>
      ^C<br>
      Thread 1 "xiphos" received signal SIGINT, Interrupt.<br>
      0x00007fffecfedb99 in syscall () from /lib64/libc.so.6<br>
      (gdb) bt<br>
      #0  0x00007fffecfedb99 in syscall () at /lib64/libc.so.6<br>
      #1  0x00007ffff748350f in g_cond_wait () at
      /lib64/libglib-2.0.so.0<br>
      #2  0x00007ffff1962d03 in g_context_specific_group_request_state
      () at /lib64/libgio-2.0.so.0<br>
      #3  0x00007ffff1962db4 in g_context_specific_group_get () at
      /lib64/libgio-2.0.so.0<br>
      #4  0x00007ffff1a1e579 in g_unix_volume_monitor_init () at
      /lib64/libgio-2.0.so.0<br>
      #5  0x00007ffff773af2d in g_type_create_instance () at
      /lib64/libgobject-2.0.so.0<br>
      #6  0x00007ffff771bdb8 in g_object_new_internal () at
      /lib64/libgobject-2.0.so.0<br>
      #7  0x00007ffff771d555 in g_object_new_with_properties () at
      /lib64/libgobject-2.0.so.0<br>
      #8  0x00007ffff771dfd1 in g_object_new () at
      /lib64/libgobject-2.0.so.0<br>
      #9  0x00007ffff19bce5c in g_volume_monitor_get () at
      /lib64/libgio-2.0.so.0<br>
      #10 0x00007ffff32f5585 in gtk_places_sidebar_init () at
      /lib64/libgtk-3.so.0<br>
      #11 0x00007ffff773af2d in g_type_create_instance () at
      /lib64/libgobject-2.0.so.0<br>
      #12 0x00007ffff771bdb8 in g_object_new_internal () at
      /lib64/libgobject-2.0.so.0<br>
      #13 0x00007ffff771d82d in g_object_newv () at
      /lib64/libgobject-2.0.so.0<br>
      #14 0x00007ffff319de0c in _gtk_builder_construct () at
      /lib64/libgtk-3.so.0<br>
      #15 0x00007ffff31a08ba in start_element () at /lib64/libgtk-3.so.0<br>
      #16 0x00007ffff7441194 in emit_start_element () at
      /lib64/libglib-2.0.so.0<br>
      [ and onward through 80 frames ]<br>
    </font>
  </body>
</html>