My thoughts were going along a line a little simpler than plugins. I was thinking that as the areas which need customising are small, then just have factory methods/classes to create those parts which are felt to need this variation, and the factory method could choose the right one for the platform or a default if the platform is not specifically known about.
You mention touchscreen devices or other platforms, I think where user interaction differs so much it may deserve a whole different interface to the desktop version, in which case I feel that should be considered porting BrailleBlaster to that platform. If BrailleBlaster is designed correctly, keeping UI code separate from the workings inside (eg. things like the MVC design pattern) then it should be fairly easy for someone to develop a UI suited to that platform.
I feel plugins may need extra effort with no real gain, IE. the dynamical nature of plugins isn't needed as a user is unlikely to want to change the UI. What were your reasons for suggesting a plugin, did I miss something.
Anyway this is the level of design I think discussion really should be happening at, things like classes are too small here to see the bigger picture of how it goes together.
Michael Whapples On 10/12/10 16:33, Alex Jurgensen wrote:
Hi Michael, How do you prepose that we go about implementing this.I was thinking that if we are using a plug-in architecture, as I suggested for the embosser drivers, we should create plugins that would extend the core UI on the various platforms.This would allow people who are familiar with a particular platform to write the platform-specific pats of the UI and would help us account for radically different UIs in the future, for instance touch screen interfaces.Let me know what you think. rEgards, Alex, On 2010-12-10, at 8:09 AM, Michael Whapples wrote:MichaelAlex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx <mailto:ASquared21@xxxxxxxxxxxxxxxxx> Visit us on the web at:www.vipbc.org <http://www.vipbc.org/>
