GNOME Bugzilla – Bug 313737
Disable the "BRLTTY's BrlAPI choice" when brltty is not available
Last modified: 2005-08-22 13:01:15 UTC
Please describe the problem: If brltty is not available, gnopernicus compiles fine and runs fine, but the braille device initialization fails without a single error message. Steps to reproduce: 1. Compile & install brltty, 2. Compile & install gnopernicus, 3. Choose BRLTTY in the list, save preferences 4. Uninstall any existing brltty, 5. Re-compile & install gnopernicus. 6. Run it. Actual results: Gnopernicus runs, and says it wasn't able to setup the braille device, without further explanation. Expected results: I'd expect gnopernicus to say that Brltty support wasn't compiled, and that one should choose another braille device. And I'd expect the Brltty choice not to be available when choosing the braille device. Does this happen every time? Yes Other information: To my mind, the best way would be, when brltty is not available, to disable the Brltty device in the braille device list. And then, when the gconf-configured braille device is not present in the braille device list, a warning should warn about that, and ask the user to select another braille device.
Created attachment 50898 [details] [review] proposed patch This patch doesn't add BRLTTY to devices list if brltty support is off. Also (in this case) it selects the "<none>" device in order to avoid the bug #167221.
Comment on attachment 50898 [details] [review] proposed patch still compile-time based, so this doesn't solve the problem if BRLTTY is not installed.
Yes it does: - If at compile time BRLTTY is installed, everything works. - If at compile time BRLTTY is not installed, BRLTTY support will not be compiled in and the choice will now not be available, so that the user knows what the problem is (BRLTTY not installed before compiling). - If at compile time BRLTTY is installed, and then uninstalled, gnopernicus will fail to load the BRLTTY driver, hence producing an error message, the user knows what the problem is (BRLTTY not installed any more). - If at compile time BRLTTY is not installed, and then installed, gnopernicus will not provide the BRLTTY choice, so he knows what the problem is (needs to recompile gnopernicus so as to get the choice). (BTW, with this patch applied, http://bugzilla.gnome.org/show_bug.cgi?id=303633 is resolved too: the user knows he needs to recompile the software, as usual with such dependency). Things always work this way with Unix software.
The issue, however, is whether Gnopernicus *should* have a hard dependency on BrlTTY or not. Some users with get Gnopernicus with their distros. If those distros include BrlTTY, then great, that Gnopernicus will (hopefully) expect to use it and life will be good. If those distros don't include BrlTTY then not as great, but Gnopernicus will (hopefully) not expect to use it and so life will be OK. However, what about users who get these things separately? It would be nice if I could get a Gnopernicus that used BrlTTY if it was present, and failed gracefully if it isn't present. Perhaps that is just a pipe dream, but it is nontheless a nice one.
Well, the historical unix way it usually _not_ to have such behavior, and have to recompile things. Now have a look at my latest comment on http://bugzilla.gnome.org/show_bug.cgi?id=303633 This is the way plugin-based software (xmms/gstreamer/...) behave. It is the best solution here to my mind. The ttybrl.so file could even be packaged separately in a gnopernicus-brlapi package that would depend on brlapi, so that the user, when seeing that, will know he needs to install that one too to get access to brltty's brlapi, and then discover that there is a dependency on brlapi to get it working.