First of all I want to apologise for my tone. I was under severe lack of
sleep these days and will be happy if we could forget my out-of-place
remarks and get on with real stuff.
On 15.03.2012 23:40, Dave Mielke wrote:
[quoted lines by Vladimir 'φ-coder/phcoder' Serbinenko on 2012/03/15 at 22:27
+0100]
Samuel already said it: I just want to have something that works at
least minimally to begin with. To make whole brltty at least compile
would mean twice as much work.
As I've already said, I'd be glad to do the work of making brltty compile if
you'd be so kind as to tell me how to set up a build environment for Grub. I
think it's the better approach, and I'm not just compliaining - I'm offering to
help.
bzr branch http://bzr.savannah.gnu.org/r/grub/branches/brltty/
Rest of instructions are in INSTALL. I can upload a tarball if you prefer.
Another thing I forgot to mention is that GRUB's exit (), fatal () and
so on calls can be used only in critical situation like an important
memory corruption. I have #if 0-ed out few function which use exit ().
If you think that it's better to have nothing at all rather than something to
start with then I'm at wrong address.
That's your judgement call. If you aren't interested in my thoughts, opinions,
and suggestions, then perhaps you are.
I'm, lack of sleep :(.
common = braille/brltty_wrap/log.c;
GRUB has no file writing facilities
AGain, replacing a whole file just for that isn't good.
Again, putting a dummy there to get something working at all for the
first stage is more important than to get tiny bits right and the
whole not compiling at all.
You've been speaking as though this is your permanent goal. If my understanding
has been incorrect on this point then I stand corrected.
The prefered way to handle logs in GRUB is grub_dprintf. I'll see how I
can abstract it for brltty.
common = braille/brltty_wrap/serial.c;
Platform-specific.
Parts of it, yes, but not all of it. Again, replacinb the whole file isn't
right.
Most of this file should be split the same way as usb.c is.
I've already said that I know serial.c to be one of the three biggest offenders
in this area. One of the problems with splitting it up, though, is the fact
that platform-dependent type definitions are used internally so that things
like attribute caching can be all done in common, portable code.
GRUB already caches attributes but double caching makes no harm.
No threads. The whole point of async is to let a single thread handle many
events.
GRUB works completely differently from POSIX-compliant OSes. GRUB is
at most similar to msdos in some aspects (like being single-thread)
but offers full features in others (like Unicode).
As I said, async doesn't rely on threads. It allows the single main program
thread to handle multiple tasks.
I'm currently not able to make it work at all. I got this impression
from reading the code. But if async code does a rescan then we'll need a
cache layer to avoid real rescans.
common = braille/brltty_wrap/ktb.c;
Currently dummy for keys.
Totally bad idea.
It makes the whole compile.
It also renders the controls on the braille devices entirely useless.
For the first prototype I want to make keys useless. Just so I can check
only half of the code.
In GRUB renderer is separated from info. It's easier to have good
Braille display by making braille another renderer rather than rendering
in standard screen and then having a reader.
Why not render the screen content into a string array,
It's possible to make a virtual 80x24 terminal. However special
structure of GRUB and its small code size has already allowed us to
find better solutions to problems than what is applicable to a big OS
where you can't change all components to improve input to your
command. In this case I thought that having the complete model would
allow better braille rendering. The solution of rendering into 80x24
and then attempting to parse seems to me as a kludge.
A braille user needs to be able to see the whole screen, just like you like to
see the whole screen. Do you really think it's somehow better to have two
completely different renders, both of which, independently, know what should be
on the whole screen? Isn't it better for the screen to be rendered logically
once, and then to have various presenation layers to turn that logical
representation into physical ones?
GRUB can work in one of three modes:
- menu mode. In this case a model is the list of entries and currently
chosen entry
- editor mode. In this case a model is the list of lines and current
position.
- cmdline editing mode. In this case the model is current line and position.
- text mode. In this case a model is the incoming flow of strings (not
characters as characters aren't enough for bidi), some of them
highlighted. Some of them contain line breaks.
In any of the modes then one instance of renderer is attached per output
terminal which takes its characteristics into account. In case of menu
we have 2 different renderers: textual and graphical.
Terminal code also keeping previous text output while in text or cmdline
mode.
We already use this to represent the same info on different terminals:
E.g. http://robertmh.wordpress.com/2009/12/25/multiple-grub-terminals/
So the may not even be a textual representation like what you refer to
(e.g. in case of gfxmenu). So we probably need some wrap renderer
between GRUB and BRLTTY. One possibility is to render to 80x24 using
textual renderer but skipping some decorations like borders.
It's not good, by the way, to go down a path which would allow the braille
screen to have different content than what's shown on the monitor. If a braille
user and a sighted person are working together, it's critical that they're both
seeing exactly the same data in exactly the same layout. The importance of this
cannot be understated.
Given the above, can you now see the sense in first rendering the screen into a
logical representation? It doesn't need to be something hard-coded like 80x24.
As referenced before the may be no textual screen at all. Or the may be
several. We can choose any size which results in best brltty results,
even infty x infty, or give brltty raw model but it would break the
structure to use a parameter from another terminal which may or may not
exist.
Also, given the lack of core support, no user with a braille display smaller
than 40 cells will be able to use it.
40 is a parameter
I still maintain that Grub shouldn't need to care about the properties of the
braille device. Rendering good braille isn't as simple as putting text on the
display.
It may make sense to tweak text renderer to a given brltty device.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
