At 9:21 AM +0000 1/25/08, Steve Lee wrote: > > I could for example imagine the following plug-ins: >> - a basic onscreen keyboard plugin >> - a dwelling plugin >> - a word prediction plugin >> - a switch access plugin >> - an ui grabbing plugin >> - a speech plugin >> - ... > >I like this, though a dwell and speech (and possibly prediction) are >better served by integration with general purpose ATs.
I don't understand exactly what you mean by general purpose ATs; what would be the non general purpose ATs? In fact, in my view the fonctionalities of the "plugin" would be available sessionwide. And now the following occurs to me: should I not say systemwide instead of sessionwide!? For example what about GDM? Say a user installs an AT; should that same AT not automatically be available at the login-screen, but not necessarily activated. I could imagine following scenario: User Paul gets an account on a machine. As he is a user that can only move the pointer, he needs an onscreen keyboard and dwelling. Consequently, someone installs the onscreen keyboard plugin and the dwelling plugin in Paul's session. By installing the onscreen keyboard plugin, a menu automatically appears at the GDM login screen that user Paul can use to start the onscreen keyboard at the login screen. By installing the dwelling plugin in the session, a dwellable spot appears at the login screen that user Paul can use to start dwelling (obviously, Paul is not able to start dwelling by a menu since he cannot click; that is why the dwelling plugin has to install the spot or some other thing that Paul can use to start dwelling). Say user John, that uses the same machine, does not need any AT. He sees that new AT tools have been installed; but he can simply ignore them since they are not running by default. Does a plugin have to announce itself to the session? If that is the case, I would suggest that the plugin should not only announce itself to the session, but also to gdm. I suppose that this would require the cooperation of gdm (hi Bryan ;-) ) and the cooperation of the plugin writer to ship the necessary things (among others the spot for gdm) for the gnome session and for gdm. For the moment I don't know whether such a modular architectures with "plugins" makes also sense for the other ATs available. The scenario presented here is from a users standpoint; but should it not be the starting point of the discussions on what needs to be done!? >Someone >suggested a calculator plugin that evaluated numeric expressions, >rather like prediction. Do I get it right: the suggestion is to use a numerical computation to find the completion and prediction word? I am curious: Is there any theoretical model supporting the suggestion? >A script plugin would be useful for power users. What kind of scripts are you talking about? Does the script provided by an application (or plugin) not depend on what that application expects? Supposing, we have plugin A that has a cli and thus understands shell scripts. We also have plugin B that requires perl scripts (I suppose the scripts understood by an application depends on what kind of scripts it has been programmed to understand.) What could plugn C, the script plugin do? > > Maybe another word concerning osk-ng: the intention is to make it >> work on multiple platforms. Could you please explain to me the reason >> for making it cross-platform? > >Being platform agnostic (like Mozilla) means more users can be reached >using the applications that they prefer. Will (for example) Windows user even look for free software? I don't know, but I assume most will not. I fear that they have the reflex to walk into a shop and buy. >In addition most users are on >Windows and being cross platform reduces the barriers to migration to >Linux. I agree that it will make the transition easier, but having the same application will probably not trigger it. There are so many applications on (for example) Windows, that having a few applications that are the same will not make much difference. (Though AT might be a special case.) Priority should (in my opinion) be given to make the switch possible for users that want to switch, by providing them the AT they need. And if it is of outstanding quality, it might even attract new users who learn about it on specialised forums and lists. (Besides AT, there are also other things that can hinder the switch, for example years of emails stuck in a client that cannot be moved properly to gnome,...) Of course, if there are enough resources to make the product outstanding and cross platform, it will be better. (If making it cross platform requires only little more resources, it might also be worth doing it; but again: it should not be at the expense of the quality of the product.) However, I want to remark that I am not an evangelizer; I don't know what makes users really switch; so I might also be wrong. >And there are >mobile platforms and the Ultra Compact PCs (e.g. eeePC). These look >exciting from the point of view of portable communications devices >(AAC). The increased presence of Linux in these applications means >there is less distance between platforms. For example I have a >Linux/Mozilla based Nokia n810 and plan to have a play with it in this >area. Incorporating these into the development of AT does make sense as it is about the creation of new solutions. Best regards Francesco _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
