Hello braillers!
BRLTTY has some support for working with AT-SPI2 applications, mostly their
terminal widgets. I would like to see some enhancements in this area for the
following reasons:
Firstly, X windows terminal emulators are in many ways better than the Linux
console (and worse in many othe
Hi, and thank you for the quick reply!
Samuel Thibault writes:
> Aura Kelloniemi, le Fri 28 Aug 2015 23:55:53 +0300, a écrit :
>> - BRLTTY does not correctly detect the terminal size (it tries to guess it by
>> examining line lengths, but this fails). Because of this the curs
Hello
I have tried hacking with brltty and I noticed that in the current git head
version the Freedom Scientific driver is broken.
Symptoms: BRLTTY no more recognizes the Gdf and Wheel key names on Focus Blue
(referred to as small model in BRLTTY sources).
Reason:
In brltty/Drivers/Braille/Freed
Hello
Samuel Thibault writes:
> Aura Kelloniemi, le Sat 29 Aug 2015 01:14:43 +0300, a écrit :
>> >> - Sometimes BRLTTY shows incorrect text (text that has already disappeared
>> >> from the visual window)
>>
>> > That may be bugs in the term
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/08/30 at 22:10 +0300]
>>I have tried hacking with brltty and I noticed that in the current git head
>>version the Freedom Scientific driver is broken.
>>
>>Symptoms: BRLTTY no more recognizes the Gdf a
Samuel Thibault writes:
> Samuel Thibault, le Sun 13 Sep 2015 16:10:48 +0200, a écrit :
>> Aura Kelloniemi, le Sun 30 Aug 2015 23:40:03 +0300, a écrit :
>> > Orca still notices cursor movement and the
>> > added characters, so the problem must be in BRLTTY.
[--
Klaus-Peter Wegge writes:
> Hello,
> with my update to debian 8 I also updated from brltty3.8 to 5.2.
> Now I'm approaching the following problem when using alpine2.11:
> When reading a mail by moving the braille window around
> the braille window jumps back to the current cursor position a
Hello
Dave Mielke writes:
> Right now, the handler that processes a screen update alert is scheduled to
> execute immediately. My theory is that it might be better to schedule it to
> occur a few milliseconds later.
I tried the git head. My expert test bench looked like this:
Test #1: emac
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/09/14 at 19:57 +0300]
>>I think that the problem with Dave's attempt to fix this problem was that
>>screen updates just take a longer time than what was suspected. However, for
>>top for example,
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/09/14 at 21:56 +0300]
>>So, here are the new results. Now I tested with emacs with up to four windows
>>all updating the mode line continuously. I also tested with elinks which also
>>has a "clo
Samuel Thibault writes:
> Aura Kelloniemi, on Fri 28 Aug 2015 23:55:53 +0300, wrote:
>> - There's no blinking cursor, or there is a double cursor (this is due to a
>> bug in brlapi - cursor never blinks in brlapi applications)
> This should be fixed in git.
It is fix
Hi
I use BRLTTY on a virtual terminal which is very wide (200 characters). There
are two types of commands which would be very useful for me and I wish they
could be added.
The first is aset of commands which move the window to a different line, and
then move it to the leftmost edge of the termin
Hello
BRLTTY nowadays displays colour names incorrectly with the Describe Character
command. This has been the case for a long time, I just haven't reported it.
This is probably due to some changes in Linux's console infrastructure, and
may have been introduced with frame buffers. It may be that c
Samuel Thibault writes:
> We do prefer to have the brlapi driver pass the cursor position to the
> second brltty, for displays which can show it.
OK. BRLTTY's BrlAPI driver should then ask to not show the cursor in menus,
messages, info mode, etc. Now if I invoke the Describe Character command
Hello
I reported four bugs to VTE. The links are here:
https://bugzilla.gnome.org/show_bug.cgi?id=758172
https://bugzilla.gnome.org/show_bug.cgi?id=758176
https://bugzilla.gnome.org/show_bug.cgi?id=758177
https://bugzilla.gnome.org/show_bug.cgi?id=758178
--
Aura
_
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/11/16 at 14:09 +0200]
>>OK. BRLTTY's BrlAPI driver should then ask to not show the cursor in menus,
>>messages, info mode, etc. Now if I invoke the Describe Character command I
>>still see the cursor in
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/11/16 at 19:35 +0200]
>>but preferences still show it.
> Yes. That's because the Preferences Menu is displayed in a virtual screen
> that
> supports full navigation. For example, the HOME func
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/11/13 at 11:26 +0200]
>>BRLTTY nowadays displays colour names incorrectly with the Describe Character
>>command.
> Could you please test this with the latest code to see if it's been resolved?
It seems
Samuel Thibault writes:
> Samuel Thibault, on Tue 17 Nov 2015 10:07:37 +0100, wrote:
>> Aura Kelloniemi, on Tue 17 Nov 2015 10:23:33 +0200, wrote:
>> > I could not get the blink attribute working on Linux console.
>> > Traditionally it
>> > changed the ba
Samuel Thibault writes:
> Mario Lang, on Tue 17 Nov 2015 22:11:15 +0100, wrote:
>> When we originally planned to do it via SHM, D-Bus was not around.
>> Is SHM still the best option?
[--]
>> The libraries are a convenience, but it is perfectly
>> possible to code a standalone AT-SPI client just
Dave Mielke writes:
> [quoted lines by adr...@pa0rda.nl on 2015/12/16 at 10:17 +0100]
>>I installed brltty 5.3 yesterday. Today I installed a new kernel on
>>CentOS and after rebooting I get:
>>Can't get console state
I have the same problem. I'm running BRLTTY git head from yesterday on "Linu
Dave Mielke writes:
> Would those of you who've had the "can't get console state" problem please
> update to the latest code to see if it's been resolved.
Tried it, now it says: no screen. I checked very quickly, but found no errors
in log.
--
Aura
__
Dave Mielke writes:
> [quoted lines by Aura Kelloniemi on 2015/12/17 at 08:31 +0200]
>>Tried it, now it says: no screen. I checked very quickly, but found no errors
>>in log.
> The message "no screen" means that the screen driver isn't running. Maybe
> i
Dave Mielke writes:
> [quoted lines by Nicolas Pitre on 2015/12/17 at 13:29 -0500]
>>That calls for another official release I'd say.
> Yes, it certainly does. I still need Aura to confirm the fix too, though.
It works now, thank you!
--
Aura
___
Hello!
Dave Mielke writes:
> [quoted lines by Samuel Thibault on 2016/02/09 at 01:21 +0100]
> >Perhaps a rule of thumb would be to take the character which has the
> >lowest unicode value.
> :-) That's our current problem. 0X00 < 0X20
I would have preferred modifying the braille table of OP
Hello
In the current git version from today, I have the following problems:
1. Commands bound to long key presses don't work in BrlAPI; they just don't
get triggered.
2. When I run brltty with the AtSpi2 screen driver, it does not show anythhing
on the display. The screen driver does not seem to
Samuel Thibault writes:
> Aura Kelloniemi, on Tue 17 May 2016 15:25:43 +0300, wrote:
> > 1. Commands bound to long key presses don't work in BrlAPI; they just don't
> > get triggered.
> I have to say I don't know what these are.
Long key presses of a
Y git head and then report back
here.
Aura Kelloniemi writes:
> Samuel Thibault writes:
> > Aura Kelloniemi, on Tue 17 May 2016 15:25:43 +0300, wrote:
> > > 2. When I run brltty with the AtSpi2 screen driver, it does not show
> anythhing
> > > on the dis
28 matches
Mail list logo
