Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
On Sun, 2015-11-22 at 19:49 +0100, Samuel Thibault wrote: > Ritesh Raj Sarraf, on Sun 22 Nov 2015 21:57:12 +0530, wrote: > > I'm also curious to know if KDE5/Qt5 apps really support the at-spi > > bridge. > > Qt5 actually embeds its own at-spi bridge. That was my impression too, but it does not seem to be working, at least on Debian. Perhaps the Debian KDE Team (CCed) can confirm if it is supposed to work with KDE5/Qt5, or not. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
On Mon, 2015-11-23 at 17:34 +0100, Samuel Thibault wrote: > It is working, at least basically. the > ssh://git.debian.org/git/pkg-a11y/check-a11y tool shows that both qt4 > and qt5 applications are accessible at the same time. > Oh! Thanks for pointing that out Samuel. Those tests are working fine. But not when in general use. > > Perhaps the Debian KDE Team (CCed) can confirm if it > > is supposed to work with KDE5/Qt5, or not. > > It is supposed to work (and much better than Qt4) From the logs below, it looks like caribou is the cuplprit. :-( It says that the daemon was activated, but no soft keyboard shows up. Nov 23 22:27:25 learner dbus-daemon[9906]: Activating service name='org.gnome.Caribou.Daemon' Nov 23 22:27:25 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_group_model_create_group_name: assertion 'group != NULL' failed Nov 23 22:27:25 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_keyboard_model_populate_group: assertion 'group != NULL' failed Nov 23 22:27:25 learner org.gnome.Caribou.Daemon[9906]: (caribou:18991): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Nov 23 22:27:25 learner dbus-daemon[9906]: Successfully activated service 'org.gnome.Caribou.Daemon' Nov 23 22:27:52 learner dbus-daemon[9906]: Activating service name='org.gnome.Caribou.Daemon' Nov 23 22:27:52 learner systemd[1]: Starting Laptop Mode Tools - Battery Polling Service... Nov 23 22:27:52 learner systemd[1]: Reloading Laptop Mode Tools. Nov 23 22:27:52 learner systemd[1]: Started Laptop Mode Tools - Battery Polling Service. Nov 23 22:27:52 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_group_model_create_group_name: assertion 'group != NULL' failed Nov 23 22:27:52 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_keyboard_model_populate_group: assertion 'group != NULL' failed Nov 23 22:27:52 learner org.gnome.Caribou.Daemon[9906]: (caribou:19015): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Nov 23 22:27:52 learner dbus-daemon[9906]: Successfully activated service 'org.gnome.Caribou.Daemon' Nov 23 22:27:52 learner laptop-mode[19073]: Laptop mode Nov 23 22:27:52 learner laptop_mode[19017]: Laptop mode Nov 23 22:27:52 learner laptop-mode[19074]: enabled, active [unchanged] Nov 23 22:27:52 learner laptop_mode[19017]: enabled, active [unchanged] Nov 23 22:27:52 learner systemd[1]: Reloaded Laptop Mode Tools. Nov 23 22:27:55 learner dbus-daemon[9906]: Activating service name='org.gnome.Caribou.Daemon' Nov 23 22:27:55 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_group_model_create_group_name: assertion 'group != NULL' failed Nov 23 22:27:55 learner gnome-session[9877]: (gnome-shell:10151): caribou-CRITICAL **: caribou_keyboard_model_populate_group: assertion 'group != NULL' failed Nov 23 22:27:55 learner org.gnome.Caribou.Daemon[9906]: (caribou:19090): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Nov 23 22:27:55 learner dbus-daemon[9906]: Successfully activated service 'org.gnome.Caribou.Daemon' -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Ritesh Raj Sarraf, on Mon 23 Nov 2015 17:11:46 +0530, wrote: > On Sun, 2015-11-22 at 19:49 +0100, Samuel Thibault wrote: > > Ritesh Raj Sarraf, on Sun 22 Nov 2015 21:57:12 +0530, wrote: > > > I'm also curious to know if KDE5/Qt5 apps really support the at-spi > > > bridge. > > > > Qt5 actually embeds its own at-spi bridge. > > That was my impression too, but it does not seem to be working, at > least on Debian. It is working, at least basically. the ssh://git.debian.org/git/pkg-a11y/check-a11y tool shows that both qt4 and qt5 applications are accessible at the same time. > Perhaps the Debian KDE Team (CCed) can confirm if it > is supposed to work with KDE5/Qt5, or not. It is supposed to work (and much better than Qt4) Samuel
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
I think there is a problem when both the frameworks are in use together. Nov 23 21:26:13 learner gnome-session[9951]: (gnome-shell:10216): caribou-CRITICAL **: caribou_group_model_create_group_name: assertion 'group != NULL' failed Nov 23 21:26:13 learner gnome-session[9951]: (gnome-shell:10216): caribou-CRITICAL **: caribou_keyboard_model_populate_group: assertion 'group != NULL' failed Nov 23 21:26:13 learner org.gnome.Caribou.Daemon[9980]: (caribou:16512): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Nov 23 21:26:13 learner dbus-daemon[9980]: Successfully activated service 'org.gnome.Caribou.Daemon' Nov 23 21:26:17 learner org.gnome.Caribou.Daemon[9980]: ** (caribou:16512): WARNING **: AT-SPI: Error in GetItems, sender=(null), error=Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. To me this looks like caribou daemon, which is supposed to pop-up the soft keyboard, is mesbehaving. This message was seen when running kwrite (kde5) which obviously will trigger the textinput field to pop- up caribou keyboard. On Mon, 2015-11-23 at 17:11 +0530, Ritesh Raj Sarraf wrote: > On Sun, 2015-11-22 at 19:49 +0100, Samuel Thibault wrote: > > Ritesh Raj Sarraf, on Sun 22 Nov 2015 21:57:12 +0530, wrote: > > > I'm also curious to know if KDE5/Qt5 apps really support the at- > > > spi > > > bridge. > > > > Qt5 actually embeds its own at-spi bridge. > > That was my impression too, but it does not seem to be working, at > least on Debian. Perhaps the Debian KDE Team (CCed) can confirm if it > is supposed to work with KDE5/Qt5, or not. > > -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: This is a digitally signed message part
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Michael Biebl, on Tue 13 Oct 2015 14:38:10 +0200, wrote: > Am 13.10.2015 um 14:30 schrieb Samuel Thibault: > > Well, let's have a look at solution, but to me this is really religious > > haircutting, and will most probably hurt people who need it. > > As said, I think moving the qt-at-spi dependency to say libqtgui4 or > libqtcore4 (i.e. something from Qt4) looks like a better approach. This is now done in the qt4-x11 package, so I will drop the qt-at-spi dependency from python-pyatspi. > You mentioned kedit as an example where you want to have qt-at-spi > installed. But does qt-at-spi actually work with KDE5/Qt5 ? qt-at-spi is for Qt4. While typing kedit, I actually thought kate. Samuel
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Michael Biebl, le Tue 13 Oct 2015 14:24:22 +0200, a écrit : > this needs to be fixed. Otherwise I'll have to consider dropping > gnome-orca from the default GNOME installation. > > Pulling in unused KDE and Qt libraries is not desirable on a default > GNOME installation. Is pulling a handful of MiB really a problem?! Well, let's have a look at solution, but to me this is really religious haircutting, and will most probably hurt people who need it. Samuel
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Am 13.10.2015 um 14:30 schrieb Samuel Thibault: > Well, let's have a look at solution, but to me this is really religious > haircutting, and will most probably hurt people who need it. As said, I think moving the qt-at-spi dependency to say libqtgui4 or libqtcore4 (i.e. something from Qt4) looks like a better approach. You mentioned kedit as an example where you want to have qt-at-spi installed. But does qt-at-spi actually work with KDE5/Qt5 ? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Aha, looks like I've found the culprit responsible for Cinnamon indirectly depending on Qt libs :-/ $ aptitude why libqtgui4 i cinnamon Depends caribou i A caribouDepends python-pyatspi i A python-pyatspi Depends qt-at-spi i A qt-at-spi Depends libqtgui4 (= 4:4.8~)
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Ильяс Гасанов, le Sat 16 Aug 2014 00:52:58 +0400, a écrit : Aren't there other options considerable - like, making qt-at-spi package itself not depend on qt4 libs? [...] I guess the same could be stated about at-spi2-core dependences on glib/gtk packages. I had discussed about such kind of things with the maintainer of at-spi1 in the past, and the answer was a clear come on, it's really small dependencies by nowadays' standards, and not using them would mean reimplementing convenience functions such as utf-8 handling, list handling, etc.. So this is mostly a no-go. Personally I can't imagine any way in which it could actually be used without having any qt applications to launch. Sure, but python-pyatspi can't know whether there are some qt applications or not. However, when an average user installs said software, these libs would automatically be fetched and installed aside. Kind of a dirty hack, but it seems fine at least from my perspective. Again, what is the *actual* gain of introducing such hack? Saving 25MiB worth of disk space, really? Samuel -- 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/20140818234912.gu8...@type.youpi.perso.aquilenet.fr
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Aren't there other options considerable - like, making qt-at-spi package itself not depend on qt4 libs? Personally I can't imagine any way in which it could actually be used without having any qt applications to launch. However, when an average user installs said software, these libs would automatically be fetched and installed aside. Kind of a dirty hack, but it seems fine at least from my perspective. I guess the same could be stated about at-spi2-core dependences on glib/gtk packages. Best regards, -- Ilyas Gasanov -- 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/1408135978.5442.8.camel@lamed
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Gonzalo Bermúdez, le Mon 11 Aug 2014 00:30:03 -0300, a écrit : There's already a package named kdeaccessibility, This package has very little to do with at-spi2 actually. kdeaccessibility simply depends on the kde-ish accessibility tools (magnifier, text to speech, etc.), while python-pyatspi is about having screen reading support through at-spi2, which is completely independent from the actual desktop being used. and then there's gnome-core for gnome. I don't see the relation with the issue being discussed. Gnome has a gnome-accessibility package, which simply depends on the gnome-ish accessibility tools (magnifier, on-screen keyboard, etc.). Same remark as above. Wouldn't it make sense for those packages to actually decide which of the two is actually used within a given system? Again, people don't even really realize whether they are using a gnome or KDE application is being used. So they *need* that both be accessible, thus the dependency on whatever it takes to make both accessible. And if openoffice needed a java bridge to get accessible (like it does on windows), we would also have made depended on by python-pyatspi. What *actual* issue do you want to solve here? (except disk space -I've shown that it's neglectible by nowadays' standards- or KDE vs Gnome troll) Samuel -- 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/20140811094326.go3...@type.youpi.perso.aquilenet.fr
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Package: python-pyatspi Version: 2.10.0+dfsg-1 Followup-For: Bug #757152 There's already a package named kdeaccessibility, and then there's gnome-core for gnome. Wouldn't it make sense for those packages to actually decide which of the two is actually used within a given system? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pyatspi depends on: ii gir1.2-atspi-2.0 2.12.0-2 ii libatk-adaptor2.12.1-1+b1 ii libgail-common2.24.24-1 ii python2.7.8-1 ii python-gi 3.12.1-1+b1 python-pyatspi recommends no packages. python-pyatspi 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/20140811033003.844.94481.report...@gonzalo.v.home
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Package: python-pyatspi Version: 2.10.0+dfsg-2 Severity: normal This latest version of the python-pyatspi package depends on both at-spi2-core and qt-at-spi, which each depend on part of gnome and kde, respectively. In the common case, only one of these desktops is installed and it makes no sense to pull in part of the other. The original bug report #749523 mentions depending on at-spi2-core|qt-at-spi, which would allow the user to pick the most appropriate choice. I think this would be a better solution than depending on both packages. I suppose another option would be to create separate python-pyatspi-gnome and python-pyatspi-kde packages. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pyatspi depends on: ii gir1.2-atspi-2.0 2.12.0-2 ii libatk-adaptor2.12.1-1+b1 ii libgail-common2.24.24-1 ii python2.7.8-1 ii python-gi 3.12.1-1+b1 python-pyatspi recommends no packages. python-pyatspi 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/20140805191131.22717.16396.report...@walnut.matijs.net
Bug#757152: python-pyatspi: Should depond on at-spi2-core OR qt-at-spi
Hello, Matijs van Zuijlen, le Tue 05 Aug 2014 21:11:31 +0200, a écrit : This latest version of the python-pyatspi package depends on both at-spi2-core and qt-at-spi, Yes, this is on purpose. In the common case, only one of these desktops is installed and it makes no sense to pull in part of the other. It makes a lot of sense for a user to be told that e.g. kedit is nice, and try to install and run it from his gnome desktop, or vice-versa with gedit. Or taking other more convincing examples, it makes a lot of sense for a user to install and use vlc (just like he used to use it on Windows...) on a Gnome desktop, or gimp (just like he used to use it on Windows...) on a KDE dekstop. I suppose another option would be to create separate python-pyatspi-gnome and python-pyatspi-kde packages. Average users have no idea what qt/kde vs gtk means (in particular blind people who can not even see the difference...), and thus they won't know which one they would have to install a particular package in order to get access to some software. Actually, qt-at-spi even happens to depend on at-spi2-core in the end, so the question is about the additional packages brought by qt-at-spi. The raw figure is, starting from a bare system without even the standard task, plus at-spi2-core, 38MiB brought by installing qt-at-spi. But that includes fontconfig, libice6 and other such stuff that will typically be brought by a gnome destkop. Measuring only the extra qt libs gives only 25MiB. Is that saving really worth the pain of a user wondering why this or that application is not accessible at all? Samuel -- 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/20140806001840.ge3...@type.youpi.perso.aquilenet.fr
