Re: [BRLTTY] OT: Talksback not announcing callers on Android
Dear Henk, Many thanks for your response! > The appropriate mailing list to post this would be: > eyes-f...@googlegroups.com Yeah, I discovered that other list and posted there, thanks a lot. > The short answeris that this feature was removed, because it didn’t > work on all devices. Okay. May I ask how you got to know this? Because nobody could respond to this question on the eyes-free list and I was not able to find any release notes or change log documenting that point. > Since it worked perfectly on Google’s own devices, I think the > decision was rather odd at least. I agree. Especially given that third party applications manage to provide the feature, I don't see any reason why it wouldn't be possible for TalkBack to do it in a portable way. > Your friend could try an app like shouter. Okay, that's the app suggested on Eyes-Free, too, so I passed on the suggestion, thanks a lot. Best wishes, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] autospeak=yes and using BRLTTY without braille display
Sebastian Humenda (2017/01/19 14:35 +0100): > >One thing I'd find useful here would be to have command-line options to > >enter help-screen, preferences menu and command-learn mode as soon as > >brltty is started. > Yes, or a command from the command line to tell the currently running BRLTTY > that the learn mode was requested. Might be a bit more involved to implement, but still doable with BrlAPI. By the way: in brltty's Programs directory there is the apitest porgram which lets you use Learn Mode from the command-line. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] NVDA with Alva Delphi on Windows 10 x64
J.G (2017/03/29 20:48 +0200): > Hi, > > use brltty 5.2(1). newer versions of brltty are getting creshed with > nvda. Do we know why? It would be good to debug this. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] NVDA with Alva Delphi on Windows 10 x64
Samuel Thibault (2017/03/29 22:56 +0200): > We can build the brlapi bindings for python2 too (we do this in debian > for instance). If it's the only missing bit it would indeed be great to fill the gap! Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Testing on Windows
Hi Felix, Felix Grützmacher - Handy Tech Elektronik GmbH (2017/04/05 09:21 +0200): > Hello, > > just to be sure: after installing, what would I need to do to make BRLTTY > Braille within a console window that I launch? I think you need to run brltty with the appropriate (Windows) screen driver. On the command-line that would be option -x wn I think. There should be a screen-driver configuration directive, too. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Making freeze screen be per virtual console.
Dear all, Dave Mielke (2017/04/19 04:00 -0400): > Hi: > > One of the pending feature requests is to make freezing the screen be per > virtual console instead of a global operation. I myself think it's a good > idea, > but I thought I'd ask in case anyone can think of a reason why it > mightn't be. Just in case some of us would prefer the current behaviour, perhaps it would be possible to make this a preference. Thanks! Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Hi Mario, Beware, you used the old address for the list. The new address is brltty@brltty.com Mario Lang (2017/07/23 00:12 +0200): > Hi. > > Does anyone know if Raw keycode mode of BrlAPI does still work? Here, > calling brlapi__readKey after brlapi__enterTtyMode with "HandyTech" as > the driver string seems to block forever, while "" as driver string > gives me command keys as expected. Did it work in the past or is that your first attempt with this driver? > I know the number of users of raw > mode might be near to nothing, so I am sort of guessing it might have > been broken somewhere in the past? Actually, it seems the HandyTech driver does not support delivering raw key codes yet. It should define the BRL_HAVE_KEY_CODES macro and implement the brl_readKey and brl_keyToCommand methods. What I find strange, though, is that you do not get a proper error from BrlAPI. Normally, if you try to enter in raw keycode mode with a driver that does not support it, you should get an oeration not supported error, I think. > Also, now that we have symbolic key names, I wonder, is there any > possibility to create some sort of "hybrid" raw mode for BrlAPI, which > would return key names and press/release status? Samuel and I should probably think about it, indeed. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Hi,
Mario Lang (2017/07/23 11:54 +0200):
> Oh!!! Thanks for reminding me. Indeed, now it dawns on me that there
> is this driver-specific translation mechanism... This sort of got lost
> in the noise (for me) since we have introducted key tables. I guess I
> need to see if the HandyTech driver can be extended with these
> translation functions.
Yes. I expect this to be not too hard because the code that converts
keycodes to commands is already there somehow, more or less explicitly.
So, in my experience, such a change mostly consists in factorizing the
driver code and making it cleaner.
> > What I find strange, though, is that you do not get a proper error from
> > BrlAPI. Normally, if you try to enter in raw keycode mode with a driver
> > that does not support it, you should get an oeration not supported
> > error, I think.
>
> I just checked, and no, I didn't miss error handling:
>
> BrlAPI::TTY BrlAPI::Connection::tty(int TTY, bool Raw) {
> auto Number = brlapi__enterTtyMode(BrlAPI->handle(), TTY, Raw?
> "HandyTech" : "");
Unrelated note: I would rather not use "Raw" as the name of the boolean
parameter because this can be confusing in the context of BrlAPI. Raw is
indeed used to mean a mode where you get packets directly from the
driver, so you are at a lower level than when you receive keycodes. So
I'd rather call this argument keyCodes or something like that. Just to
improve clarity, that would indeed change nothing to the behaviour of
the code, of course.
> if (Number == -1) throw std::system_error(brlapi_errno,
> std::generic_category());
> return { this, Number };
> }
With this code, will you get proper BrlAPI error messages?
In other words, does your code call brlapi_strerror or the like
somewhere?
> It reports an error (no device or address) if I pass an invalid driver
> name string. Maybe it should report a similar error if the driver
> string is correct, but the driver doesn't have the translation
> functions?
That is indeed what is supposed to happen, see the isKeyCapable function
in Programs/api_servec.c.
I have to say, though, I do not understand how the code is actually
supposed to work for now. First? I don't understand why the previously
mentionned funciton refers to the disp variable. Second, I was not able
to find the code that performs the delivery of key codes.
Mario, if you feel like experimenting, you could comment what appears
after the or in the isKeyCapable function and then my guess is that you
should get a proper error when trying to enter in tty mode.
> >> Also, now that we have symbolic key names, I wonder, is there any
> >> possibility to create some sort of "hybrid" raw mode for BrlAPI, which
> >> would return key names and press/release status?
> >
> > Samuel and I should probably think about it, indeed.
>
> Please do. I have an actual use case herre, which I'd like to implement
> in the upcoming months. I'd like to build a musical instrument (a
> control voltage sequencer) out of a Braille display as main (and only)
> interface. For
> that, having to deal with BRLTTY commands is not very convenient since
> what I am building is not a screen reader, rather, it is a native
> braille based hardware/software sequencer. Here is a repository
> already, but it only contains binding code for now. Maybe another
> result of this will be modern C++ BrlAPI bindings:
> https://github.com/mlang/brlcv
Just to be sure. Assuming the current code is made to work correctly,
why wouldn't you be able to implement your tool with the code in its
present state? Why do you need symbolic key names for that?
In keycodes mode, the driver and the client program simply have to agree
on the meaning of the numbers and then they can exchange pretty much
whatever they like.
Cheers,
Shérab.
___
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.com
For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Hi, Mario Lang (2017/07/24 00:30 +0200): > Grepping for brl_keyToCommand and brl_readKey, I only find the Visio and > TTY drivers to have such a function. Seems my original feeling is true, > though for > different reasons: raw keycode mode isn't supported by a majority of the > drivers. Well, in the "isKeyCapable" function, there is this bit of code: ... || (disp && disp->keyNames!=NULL So I'm not sure, perhaps something has been implemented based on keyNames, I can't remember and was not able to find anything in the code. > So it isn't really about just HandyTech, rather, the question > seems to be: do we still care for this feature? The idea that was behind it initially was to allow one to write device-specific software, e.g. re-implement under Linux manufacturer-provided software one was used to under DOS/Windows. > If so, should we make an effort to convert our drivers to support it? I'd say yes, it's worth the effort, both for the feature and for what it brings in terms of code improvement. > Or is there a better way, now that we have key name tables? I don't know. > std::error_code, which is what is being used under the hood here, allows > to pass low level error codes around. And yes, indeed, this *will* > allow for proper BrlAPI error messages. For now, I am just pretending > brlapi_errno contains standard errno values. Okay. But you know that is not actually true, I guess. > Once I get to it, it is > just a matter of implementing a BrlAPI::ErrorCategory and using it inside > of the throw instead of generic_category, and the exception message will > automatically contain the proper error message, and can also still be > handled programatically. Good. > > In other words, does your code call brlapi_strerror or the like > > somewhere? > > Not yet, but everything in place to do that soon. Good, again. > > Just to be sure. Assuming the current code is made to work correctly, > > why wouldn't you be able to implement your tool with the code in its > > present state? Why do you need symbolic key names for that? > > I would be able to do what I want with raw keycodes as well. But not > needing to duplicate keycode decoding logic for every supported model in > the client would be convenient. Symbolic was probably misleading. > While a function to retrieve the actual key name from the driver would > probably be a nice to have, what I am actually thinking about is an > interface to how most drivers tell the core that a key was pressed or > released these days. Take the following example statement from the > HandyTech driver as an example: > > return enqueueKeyEvent(brl, HT_GRP_RoutingKeys, byte - HT_KEY_ROUTING, > !release); > > There is a key group, an actual key value, and the press/release status. > As the example nicely shows, the decoding of keycodes basically > happens before enqueueKeyEvent is finally called. It are these, still > untranslated to commands, but already logically decoded key events that > I am interested in as a BrlAPI client. If backwards compatibility is an > issue, just go for a new name like brlapi__readKeyEvent. But since we > have the information on that level inside of the core since the key name > table rewrite, I think we should make it possible for BrlAPI clients to > make use of it. Since all drivers that have been rewritten to use key > tables should actually call enqueueKeyEvent at some point, passing key > events to BrlAPI clients should also not need any driver change. > Contrary to enabling old keycode mode, which I don't really know how to > fit into the new callback way. Okay, I get your point. Will talk about it with Samuel. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Mario Lang (2017/07/27 16:40 +0200): > In fact, I know the core doesn't pass the keypresses on because some of > the keys result in BRLTTY playing a sound, as if it were trying to read > a screen. Maybe the detection logic for brl_keyToCommand() is the > problem? Or something else? See the brlapi_acceptKeyRange function & co. You may need to let BrlAPI know which keys your application is interested in. I thought in "raw keycode" mode all the keys would be passed to the client by defautl but it may not be the case. hth, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] problem with brltty and polkit
Dear Kelly, Kelly Prescott (2017/04/27 15:50 -0500): > I am running brltty on archlinux. > Text mode works fine, but brlapi which orca needs does not appear to work > anymore. > It worked in 5.4. > When I start the daemon I get: > > --log-- > Apr 27 15:15:14 io.coolip.net brltty[383]: BrlAPI Server: release 0.6.6 > Apr 27 15:15:14 io.coolip.net brltty[383]: unknown > authentication/authorization method: polkit > Apr 27 15:15:14 io.coolip.net brltty[383]: Unable to start auth server > --endlog-- > I have the file org.a11y.brlapi.policy in /usr/share/polkit1/actions > When I manually build the package, I can see that polkit support appears to > be included as the config.log says it is. But then, is it the brltty you have just built that you are running, or another one? If it is the one you have just built and if, once it is run it can't find polkit while configure seemed happy, could it be that the polkit daemon has not been started on your system? > Any suggestions about how to fix this would be helpful. I know nothing about polkit unfortunately so I can't help much more with this. Another route you could try is using a different authentication method. For instance, you could run brltty with arguments -A auth=none to disable authentication completely. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] cannot compile git on one of my systems
Hi, John Covici (2017/08/09 07:32 -0400): > Hi. I am having problems compiling on one of my systems using git. I > want to put this on a cd which I am generating, so thesystem is a bit > different. > > What I get is that reldeps.mk is missing and so the make stops. > > Thanks in advance for any suggestions. Did you run autogen from brltty's root source directory? If you did, please describe more precisely what you are doing from git clone onwards. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] adding custom command to replace a braille window
Dear Vikash, Vikash Kesharwani (2017/05/21 09:08 +0530): > I am working on a braille display, where we can support contracted input. > So , since brltty does not support that, we decided to take user input in a > temporary buffer, translate it and send it to brltty. Obviously this is > very complex thing to implement, but I just want help on this issue I am > facing. OK, got it, thanks for clarifying. In the long run, I think uncontracting should really not be done inside of a braille driver because it is not a driver-specific thing. Now if it is only for tests, cou might be able to do it in readCommand as you propose but that looks as a lot of work, too. If it is only for testing purposes, you could also write a BrlAPI client that reads the keypresses and interprets them with the help of liblouis. Of course the uncontracting feature would then be available only in this client but it may be enough for testing. hth, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] adding custom command to replace a braille window
Dear Vikash, I'll leave the details to somebody else, perhaps Dave himself. What exactly are you trying to do? Why do you need to replace a window with another one? Could you perhaps give an example of a context where the thing you are trying to do would be useful? Cheers, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] htdoc
Hi Jean-Philippe, Do we have the file transfer protocol somewhere? Or do we have Halim Sajin's work somewhere? I may be able to help. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Using lynx with braille display
Hi, Vikash Kesharwani (2017/05/31 18:24 +0530): > Hi I am trying to use lynx with braille display, When I open a page it > jumps to the first link directly, skipping all the text content before it. > How do I read all those text(how do I know there are text before the > cursor). If you don't like the cursor being on the first link you can disable this behaviour I think. To see the text before the first link, I'd suggest to start reading from the top of the screen and paying attention to the page number. If it is 1 you know you are at the beginning of the page, if it is greater than 1 you know you are not. You can press the Home key in any case to make sure you are at the beginning of the page and then start reading from the top of the screen. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Crash when sending char é
Hi, YOu may try to compile the client proram with -O0 -g to enable debugging. Then before running the program make sure core dumps are enabled with the following shell command: ulimit -c unlimited Then run the program, this should create a "core" file that you can then use with gdb like this: gdb program-executable core Then in gdb the bt command should show you where exactly the crash occurred. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Dave Mielke (2017/08/23 22:36 -0400): > [quoted lines by Dave Mielke on 2017/08/23 at 17:33 -0400] > > [quoted lines by Shérab on 2017/08/23 at 22:08 +0200] > > >Couldn't we imagine that the clients define command groups and commands by > >specifying their names and numerical values and then there could be > >tables similar to the core ones mapping braille keys to these > >client-defined commands? > > Each client specifies which key ranges it'll handle. Those key ranges are for > values derived from key table processing. In other words, key table > processing > occurs before determining which client should get any given key code, so key > table processing is common to all clients. Perhaps I'm missing something, > but, > to me, that gets in the way of clients defining their own commands. Indeed. That's why I suggested to provide the keybindigns processing code as a library. That way this could be done by each client and the code would still be shared. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Hi, Mario Lang (2017/08/24 16:54 +0200): > I think we already have something like that, a predefined set of > commands. The problem is, that we can not predict what a BrlAPI client > actually wants to do. So we can make some assumptions about how a > graphical screen reader works, but this will likely always be limiting > to some types of clients (that might not even be written yet). Fully agreed. > Also, I am wondering how clients are going to implement their own > bindings. > JAWS for instance has an interactive key binding editor which is very > nice for users. You can define a new binding for a screen reader command by > simply pressing the desired key combination interactively. > I am suspecting that some BrlAPI clients would like to do something > similar at some point. Especially if the set of screen reader commands > grows. Some of these commands might not be bound by default to > anything, waiting for the user to customize a binding if they really need the > command. > > If I haven't overlooked something, to me, what is missing is a way > for the client to query the actual model the driver has > detected. With that, a client could implement their own key code > handling, because they actually would know what they can expect from a > readKey call. This is something which is supposed to be provided by the BrlAPI properties, once they will be implemented. > The client would still need to do their own key code > handling, which seems fine to me if what is desired is more control. To make this easier and to warranty as much coherence with the core's way of handling the bindings, would it make sense to build the code in charge of this as a library that the clients could link to and use? > Exporing our knowledge of how certain NavigationKeys are named could > also help the client to avoid duplicating too much stuff. I believe that this could be a side-effect of having the library previously suggested. > In any case, if we proceed with an attempt to generalize for graphical > screen readers, we really should talk to Orca dev what they actually > would want to have. They might have some insights that we haven't > thought about yet. I am fully convinced it will be beneficial to talk to Orca developers. In particular, I always have the impression that Orca, like Jaws, Window-Eyes and VoiceOver are speech-centric screen review system while brltty is, in my opinon, braille-cedntric. By this, I mean that the features offered by the screen reviewing system, brltty excepted, seem much reacher to me when it comes to speech than when it comes to braille. Also, I believe that these systems have been developed with speech in mind and that braille support has been incorporated to them only afterwards, at east that is my impression. As an example, I am pretty sure these tools can be used quite easily with speech only. But I believe one could not use them with only braille turned on, or at least it would not be as comfortable to use as the pure speech way. Do you guys share this vision of things? In that case I think talking to Orca developers becomes even more important. We would also need to think about how we, braille fans, would like to access a graphical desktop with braille only. Comments warmly welcome. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Dave Mielke (2017/08/24 17:58 -0400): > The model is effectively exported by the driver via brl->keyBindings, which > is > the name of the key table. In the case where a user defines a personal braille table, because he wants to redefine a few bindings in a way he prefers, what is it that is going to be exported? Is it the name of this personal braille table, or is it still the name of a table from which the model can easily be inferred? Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] HumanWare Brailliant BI14
Dear Vincent, I am using HumanWare's Brailliant BI 40 intensively and it works totally with brltty. I don't know since which version, but it does work. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Issue in panning to next page in lynx
Dear Vikash, > Hi I am using lynx with brltty. When I open a webpage I go to top left and > then read the webpage window by window. But how do I know that I have > reached the end of the page so that I can go to next page or go to previous > page. I think if you use lynx a bit you will figure it out quite naturally. At the top of the page there is its title which is centered, while at the bottom of the page lynx has a status line which is typical and easily recognizable. > Also Is there any way to have this information available in in a Braille > Driver? No. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Aura Kelloniemi (2017/07/31 01:25 +0300): > Hello list, > > Shérab <sebastien.hinde...@ens-lyon.org> writes: > > Mario Lang (2017/07/24 00:30 +0200): > > > I would be able to do what I want with raw keycodes as well. But not > > > needing to duplicate keycode decoding logic for every supported model in > > > the client would be convenient. Symbolic was probably misleading. > > > While a function to retrieve the actual key name from the driver would > > > probably be a nice to have, what I am actually thinking about is an > > > interface to how most drivers tell the core that a key was pressed or > > > released these days. Take the following example statement from the > > > HandyTech driver as an example: > > > > > > return enqueueKeyEvent(brl, HT_GRP_RoutingKeys, byte - > HT_KEY_ROUTING, !release); > > > > > > There is a key group, an actual key value, and the press/release status. > > > As the example nicely shows, the decoding of keycodes basically > > > happens before enqueueKeyEvent is finally called. It are these, still > > > untranslated to commands, but already logically decoded key events that > > > I am interested in as a BrlAPI client. If backwards compatibility is an > > > issue, just go for a new name like brlapi__readKeyEvent. But since we > > > have the information on that level inside of the core since the key name > > > table rewrite, I think we should make it possible for BrlAPI clients to > > > make use of it. Since all drivers that have been rewritten to use key > > > tables should actually call enqueueKeyEvent at some point, passing key > > > events to BrlAPI clients should also not need any driver change. > > > Contrary to enabling old keycode mode, which I don't really know how to > > > fit into the new callback way. > > > Okay, I get your point. Will talk about it with Samuel. > > I also need this feature, please consider implementing it. > > My experience with BrlAPI suggests that the current interface based on BRLTTY > commands is useful if and only if one's application is very similar to BRLTTY > itself. However, I don't know of a single application that uses BrlAPI and is > very similar to BRLTTY. Orca for instance. > Most applications don't have use for most of the > commands understood by BRLTTY, but instead would benefit from their own > command set in order to make the braille display interface as intuitive as > possible. I share Samuel's fear that is will be difficult to design something which is generic enough. What can we do beyond returning the keycodes themselves or brltty commands, as we currently do? > What I have wanted to implement for a long time is an interface to the text > editor Emacs (yes, I hear you saying that it is accessible already - you are > right, but read on). Emacs can be made much easier to use by allowing the user > to do basic editing with their braille display such that they don't need to > move their hands to the computer keyboard in order to copy/paste, to activate > buttons, to switch buffers and windows, etc. A special braille interface to > Emacs could also communicate to the user about different Faces used by Emacs > (by using special marker dots or symbols as configured by the user) - and it > would allow the user to use their braille display's routing keys in a similar > fashion a sighted person would use a mouse. Note also that Emacs is not > accessible to BRLTTY users when it is run in an X Windows mode (which is very > useful for having full keyboard input support in Emacs). I find all this very interesting. I am pretty sure a lot of research and experimenting remains to be done regarding the way to most effectively use a braille terminal. > I would like the keys to be categorized in a simple fashion. It would be ideal > if BrlAPI could return (in addition to the key press status) the name of the > key (as defined by the display manufacturer) plus the category > information. I think the key code as returned now does reflect all this, at least as faithfully as brltty does in its braille tables, no? Perhaps there is some decoding to do which we could make easier, but I think the information is pretty much there already. > A function that would return a list of all the keys on the braille display > (along with their category information) would be of use to applications which > allow the BrlAPI input interface to eb configured inside the app. I don't know > though if it is possible to write this kind of a function such that it would > provide accurate information. Couldn't the client get this by parsing the keytable for the device? Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] BrlAPI Raw key code mode?
Hi Aura, Aura Kelloniemi (2017/09/01 08:01 +0300): > Samuel Thibault <samuel.thiba...@ens-lyon.org> writes: > > > Dave Mielke, on ven. 25 août 2017 17:27:45 -0400, wrote: > > > [quoted lines by Shérab on 2017/08/25 at 22:47 +0200] > > > > > > >> Each client specifies which key ranges it'll handle. Those key ranges > are for > > > >> values derived from key table processing. In other words, key table > processing > > > >> occurs before determining which client should get any given key code, > so key > > > >> table processing is common to all clients. Perhaps I'm missing > something, but, > > > >> to me, that gets in the way of clients defining their own commands. > > > > > > > >Indeed. That's why I suggested to provide the keybindigns processing > > > >code as a library. That way this could be done by each client and the > > > >code would still be shared. > > > > > > I don't see how that'd work. If a client specifies raw key codes then it > gets > > > everything. That only allows for one client at a time. It also doesn't > allow > > > for xbrlapi to be running in order to handle input. > > > AIUI, an application which would use a different binding than the brltty > > commands would have to be responsible. I.e. if it only supports a set of > > key events, it should only request the brltty daemon to send these, and > > let the daemon send others to other clients, if any, such as xbrlapi. > > I would prefer the interface to be such that BRLTTY sends the raw key codes > (or commands, or maybe even both) to a client. Then the client responds to > BRLTTY whether it actually consumed the key or not so that BRLTTY can pass the > same code to another client. For a key which is not consumed by the client, that may make its processing very slow, even from a user experience perspective, IMO. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Braille display hardware recommendations
Jason White (2017/10/09 23:54 +): > Shérab <sebastien.hinde...@ens-lyon.org> wrote: > > > I use HumanWare's Brailliant 40 daily and quite like its braille > > display. It also has a braille keyboard which I don't find very easy to > > use because the keys do not go down a lot when you press them. > > > > I looked at one very briefly at an exhibition (more than three, perhaps four > years ago - maybe even more). I don't remember the keyboard layout very well > though. At the front are 4 thumb keys. On top of the device, closest to the user are the two space bars that are really the same key, meaning e.g. the left one can not be bound to something else than the right one. Then comes the braille display and the routing keys. At the left of this are three round keys forming a vertical bar, same at the right. These six keys are like braille dots. Behind the routing keys is the braille keyboard. It's two groups of four keys each. > > This device does not have editing facilities built-in, though. > > > > As I remember, it cannot store files either. Indeed. > Their BrailleNote Touch can - and > it's quite impressive - but only has a 32-cell line. It reminds me of the BrailleSense from hims. I like its shape and design but it also has 32 cells only and I am not sure Hims has a lot of interest in Linux support. > > I also have a BrailleStar from HandyTech. It has curved cells and no > > braille keyboard but I quite appreciate the contacts with the > > manufacturer. With such a device you can embed a Raspberry Pi as Mario > > did and that's in my opinion a very interesting aspect. > > That's very interesting. It probably voids the manufacturer's warranty, but I > nevertheless like the idea. I don't think it does because you don't need to do anything special regarding the device to make this possible. The communication between the device and the i goes through bluetooth. In the device itself there is a slot in which there is a cable that comes out and provides electric power. Originally this has been done to let users put their phones there and this is what is being re-used to put the pi in a safe place, but as you can see from the point of view of the braille device nothing special is done. > Their newer device in this category is the Active Braille, which supports > sensors that detect the position of the user's reading fingers on the display. > This allows the braille window to be advanced automatically as the user > progresses through the text. This feature can also be used for other purposes > (e.g., in teaching braille and in research) that may not be of direct interest > to most participants in the BRLTTY list. Isn't it the ActiveStart you are actually talking about? That's the one I have, in fact, I wrote the wrong name in my previous mail, sorry about that. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] brailliant info needed
Hi Brian, Yes, normally the Brailliant is detected and BRLTTU starts. You may try with a different computer and a different cable to make sure... Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] brailliant info needed
Adrian van Bloois (2017/11/12 22:11 +0100): > On Sun, Nov 12, 2017 at 02:26:23PM -0600, Brian Tew wrote: > > brltty 5.3.1 rev 5.3.1 on ubuntu 16.04.2 x86/64 > Can anybody confirm that this version supports this brailliant? Sure it does. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] brailliant info needed
Dave Mielke (2017/11/12 16:48 -0500): > [quoted lines by Adrian van Bloois on 2017/11/12 at 22:11 +0100] > > >On Sun, Nov 12, 2017 at 02:26:23PM -0600, Brian Tew wrote: > >> brltty 5.3.1 rev 5.3.1 on ubuntu 16.04.2 x86/64 > >Can anybody confirm that this version supports this brailliant? > > In theory, yes, but in practice, no. There was a serious bug in the Baum > driver > in 5.3.1 which was fixed in 5.4. The Baum driver? Aren't we talking about HumanWare's Brailliant, here? Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] brailliant info needed
Dave Mielke (2017/11/12 18:05 -0500): > [quoted lines by Shérab on 2017/11/13 at 00:02 +0100] > > >The Baum driver? Aren't we talking about HumanWare's Brailliant, here? > > No. The Brailliant and the Brailliant BI are completely different devices. > The > former uses the Baum driver whereas the latter uses the HumanWare > driver. Oops, sorry. Was not at all aware of this difference. Thanks a lot for clarifying this. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Re: How doyou read books?
Dear Aura, > Thanks. There have been some API changes in Python's regex module which I have > to update my program for. I also need to do some checking, and make the key > bindings somehow customizable - probably by editing a bunch of constants in a > Python script, but that's better than no customizability. Sure. > There are dreadful confessions about crimes that I did in my past lives > written into the doc strings of methods... No, not really. I will release it > when I have time to do some cleanup on the code. Thanks! > I consider my program to be useful for reading files, but it has some inherent > limitations, e.g. the file being read has to fit in RAM at once. I don't think > that it would either be a good idea to start duplicating features of other > applications (like web browsers, directory managers, text editors, etc.) in > it, because it would be a huge effort. Also my program does not support > keyborad input from the TTY, so it is not very useful with braille devices > which don't have a braille keyboard. Yeah it was the same with bless and I didn't even go as far as you did. > As a result I'm not interested to develop this code very much. I would instead > want to write a BrlAPI interface for emacs, because emacs already supports a > lot > of functionality. Emacs is pretty usable with braille display already, but it > could see a little bit of enhancement (e.g. using routing keys as a > replacement for the mouse). Sure. Itmakes much more sense htan re-inventing the wheel. It would also be great if we could somehow achieve continuous reading, not having to do the Page Donw / CMd_TOP_LEFT sequence while reading, since that was the initial topic of this conversation. > But definitely I don't have anything against somebody else developing my code > further. Be warned though, that it has not been designed with extensibility in > mind. Your wise remark about developing an emacs interface to BrlAPI gave me a pause. I fully agree it's way better to develop such things than to spend time writing too specific code nobody will maintain. > > It would also be nice if you could bemore precise about the kind of > > improvemnets you would like to see in BrlAPI regarding the handling of > > keys and commands. > > You can read about this from a thread titled "[BRLTTY] BrlAPI Raw key code > mode?" started by Mario Lang on this mailing list on 23 Jul 2017 > 00:12:56. Yeah I remember this thread. One thing has happened since then: BrlAPI can now return the model identifier. So it is possible for a client to get this model identifier and then ask for raw key codes that it can then interpret as it wishes. I realise I should have announced this on the list and apologize for not having done so. From what I remember from the thread you mention, there was a consensus around this feature of being able to get the model identifier. The other thing I remember from it is that the next steps were not as obvious. I don't think there was a consensus on what should happend beyond this model identifier feature. Or was there one? Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Changing BRLTTY key mapping [repost]
Dear Vincent and all, I started to use an HandyTech ActiveStar 40 one week ago, too. Although I do not use the internal notetaker and have thus no idea about what the reference bindings are, I also considered altering the bindings that come with brltty, because I find some of them a bit counter intuitive or unpractical. I agree that the bindings used to change the currnet window, for instance, could be improved, atleast on my device. The ones you suggest, Vincent, look more natural to me, too. Best wishes and many thanks for having started this thread, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Re: How do you read books?
Hi, Lee, Lee Maschmeyer (2018/03/06 18:43 -0500): > For what it's worth, lb wiggles the cursor when you turn the page. Sorry if I missed a message inthis thread, but what is lb? Lee Maschmeyer (2018/03/06 20:20 -0500): > I do include a helper app that scrolls one line every X seconds. Where is that inlcuded? Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Running brltty in X11, and clipboards
Hi Samuel, Just so that you know: you are still using the former address of the list, brl...@mielke.cc, rather than the new one, brltty@brltty.com Coming to your message, if I understood you correctly the first approach seems more complete but also more difficult to implement, while the second one seems simpler to implement but with the drawback that it would not support a few features like rectangular copy and accumulation. One additional benefit I can see to the second approach is that it would let a sighted co-worker see what gets selected, which I find nice. So perhaps this second approach could be implemented first and then we could experiment with it and see whether the features we won't have are really missing? Best, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
[BRLTTY] Braille representation of some Unicode characters
Dear all, I am wondering whether some Unicode characters have a braille representation that takes more than one cell in our braille tables. There is for instance the case of the horizontal ellipsis (I don't know its codepoint anddon't know how to easily find it, sorry). For such a character, I'd like to have a representationlike ... (so three braille cells), but then it will mean that one screen line of 80 won't fit with my 40 braille display as wellas when each character on the screen occupies exactly one braille cell. Do you guys have any thought about this? Thanks, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] Problem in the documentation for Handytech Activebraille 40
Hi, After a discussion by phone, the problem is solved. There was actually a misunderstanding on how the names of the keys have to be interpreted. Indeed, on the Active Braille and Active Star, the functionkeys are called B1 to B8. Moreover, their layout really suggests a braille keyboard. So Jean-Philippe interpreted B1 to be the first braille dot, B2the second braille dot, etc. However, B1 and B8 actually refer to key numbers from left to right. So B1 is the key at the left, then comes B2, B3 and B4 and then, at the right of the two central keys, from left to right, B5, B6, B7 and B8 at the extreme right. It may be a good idea to clarify what the names B1 to B8 mean in the key table. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] How doyou read books?
Dear Arthur, Many thanks for your interesting response! You did send it only to me personnally so I quote it below so that everybody can read it and then I reply, below. Arthur BREUNEVAL (2018/03/04 19:12 +0100): > Hello Shérab, > I personally read books in TXT format, with the internal editor of my > device (Esytime, or Iris before). When I want to stop my reading, I > simply put the device in hibernate mode, so I can restart when I want > and at the same position I left. My device has an automatic reading > mode, so it can move the Braille yindow with a certain time shift you > can set, but I prefer to move it manually, since I'm not absolutely > constant when I'm reading. Some lines need more time to be read, I don't > want to impose a rythm to my reading, it is the book that does it. > > Except for technical books, or even for books that don't count a story > (like novels), that I can read with the speech synthesis, this is always > the method I use. I am not found of automatic reading mode, for the reasons you explain. Even with a device that can detect my fingers and ajust the speed to thier position, I think I would prefer not having the device move the text without me deciding. I think it's too bad there is no free software to read books in braille in a comfortable way, would really be a nice thing to have, IMO. Best wishes, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] How doyou read books?
Thanks a lot for your feedback, John! So, when you get a book in HTML or epub or whatever, you convert it to text? Best wishes, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
[BRLTTY] How doyou read books?
Dear all, I am wondering what you guys find most comfortable to read books in text formats. Perhaps the first question could be which file format do you prefer? And then, which tool do you use to read it? Is it less, a text editor, lynx, or perhaps the internal tools of your notetakers? What do you find most comfortable for long reading sessions and are you trying to achieve continuous reading (that is, you don't have to do anything special to update the screen?). Also, does your solution provide a way to keep track of your position between your reading sesions? Or perhaps you read books only through speech synthesis? All the best, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] [OT] Re: How doyou read books?
Dear Aura, Many thakns for your very interesting answer! Along time ago I also started to write a program to read books on my braille device. The program was written in OCaml and its ideas were very close to what you describe. Unfortunately I didn't maintain it and since it seems less advanced than yours, I wouldn't mind at all giving it up to collaborate with you. This program I wrote was called bless. This had two meanings. First it was meaning braille-less, so a version of less but made braille-friendly. Second bless like in blessing, because I saw it as a blessing to be able to read comfortably. If there are no secrets in your code, would you mind making it available on GitHub? It would also be nice if you could bemore precise about the kind of improvemnets you would like to see in BrlAPI regarding the handling of keys and commands. Best wishes, Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
Re: [BRLTTY] How doyou read books?
I think it's thanks to Emacs' desktop that the positions in files are remembered. Shérab. ___ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.com For general information, go to: http://brltty.com/mailman/listinfo/brltty
