[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. >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. >>> 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. >>> 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. >>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. >>> 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. >>>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? 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. I think a list of arbitrarily long lines would be good enough. The real screen renderer could then wrap each line as needed to fit the actual screen width. >It seems that my efforts about this aren't appreciated. No one has said that. The fact is that I myself do appreciate your efforts. I really and truly would lvoe to see good braille support in Grub. My goal here isn't to discourage the work. It is, rather, to emphasize the needs of a braille user, and to try to ensure that this project doesn't go down what I believe to be a wrong path. If you're going to assume that anything I suggest that differs from your own already-formed opinions is garbage, then I guess we're at an impass. >>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. >>And also, as posted earlier to the list by a user, users also need to be able >>to inspect the rest of the screen, not just the current line, so that they, >>for >>example, can reveiw the list of special keys, etc. >So is it better to support keys without braille display? I don't understand. The user said he'd like to be able to look at the whole screen with his braille device so that he can remind himself what the special keyboard keys are within the Grub environment. This is a valid and good request. It simply highlights the need for a braille user to be able to see the whole screen rather than just the current line. >I've already made usb_grub.c. But it seems that if I do only that and >brltty is started when a new device is plugged in, it won't be picked >up. This is probably a result of you having disabled async. It really would be a good idea to find a way to get the timer part of async working. I don't mind helping with this, but I can't until I know how to set up a Grub build environment. >>You don't understand braille devices, do you. >Then tell me. Nothing is more frustrating than hearing "your idea >sucks, the only good code is ours, you're an idiot who doesn't >understand anything and we won't tell you" Please! I haven't called you an idiot. You can't possibly be an idiot if you're undertaking this kind of project. There's nothing wrong with admitting ones ignorance on a topic, though. I, for example, am entirely ignorant when it comes to Grub internals. I don't mind admitting this. Likewise, you're unfamiliar with the use of braille when it comes to handling a computer screen. There's nothing at all wrong with you admitting this, either. We both have complementary skills, here. I know about braille use and you know about Grub. Also, I haven't been just trashing your ideas. I believe I have, each and every time, attempted to explain the reasons behind what I'm saying. If there actually has been an instance where I've simply said that you're wrong, without explaining why, then I'm sorry. >> You're making an assumption ehre >>which is simply not true. Controls on the braille device don't show up as >>keyboard events. >We have unified event queue. It's not a problem to add new virtual key. A braille user has come to expect the various controls on his device to work in the ways that they do. It'd be nearly impossible for you to redefine all of tjis in some brand new set of tables outside of brltty. Even if you somehow could, it'd go out-of-date the moment we make some change in that area. Braille device controls aren't simple things. In many cases, key combinations, rather than just single keys, are used to define screen navigation operations. There's also a very rich set of screen navigation operations which braille users have available to them. Reducing this to a simple left/right scroll would be extremely limiting. Try to imagine how you would feel if you were suddenly handed a keyboard where all of the keys were in different places, and a monitor which only let you see part of the one line that someone else thought would be the only line on the whole screen you should ever be able to look at. Would you be a very efficient user of your computer if this were done to you? >>I don't know how many times I'll need to keep saying this in order to make the >>point stick. >Again, I want something to work at all. It will work. I ahve no doubt about that. It boils down to do we want the deception of something far less than adequate working faster, or are we willing to put in the effort and patience to make it work right. >I want the cooperation and future version importability to work. But >if it doesn't work for any reason I'll just import one version and be >happy with it. That's one of my concerns. Doing this work in a way which doesn't lend itself to on-going, easy maintenance will make the work eventually become irrelevant. You'll be happy with a version that works, but a user with a new device which ssn't supported by your old version won't be happy. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of Salvation. EMail: d...@mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html http://FamilyRadio.com/ | http://Mielke.cc/bible/ _______________________________________________ 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
