solution to the problem of orca and gecko not working in non-gnome environment
In my XFCE environment, It appears that the problem is occurring from a Gtk module import path issue. I coppied the /usr/lib/x86_64-linux-gnu/gtk-2.0/modules directory to /usr/lib/gtk-2.0 and things work for me in the Mozilla apps. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394384383.31203.92360033.63a56...@webmail.messagingengine.com
Re: solution to the problem of orca and gecko not working in non-gnome environment
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. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140309231427.ga7...@jdc.jasonjgw.net
Re: solution to the problem of orca and gecko not working in non-gnome environment
Jason White ja...@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. Mraw, KiBi. signature.asc Description: Digital signature
Re: solution to the problem of orca and gecko not working in non-gnome environment
On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote: Jason White ja...@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. -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1394408040.12662.92454065.4a116...@webmail.messagingengine.com
Bug#741211: gnome-orca: missing dependency on gsettings-desktop-schemas?
Package: gnome-orca Version: 3.10.2-1 Severity: serious Justification: missing dep Hi, just installing gnome-orca and trying to launch orca leads to: | (process:21919): GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.a11y.applications' is not installed | | Trace/breakpoint trap Installing gsettings-desktop-schemas seems to fix this; looks like something that should be in Depends/Recommends? Mraw, KiBi. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-orca depends on: ii gir1.2-glib-2.01.38.0-2 ii gir1.2-gtk-3.0 3.10.7-1 ii gir1.2-pango-1.0 1.36.2-2 ii gir1.2-wnck-3.03.4.7-1 ii python33.3.4-1 ii python3-brlapi 4.5-3+b2 ii python3-cairo 1.10.0+dfsg-4 ii python3-gi 3.10.2-2+b1 ii python3-louis 2.5.3-2 ii python3-pyatspi2.10.0+dfsg-1 ii python3-speechd0.8-5 pn python3:anynone ii speech-dispatcher 0.8-5 Versions of packages gnome-orca recommends: ii libgail-common 2.24.22-1 ii xbrlapi 4.5-3+b2 gnome-orca suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014031112.21930.78078.reportbug@debian
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_d...@fastmail.fm wrote: On Sun, Mar 9, 2014, at 07:21 PM, Cyril Brulebois wrote: Jason White ja...@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 -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310002115.GA22610@acapella
