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
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
>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
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
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
On Sun, Sep 03, 2023 at 09:39:56PM +0200, Jérémy Prego wrote: > hello, hello Jérémy. > I've just found the library that's causing the problem. > > it's the libvte-2.91-0 library in version 0.73.93-1 currently in debian > testing. downgrading to version 0.72.2-3 solves the problem. that happened because bug [1] was fixed in libvte. in fact I think this fix improved more than it got worse, so I'm sad that it was rolled back. > i'm relieved! :) > > I was thinking of making a bug report in debian against the package, but I > confess I don't know what to put in it. A question for Samuel. in order to return this fix, where the correction of the diff algorithm should occur in libvte or in orca? because as a vte-based terminal every day user, I can't imagine life without this patch. ps Well, this patch has a difficult fate. > Jerem [1]: https://gitlab.gnome.org/GNOME/vte/-/issues/88 -- Sincerely, Alexander
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
I've just seen that version 0.73.99-1, which will soon be available in sid and then in testing, solves the problem for me with this version as well. so for me the problem is closed, as it will soon be corrected in debian. Jerem Le 03/09/2023 à 23:08, Alexander Epaneshnikov a écrit : On Sun, Sep 03, 2023 at 09:39:56PM +0200, Jérémy Prego wrote: hello, hello Jérémy. I've just found the library that's causing the problem. it's the libvte-2.91-0 library in version 0.73.93-1 currently in debian testing. downgrading to version 0.72.2-3 solves the problem. that happened because bug [1] was fixed in libvte. in fact I think this fix improved more than it got worse, so I'm sad that it was rolled back. i'm relieved! :) I was thinking of making a bug report in debian against the package, but I confess I don't know what to put in it. A question for Samuel. in order to return this fix, where the correction of the diff algorithm should occur in libvte or in orca? because as a vte-based terminal every day user, I can't imagine life without this patch. ps Well, this patch has a difficult fate. Jerem [1]: https://gitlab.gnome.org/GNOME/vte/-/issues/88
Re: [orca] (solved) orca's strange behavior in a crowded terminal
hello, I've just found the library that's causing the problem. it's the libvte-2.91-0 library in version 0.73.93-1 currently in debian testing. downgrading to version 0.72.2-3 solves the problem. i'm relieved! :) I was thinking of making a bug report in debian against the package, but I confess I don't know what to put in it. Jerem Le 02/09/2023 à 02:55, Jérémy Prego (jeremy) a écrit : Hello, since this evening, I've been experiencing a strange bug with orca, but I don't think he's the direct culprit. if I fill my terminal and then issue a command, e.g. "echo foo", Orca will read out the entire terminal window, not just the text that has just been added to the terminal. as long as the terminal isn't full, everything's fine, it works as expected. I've tried downgrading at-spi with all the right debian packages, but the problem is still there. I'm attaching a debug, if it helps to understand what's going on :) thanks, Jerem
Re: Orca Isn't Autostarting
I also looked in /var/log, and there are a lot of log folders there, and I looked in speech-dispatcher, and there was nothing in that folder. Maybe someone can suggest a log file to look for. Here's a LS of what is in /var/log: alternatives.log apt auth.log boot.log boot.log.1 btmp cups daemon.log debug dpkg.log faillog fontconfig.log gdm3 installer journal kern.log lastlog messages popularity-contest popularity-contest.0 popularity-contest.gpg private runit speech-dispatcher syslog unattended-upgrades user.log wtmp - Original Message - From: "K0LNY_Glenn" To: "Jason White" Cc: Sent: Saturday, December 10, 2022 4:54 PM Subject: Re: Orca Isn't Autostarting Here's a snippet from a journal.txt I made of the output, just involving today, and around Orca. It mentions something about Orca, and I don't know what it is pointing to: The segment is: [843]: Run “orca --replace” to replace that process with a new one. snippet below: ted service 'org.a11y.Bus' Dec 10 16:14:04 asus701 systemd[481]: Started Accessibility services bus. Dec 10 16:14:04 asus701 at-spi-bus-launcher[725]: dbus-daemon[725]: Activating service name='org.a11y.atspi.Registry' requested by ':1.1' (uid=1000 pid=708 comm="/usr/libexec/ibus-ui-gtk3 ") Dec 10 16:14:04 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.28' (uid=1000 pid=709 comm="/usr/libexec/ibus-extension-gtk3 ") Dec 10 16:14:05 asus701 systemd[481]: Starting Portal service... Dec 10 16:14:05 asus701 at-spi-bus-launcher[725]: dbus-daemon[725]: Successfully activated service 'org.a11y.atspi.Registry' Dec 10 16:14:05 asus701 at-spi-bus-launcher[736]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.portal.Documents' unit='xdg-document-portal.service' requested by ':1.31' (uid=1000 pid=739 comm="/usr/libexec/xdg-desktop-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting flatpak document portal service... Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.impl.portal.PermissionStore' unit='xdg-permission-store.service' requested by ':1.32' (uid=1000 pid=745 comm="/usr/libexec/xdg-document-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting sandboxed app permission store... Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore' Dec 10 16:14:05 asus701 systemd[481]: Started sandboxed app permission store. Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.portal.Documents' Dec 10 16:14:05 asus701 systemd[481]: Started flatpak document portal service. Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk' unit='xdg-desktop-portal-gtk.service' requested by ':1.31' (uid=1000 pid=739 comm="/usr/libexec/xdg-desktop-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting Portal service (GTK+/GNOME implementation)... Dec 10 16:14:06 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating service name='ca.desrt.dconf' requested by ':1.26' (uid=1000 pid=590 comm="x-session-manager ") Dec 10 16:14:06 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'ca.desrt.dconf' Dec 10 16:14:06 asus701 /usr/libexec/gdm-x-session[590]: x-session-manager[590]: WARNING: Unable to find provider '' of required component 'dock' Dec 10 16:14:06 asus701 x-session-manager[590]: WARNING: Unable to find provider '' of required component 'dock' Dec 10 16:14:07 asus701 /usr/libexec/gdm-x-session[770]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:07 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk' Dec 10 16:14:07 asus701 systemd[481]: Started Portal service (GTK+/GNOME implementation). Dec 10 16:14:08 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.portal.Desktop' Dec 10 16:14:08 asus701 systemd[481]: Started Portal service. Dec 10 16:14:12 asus701 /usr/libexec/gdm-x-session[797]: Window manager warning: Log level 128: unsetenv() is not thread-safe and should not be used after threads are created Dec 10 16:14:19 asus701 gnome-keyring-daemon[508]: The PKCS#11 component was already initialized Dec 10 16:14:19 asus701 /usr/libexec/gdm-x-session[835]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:20 asus701 gnome-keyring-daemon[508]: The SSH agent was already initialized Dec 10 16:14:20 asus701 /usr/libexec/gdm-x-session[851]: SSH_AUTH_SOCK=/run/us
Re: Orca Isn't Autostarting
Here's a snippet from a journal.txt I made of the output, just involving today, and around Orca. It mentions something about Orca, and I don't know what it is pointing to: The segment is: [843]: Run “orca --replace” to replace that process with a new one. snippet below: ted service 'org.a11y.Bus' Dec 10 16:14:04 asus701 systemd[481]: Started Accessibility services bus. Dec 10 16:14:04 asus701 at-spi-bus-launcher[725]: dbus-daemon[725]: Activating service name='org.a11y.atspi.Registry' requested by ':1.1' (uid=1000 pid=708 comm="/usr/libexec/ibus-ui-gtk3 ") Dec 10 16:14:04 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.28' (uid=1000 pid=709 comm="/usr/libexec/ibus-extension-gtk3 ") Dec 10 16:14:05 asus701 systemd[481]: Starting Portal service... Dec 10 16:14:05 asus701 at-spi-bus-launcher[725]: dbus-daemon[725]: Successfully activated service 'org.a11y.atspi.Registry' Dec 10 16:14:05 asus701 at-spi-bus-launcher[736]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.portal.Documents' unit='xdg-document-portal.service' requested by ':1.31' (uid=1000 pid=739 comm="/usr/libexec/xdg-desktop-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting flatpak document portal service... Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.impl.portal.PermissionStore' unit='xdg-permission-store.service' requested by ':1.32' (uid=1000 pid=745 comm="/usr/libexec/xdg-document-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting sandboxed app permission store... Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore' Dec 10 16:14:05 asus701 systemd[481]: Started sandboxed app permission store. Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.portal.Documents' Dec 10 16:14:05 asus701 systemd[481]: Started flatpak document portal service. Dec 10 16:14:05 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.gtk' unit='xdg-desktop-portal-gtk.service' requested by ':1.31' (uid=1000 pid=739 comm="/usr/libexec/xdg-desktop-portal ") Dec 10 16:14:05 asus701 systemd[481]: Starting Portal service (GTK+/GNOME implementation)... Dec 10 16:14:06 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Activating service name='ca.desrt.dconf' requested by ':1.26' (uid=1000 pid=590 comm="x-session-manager ") Dec 10 16:14:06 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'ca.desrt.dconf' Dec 10 16:14:06 asus701 /usr/libexec/gdm-x-session[590]: x-session-manager[590]: WARNING: Unable to find provider '' of required component 'dock' Dec 10 16:14:06 asus701 x-session-manager[590]: WARNING: Unable to find provider '' of required component 'dock' Dec 10 16:14:07 asus701 /usr/libexec/gdm-x-session[770]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:07 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk' Dec 10 16:14:07 asus701 systemd[481]: Started Portal service (GTK+/GNOME implementation). Dec 10 16:14:08 asus701 dbus-daemon[525]: [session uid=1000 pid=525] Successfully activated service 'org.freedesktop.portal.Desktop' Dec 10 16:14:08 asus701 systemd[481]: Started Portal service. Dec 10 16:14:12 asus701 /usr/libexec/gdm-x-session[797]: Window manager warning: Log level 128: unsetenv() is not thread-safe and should not be used after threads are created Dec 10 16:14:19 asus701 gnome-keyring-daemon[508]: The PKCS#11 component was already initialized Dec 10 16:14:19 asus701 /usr/libexec/gdm-x-session[835]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:20 asus701 gnome-keyring-daemon[508]: The SSH agent was already initialized Dec 10 16:14:20 asus701 /usr/libexec/gdm-x-session[851]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:20 asus701 caja[826]: Failed to register client: GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register client Dec 10 16:14:20 asus701 gnome-keyring-daemon[508]: The Secret Service was already initialized Dec 10 16:14:20 asus701 /usr/libexec/gdm-x-session[858]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh Dec 10 16:14:22 asus701 pulseaudio[500]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network co
Re: Orca Isn't Autostarting
Thank you. - Original Message - From: "Jason White" To: "K0LNY_Glenn" Sent: Saturday, December 10, 2022 4:19 PM Subject: Re: Orca Isn't Autostarting On 11/12/22 09:09, K0LNY_Glenn wrote: > Which logs should I look, and where? Run journalctl and have a look. > Also, how do I check running services? ps -ef will show you the list. You can use pgrep (e.g., "pgrep orca") to search for specific processes. Also, please reply via the mailing list so that everyone can contribute to the discussion. You sent your reply to me only, or so it appears.
Re: Orca Isn't Autostarting
On 10/12/22 14:32, K0LNY_Glenn wrote: The last command didn't give an error, but it still does not auto start. Thanks for trying. Have you examined your system logs to find out whether it attempts to start, but fails for some reason? Check whether at-spi2 is run. This is needed for Orca. Check whether Orca itself runs. You could also log in via ssh from another machine after the boot process is completed and look at the running processes.
Re: Orca Isn't Autostarting
The last command didn't give an error, but it still does not auto start. Thanks for trying. - Original Message - From: "Paul Wise" To: "K0LNY_Glenn" ; Sent: Friday, December 09, 2022 8:39 PM Subject: Re: Orca Isn't Autostarting
Re: Orca Isn't Autostarting
Well I looked in /etc/xdg/autostart and Orca is in there, something like: orca-autostart.desktop. Glenn - Original Message - From: "Paul Wise" To: "K0LNY_Glenn" ; Sent: Friday, December 09, 2022 8:39 PM Subject: Re: Orca Isn't Autostarting
Re: Orca Isn't Autostarting
Thanks Paul, I'll look at those suggestions. Glenn - Original Message - From: "Paul Wise" To: "K0LNY_Glenn" ; Sent: Friday, December 09, 2022 8:39 PM Subject: Re: Orca Isn't Autostarting
Re: Orca Isn't Autostarting
On Fri, 2022-12-09 at 18:30 -0600, K0LNY_Glenn wrote: > Hope someone has some ideas. I note that orca is supposed to autostart by default: $ apt-file search autostart | grep ^orca: orca: /etc/xdg/autostart/orca-autostart.desktop Seems it only happens when the screen-reader option is enabled in the GNOME settings. I am not sure if MATE sets that setting though. $ grep -iE 'exec|condition' /etc/xdg/autostart/orca-autostart.desktop Exec=orca AutostartCondition=GSettings org.gnome.desktop.a11y.applications screen-reader-enabled You could try enabling the GNOME screen reader setting manually: $ gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Orca Isn't Autostarting
Hi Jason, Thanks, yeah, I did all that, but the odd thing is, that in "universal access, there is no entry for the screenreader, there were two things in there, keyboard accessibility, and I forget the other one. Usually once it has been enabled, it always auto starts.I didn't uninstall the Gnome Flashback, just installed mate-desktop-environment-extras. I noticed that Mate used the Orca voice settings I set up when I was running the Gnome Flashback. Glenn - Original Message - From: "Jason White" To: Sent: Friday, December 09, 2022 6:53 PM Subject: Re: Orca Isn't Autostarting If you start Orca at the log-in dialogue with Alt-Super-S, it should remain running in the desktop session and persist across reboots. (I'm using Debian Testing and GNOME, so this isn't your exact situation.) Also, check your desktop's Accessibility settings and ensure that "screen reader" is eanbled. On 10/12/22 11:30, K0LNY_Glenn wrote: > Hello, > On Debian 11.5, I just installed Mate with extras. > I put Orca in the auto start applications in control panel, but it still > isn't auto starting. > I've been trying to find an answer on-line, regarding making an icon and > putting it into an auto start folder, but the closest reference I found > mentions that there is a ./config in home/user but there is no such folder > in there. > In the Raspberry PI, I once made a .desktop file and put it into a folder > for desktop startup applications, but I searched the computer for .desktop > and didn't find any such files. > Hope someone has some ideas. > > Thanks. > > Glenn >
Re: Orca Isn't Autostarting
If you start Orca at the log-in dialogue with Alt-Super-S, it should remain running in the desktop session and persist across reboots. (I'm using Debian Testing and GNOME, so this isn't your exact situation.) Also, check your desktop's Accessibility settings and ensure that "screen reader" is eanbled. On 10/12/22 11:30, K0LNY_Glenn wrote: Hello, On Debian 11.5, I just installed Mate with extras. I put Orca in the auto start applications in control panel, but it still isn't auto starting. I've been trying to find an answer on-line, regarding making an icon and putting it into an auto start folder, but the closest reference I found mentions that there is a ./config in home/user but there is no such folder in there. In the Raspberry PI, I once made a .desktop file and put it into a folder for desktop startup applications, but I searched the computer for .desktop and didn't find any such files. Hope someone has some ideas. Thanks. Glenn
Orca Isn't Autostarting
Hello, On Debian 11.5, I just installed Mate with extras. I put Orca in the auto start applications in control panel, but it still isn't auto starting. I've been trying to find an answer on-line, regarding making an icon and putting it into an auto start folder, but the closest reference I found mentions that there is a ./config in home/user but there is no such folder in there. In the Raspberry PI, I once made a .desktop file and put it into a folder for desktop startup applications, but I searched the computer for .desktop and didn't find any such files. Hope someone has some ideas. Thanks. Glenn
Re: Debian and Orca installation Question
Hello, Egon, le mar. 15 nov. 2022 06:10:59 +0100, a ecrit: > What can I do when the kernel in Debian stable (even with non-free > firmware-supported net-install image) not support the integrated Wi-Fi > card of my notebook? Easiest is to use a USB wifi dongle. Samuel
Re: Debian and Orca installation Question
The super key is the windows start key. Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) . On Tue, 15 Nov 2022, Jason White wrote: > > On 30/10/22 05:03, Egon wrote: > > I installed the Mate desktop environment. > > Orca did not start automatically but the console-based speaking software > > did. > > > > How can I install the system to avoid these problems? > In a properly installed system, pressing Alt-Super-S at the log-in dialogue > should start Orca. > >
Re: Debian and Orca installation Question
Hi All, Thank you. What can I do when the kernel in Debian stable (even with non-free firmware-supported net-install image) not support the integrated Wi-Fi card of my notebook? How can be easy to create net-install media with pached-kernel to support it? The Wi-Fi card name is: MediaTek MT7921 Best regards: Egon
Re: Debian and Orca installation Question
Hello, Egon, le sam. 29 oct. 2022 20:46:21 +0200, a ecrit: > 2022-10-29 20:07 GMT+02:00, Jordan Livesey : > > just use the netinstall iso files, they give you a minimal mate desktop > > with gimp and libreoffice but everything else you are free to use and > > customise in turms of what else you want, plus, orca comes as standard, if > > your pc requires non free firmware, go grab one of those images > > > It is a notebook PC without RJ45 port and I have fear that I unable to > set Wi-Fi connection... > So, to use the netinstall image is not possible in this situation I think. You can use the firmware-enabled netinst image: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/amd64/iso-cd/firmware-11.5.0-amd64-netinst.iso Samuel
Re: Debian and Orca installation Question
Hi, 2022-10-29 22:46 GMT+02:00, Samuel Thibault : > Hello, > > Egon, le sam. 29 oct. 2022 20:03:33 +0200, a ecrit: >> better if I install it from "debian-11.5.0-amd64-DVD-1.iso" image? > > When installing from that image, I do get Orca starting automatically. > What can I do if both Orca and Speakup starts automatically? I think Speakup starts when a person choose a "Speech support" install option. Best regards: Egon
Re: Debian and Orca installation Question
Egon, le sam. 29 oct. 2022 20:03:33 +0200, a ecrit: > How can I install the system to avoid these problems? > Can I install the system from "debian-live-11.3.0-amd64-mate.iso" It seems that the debian live images have dropped the bits that make orca auto-started. Samuel
Re: Debian and Orca installation Question
Hello, Egon, le sam. 29 oct. 2022 20:03:33 +0200, a ecrit: > better if I install it from "debian-11.5.0-amd64-DVD-1.iso" image? When installing from that image, I do get Orca starting automatically. Samuel
Re: Debian and Orca installation Question
Hi, 2022-10-29 20:07 GMT+02:00, Jordan Livesey : > just use the netinstall iso files, they give you a minimal mate desktop > with gimp and libreoffice but everything else you are free to use and > customise in turms of what else you want, plus, orca comes as standard, if > your pc requires non free firmware, go grab one of those images > It is a notebook PC without RJ45 port and I have fear that I unable to set Wi-Fi connection... So, to use the netinstall image is not possible in this situation I think. Best regards: Egon
Re: Debian and Orca installation Question
just use the netinstall iso files, they give you a minimal mate desktop with gimp and libreoffice but everything else you are free to use and customise in turms of what else you want, plus, orca comes as standard, if your pc requires non free firmware, go grab one of those images On Sat, Oct 29, 2022 at 7:03 PM Egon wrote: > Hi All, > > How can I install Debian without "auto start of Orca" problem? > I installed Debian with "Speech support" option from the actual Debian > standard first DVD many years ago. > I installed the Mate desktop environment. > Orca did not start automatically but the console-based speaking software > did. > > How can I install the system to avoid these problems? > Can I install the system from "debian-live-11.3.0-amd64-mate.iso" or > better if I install it from "debian-11.5.0-amd64-DVD-1.iso" image? > > Best regards: Egon > >
Debian and Orca installation Question
Hi All, How can I install Debian without "auto start of Orca" problem? I installed Debian with "Speech support" option from the actual Debian standard first DVD many years ago. I installed the Mate desktop environment. Orca did not start automatically but the console-based speaking software did. How can I install the system to avoid these problems? Can I install the system from "debian-live-11.3.0-amd64-mate.iso" or better if I install it from "debian-11.5.0-amd64-DVD-1.iso" image? Best regards: Egon
Re: webkit and the orca screen reader
I remember trying out conqueror once which is based on webkit but being kkde plasma, it doesn't work with orca On Wed, Oct 26, 2022 at 3:02 PM Jordan Livesey wrote: > > > On Wed, Oct 26, 2022 at 2:29 PM john doe wrote: > >> On 10/26/22 13:14, Jordan Livesey wrote: >> > hello everyone, due to google chrome having issues with orca, or any >> > chromium based browser for that matter, where orca is reading lines >> >> Can you expend on the issue(s) you are having? >> >> > regardless of your orca settings, I have decided to try a webkit based >> > browser if any are for linux >> >> Google is your friend. >> >> > , how accessible is webkit with orca? >> > >> >> I would say give it a go, what will be good enough for me might not be >> for you! >> >> -- >> John Doe >> >>
Re: webkit and the orca screen reader
On Wed, Oct 26, 2022 at 2:29 PM john doe wrote: > On 10/26/22 13:14, Jordan Livesey wrote: > > hello everyone, due to google chrome having issues with orca, or any > > chromium based browser for that matter, where orca is reading lines > > Can you expend on the issue(s) you are having? > > > regardless of your orca settings, I have decided to try a webkit based > > browser if any are for linux > > Google is your friend. > > > , how accessible is webkit with orca? > > > > I would say give it a go, what will be good enough for me might not be > for you! > > -- > John Doe > >
Re: webkit and the orca screen reader
On 10/26/22 13:14, Jordan Livesey wrote: hello everyone, due to google chrome having issues with orca, or any chromium based browser for that matter, where orca is reading lines Can you expend on the issue(s) you are having? regardless of your orca settings, I have decided to try a webkit based browser if any are for linux Google is your friend. , how accessible is webkit with orca? I would say give it a go, what will be good enough for me might not be for you! -- John Doe
webkit and the orca screen reader
hello everyone, due to google chrome having issues with orca, or any chromium based browser for that matter, where orca is reading lines regardless of your orca settings, I have decided to try a webkit based browser if any are for linux, how accessible is webkit with orca?
Re: what's new in orca 43.0
I thought tesseract ocr would work but how would that be implemented with orca. is tesseract ocr even in bookworm? On Tue, Oct 18, 2022 at 4:20 PM chrys wrote: > Howdy Jordan, > > // I want to see this screen reader get lots of other new future > releases where you have ocr support and finally > when you feel confident you can try my plugin driven refactoring of > orca. its still a WIP but woks quite well. i created an simple OCR > plugin there for testing > https://www.patreon.com/posts/ocr-plugin-62328158 > > or you might want to give a shot to OCRdesktop 4, a stand alone > applications to analyse applications (and files) using OCR: > https://www.patreon.com/posts/ocrdesktop-4-0-62003474 > > cheers chrys > > Am 18.10.22 um 15:29 schrieb Jordan Livesey: > > hello folks, decided to install debian testing, which is the only > > version of debian I can actually get working on my computer. in doing > > so I am now running the latest orca, are there any new improvements I > > should > > be aware of? I want to see this screen reader get lots of other new > > future releases where you have ocr support and finally support for > > calamares, don't get me wrong, love the text based installer but it > > would be good to have calameres be accessible then those will > > eventually be upstream > > >
Re: what's new in orca 43.0
Howdy Jordan, // I want to see this screen reader get lots of other new future releases where you have ocr support and finally when you feel confident you can try my plugin driven refactoring of orca. its still a WIP but woks quite well. i created an simple OCR plugin there for testing https://www.patreon.com/posts/ocr-plugin-62328158 or you might want to give a shot to OCRdesktop 4, a stand alone applications to analyse applications (and files) using OCR: https://www.patreon.com/posts/ocrdesktop-4-0-62003474 cheers chrys Am 18.10.22 um 15:29 schrieb Jordan Livesey: hello folks, decided to install debian testing, which is the only version of debian I can actually get working on my computer. in doing so I am now running the latest orca, are there any new improvements I should be aware of? I want to see this screen reader get lots of other new future releases where you have ocr support and finally support for calamares, don't get me wrong, love the text based installer but it would be good to have calameres be accessible then those will eventually be upstream
what's new in orca 43.0
hello folks, decided to install debian testing, which is the only version of debian I can actually get working on my computer. in doing so I am now running the latest orca, are there any new improvements I should be aware of? I want to see this screen reader get lots of other new future releases where you have ocr support and finally support for calamares, don't get me wrong, love the text based installer but it would be good to have calameres be accessible then those will eventually be upstream
Re: Videocall hearing the voice of Orca
On 9/9/22 03:15, john doe wrote: I'm already doing that but it's a micro/headphone combo, so that might be the issue. Trying different headphones might be worthwhile. So far as I know, this is not a Linux-specific issue, so you probably aren't in a worse position than users of other operating system. I know that doesn't help much. Another possibility might be the echo cancellation module of Pipewire.
Re: Videocall hearing the voice of Orca
Answering publicly to this e-mail. On 9/7/2022 4:01 PM, Frank Carmickle wrote: How can I ensure that I'm the only one that will hear Orca and prevent other persons in the call from hearing it? If you are listening to Orca in headphones and you are still having this issue, you may have the output of the sound device captured in some way. I'm already doing that but it's a micro/headphone combo, so that might be the issue. For now the workaround is to not use the computer while I'm talking! Thanks all for the feedback. -- John Doe
Re: Videocall hearing the voice of Orca
On 7/9/22 04:45, john doe wrote: How can I ensure that I'm the only one that will hear Orca and prevent other persons in the call from hearing it? I turn speech off during online meetings and use only the braille display. This eliminates the problem you describe. More importantly, it frees my hearing to listen exclusively to the meeting participants.
Re: Videocall hearing the voice of Orca
I wonder then if a throat microphone would help. That is a microphone that rests on your larynx. Glenn - Original Message - From: "Sam Hartman" To: "Debian Accessibility Team" Sent: Thursday, September 08, 2022 12:34 PM Subject: Re: Videocall hearing the voice of Orca >>>>> "john" == john doe writes: john> Hello all, I use Orca to do some videocalling, the issue that john> I'm having is that voice of Orca is also audible at the other john> end. john> How can I ensure that I'm the only one that will hear Orca and john> prevent other persons in the call from hearing it? Use a bluetooth headset withd pipewire. I find Pulse's bluetooth support is not good enough for quality calls. Alternatively use a USB headset with either Pulse or Pipewire. The point is that you don't want your microphone to be able to pick up audio from your screen readers.
