OK. The needs of users must take priority. Development will be
concentrated on the GUI version. The text version will be a separate
project. I don't anticipate any great difficulty with GUI, especially
since much code can be taken from BrailleBlaster.
BrailleZephyr will be basically a library, so that it may be used in BB
at a later date. The main class will essentially just call this
library.
As for the text version, I am in fact thinking of something like nano,
but more interactive.
I am using brltty and a Focus 40 Blue, which has an 8-key Braille
keyboard. When I translate books from Bookshare with file2brl I can use
this combination with nano to read the resulting file. I do editing as I
go along.
John
On Mon, Jun 22, 2015 at 10:43:16PM +0100, Michael Whapples wrote:
Exactly my thoughts too.
Also even if you convince such a user to use the command line, they would
probably benefit from simpler, more intuitive interfaces (eg. I am thinking
in text editors nano). Such a editor interface in a text console I think
would be much harder to do than a basic graphical interface.
I do think John is over estimating the work in creating a GUI.
Michael Whapples
On 22/06/2015 22:25, Greg Kearney wrote:
Everyone keep in mind who our customers are for this. Most of them have
never used a command-line interface in their lives and don't even know what
one is.
Commonwealth Braille & Talking Book Cooperative
Greg Kearney, General Manager
#320, 185-911 Yates Street
Victoria, BC V8V 4Y9
CANADA
Email: info@xxxxxxxxx
U.S. Address
21908 Almaden Av.
Cupertino, CA 95014
UNITED STATES
Email: gkearney@xxxxxxxxx
On Jun 22, 2015, at 1:11 PM, John J. Boyer <john.boyer@xxxxxxxxxxxxxxxxx>For a description of the software, to download it and links to
wrote:
Hi Michael,
Well, there are people who much prefer working at the command-line or
console level. The text interface would be interactive, like lou_debug.
John
On Mon, Jun 22, 2015 at 06:01:01PM +0100, Michael Whapples wrote:
I possibly would question whether it is simpler to develop a text based--
editor than a graphical one.
May be it is due to me always having graphical environments available since
I started programming, and normally for editing one reaches for the GUI
toolkit. The text edit controls do so much stuff for providing editing
features.
I don't know whether there are similar toolkits which simplify text console
applications by providing an edit control. Well I know of NCurses and
Dialog
but don't know whether these have anything of much use.
May be a line editor like ed would be simpler to write, but I doubt its
ease
of use.
The two interfaces probably will have little in common, I would suggest
sorting out the GUI first, if ever doing a text version.
Michael Whapples
On 22/06/2015 16:49, John J. Boyer wrote:
GeneralFor a description of the software, to download it and links to
To achieve cross-platform usability and ease of installation the program
will be writen in Java and will consist of a single .jar file and a
version of swt.jar for the platform. It will also have a programData
directory to hold things like files giving the correspondence of ASCII
characters to dot patterns, settings and documentation. It will be
licensed under a permissive license like Apache 2.0, so there are few
restrictions on its use by anyone. For the time being it will be hosted
on the AbilitiesSoft website. A git repository will be established. A
mailing list may be set up later.
There will be two modes, text environment and GUI environment. Each mode
will be encapsulated within a Java package so that it can be used as a
component by other programs. There will be a small Main class which
determines which mode will be used based on whether or not a GUI
environment is available.
Development
The text mode will be developed first because it is simpler, though it
will not have all the features of the GUI mode, such as displaying dot
patterns. Development will be in two stages:
Stage One - the basics.
The editor in its first version needs to do the following:
1. 6/8 key entry so you can type braille with chorded entry from a
standard keyboard.
2. A bell feature like the Perkins Braille Writer has. Set it to x
number of cells from the end of a line and it goes off when you reach
that point.
3. A way to set the number of cells across and the number of line down
on a page, a second "bell" indicator that can be set to go off when you
are X number of lines from the bottom of the page.
4. Visual indications of page breaks in document.
6. Line numbering by page or document. (nice but not critical)
That is it for the first version. A straight up computer version of a
manual Braille writer, nothing more.
Stage Two - formatting.
1. Braille and print page number insertion and formatting. A command
that will for example insert the next print page number into the file
with the leader indicators of your choice. You could also restart the
page numbering with a dialog asking what print and braille page number
to start.
2. Controls to program the position and style of the various page
numbering. What numbers to start with, where they are placed leaders,
etc.
3. Centring, flush right of selected lines (we might get this in version
1 above)
project pages go to http://liblouis.org
John J. Boyer; President,
AbilitiesSoft, Inc.
http://www.abilitiessoft.org
Madison, Wisconsin USA
We develop software for people with disabilities which is abailable at
no cost.
For a description of the software, to download it and links to
project pages go to http://liblouis.org
project pages go to http://liblouis.org
For a description of the software, to download it and links to
project pages go to http://liblouis.org
