Nikhil Nair wrote: > Am I right in suspecting that, if I were to use this method for another > package which had unsatisfied dependencies, setup.exe wouldnt' sort out > those dependencies for me? Or would it assume the dependencies had > changed since version 0-0, and handle them seamlessly?
It should actually sort out the dependencies. Though I have not actually tested this. But conceptually the logic flow is the same as installing package A in setup, deselecting dependent package B, and then re-running setup and seeing that it has re-selected package B for you. In other words, each time setup initializes it should fill in any dangling dependencies. > On a different note, could anyone spare a few minutes to describe exactly > how you operate the chooser, as a sighted user? If I can understand what > I should be doing with the mouse, I may be able to get my screen reader to > emulate that; it has quite a bit of power to simulate clicks, holding the > mouse buttons etc., though most blind people don't use them since > ordinary keyboard access is so much easier. Applications which need mouse > manipulation of that sort are generally considered to be inaccessible, but > that doesn't mean you can't get them working if you know what to do. As Igor said it's not so much a problem of mouse input, the problem is that the package selection widget is a custom window that paints everything itself, rather than using any standard components. I still think it is possible to rework all this and end up with a result that is both easier to use and accessible. I can't offer any idea of when that might happen, but I do hope that everyone with a stake in having an accessible setup.exe will at least keep a cursory watch for setup test releases so that we can get feedback on how new versions with these changes work with screen readers. I'll try to remember to include something like "[accessibility]" in any subject that asks for feedback on the topic. Brian
