Re: solution to the problem of orca and gecko not working in non-gnome environment
On Mon, Mar 10, 2014 at 10:34:00AM EST, am_dxer@fastmail.fm wrote:
>
>
> On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote:
> > Jason White <jason@jasonjgw.net> (2014-03-10):
> > > I think I've found it with a quick search of the Mozilla repository.
> > > mozilla/accessible/src/atk/Platform.cpp, line 81:
> > >
> > > 81 #if defined(LINUX) && defined(__x86_64__)
> > > 82 libPath.Append(":/usr/lib64:/usr/lib");
> > >
> > > If you change line 82 to
> > > libPath.Append(":/usr/lib64:/usr/lib:/usr/lib/x86_64-linux-gnu");
> > > and rebuild Mozilla, it might work.
> >
> > I think that's a very good catch indeed. There are a few other places
> > where one can find /usr/lib in *.ccp files in iceweasel, but most of
> > them are debug directories, or paths below /usr/lib/mozilla/.
> >
> > I suspect it would be nice to have a placeholder/#define somewhere so
> > that the proper multiarch directory can be injected from debian/rules;
> > depending on how easily I can reproduce the issue, I'll try and get a
> > working patch and submit the bug report against iceweasel.
> >
> I appreciate all the helpful replies so far. The thing that seems so
> puzzling to me is why this problem does not occur when running in gnome
> shell.
Things work properly in GNOME shell because gnome-settings-daemon in conjunction with libatk-adaptor does something to inject the recommended GTK modules into the environment of GTK apps that get launched. I am not sure how this is done, probably an X setting or property somewhere. Libatk-adaptor doesn't *do* anything as such, but it provides a .desktop file that lives in /usr/lib/gnome-settings-daemon-3.0/gtk-modules that gets read by gnome-settings-daemon and acted upon.
Luke
Reply to: