Re: UEFI conflicts with Orca during installation
Kenneth Schack Banner, le jeu. 10 oct. 2024 11:32:11 +0200, a ecrit: > A last, but minor issue is that in the Debian 12.7 installer, if it comes to > 90%, then Orca will read it as "9 0" and not "90". (you mean speakup) That's most probably just because the 9 is printed at the end of a line, and the 0 at the beginning of the next line. That needs to be fixed within speakup itself, apparently. Samuel
Re: UEFI conflicts with Orca during installation
Kenneth Schack Banner, le jeu. 10 oct. 2024 11:32:11 +0200, a ecrit: > Current workaround is a USB audio card which works, but on three diffrent > machines UEFI seems to block the internal audio? If the three different machines have similar audio cards, that wouldn't be really surprising. We'd need e.g. kernel logs to see if it's a missing driver, a missing firmware, etc. Samuel
Re: UEFI conflicts with Orca during installation
Hello, Kenneth Schack Banner, le jeu. 10 oct. 2024 11:32:11 +0200, a ecrit: > I have just noticed that if my computer uses UEFI boot on USB, then after 30 > seconds in the debian boot menu it wont auto run with speech - I need to > press s to run it Indeed, the timeout is not implemented for the UEFI case. We first need grub to add some support for timeout entry to be different from the default entry. Samuel
Re: UEFI conflicts with Orca during installation
On 10/10/24 11:32, Kenneth Schack Banner wrote: I have just noticed that if my computer uses UEFI boot on USB, then > Does that mean that you have no problem if you set "legacy BIOs" in the set up menu (BIOs)? > after 30 seconds in the debian boot menu it wont auto run with speech - I need to press s to run it and i experience that my audio cards is not able to use? We can only help you if we have access to the logs of the Debian Installer [1]. Looks like their are two issues here at play: - Not entering "Install Debian With Speech" after 30secs of inactivety. - Missing driver for the sound card. Current workaround is a USB audio card which works, but on three diffrent machines UEFI seems to block the internal audio? To me, what you are reporting is that the driver for the sound card is not present in D-I, which makes, the installer not able to speak. A last, but minor issue is that in the Debian 12.7 installer, if it comes to 90%, then Orca will read it as "9 0" and not "90". You are likely talking about Espeakup and not Orca! ;^) I'm not sure if I understand the link you are making with the type of BIOs being use. [1] https://www.debian.org/releases/stable/i386/ch05s04 -- John Doe
UEFI conflicts with Orca during installation
Hi, I have just noticed that if my computer uses UEFI boot on USB, then after 30 seconds in the debian boot menu it wont auto run with speech - I need to press s to run it and i experience that my audio cards is not able to use? Current workaround is a USB audio card which works, but on three diffrent machines UEFI seems to block the internal audio? A last, but minor issue is that in the Debian 12.7 installer, if it comes to 90%, then Orca will read it as "9 0" and not "90". Best kind regards Kenneth
Re: Orca modificer not working
Hello, Kenneth Schack Banner, le lun. 07 oct. 2024 15:37:02 +0200, a ecrit: > The Orca modifier key should either be shift, alt, caps or insert, but none > of these works. insert does work for me with debian 12.7 on both LXDE and MATE desktops. Switching to capslock as modified also made capslock work as modified. Perhaps it's your laptop keyboard which doesn't support pressing these together? :/ You can try to run sudo showkey, press insert-space, and check that the output is: keycode 110 press keycode 57 press keycode 57 release keycode 110 release (110 is insert, and 57 is space) Samuel
Re: Orca modificer not working
Generally ORCA works best with Mate desktop. I have used it on a Dell laptop with no problem. Maybe you could install the Mate desktop along side the other desktop and login with that and see if it works better. From: Kenneth Schack Banner Sent: Monday, October 7, 2024 9:37 AM To: debian-accessibility@lists.debian.org Subject: Orca modificer not working Hi, I just installed Debian 12.7 bookworm on an Lenovo Thinkpad X240 laptop with the LXDE desktop enovirement and have some troubles using Orca. The Orca modifier key should either be shift, alt, caps or insert, but none of these works. I have tried all + space bar which should launch Orca settings (As far as i know) - But nothing happens.. I have also tried to launch Orca settings by opening a terminal and run: orca -s This will launch fine, i can adjust the speed of the speech, so i went to the bindings and choose insert for the bindings key (thinking thats the Orca modifier key), but it just dont wanna work. I have also upgraded Orca from 43 to 47.3, which gave some benefits, but still the Orca modifier dosent seem to work? Best kind regards Kenneth
Orca modificer not working
Hi, I just installed Debian 12.7 bookworm on an Lenovo Thinkpad X240 laptop with the LXDE desktop enovirement and have some troubles using Orca. The Orca modifier key should either be shift, alt, caps or insert, but none of these works. I have tried all + space bar which should launch Orca settings (As far as i know) - But nothing happens.. I have also tried to launch Orca settings by opening a terminal and run: orca -s This will launch fine, i can adjust the speed of the speech, so i went to the bindings and choose insert for the bindings key (thinking thats the Orca modifier key), but it just dont wanna work. I have also upgraded Orca from 43 to 47.3, which gave some benefits, but still the Orca modifier dosent seem to work? Best kind regards Kenneth
Re: Orca/espeakup loud audio on login screen and..
Hi Jason, I must say i did not know the keyboard had media keys, but they only work after i have logged into and am on the desktop.. So i havent been able to adjust sound level on login screen and also tried to enable/disable screen reader on login screen which also did not work. I have change the keys for the enable/disable screen reader to ctrl + alt + s since the super key dosent get registred properly.. Best kind regards Kenneth Den 24.09.2024 kl. 18.48 skrev Jason J.G. White: On 24/9/24 09:18, Kenneth Schack Banner wrote: When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? The most likely reason is that the audio configurations are separate. The login manager obviously doesn't run under the account of any of the users on the machine; it runs under a system account. Have you tried using the media keys, if any, to adjust the volume at the login prompt?
Re: Orca/espeakup loud audio on login screen and..
On 24/9/24 09:18, Kenneth Schack Banner wrote: When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? The most likely reason is that the audio configurations are separate. The login manager obviously doesn't run under the account of any of the users on the machine; it runs under a system account. Have you tried using the media keys, if any, to adjust the volume at the login prompt?
Orca/espeakup loud audio on login screen and..
Hi, Im trying to make my sons computer run Linux Debian, but feel like im hitting an issue with Orca/espeakup. I have installed Debian 12.7 with Cinnamon as desktop, why lightdm is the window manager. When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? I have also now, tried to disable the screen reader service, but it still auto starts, i ran this command: sudo systemtl disable espeakup.service (Im using espeakup in Orca) After the login, the screen reader is also speaking, but there is no service on it? Best kind regards Kenneth
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
OK, thank you Samuel, I got that newer package, so maybe I have other issues here. With Speakup on, I switch to console 24-and-run startx. It begins with "play warn alsa" and goes on for maybe 2 minutes. If I switch Speakup off before launching startx, I get no graphical speech from Voxin Allison. I wish I had a good way of letting you hear an audio output, or maybe these errors are in a file? Would be thrilled to post. When examining running processes, which I killed, were i3, xinit, xorg, startxI also re-installed orca OK, just ran startx and tried an alt+f2 orca got traceback messages, so tried alt+escape and typed brave. References to orca 11. Now hearing something about at-spy bus daemon cannot open display. Thanks so much for listening. Chime
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Samuel Thibault, le ven. 23 août 2024 00:25:32 +0200, a ecrit: > Chime Hart, le jeu. 22 août 2024 15:15:36 -0700, a ecrit: > > OK, thank you Samuel, so just running an > > apt upgrade at-spi > > didn't do the trick, so please inform what will I type to enjoy your > > changes? > > It's the gir1.2-atspi-2.0 package that matters. Also, note that there is a build delay between my upload and getting the update on mirrors etc. Samuel
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Chime Hart, le jeu. 22 août 2024 15:15:36 -0700, a ecrit: > OK, thank you Samuel, so just running an > apt upgrade at-spi > didn't do the trick, so please inform what will I type to enjoy your > changes? It's the gir1.2-atspi-2.0 package that matters. Samuel
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
OK, thank you Samuel, so just running an apt upgrade at-spi didn't do the trick, so please inform what will I type to enjoy your changes? Thanks in advance Chime
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Samuel Thibault, le ven. 09 août 2024 10:02:34 +0200, a ecrit: > Jeremy Bícha, le jeu. 08 août 2024 17:26:35 -0400, a ecrit: > > Could someone affected by this issue please file a RC bug against > > at-spi2-core to help others be informed about the bug and avoid > > upgrading the package if possible? > > I have already forwarded the report as RC bug report. I have uploaded the upstream fix. Samuel
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Hello, Jeremy Bícha, le jeu. 08 août 2024 17:26:35 -0400, a ecrit: > Could someone affected by this issue please file a RC bug against > at-spi2-core to help others be informed about the bug and avoid > upgrading the package if possible? I have already forwarded the report as RC bug report. Samuel
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Could someone affected by this issue please file a RC bug against at-spi2-core to help others be informed about the bug and avoid upgrading the package if possible? Sorry I had too many other commitments today to be able to investigate and figure out a packaging workaround if needed. Thank you, Jeremy Bícha
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Well, I manually grabbed a newer ORCA, but still whether its 46.2 or 47.1, seemingly same results here, as I am getting evolution warnings along with something about gst scanner. I did ask on an ORCA list, but some of their responses were I should dich the console for 2weeks-and-just use ORCA. I only use graphical when I cannot accomplish an item in console Chime
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
On Thu, Aug 8, 2024 at 1:05 PM Jason J.G. White wrote: > On 8/8/24 09:32, Jérémy Prego wrote: > > I don't know if this is the right way to report my bug, but I > > discovered that updating the atspi2 stack to version 2.53.1-1 prevents > > orca from starting with a python error : > Try upgrading Orca as well, as the problem may have been fixed upstream. There isn't yet an Orca update available in Debian. Sorry, I was the one who uploaded the at-spi2-core update to Unstable; new versions usually are fine. I won't be able to take a look for a few more hours. One particular thing that changed is that now it's just going to read "button" instead of "push button" which I think is a very nice improvement but maybe this broke some assumptions. Thank you, Jeremy Bícha
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
On 8/8/24 09:32, Jérémy Prego wrote: I don't know if this is the right way to report my bug, but I discovered that updating the atspi2 stack to version 2.53.1-1 prevents orca from starting with a python error : Try upgrading Orca as well, as the problem may have been fixed upstream.
Re: testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
On 8/8/24 15:32, Jérémy Prego wrote:
Hello,
I don't know if this is the right way to report my bug, but I discovered
that updating the atspi2 stack to version 2.53.1-1 prevents orca from
starting with a python error :
$ orca
Traceback (most recent call last):
File "/usr/bin/orca", line 50, in
from orca import script_manager
File "/usr/lib/python3/dist-packages/orca/script_manager.py", line
42, in
from .scripts import apps, default, sleepmode, toolkits
File "/usr/lib/python3/dist-packages/orca/scripts/default.py", line
47, in
from orca import script
File "/usr/lib/python3/dist-packages/orca/script.py", line 49, in
from . import braille_generator
File "/usr/lib/python3/dist-packages/orca/braille_generator.py",
line 44, in
from .braille_rolenames import shortRoleNames
File "/usr/lib/python3/dist-packages/orca/braille_rolenames.py",
line 187, in
Atspi.Role.PUSH_BUTTON: _("btn"),
^^
AttributeError: type object 'Role' has no attribute 'PUSH_BUTTON'. Did
you mean: 'SPIN_BUTTON'?
You may want to crosspost to the Orca mailing list.
--
John Doe
testing/sid: upgrade atspi to version 2.53.1-1 break orca on my system
Hello,
I don't know if this is the right way to report my bug, but I discovered
that updating the atspi2 stack to version 2.53.1-1 prevents orca from
starting with a python error :
$ orca
Traceback (most recent call last):
File "/usr/bin/orca", line 50, in
from orca import script_manager
File "/usr/lib/python3/dist-packages/orca/script_manager.py", line
42, in
from .scripts import apps, default, sleepmode, toolkits
File "/usr/lib/python3/dist-packages/orca/scripts/default.py", line
47, in
from orca import script
File "/usr/lib/python3/dist-packages/orca/script.py", line 49, in
from . import braille_generator
File "/usr/lib/python3/dist-packages/orca/braille_generator.py",
line 44, in
from .braille_rolenames import shortRoleNames
File "/usr/lib/python3/dist-packages/orca/braille_rolenames.py",
line 187, in
Atspi.Role.PUSH_BUTTON: _("btn"),
^^
AttributeError: type object 'Role' has no attribute 'PUSH_BUTTON'. Did
you mean: 'SPIN_BUTTON'?
jeremy@jerem-debian:~ $ orca --replace
Traceback (most recent call last):
File "/usr/bin/orca", line 50, in
from orca import script_manager
File "/usr/lib/python3/dist-packages/orca/script_manager.py", line
42, in
from .scripts import apps, default, sleepmode, toolkits
File "/usr/lib/python3/dist-packages/orca/scripts/default.py", line
47, in
from orca import script
File "/usr/lib/python3/dist-packages/orca/script.py", line 49, in
from . import braille_generator
File "/usr/lib/python3/dist-packages/orca/braille_generator.py",
line 44, in
from .braille_rolenames import shortRoleNames
File "/usr/lib/python3/dist-packages/orca/braille_rolenames.py",
line 187, in
Atspi.Role.PUSH_BUTTON: _("btn"),
^^
AttributeError: type object 'Role' has no attribute 'PUSH_BUTTON'. Did
you mean: 'SPIN_BUTTON'?
I'm pasting below the list of packages I have to install for
accessibility, I hope I haven't forgotten any.
ii at-spi2-common 2.53.1-1 all Assistive
Technology Service Provider Interface (common files)
ii at-spi2-core 2.53.1-1 amd64 Assistive
Technology Service Provider Interface (D-Bus core)
ii gir1.2-atk-1.0:amd64 2.53.1-1 amd64 ATK
accessibility toolkit (GObject introspection)
ii gir1.2-atspi-2.0:amd64 2.53.1-1 amd64 Assistive
Technology Service Provider (GObject introspection)
ii libatk-adaptor:amd64 2.53.1-1 amd64 AT-SPI 2
toolkit bridge
ii libatk-bridge2.0-0t64:amd64 2.53.1-1 amd64 AT-SPI 2
toolkit bridge - shared library
ii libatk1.0-0t64:amd64 2.53.1-1 amd64 ATK
accessibility toolkit
ii libatspi2.0-0t64:amd64 2.53.1-1 amd64 Assistive
Technology Service Provider Interface - shared library
downgrade from "gir1.2-atspi-2.0" to launch orca again
Re: Resetting Orca
That fixed it, thank you! - Original Message - From: "Christian Schoepplein" To: Sent: Tuesday, July 9, 2024 3:45 AM Subject: Re: Resetting Orca Hi, On Mon, Jul 08, 2024 at 02:40:01PM -0500, K0LNY ?? wrote: > Is there a way to load Orca with default settings, or a CLI option to > specify the synth, such as espeak? No, there isn't such a option IMHO. But maybe the following works: 1. Press Alt+F2 to run a command. 2. Insert the following: orca -r --speech-system speechdispatcherfactory Orca stores all preferences for a user in the ~/.local/share/orca directory. If you want to reset Orca to its defaults just remove this directory, press Alt+F2 and insert orca -r If this should be done automaticaly and without a running screen reader just write a little script and configure a keyboard shortcut to run this script if its necessary from every where in Mate. Ciao, Schoepp
Re: Resetting Orca
Hi, On Mon, Jul 08, 2024 at 02:40:01PM -0500, K0LNY ?? wrote: > Is there a way to load Orca with default settings, or a CLI option to > specify the synth, such as espeak? No, there isn't such a option IMHO. But maybe the following works: 1. Press Alt+F2 to run a command. 2. Insert the following: orca -r --speech-system speechdispatcherfactory Orca stores all preferences for a user in the ~/.local/share/orca directory. If you want to reset Orca to its defaults just remove this directory, press Alt+F2 and insert orca -r If this should be done automaticaly and without a running screen reader just write a little script and configure a keyboard shortcut to run this script if its necessary from every where in Mate. Ciao, Schoepp
Re: Resetting Orca
To add to this, I tried to find a contact from the Gnome - Orca site to ask about this, and could not find a contact. Does anyone here know how to reach out to someone from that team? I need to suggest a couple things, such as a way to launch Orca with a specific TTS engine, like we can do with SpeakUp. Also, a way to just reset Orca. And finally, a portable Orca, like the Portable NVDA would be helpful in situations like this. Glenn - Original Message - From: K0LNY ?? To: debian-accessibility@lists.debian.org Sent: Monday, July 8, 2024 2:40 PM Subject: Resetting Orca Hi, In Ubuntu, 24.04, the Orca there had dectalk open source version in the available synths. So I selected that, and now I have no TTS. Question, Is there a way to load Orca with default settings, or a CLI option to specify the synth, such as espeak? I have uninstalled and reinstalled Orca in a terminal, hoping it worked with no feedback, but that didn't help. Thanks. Glenn Change is inevitable, except from a vending machine. Glenn K0LNY & WSAT439
Resetting Orca
Hi, In Ubuntu, 24.04, the Orca there had dectalk open source version in the available synths. So I selected that, and now I have no TTS. Question, Is there a way to load Orca with default settings, or a CLI option to specify the synth, such as espeak? I have uninstalled and reinstalled Orca in a terminal, hoping it worked with no feedback, but that didn't help. Thanks. Glenn Change is inevitable, except from a vending machine. Glenn K0LNY & WSAT439
Re: Orca 47 alpha
On 7/7/24 19:19, Samuel Thibault wrote: Hello, Chime Hart, le jeu. 04 juil. 2024 17:16:31 -0700, a ecrit: Hi All: In looking over an ORCA config file, I couldn't help but notice, similar to the Fenrir manual, most options have 3words jammed together, no spaces. Now, in a windows enviremnent with mixed case enabled, this would not be an issue, but listening in a console with a DecTalk, much of it is a jumble. This would need to be reported to orca (to change the option names), or to espeak-ng (to add a mixed case support). Camel/mix case, with the stock version of Orca on Bookworm is perfectly doable. -- John Doe
Re: Orca 47 alpha
Chime Hart, le dim. 07 juil. 2024 10:28:12 -0700, a ecrit: > Hi Samuel: Are you suggesting I file a "reportbug" item with ORCA? No, that you report to the orca mailing list. Samuel
Re: Orca 47 alpha
Hi Samuel: Are you suggesting I file a "reportbug" item with ORCA? Honestly since I stay as far away as I can from espeak, I wouldn't know how it handles mixed case. As far as the Fenrir options-and-manual, I will discuss those with Storm. Thank you. Chime
Re: Orca 47 alpha
Hello, Chime Hart, le jeu. 04 juil. 2024 17:16:31 -0700, a ecrit: > Hi All: In looking over an ORCA config file, I couldn't help but notice, > similar to the Fenrir manual, most options have 3words jammed together, no > spaces. Now, in a windows enviremnent with mixed case enabled, this would > not be an issue, but listening in a console with a DecTalk, much of it is a > jumble. This would need to be reported to orca (to change the option names), or to espeak-ng (to add a mixed case support). Samuel
Re: Orca 47 alpha
Hi All: In looking over an ORCA config file, I couldn't help but notice, similar to the Fenrir manual, most options have 3words jammed together, no spaces. Now, in a windows enviremnent with mixed case enabled, this would not be an issue, but listening in a console with a DecTalk, much of it is a jumble. OK, as an experiment, I just switched over to Allison in Voxin. It does separate the words. Chime
Re: Orca 47 alpha
Well, Roberto-and-All, I tried apt or aptitude install orca it says its the latest version 46.2 minus 1. I am in Trixy Sid. Please inform what changes in that newer version? Thanks so much in advance Chime
Re: Orca 47 alpha
Thank you Samuel, I installed it now on a Raspberry pi 400 with bookworm. It seems to work fine Best regards Roberto Burceni Linux System Admin & PHP developer Esperto accessibilità siti web E-mail: robe...@robertoburceni.it Phone: +393358208080 P.iva: 04025840986 Il 04/07/24 15:03, Samuel Thibault ha scritto: Hello, I have uploaded orca 47~alpha-1 in experimental, it will be available within a few hours. (Since orca has very little dependencies, you can safely install that version on a stable/testing/sid) Samuel
Orca 47 alpha
Hello, I have uploaded orca 47~alpha-1 in experimental, it will be available within a few hours. (Since orca has very little dependencies, you can safely install that version on a stable/testing/sid) Samuel
orca 46 beta
Hello, I have uploaded orca 46 beta to experimental. So please test and report to the orca list ;) Samuel
Re: orca 46 alpha
Sebastian Humenda, le dim. 21 janv. 2024 16:47:09 +0100, a ecrit: > Samuel Thibault schrieb am 21.01.2024, 11:43 +0100: > >Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: > >> Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: > >> >I have uploaded orca 46 alpha to experimental. It is notably said to > >> >have improved performance a lot through using cache.o > >> Sounds great, thanks for giving the opportunity to test it out. > >> Are there any minimum required software versions of involved components? > > > >Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. > > It still doesn't start with the same debug output. I would probably need an > unstable system to test things properly. Or has anyone tried it successfully > on Bookworm? I gave a try, you need to upgrade gir1.2-atspi-2.0 to 2.50 as well. Samuel
Re: orca 46 alpha
On 1/21/24 16:47, Sebastian Humenda wrote: Hi Samuel Samuel Thibault schrieb am 21.01.2024, 11:43 +0100: Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: I have uploaded orca 46 alpha to experimental. It is notably said to have improved performance a lot through using cache.o Sounds great, thanks for giving the opportunity to test it out. Are there any minimum required software versions of involved components? Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. It still doesn't start with the same debug output. I would probably need an What output are you seeing and which one are you expecting? -- John Doe
Re: orca 46 alpha
Hi Samuel Samuel Thibault schrieb am 21.01.2024, 11:43 +0100: >Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: >> Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: >> >I have uploaded orca 46 alpha to experimental. It is notably said to >> >have improved performance a lot through using cache.o >> Sounds great, thanks for giving the opportunity to test it out. >> Are there any minimum required software versions of involved components? > >Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. It still doesn't start with the same debug output. I would probably need an unstable system to test things properly. Or has anyone tried it successfully on Bookworm? Cheers Sebastian signature.asc Description: PGP signature
Re: orca 46 alpha
Sebastian Humenda, le dim. 21 janv. 2024 11:33:42 +0100, a ecrit: > Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: > >I have uploaded orca 46 alpha to experimental. It is notably said to > >have improved performance a lot through using cache.o > Sounds great, thanks for giving the opportunity to test it out. > Are there any minimum required software versions of involved components? Ah, yes, you need at-spi2-core >= 2.50, it's available as backport. Samuel
Re: orca 46 alpha
Hi Samuel Thibault schrieb am 20.01.2024, 23:35 +0100: >I have uploaded orca 46 alpha to experimental. It is notably said to >have improved performance a lot through using cache.o Sounds great, thanks for giving the opportunity to test it out. Are there any minimum required software versions of involved components? I'm running Bookworm and the log on starting orca says 11:31:04.630479 - INFO: About to launch Orca. Thanks Sebastian signature.asc Description: PGP signature
Re: orca 46 alpha
Hi Samuel, Thanks for that upload. I’ll try to test. Raphaël Samuel Thibault writes: > Hello, > > I have uploaded orca 46 alpha to experimental. It is notably said to > have improved performance a lot through using cache. It also got > significant rewrites to clear the code, so there may be regressions > ahead. > > So please test and report to the orca list ;) > > Samuel > -- Raphaël POITEVIN www.leclavierquibave.fr
orca 46 alpha
Hello, I have uploaded orca 46 alpha to experimental. It is notably said to have improved performance a lot through using cache. It also got significant rewrites to clear the code, so there may be regressions ahead. So please test and report to the orca list ;) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Nov 14, 2023 at 09:57:25PM +0100, Samuel Thibault wrote: >Jason J.G. White, le mar. 14 nov. 2023 08:56:27 -0500, a ecrit: >> On 14/11/23 08:35, Christian Schoepplein wrote: >> >> After installing the two gir packages with the fix from your personal >> repo >> >> all things are good again: >> >> You'll need to mark the appropriate libvte packages as on hold until Samuel's >> patch is accepted upstream, and the upstream version enters Debian. >> Otherwise, >> Samuel's packages will be replaced every time a new upstream version enters >> the >> repository you're using. > >The debian package 0.74.1-1 does contain my fix as kindly patched by the >debian maintainer, Jeremy Bicha. Ah, OK, thats why it worked with the 0.74.1-1 package before. >Christian, can you confirm by running > >zgrep libvte-2.91-0 /var/log/dpkg.log. > >that the libvte-2.91-0 package (which really contains the binary built >with my patch) was upgraded before you noticed the issue? And thus it's >really *exactly* the upgrade of the gir packages that brought the issue? I' ve reinstalled and reconfigured all regarding packages and everything seems to be fine again. Currently the 0.74.1-1 package is installed. I have no idea what was going on yesterday where the problems with screen refreshing suddenly occured again... Sorry for the confusion... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, This is all very odd. Jason J.G. White, le mar. 14 nov. 2023 08:56:27 -0500, a ecrit: > > On 14/11/23 08:35, Christian Schoepplein wrote: > > After installing the two gir packages with the fix from your personal repo > > all things are good again: > > You'll need to mark the appropriate libvte packages as on hold until Samuel's > patch is accepted upstream, and the upstream version enters Debian. Otherwise, > Samuel's packages will be replaced every time a new upstream version enters > the > repository you're using. The debian package 0.74.1-1 does contain my fix as kindly patched by the debian maintainer, Jeremy Bicha. So the Debian package is supposed to provide the same fix as my package. Christian, can you confirm by running zgrep libvte-2.91-0 /var/log/dpkg.log. that the libvte-2.91-0 package (which really contains the binary built with my patch) was upgraded before you noticed the issue? And thus it's really *exactly* the upgrade of the gir packages that brought the issue? (which is really odd since gir packages don't ship implementations, they just provide interfaces) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Tue, Nov 14, 2023 at 08:56:27AM -0500, Jason J.G. White wrote: > On 14/11/23 08:35, Christian Schoepplein wrote: > > > After installing the two gir packages with the fix from your personal > > repo > > all things are good again: > > You'll need to mark the appropriate libvte packages as on hold until > Samuel's patch is accepted upstream, and the upstream version enters > Debian. Otherwise, Samuel's packages will be replaced every time a new > upstream version enters the repository you're using. OK, thanks. I've pinned Samuels packages but removed this some weeks ago. Since then everything was working fine till gir was updated... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On 14/11/23 08:35, Christian Schoepplein wrote: After installing the two gir packages with the fix from your personal repo all things are good again: You'll need to mark the appropriate libvte packages as on hold until Samuel's patch is accepted upstream, and the upstream version enters Debian. Otherwise, Samuel's packages will be replaced every time a new upstream version enters the repository you're using.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an >improved patch. Could people try it? I have also uploaded patched Debian >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ I was using this patched packages and lately the packages for Debian Testing and it was perfectly possible to work in mate-terminal. However, a few days ago some packages where updated to an newer version and since then again the screen content is not longer refreshed in some situations. This are the currently installed packages that again cause problems with the screen refreshing in mate-terminal: cs@d5421:~$ dpkg -l | grep vte ii gir1.2-vte-2.91:amd64 0.74.1-1 ii gir1.2-vte-3.91:amd64 0.74.1-1 ii libvte-2.91-0:amd64 0.74.1-1 ii libvte-2.91-common 0.74.1-1 ii libvte-2.91-dev:amd64 0.74.1-1 ii libvte-2.91-gtk4-0:amd640.74.1-1 ii libvte-2.91-gtk4-dev:amd64 0.74.1-1 ii libvte-common 1:0.28.2-6 ii libvted-3-0:amd64 3.10.0-2+b1 After installing the two gir packages with the fix from your personal repo all things are good again: cs@d5421:~$ dpkg -l | grep vte ii gir1.2-vte-2.91:amd64 0.73.99-1+fix ii gir1.2-vte-3.91:amd64 0.73.99-1+fix ii libvte-2.91-0:amd64 0.74.1-1 ii libvte-2.91-common 0.74.1-1 ii libvte-2.91-dev:amd64 0.74.1-1 ii libvte-2.91-gtk4-0:amd640.74.1-1 ii libvte-2.91-gtk4-dev:amd64 0.74.1-1 ii libvte-common 1:0.28.2-6 ii libvted-3-0:amd64 3.10.0-2+b1 These are the packages with vte that have been updated lately: cs@d5421:~$ grep vte /var/log/dpkg.log 2023-11-10 10:28:28 upgrade libvted-3-0:amd64 3.10.0-2 3.10.0-2+b1 2023-11-10 10:28:28 status half-configured libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status unpacked libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status half-installed libvted-3-0:amd64 3.10.0-2 2023-11-10 10:28:28 status unpacked libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 configure libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status unpacked libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status half-configured libvted-3-0:amd64 3.10.0-2+b1 2023-11-10 10:28:29 status installed libvted-3-0:amd64 3.10.0-2+b1 2023-11-14 14:06:31 upgrade gir1.2-vte-2.91:amd64 0.74.1-1 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status half-installed gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 upgrade gir1.2-vte-3.91:amd64 0.74.1-1 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status half-installed gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:06:31 status unpacked gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 configure gir1.2-vte-2.91:amd64 0.73.99-1+fix 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 status installed gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 configure gir1.2-vte-3.91:amd64 0.73.99-1+fix 0.73.99-1+fix 2023-11-14 14:06:31 status half-configured gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:06:31 status installed gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 upgrade gir1.2-vte-2.91:amd64 0.73.99-1+fix 0.74.1-1 2023-11-14 14:13:32 status half-configured gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status unpacked gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status half-installed gir1.2-vte-2.91:amd64 0.73.99-1+fix 2023-11-14 14:13:32 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 upgrade gir1.2-vte-3.91:amd64 0.73.99-1+fix 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status half-installed gir1.2-vte-3.91:amd64 0.73.99-1+fix 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 configure gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status unpacked gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 status installed gir1.2-vte-3.91:amd64 0.74.1-1 2023-11-14 14:13:33 configure gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status unpacked gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status half-configured gir1.2-vte-2.91:amd64 0.74.1-1 2023-11-14 14:13:33 status installed gir1.2-vte-2.91:amd64 0.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello,
Interesting... So it's tmux as source which poses problem,
for whatever reason. And you don't have a /etc/tmux.conf or a
~/.config/tmux/tmux.conf?
Christian Schoepplein, le mer. 25 oct. 2023 09:50:26 +0200, a ecrit:
> If I open a tmux session and copy multiline content from this session with
> the new flatfview feature from orca and not with brltty's COPY_RECT feature
Ok, how do you copy from orca exactly? The
FLAT_REVIEW_COPY = _("Copy the contents under flat review to the clipboard")
Orca command? Or braille routing keys?
Could you kill your xbrlapi, then try to run
xbrlapi -v -n 2> log
then perform the failing copy/paste, and send us the log?
Also, could you try if you can reproduce the issue with orca without
xbrlapi running?
Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello Samuel, On Tue, Oct 24, 2023 at 07:59:44PM +0200, Samuel Thibault wrote: >What do you get when you paste into another graphical application such >as pluma or gedit? And conversely when pasting into tmux? When I am in a tmux session and copy multiline text with brltty's COPY_RECT command * the text is inserted in reverse order and with broken lines in another terminal, no matter if there is a tmux session running or not * is inserted correctly in pluma. This does not happen if I copy the multiline text with brltty's COPY_RECT command when I am not in a tmux session. >> I've also tested it with the new show flatview contents feature of orca 45 >> during working in a tmux session. There the same issue is happening if I >> copy multiline text and insert it using different editors. > >I don't see the relation between flatview and copy? Are you using a copy >feature from orca? No. I just tested if the same thing occures if I do not use brltty's COPY_RECT feature to get multiline content into the clipboard. If I open a tmux session and copy multiline content from this session with the new flatfview feature from orca and not with brltty's COPY_RECT feature it is also broken when I insert this multiline text in an editor running in a terminal. Inserting the same content in pluma works fine. So it does not matter if copying content with brltty or with orca, but it seems to be related where the content of the clipboard is inserted. I hope the problem is more clear now. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Please answer all questions :) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Christian Schoepplein, le mar. 24 oct. 2023 17:07:59 +0200, a ecrit: > I've also tested it with the new show flatview contents feature of orca 45 > during working in a tmux session. There the same issue is happening if I > copy multiline text and insert it using different editors. I don't see the relation between flatview and copy? Are you using a copy feature from orca? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi again, On Tue, Oct 24, 2023 at 04:58:12PM +0200, Christian Schoepplein wrote: >Hi samuel, > >On Sun, Oct 22, 2023 at 10:38:41PM +0200, Samuel Thibault wrote: >>Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: >>> Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: >>> > The issue is with copying content via the cliphboard feature of brltty if >>> > I >>> > am inside a tmux session which I need to use very ofthen for my daily job. >>> > >>> > The original content I like to copy looks like this: >>> > >>> > borg_backup_client_exclude_host_specific: >>> > - /rpool >>> > - /tank >>> >>> Does it happen with whatever kind of content, or is it specific to this >>> kind of content? Is this showing up in an editor? (which editor?) or as >>> output of a command? > >Its happening with any content and in different editors, e.g. vim or nano. > >>Also, I forgot: are you using COPY_LINE or COPY_RECT? > >I tried both. > >If I copy a multiline text with COPY_LINE and paste it the whole content is >inserted on one line. I think this is the expected behaviour, at least I >understand brltty's help this way. No line breaks are copied or the content >is inserted as one long line. > >If I use COPY_RECT, which is the way I normaly would copy multiline content, >the issue is happening and the content is inserted in reverse order and with >broken line breaks. > >I'll test if the internal tmux copy and paste function is working without a >problem if I've found out how to use it, currently I am to stupid to >understand how it works :-). I've also tested it with the new show flatview contents feature of orca 45 during working in a tmux session. There the same issue is happening if I copy multiline text and insert it using different editors. BTW.: I am on Debian Testing and I am using the libvte packages from your package repository. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi samuel, On Sun, Oct 22, 2023 at 10:38:41PM +0200, Samuel Thibault wrote: >Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: >> Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: >> > The issue is with copying content via the cliphboard feature of brltty if >> > I >> > am inside a tmux session which I need to use very ofthen for my daily job. >> > >> > The original content I like to copy looks like this: >> > >> > borg_backup_client_exclude_host_specific: >> > - /rpool >> > - /tank >> >> Does it happen with whatever kind of content, or is it specific to this >> kind of content? Is this showing up in an editor? (which editor?) or as >> output of a command? Its happening with any content and in different editors, e.g. vim or nano. >Also, I forgot: are you using COPY_LINE or COPY_RECT? I tried both. If I copy a multiline text with COPY_LINE and paste it the whole content is inserted on one line. I think this is the expected behaviour, at least I understand brltty's help this way. No line breaks are copied or the content is inserted as one long line. If I use COPY_RECT, which is the way I normaly would copy multiline content, the issue is happening and the content is inserted in reverse order and with broken line breaks. I'll test if the internal tmux copy and paste function is working without a problem if I've found out how to use it, currently I am to stupid to understand how it works :-). Ciao and thanks, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le dim. 22 oct. 2023 22:36:34 +0200, a ecrit: > Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > > The issue is with copying content via the cliphboard feature of brltty if I > > am inside a tmux session which I need to use very ofthen for my daily job. > > > > The original content I like to copy looks like this: > > > > borg_backup_client_exclude_host_specific: > > - /rpool > > - /tank > > Does it happen with whatever kind of content, or is it specific to this > kind of content? Is this showing up in an editor? (which editor?) or as > output of a command? Also, I forgot: are you using COPY_LINE or COPY_RECT? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 10 oct. 2023 12:46:21 +0200, a ecrit: > The issue is with copying content via the cliphboard feature of brltty if I > am inside a tmux session which I need to use very ofthen for my daily job. > > The original content I like to copy looks like this: > > borg_backup_client_exclude_host_specific: > - /rpool > - /tank Does it happen with whatever kind of content, or is it specific to this kind of content? Is this showing up in an editor? (which editor?) or as output of a command? > Outside a tmux session copying this content works quite well. But inside a > tmux session I get this when inserting the textblock into another file: Into what are you pasting? An editor? (which editor?) What do you get when you paste into another graphical application such as pluma or gedit? And conversely when pasting into tmux? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel and all,
there is another strange issue with the terminal, but I do not know if it is
libvte, tmux or maybe brltty related.
I am using brltty in the terminal, the braille functionality of orca is
turned of in the orca profile settings for mate-terminal. In
/etc/X11/Xsession.d/90xbrlapi I have replaced the original entry to start
brltty like this:
"${brltty}" -b ba -s sd -x a2 --autospeak-threshold=good -Z on -N 2>/dev/null
The issue is with copying content via the cliphboard feature of brltty if I
am inside a tmux session which I need to use very ofthen for my daily job.
The original content I like to copy looks like this:
borg_backup_client_exclude_host_specific:
- /rpool
- /tank
Outside a tmux session copying this content works quite well. But inside a
tmux session I get this when inserting the textblock into another file:
M - /tank
M - /rpool
borg_backup_client_exclude_host_specific:
I do not have any special tmux settings configured.
Its clear to me that this is a very specific problem which might be related
to what so ever is involved, tmux, brltty, lbvte, but maybe someone
has an idea whats going on there and how to fix this. I am pretty sure that
this behaviour is new, I use the copy-paste feature of brltty quite ofthen
and I can't remember I had this issue in the past...
Ciao,
Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Fri, Oct 06, 2023 at 11:03:01PM +0200, Samuel Thibault wrote: >Which exact version are you testing? Please use > >dpkg -l libvte-2.91-0:amd64 > >otherwise I cannot say anything about your results. My package with >latest changes is versioned 0.73.99-1+fix, not 0.74. I got version 0.74.0-2 while updating my system today. Thats why your packages got overwritten. But I've managed to install the older packages with the fix from your repo now and everything is fine again. >> Whats the current state of the bug? > >We are waiting for feedback to make sure that things are fixed without >introducing regressions. OK, thanks for the update. Hope the fix will make it to the official libvte package soon. >> Can I somehow install the old 0.73 packages from your repo, > >Sure, see the readme file. > >> Samuel, or can you provide the 0.74 packages with the fix please or >> shall I try to build the new packages myself and include the patch? > >No need to build anything, just pick up my packages. As said, I've managed to install the older packages now and everything is fine again. But the newer packages from the updates still want to be installed when running apt upgrade I gues I've to pinn the libvte package to the version from your repo to exclude this packages from the updates till the fix has made it into a newer debian package? Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le ven. 06 oct. 2023 20:52:20 +0200, a ecrit: > On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: > > > >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an > >improved patch. Could people try it? I have also uploaded patched Debian > >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ > > I was on vacation for three weeks and updated my Debian testing system > today. Also the libvte packages have been updated to a newer version, 0.74, > and the packages with all fixes from your repo, Samuel, Which exact version are you testing? Please use dpkg -l libvte-2.91-0:amd64 otherwise I cannot say anything about your results. My package with latest changes is versioned 0.73.99-1+fix, not 0.74. > I took a look at the bug report and into the changelogs, but its not really > clear to me, if the fixes are included in the 0.74 version now or if they > are still not included. They are not. > Whats the current state of the bug? We are waiting for feedback to make sure that things are fixed without introducing regressions. > Can I somehow install the old 0.73 packages from your repo, Sure, see the readme file. > Samuel, or can you provide the 0.74 packages with the fix please or > shall I try to build the new packages myself and include the patch? No need to build anything, just pick up my packages. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel and all, On Mon, Sep 11, 2023 at 02:27:41AM +0200, Samuel Thibault wrote: > >I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an >improved patch. Could people try it? I have also uploaded patched Debian >packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ I was on vacation for three weeks and updated my Debian testing system today. Also the libvte packages have been updated to a newer version, 0.74, and the packages with all fixes from your repo, Samuel, that worked so fine with the terminal have been overwritten. With this newer versions of the packages at least some problems that have been fixed before do occure again. E.g. the screen is ruptured again when using apt and the progressbar is displayed at the bottom of the screen. Also I was able to use vim perfectly with the 0.73 packages, with the new 0.74 versions the focus again is moved to the command line of the editor. I took a look at the bug report and into the changelogs, but its not really clear to me, if the fixes are included in the 0.74 version now or if they are still not included. Whats the current state of the bug? Is the fix included in the 0.74 packages or are the problems, that I have now, new? Can I somehow install the old 0.73 packages from your repo, Samuel, or can you provide the 0.74 packages with the fix please or shall I try to build the new packages myself and include the patch? Ciao and thanks for your help, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 10:31:27PM +0200, Samuel Thibault wrote: >Samuel Thibault, le mar. 12 sept. 2023 14:07:35 +0200, a ecrit: >> Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: >> > But I noticed another thing. When I switch away from the terminal, e.g. >> > into >> > another terminal, and then switch back into the terminal with the >> > translate >> > command everything looks good and the output is in a seperate line. >> > Strange... >> >> Ok, I guess I see what you mean. > >No, I had misunderstood, I didn't realize that you were saying that the >command and its output were getting glued together on the same line. > >Apparently brltty gets a bit confused when removing the trailing '\n'. >Better be safe with screen readers and keep it always, I have updated >the patches and the built package. Thank you very much. The new packages from yesterday evening are a big progress and IMHO the biggest issues I had with the terminal seem to be fixed now. This is so much better now, really great! There is still an issue when deleting lines in nano, but unfortunately I can not reproduce this behaviour all the time and I only have it in mutt. I'll try to find out if this is related to some settings in mutt. Also in nano sometimes empty lines are not always shown correctly on the brailledevice when navigating through a file. This seems also to be an issue with brltty I think, because it only occures if I navigate the text with the keyboard and not with the brailledisplay. I'll also try to find out more about it and report back if I have a way how to reproduce it. Ciao and thank you so much again, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Samuel Thibault, le mar. 12 sept. 2023 14:07:35 +0200, a ecrit: > Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > > But I noticed another thing. When I switch away from the terminal, e.g. > > into > > another terminal, and then switch back into the terminal with the translate > > command everything looks good and the output is in a seperate line. > > Strange... > > Ok, I guess I see what you mean. No, I had misunderstood, I didn't realize that you were saying that the command and its output were getting glued together on the same line. Apparently brltty gets a bit confused when removing the trailing '\n'. Better be safe with screen readers and keep it always, I have updated the patches and the built package. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 10:38:02 +0200, a ecrit: > But I noticed another thing. When I switch away from the terminal, e.g. into > another terminal, and then switch back into the terminal with the translate > command everything looks good and the output is in a seperate line. > Strange... Ok, I guess I see what you mean. When a command produces more characters than the width of the terminal, they are put on a single ligne (from the point of view of brltty). When going out and coming back to the terminal, you do get separate lines split as per the width of the terminal. That's unrelated and will to be fixed another way. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi, Christian Schoepplein (2023/09/12 13:30 +0200): > I do have the problem not only with translate, this was just an example > command to show the issue. I have the same problems with apt and other > commands too, so the issue IMHO is not related to translate only. Yes that's what I was trying to say. I was suggesting that the issue may have to do with the difference in diwth between your terminal and Samuel's one. Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Seb and all, On Tue, Sep 12, 2023 at 10:52:39AM +0200, Sébastien Hinderer wrote: >May it be the case that translate adjusts its output to the size of the >terminal? I do have the problem not only with translate, this was just an example command to show the issue. I have the same problems with apt and other commands too, so the issue IMHO is not related to translate only. However, it seems to be related only to commands that return one line, but unfortunately not to all. E.g. git version works perfectly, the translate example or helm version show the output in the same line. Maybe there is something different how the programs crea te line breaks or whatever, I have no idea :-(. I'll post more problematic examples if I stumple over them. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, May it be the case that translate adjusts its output to the size of the terminal? That may enxplain the difference observed in behaviours between Samuel and Christian. Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Tue, Sep 12, 2023 at 09:10:56AM +0200, Samuel Thibault wrote:
>Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit:
>> The following command displays
>> the output in a long line instead dividing it into seperate lines:
>>
>> translate -i occure
>
>On my system it does output
>
>Vorkommen {n} (von etw.) [min.] | Erdölvorkommen {n} | Vorkommen [...]
On my system it looks like this:
cs@d5421:~$ translate -i occure Vorkommen {n} (von etw.) [min.] |
Erdölvorkommen {n} | Vorkommen in Linsenform; linsenförmiges Vorkommen |
schichtförmiges Vorkommen :: presence; occurrence (of sth.) | oil occurrence |
lens-shaped occurence; lenticularity | occurrence in strata
cs@d5421:~$
But I noticed another thing. When I switch away from the terminal, e.g. into
another terminal, and then switch back into the terminal with the translate
command everything looks good and the output is in a seperate line.
Strange...
>So it's the output of the command itself which is a one-liner, mate&orca
>can't do anything about it :)
I had the same behaviour also with commands that output more then one line,
e.g. with apt. Maybe there is something wrong with refreshing the screen,
because everything seems to be fine when moving to another window
and back again in the window where the problem occured.
>> ls -1 /dev > test.txt
>>
>> Open the test.txt file, scrol down some pages and then delete a line with
>> ctrl+k.
>>
>> On my machine I have to clear the screen with ctrl+l to see that the line
>> has been removed on the braille display.
>
>You mean that the braille display is still showing the very line you
>wanted to remove?
Yes.
>I am not able to reproduce this. Just to be precise:
>
>- nano test.txt
>- press page down
>(get to some line shown on the braille display)
>- press control-k
>(the line is supposed to be replaced by the next line on the braille
>display)
Yes, thats exactly what I am doing.
>Do you perhaps have some particular configuration in nano?
No, I don't. But maybe I have some mate-terminal settings that cause this
problems. I've resetted mate-terminal with the following command now to make
sure that no mate-terminal settings cause this strange problems:
dconf reset -f /org/mate/terminal/
Ciao,
Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 09:06:00AM +0200, Samuel Thibault wrote: >Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit: >> But there are still a few problematic things: > >Are these regressions over the previous state? No. Its much better now, also with the other problems I still have. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit:
> The following command displays
> the output in a long line instead dividing it into seperate lines:
>
> translate -i occure
On my system it does output
Vorkommen {n} (von etw.) [min.] | Erdölvorkommen {n} | Vorkommen [...]
So it's the output of the command itself which is a one-liner, mate&orca
can't do anything about it :)
> Also the problem that the screen content is not refreshed when deleting
> lines in a long text e.g. in the nano editor is still there. Just try the
> following:
>
> ls -1 /dev > test.txt
>
> Open the test.txt file, scrol down some pages and then delete a line with
> ctrl+k.
>
> On my machine I have to clear the screen with ctrl+l to see that the line
> has been removed on the braille display.
You mean that the braille display is still showing the very line you
wanted to remove? I am not able to reproduce this. Just to be precise:
- nano test.txt
- press page down
(get to some line shown on the braille display)
- press control-k
(the line is supposed to be replaced by the next line on the braille
display)
Do you perhaps have some particular configuration in nano?
Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, Christian Schoepplein, le mar. 12 sept. 2023 09:02:40 +0200, a ecrit: > But there are still a few problematic things: Are these regressions over the previous state? Not that I don't want to fix them, but I want to get something committed so we can make some progress, even if not perfect yet. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi Samuel, On Tue, Sep 12, 2023 at 12:36:28AM +0200, Jérémy Prego wrote: >for me, everything looks good compared to the version in debian testing I've also installed the packages you build yesterday and did some testing. The problem with the statusbar from apt seems to be gone, very cool, and also a ruptured console, that I had very ofthen after leaving mutt, did not occure so far. Thats a big improvement. But there are still a few problematic things: In some situations line breaks are not interpreted correctly. E.g. if you install packages with apt and the triggers are processed you normaly get a seperate line for every trigger. With the new versions of the packages the output for all triggers are displayed in one long line. You can trigger this behaviour also with the translate tool. The following command displays the output in a long line instead dividing it into seperate lines: translate -i occure Also the problem that the screen content is not refreshed when deleting lines in a long text e.g. in the nano editor is still there. Just try the following: ls -1 /dev > test.txt Open the test.txt file, scrol down some pages and then delete a line with ctrl+k. On my machine I have to clear the screen with ctrl+l to see that the line has been removed on the braille display. Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Le 11/09/2023 à 20:49, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: Le 11/09/2023 à 09:01, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Is this a regression over the previous versions or not? yes, it's a regression. i don't have this behavior with the version in debian testing Ok, I see the issue. I have updated the patches and package to merge the additions, could you please re-test? I can confirm that it's much better! after a quick test, I don't have any more problems, I'll test it in use, but for me, everything looks good compared to the version in debian testing thanks ! Samuel Jerem libt.tld_type is 1, lib_t.tld_source_file is '/usr/local/lib/aarch64-linux-gnu/perl/5.30.0/auto/share/dist/Mail-DMARC-opendmarc/effective_tld_names.dat' ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > A way to rupture the console is to update the packages on a system with apt. > The progress line at the bottom seems to trigger the unwanted behaviour very > reproducable :-). I know, that was the original testcase that triggered opening bug #88 ;) Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, I see the issue. I have updated the patches and package to merge the additions, could you please re-test? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Mon, Sep 11, 2023 at 09:25:44AM +0200, Samuel Thibault wrote: >Ok, is it more problematic than the various erratic behaviors that the >debian testing version has? Yes :-(. For me also the new patch brings no real improvement but thank you so much to continue working on it. A way to rupture the console is to update the packages on a system with apt. The progress line at the bottom seems to trigger the unwanted behaviour very reproducable :-). Also with the new patch I had problems to quote e.g. your email in mutt using the nano editor. I deleted the lines I did not want to quote with ctrl+k, but the screen did not refresh and nothing happens on the braille display when using the shortcut to delete the lines. I had to press ctrl+l to clear the screen to get content refreshed. Just out of curiosity: Is the problem related to libvte in general or is it related to the version in Debian? I am also using Debian testing. Because I have to use the terminal a lot I wonder if it could help to switch to another distro temporarily or on a second machine, which is really not what I want, but I need the system for my daily job... Ciao, Schoepp
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Christian Schoepplein, le lun. 11 sept. 2023 11:38:26 +0200, a ecrit: > Just out of curiosity: Is the problem related to libvte in general or is it > related to the version in Debian? It's completely a vte bug. Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 09:21:38 +0200, a ecrit: > Le 11/09/2023 à 09:01, Samuel Thibault a écrit : > > Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > > > I noticed a small problem > > > > > > 1. when you open a large file using cat file.txt |less and press enter to > > > go > > > down in the file, orca almost always pronounces the first 2 letters of the > > > line before reading the whole line. > > Is this a regression over the previous versions or not? > yes, it's a regression. i don't have this behavior with the version in debian > testing Ok, is it more problematic than the various erratic behaviors that the debian testing version has? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Le 11/09/2023 à 09:01, Samuel Thibault a écrit : Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Is this a regression over the previous versions or not? yes, it's a regression. i don't have this behavior with the version in debian testing Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Jérémy Prego, le lun. 11 sept. 2023 03:35:15 +0200, a ecrit: > I noticed a small problem > > 1. when you open a large file using cat file.txt |less and press enter to go > down in the file, orca almost always pronounces the first 2 letters of the > line before reading the whole line. Is this a regression over the previous versions or not? Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
hello, I've just tested this version out of curiosity. I noticed a small problem 1. when you open a large file using cat file.txt |less and press enter to go down in the file, orca almost always pronounces the first 2 letters of the line before reading the whole line. Jerem Le 11/09/2023 à 02:27, Samuel Thibault a écrit : Hello, I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an improved patch. Could people try it? I have also uploaded patched Debian packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ Please test so we can at last get this fixed! Samuel ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, I have updated https://gitlab.gnome.org/GNOME/vte/-/issues/88 with an improved patch. Could people try it? I have also uploaded patched Debian packages on https://people.debian.org/~sthibault/tmp/trixie-tmp/ Please test so we can at last get this fixed! Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/07 20:10 +0200): > The fixed packages are in Debian stable and testing, could people make > sure to upgrade and test before I upload the fixes to bookworm? Can't say thanks enough for your hard and prompt work. Just upgraded, everything seems to work normally. Thanks again, Seb. > > Samuel >
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault, le mar. 05 sept. 2023 00:08:33 +0200, a ecrit: > Samuel Thibault, le lun. 04 sept. 2023 22:59:05 +0200, a ecrit: > > I'm on it. > > So, as usual it's the combination of two issues that were producing the > odd behavior. > [...] > So, long story short: > > https://github.com/brltty/brltty/pull/428 > > and I'll backport some fixes to bookworm. The fixed packages are in Debian stable and testing, could people make sure to upgrade and test before I upload the fixes to bookworm? Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Chevelle, le lun. 04 sept. 2023 20:27:08 -0400, a ecrit: > Thanks Samuel. The ORCA Debian package only has xbrlapi as Reccomends. > There doesn't seem to be any warning by ORCA so if xbrlapi isn't installed > the unsuspecting user has a Braille display that doesn't work properly. > Should xbrlapi be a depends instead? No: orca doesn't depend on xbrlapi to produce its behavior. xbrlapi being a recommend already makes the xbrlapi installed by default, without making it mandatory for people who don't actually need it. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Thanks Samuel. The ORCA Debian package only has xbrlapi as Reccomends. There doesn't seem to be any warning by ORCA so if xbrlapi isn't installed the unsuspecting user has a Braille display that doesn't work properly. Should xbrlapi be a depends instead? On 9/4/23 18:08, Samuel Thibault wrote: Samuel Thibault, le lun. 04 sept. 2023 22:59:05 +0200, a ecrit: I'm on it. So, as usual it's the combination of two issues that were producing the odd behavior. What was happening is that with xbrlapi installed but brltty-x11 not installed, the xbrlapi startup script would try to run brltty with the BrlAPI braille driver and the AtSpi2 screen driver, but the latter wouldn't load, so brltty would fallback to the "no" screen driver. But that driver was not telling the BrlAPI braille driver that it cannot do much, on the contrary it would tell that it works really well, better than Orca, and thus the BrlAPI braille driver would consume most BrlAPI keypresses. With the AtSpi2 driver installed, it knows to tell exactly when it has good support (e.g. in terminals). It happens that upgrading xbrlapi fixed this because in the newer version the xbrlapi startup script checks that both the BrlAPI and the AtSpi2 drivers are available, and not start that brltty in that case. So, long story short: https://github.com/brltty/brltty/pull/428 and I'll backport some fixes to bookworm. Samuel ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault, le lun. 04 sept. 2023 22:59:05 +0200, a ecrit: > I'm on it. So, as usual it's the combination of two issues that were producing the odd behavior. What was happening is that with xbrlapi installed but brltty-x11 not installed, the xbrlapi startup script would try to run brltty with the BrlAPI braille driver and the AtSpi2 screen driver, but the latter wouldn't load, so brltty would fallback to the "no" screen driver. But that driver was not telling the BrlAPI braille driver that it cannot do much, on the contrary it would tell that it works really well, better than Orca, and thus the BrlAPI braille driver would consume most BrlAPI keypresses. With the AtSpi2 driver installed, it knows to tell exactly when it has good support (e.g. in terminals). It happens that upgrading xbrlapi fixed this because in the newer version the xbrlapi startup script checks that both the BrlAPI and the AtSpi2 drivers are available, and not start that brltty in that case. So, long story short: https://github.com/brltty/brltty/pull/428 and I'll backport some fixes to bookworm. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:52:11 +0200, a ecrit: > Samuel Thibault (2023/09/04 22:42 +0200): > > Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > > > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), > > > > That makes a huge difference, that's why I was asking for versions. In > > versions before 6.6-1, the xbrlapi package was trying to start brltty > > with a ba driver and an a2 driver, only to fail loading the a2 driver. > > So possibly the presence of brltty with only the ba driver loaded is > > eating keypresses, and the addition of a2 brings things back in order, > > for whatever reason. > > So what shall we do from here? I'm on it. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 22:42 +0200): > Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), > > That makes a huge difference, that's why I was asking for versions. In > versions before 6.6-1, the xbrlapi package was trying to start brltty > with a ba driver and an a2 driver, only to fail loading the a2 driver. > So possibly the presence of brltty with only the ba driver loaded is > eating keypresses, and the addition of a2 brings things back in order, > for whatever reason. So what shall we do from here? Seb.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), That makes a huge difference, that's why I was asking for versions. In versions before 6.6-1, the xbrlapi package was trying to start brltty with a ba driver and an a2 driver, only to fail loading the a2 driver. So possibly the presence of brltty with only the ba driver loaded is eating keypresses, and the addition of a2 brings things back in order, for whatever reason. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 22:12 +0200): > I don't mean it's not implemented. I mean in the tests one can make, > Orca doesn't happen to be doing anything with them. For *whatever* > reason that might lie between the actual braille device and Orca. Yes yes, I'm following you now. > > Unless there is a regression that happened in Orca and has somehow > > been masked? > > Or in whatever is between the device and Orca. > > > Even theprecedence mechanism is not that old, probably newer than a2 > > and thus even if a2 is there for a long time it's not such a long time > > it cantake precedence over Orca when there are widgets they both know > > how to render, right? > > Without actually taking the time to actually *inspect* what is > happening, I'll just stop making any more guesses, it's a loss of time > from all of us. Yes yes, sorry, wie will stop guessing. Apologies, I was just thinking out loud because it was the easiestthing to do. > > > But again, which version of brltty are you using? > > > > 6.6-2 > > So when brltty-x11 is not installed, you do not have a second brltty > running, right? Right. Only one brltty running. But, my observations differ from those reported by Roberto. On my system, things continue to work even once brltty-x11 has been purged and the system has been restarted. Hoping it helps, here is the relevant bit of /var/log/apt/history.log: Start-Date: 2023-09-04 13:31:57 Commandline: apt install orca Upgrade: orca:amd64 (43.1-1, 44.1-2) End-Date: 2023-09-04 13:32:00 Start-Date: 2023-09-04 14:23:50 Commandline: apt install brltty-x11 Install: brltty-x11:amd64 (6.6-2) Upgrade: python3-brlapi:amd64 (6.5-7, 6.6-2), xbrlapi:amd64 (6.5-7, 6.6-2), libbrlapi0.8:amd64 (6.5-7, 6.6-2), brltty:amd64 (6.5-7, 6.6-2) End-Date: 2023-09-04 14:24:08 Start-Date: 2023-09-04 22:18:36 Commandline: apt purge brltty-x11 Purge: brltty-x11:amd64 (6.6-2) End-Date: 2023-09-04 22:18:37 Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 22:02:48 +0200, a ecrit: > Samuel Thibault (2023/09/04 21:28 +0200): > > Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > > > Samuel Thibault (2023/09/04 21:01 +0200): > > > > So the behavior you expect is not actually implemented by Orca, it's the > > > > a2 screen driver that takes precedence in the text fields > > > > > > Well I am unsure about what you mean by text field here because, for the > > > little of GUI I am using (Firefox essentially), I have observed this > > > behaviour or not being able to use braille window navigation and routing > > > keys in a very constant way. Is any place in a web page really a > > > text-filed? > > > > Yes. Or more precisely: they all expose a text interface, even if they > > don't have a text role. Since apparently orca doesn't capture routing > > key events, these events fall back to being exposed to the a2 driver, > > which gives it to brltty, which uses a2 to read the widget content, and > > perform the cursor routing. > > Are you sure Orca does not deal with routing keys? I don't mean it's not implemented. I mean in the tests one can make, Orca doesn't happen to be doing anything with them. For *whatever* reason that might lie between the actual braille device and Orca. > Isn't this something that is working for years now? I have no idea about that, as I don't actually use Orca. > Unless there is a regression that happened in Orca and has somehow > been masked? Or in whatever is between the device and Orca. > Even theprecedence mechanism is not that old, probably newer than a2 > and thus even if a2 is there for a long time it's not such a long time > it cantake precedence over Orca when there are widgets they both know > how to render, right? Without actually taking the time to actually *inspect* what is happening, I'll just stop making any more guesses, it's a loss of time from all of us. > > > Also, if the a2 screen driver "just" takes precedence, shouldn't things > > > still work when it's not there? > > > > If Orca was capturing routing key events, yes. It appears that doesn't > > happen. > > That's a real surprise to me. Yes, but that's a fact: in my test it doesn't print any log upon routing key press. > > In the test I made with Roberto's case, it really was brltty's way of > > pressing arrows to simulate routing, that Orca doesn't implement > > anyway. > > In which context (applicaiton, widget) did you test? Routing key in pluma. > Intuitively, I'd have assumed that indeed orca is not simulating arrow > key presses as brltty does but that it rather implements the routing by > simulaitng moves of the mouse ppointer, and mouse clicks. > > In particular, I was under the impression that, in fFirefox, when I am > "clicking" on a link with the cursor routing keys, it's really like if I > was doing a mouse click. Ok, but what I saw was definitely brltty's routing, for whatever reason that might happen to be. > > But again, which version of brltty are you using? > > 6.6-2 So when brltty-x11 is not installed, you do not have a second brltty running, right? Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 21:28 +0200): > Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > > Samuel Thibault (2023/09/04 21:01 +0200): > > > So the behavior you expect is not actually implemented by Orca, it's the > > > a2 screen driver that takes precedence in the text fields > > > > Well I am unsure about what you mean by text field here because, for the > > little of GUI I am using (Firefox essentially), I have observed this > > behaviour or not being able to use braille window navigation and routing > > keys in a very constant way. Is any place in a web page really a > > text-filed? > > Yes. Or more precisely: they all expose a text interface, even if they > don't have a text role. Since apparently orca doesn't capture routing > key events, these events fall back to being exposed to the a2 driver, > which gives it to brltty, which uses a2 to read the widget content, and > perform the cursor routing. Are you sure Orca does not deal with routing keys? See for instance the output of git grep -l processRoutingKey in the orca sources. Isn't this something that is working for years now? I mean, correct me if I am wrong but I thought it's not such a long time a2 is around and dealing with all the text fields, compared to Orca's ability to deal with routing keys. Unless there is a regression that happened in Orca and has somehow been masked? Even theprecedence mechanism is not that old, probably newer than a2 and thus even if a2 is there for a long time it's not such a long time it cantake precedence over Orca when there are widgets they both know how to render, right? > > Also, if the a2 screen driver "just" takes precedence, shouldn't things > > still work when it's not there? > > If Orca was capturing routing key events, yes. It appears that doesn't > happen. That's a real surprise to me. > In the test I made with Roberto's case, it really was brltty's way of > pressing arrows to simulate routing, that Orca doesn't implement > anyway. In which context (applicaiton, widget) did you test? Intuitively, I'd have assumed that indeed orca is not simulating arrow key presses as brltty does but that it rather implements the routing by simulaitng moves of the mouse ppointer, and mouse clicks. In particular, I was under the impression that, in fFirefox, when I am "clicking" on a link with the cursor routing keys, it's really like if I was doing a mouse click. > > > knows it brings better support in that case (the cursor routing you get > > > is achieved by the brltty core itself, not the a2 driver which is only > > > the "messenger"). > > > > But that is not what is supposed to happen when you click (use cursor > > routing keys) on links in Firefox, right? > > Ah, that part seems odd however, indeed. OK, I feel kind of relieved we can agree on this oddness, at least. ;-) > But again, which version of brltty are you using? 6.6-2 > > > So it's not really Orca that "depends" on brltty-x11, it's just that > > > brltty-x11 is an interesting complement to Orca, to improve screen > > > reading. > > > > I don't think it's fair to put things this way frankly. Currently, you > > simply can't read the screen in braille without brltty-x11... > > If that is so, it's a bug that needs a fix in Orca, and not just make > people install brltty-x11 as a workaround that we don't even understand > how it happens to work. Yes, I fully agree. Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Roberto Burceni, le lun. 04 sept. 2023 21:39:07 +0200, a ecrit: > Ok but at this point which is the exactly the main function of brltty-x11? Providing a brltty-like experience wherever it can on the graphical desktop. Yes that's not very precise, because the details are dense. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Ok but at this point which is the exactly the main function of brltty-x11? Roberto Burceni Linux System Admin & PHP developer Esperto accessibilità siti web E-mail: robe...@robertoburceni.it Phone: +393358208080 P.iva: 04025840986 Il 04/09/23 21:28, Samuel Thibault ha scritto: Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: Samuel Thibault (2023/09/04 21:01 +0200): So the behavior you expect is not actually implemented by Orca, it's the a2 screen driver that takes precedence in the text fields Well I am unsure about what you mean by text field here because, for the little of GUI I am using (Firefox essentially), I have observed this behaviour or not being able to use braille window navigation and routing keys in a very constant way. Is any place in a web page really a text-filed? Yes. Or more precisely: they all expose a text interface, even if they don't have a text role. Since apparently orca doesn't capture routing key events, these events fall back to being exposed to the a2 driver, which gives it to brltty, which uses a2 to read the widget content, and perform the cursor routing. Also, if the a2 screen driver "just" takes precedence, shouldn't things still work when it's not there? If Orca was capturing routing key events, yes. It appears that doesn't happen. In the test I made with Roberto's case, it really was brltty's way of pressing arrows to simulate routing, that Orca doesn't implement anyway. knows it brings better support in that case (the cursor routing you get is achieved by the brltty core itself, not the a2 driver which is only the "messenger"). But that is not what is supposed to happen when you click (use cursor routing keys) on links in Firefox, right? Ah, that part seems odd however, indeed. But again, which version of brltty are you using? So it's not really Orca that "depends" on brltty-x11, it's just that brltty-x11 is an interesting complement to Orca, to improve screen reading. I don't think it's fair to put things this way frankly. Currently, you simply can't read the screen in braille without brltty-x11... If that is so, it's a bug that needs a fix in Orca, and not just make people install brltty-x11 as a workaround that we don't even understand how it happens to work. Samuel ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: Braille navigation issues with Orca 44.1
Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > Samuel Thibault (2023/09/04 21:01 +0200): > > So the behavior you expect is not actually implemented by Orca, it's the > > a2 screen driver that takes precedence in the text fields > > Well I am unsure about what you mean by text field here because, for the > little of GUI I am using (Firefox essentially), I have observed this > behaviour or not being able to use braille window navigation and routing > keys in a very constant way. Is any place in a web page really a > text-filed? Yes. Or more precisely: they all expose a text interface, even if they don't have a text role. Since apparently orca doesn't capture routing key events, these events fall back to being exposed to the a2 driver, which gives it to brltty, which uses a2 to read the widget content, and perform the cursor routing. > Also, if the a2 screen driver "just" takes precedence, shouldn't things > still work when it's not there? If Orca was capturing routing key events, yes. It appears that doesn't happen. In the test I made with Roberto's case, it really was brltty's way of pressing arrows to simulate routing, that Orca doesn't implement anyway. > > knows it brings better support in that case (the cursor routing you get > > is achieved by the brltty core itself, not the a2 driver which is only > > the "messenger"). > > But that is not what is supposed to happen when you click (use cursor > routing keys) on links in Firefox, right? Ah, that part seems odd however, indeed. But again, which version of brltty are you using? > > So it's not really Orca that "depends" on brltty-x11, it's just that > > brltty-x11 is an interesting complement to Orca, to improve screen > > reading. > > I don't think it's fair to put things this way frankly. Currently, you > simply can't read the screen in braille without brltty-x11... If that is so, it's a bug that needs a fix in Orca, and not just make people install brltty-x11 as a workaround that we don't even understand how it happens to work. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 21:01 +0200): > Ok, I see. > > So the behavior you expect is not actually implemented by Orca, it's the > a2 screen driver that takes precedence in the text fields Well I am unsure about what you mean by text field here because, for the little of GUI I am using (Firefox essentially), I have observed this behaviour or not being able to use braille window navigation and routing keys in a very constant way. Is any place in a web page really a text-filed? I did'nt see this widget as that generic and thought it was basically used for text _input_ fileds but I may be wrong on that. Also, if the a2 screen driver "just" takes precedence, shouldn't things still work when it's not there? I was about to use that things used to work but now I am unsure because perhaps brltty-x11 has always been installed on my system so perhaps this is here unnoticed since several years. > knows it brings better support in that case (the cursor routing you get > is achieved by the brltty core itself, not the a2 driver which is only > the "messenger"). But that is not what is supposed to happen when you click (use cursor routing keys) on links in Firefox, right? It is this behaviour, for instance, which does not work without brltty-x11 and does work with it. > So it's not really Orca that "depends" on brltty-x11, it's just that > brltty-x11 is an interesting complement to Orca, to improve screen > reading. I don't think it's fair to put things this way frankly. Currently, you simply can't read the screen in braille without brltty-x11... And you can't activate links with the cursor routing keys, so you are forced to use tab to give them the focus so that you can thenpress Enter. This workflow is really less efficient than being able to activate links throughthe routing keys. Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Roberto Burceni, le lun. 04 sept. 2023 21:12:44 +0200, a ecrit: > When I am in a browser and navitate with pan key, when I encounter an > unordered or ordered list, the braille display stay on the first item and do > not go on te following. > > To go to the next item I have to press down arrow key. > > Have you an idea about this behaviour? AIUI that'd have to be implemented in Orca. xbrlapi and brltty-x11 don't actually know about graphical items etc, they only provide some support within a given widget. Samuel
Re: [orca] Re: Braille navigation issues with Orca 44.1
Ok I ask another thing about braille navigation that is strange but I did not find any solution: When I am in a browser and navitate with pan key, when I encounter an unordered or ordered list, the braille display stay on the first item and do not go on te following. To go to the next item I have to press down arrow key. Have you an idea about this behaviour? Roberto Burceni Linux System Admin & PHP developer Esperto accessibilità siti web E-mail: robe...@robertoburceni.it Phone: +393358208080 P.iva: 04025840986 Il 04/09/23 21:01, Samuel Thibault ha scritto: Ok, I see. So the behavior you expect is not actually implemented by Orca, it's the a2 screen driver that takes precedence in the text fields because it knows it brings better support in that case (the cursor routing you get is achieved by the brltty core itself, not the a2 driver which is only the "messenger"). So it's not really Orca that "depends" on brltty-x11, it's just that brltty-x11 is an interesting complement to Orca, to improve screen reading. That being said, perhaps the orca package should still recommend brltty-x11, the same way it recommends xbrlapi which also improves it. We however need to be very cautious because installing brltty-x11 installs brltty, which enables usb-serial drivers which hurt ftdi serial adapters users. I'll see how to arrange that. Samuel Roberto Burceni, le lun. 04 sept. 2023 20:43:17 +0200, a ecrit: I'm using brltty 6.5 which is in ubuntu 23.04. But I discovered this problem also in debian buster and bullseye with brltty 6.3. Roberto Burceni Il 04/09/23 19:01, Samuel Thibault ha scritto: Roberto Burceni, le lun. 04 sept. 2023 18:51:50 +0200, a ecrit: I confirm that without brltty-x11 you can not navigate nor use cursor routing. Just to make sure: which version of brltty is this? There was a bug concerning keys in brltty 6.6, and a2 running might have a side effect. Samuel ___ orca mailing list o...@freelists.org https://www.freelists.org/list/orca Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Re: [orca] Re: Braille navigation issues with Orca 44.1
Ok, I see. So the behavior you expect is not actually implemented by Orca, it's the a2 screen driver that takes precedence in the text fields because it knows it brings better support in that case (the cursor routing you get is achieved by the brltty core itself, not the a2 driver which is only the "messenger"). So it's not really Orca that "depends" on brltty-x11, it's just that brltty-x11 is an interesting complement to Orca, to improve screen reading. That being said, perhaps the orca package should still recommend brltty-x11, the same way it recommends xbrlapi which also improves it. We however need to be very cautious because installing brltty-x11 installs brltty, which enables usb-serial drivers which hurt ftdi serial adapters users. I'll see how to arrange that. Samuel Roberto Burceni, le lun. 04 sept. 2023 20:43:17 +0200, a ecrit: > I'm using brltty 6.5 which is in ubuntu 23.04. But I discovered this problem > also in debian buster and bullseye with brltty 6.3. > > > Roberto Burceni > > Il 04/09/23 19:01, Samuel Thibault ha scritto: > > Roberto Burceni, le lun. 04 sept. 2023 18:51:50 +0200, a ecrit: > > > I confirm that without brltty-x11 you can not navigate nor use cursor > > > routing. > > Just to make sure: which version of brltty is this? There was a bug > > concerning keys in brltty 6.6, and a2 running might have a side effect. > > > > Samuel
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Sun, Sep 03, 2023 at 11:18:49PM +0200, Samuel Thibault wrote: > Alexander Epaneshnikov, le lun. 04 sept. 2023 00:08:42 +0300, a ecrit: > > in order to return this fix, where the correction of the diff algorithm > > should occur in libvte or in orca? > > In vte. Diff algorithms should be done as early as possible to avoid > overflowing the rest. OK. thanks for the answer. if there is any news please keep me posted. for now, I'll just keep this patch locally. > Samuel -- Sincerely, Alexander
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Alexander Epaneshnikov, le lun. 04 sept. 2023 00:08:42 +0300, a ecrit: > in order to return this fix, where the correction of the diff algorithm > should occur in libvte or in orca? In vte. Diff algorithms should be done as early as possible to avoid overflowing the rest. Samuel
