Hi John G., I disagree. As an OS X user, I expect "Exit" to be called "Quit Braille Blaster" and be located in the "Braille Blaster" menu. As a Linux user, I expect "Exit" to be called "Exit" and be placed in the "File" menu. If I were a Windows user, I would expect "Exit" to be in the "File" menu. It is all about where things are expected to be in my opinion. If I wanted to have it all the same, I wouldn't care what environment I was using. However, I do, as do most end users. It is what differentiates one platform from the next. Why would I eat an orange when I could eat a Grapefruit. They both have peals and are round, but they have different flavours. I see the same with the layout of an OS. Just my opinion. Regards, Alex, On 2010-12-10, at 9:03 AM, John Gardner wrote: > I agree completely. It’s just that I’d like to keep those tweaks to a > minimum of things that are clearly important – like where Exit is. Where > recent documents and the preferences menu are is not important imho. > John G > > > From: brailleblaster-bounce@xxxxxxxxxxxxx > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Jurgensen > Sent: Friday, December 10, 2010 9:09 AM > To: brailleblaster@xxxxxxxxxxxxx > Subject: [brailleblaster] Re: Thoughts on the Specification > > Hi John G., > > I agree with having a user friendly site for updating tutorials. However, > Windows and Linux help systems may have a feature like we have on the Mac, > where the help system is self-updating. > > About UI changes, while Eclipse handles a lot of the UI changes that we would > need to make to make the UI look native, I have sited several examples where > we may need to make adjustments, such as the "Exit" menu item, which exists > on the Mac in a menu that does not exist on any other Platform to my > knowledge, unless you cont some distributions of Linux. > > Eclipse may handle some of this by default, so I do think that we can safely > use SWT to handle most of the UI differences automatically. > > My point was that we should integrate the small tweaks that Eclipse does not > handle automaticallly into Braille Blaster. > > Regarding Key Bindings, should we not taylor those to the various platforms. > The OS's system-wide keyboard shortcuts should be respected in my opinion. > > Let me know hwat you think. > > Regards, > Alex, > > > On 2010-12-10, at 8:48 AM, John Gardner wrote: > > > I propose answers to the first two of John's questions. > 1. I do believe that the user should be able to change key bindings, for > lots of reasons. And the ones in the spec wiykd be the defaults. None are > cast in stone - I undoubtedly made a few mistakes. > 2. If I understand correctly, the "look and feel" on the different OS > platforms are controlled to a large extent by SWT, so why not just use it > without a lot of tweaking? > 3. I really don't understand much about changing the appearance of > applications, so I won't give an opinion on how much the user can/should be > able to do. However I hope that we won't agree on anything that is a major > complication. > > A few other comments. I agree more or less with John B that we should keep > UI changes to a minimum. As a Windows user I know that many applications do > not put recent documents list at the end of the file menu, and it would > hardly be a problem for anybody if there were a "recent documents item there > instead. Preferences are not at all standard. In fact I don't recall ever > seeing preferences in the edit menu. I've seen it in the file menu, in the > help menu, in the tools menu, and in other places too. If it is more > standard in other OS, I'm happy to follow their lead. > > Finally I am also happy to have help file as part of BrailleBlaster. It > would be good if we could have a user-friendly update site so that people > could easily get updates to tutorial and help files. > > John G > > > > -----Original Message----- > From: brailleblaster-bounce@xxxxxxxxxxxxx > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer > Sent: Thursday, December 09, 2010 11:24 PM > To: brailleblaster@xxxxxxxxxxxxx > Subject: [brailleblaster] Re: Thoughts on the Specification > > We have three questions that need to be resolved. > > 1. Should the user be able to change key bindings? If so, the keystrokes > given in the spec would be the default. > > 2. What aspects of BrailleBlaster's appearance should be changed from > one platform to another. > > 3. How much should the user be able to change BrailleBlaster's > appearance? > > I think it would be helpful to look at how Eclipse deals with these > matters. > > The idea of context menus was that there should be a context menu for > the Daisy view and the Braille view, with things peculiar to that view. > > I think the spec should be reworded to make things clearer. The Daisy > and Braille views should be called that, not windows. It should be > stated that the welcome "screens" will be dialog boxces. It should also > be stated that the print and emboss previews will be large dialog boxes. > Finally, it should be stated explicitly that BrailleBlaster will have a > top window containing the title bar, the menus and the status bar and > that the Braille and Daisy views will be child windows of this top-level > window. If the user has more than one document opoen, The views will > change according to which document is being viewed. Various menu items > may also be grayed out or inversely. > > BrailleBlaster will use the printing widget of SWT. This works with CUPS > on Linux and the Mac and with the printer dialogs on Windows. Embosser > dirvers, including the ViewPlus drivers, should interface with the > printing widget, not print directly on the platform. This may require > some revision of the drivers, but it is necessary for platform > independence. Some Java code may be written to manage the interface. > > The Mac is used with all kinds of proprietary software that does > printing. I don't think we have to worry about paying for CUPS. > > John B. > > On Thu, Dec 09, 2010 at 09:11:44PM -0800, Alex Jurgensen wrote: > > Hi John, > > Apple aquired the CUPS project, so the requirements for using it in paid > drivers may have changed. > > > The Mac also uses CUPS for its printing system. > > Regards, > Alex, > > > On 2010-12-09, at 5:34 PM, John Gardner wrote: > > The specs say that a user should be able to maximize either the DAISY or > Braille view to cover the other. Or put them side by side. > > On another topic - there has been some discussion about printer drivers. > It > > should be straightforward to use ViewPlus printer/embossers with the > Windows > > version of BrailleBlaster. All ViewPlus printer/embosser users have > Tiger > > ttf fonts installed, and it should be easy to set up a template so that > the > > right ones are being used to tell the ViewPlus machine which character > to > > print and which to emboss. Otherwise, BrailleBlaster is just another > Windows ap and should print/emboss just fine. However I personally > don't > > know much at all about printing with Mac or Linux. I have been told > that > > CUPS is what one should use for Linux. I remember reading about CUPS > many > > years ago, and all I remember is that it is GPL-licensed and that the > license fee for use in a commercial non-GPL printer driver is many > thousands > > of dollars per year. So what is another way? > > John G > > > > Original Message----- > From: brailleblaster-bounce@xxxxxxxxxxxxx > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of qubit > Sent: Thursday, December 09, 2010 9:09 AM > To: brailleblaster@xxxxxxxxxxxxx > Subject: [brailleblaster] Re: Thoughts on the Specification > > I think that the daisy and braille windows/views/whatever you call them > should be resizeable and draggable, like the spec said. As long as the > dialog windows are accessible, there is no need to customize them. > The main window should be as large as it can be on each platform. > My opinions. > I think that since the user can resize and drag the D&B windows, he/she > should be able to maximize one of them to cover the other, so as to see > the > > full context in that document. > Anyone comments? > --le > > ----- Original Message ----- > From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx> > To: <brailleblaster@xxxxxxxxxxxxx> > Sent: Thursday, December 09, 2010 8:33 AM > Subject: [brailleblaster] Re: Thoughts on the Specification > > > Another question we need an answer to: How much should the user be > allowed to customize the appearance of BrailleBlaster? > > John > > On Thu, Dec 09, 2010 at 06:07:40AM -0800, Alex Jurgensen wrote: > Hi, > > Well, you saved me a great deal of typing. > > I was going to point out the menu bar situation on platforms like OS X > which have a system menu bar. I've seen this talked about fro some > setups > > of Ubuntu, althought I've never seen the latter in practice. > > Thanks for getting to this task first. > > Regards, > Alex, > > > On 2010-12-09, at 1:59 AM, Michael Whapples wrote: > > Hello, > I don't think having the Braille and daisy views as top level windows > with there own menus would be very natural. Firstly it doesn't really > fit with any other GUI application I can think of, normally they > either > > modify available menu options depending on the current view or they > grey > > > out unavailable options. So as greyed out options are fairly "normal" > to > > > encounter I don't see why they would be confusing. Then there is the > case of platforms where menus aren't actually in the window but get > placed by applications in a system menu bar like in Mac OSX (NOTE: SWT > > > will automatically handle this for you). As an example of the Mac > situation, in safari the web browser, even when I go to its > preferences > > all menu options are still there but ones which are irrelevant to > preferences (eg. the option to show/hide the status bar) are greyed > out. > > > Also the idea of two top level windows being present in one > application > > at the same time just seems odd to me, I couldn't imagine it would > look > > right (it would probably look like two separate applications). Then > what > > > happens when there are more documents opened, your description seems > to > > give me more top level windows and more clutter of the desktop. Then > there is the situation of "I am working on a document in > BrailleBlaster, > > > I have finished on that document so I close the document but keeping > BrailleBlaster open as I want to work on another document", what do I > encounter at the point when BrailleBlaster has no open documents? > Having > > > the document views as child elements of a "BrailleBlaster appliccation > > > top level window" I would be left with an empty BrailleBlaster window > containing only the menus and toolbars (IE. no sub windows), allowing > me > > > to go to the menu and choose open document or new or whatever task I > want to do. Also with my idea of the view, multiple documents would > just > > > lead to more sub views, the desktop only ever has one BrailleBlaster > top > > > level window. > > Now one thing which might be desired is a shortcut pop-up menu > specific > > to each view. What I mean is one of those context menus which are > activated by right clicking the mouse of a UI element (use the > applications key or may be shift+f10 and on Mac with voiceover > vo+shift+m). In these context menus only the options relevant to that > element would be shown. > > Michael Whapples > On 09/12/10 04:55, John J. Boyer wrote: > This sounds good. My understanding was that the Daisy and Braille > windows would each have their own menus. The specification doesn't > say > > so explicitly, but it seemed reasonable, since some things would be > possible in one window and some things in another. If the Daisy and > Braille windows are embedded in a top window with the menus, status > bar > > and toolbar, the grayed-out options could be confusing and > frustrating > > for the user. Is this actually the way it will be? > > So the print and embosser previews are basically big dialog boxes. I > don't remember anyone saying they should be open continually. They > are > > opened when needed. > > I don't think BrailleBlsster should display multiple documents > simultaneously, since it already has two views for each document. > Rather, when a user switched to another document these view would be > changed for that document. > > The Daisy and Braille windows should prbably be called views instead, > especially if they don't contain their own menus. > > John > > On Wed, Dec 08, 2010 at 08:45:53PM +0000, Michael Whapples wrote: > We seem to be getting a whole jumble of things here. A window is a > very > generic thing. A dialog is a type of window, normally used to show > messages or let users select options. A dialog is not embedded in > the > > top level window but can be such that it prevents the user going > back > > to > the main window. A dialog might not cover the main application top > level > window. Then there are child windows (they may have another name) > which > usually is embedded into the top level window. These may be used for > multiple documents (eg. MS Word has been known to work like this I > don't > know about their latest version). Finally then there are what I am > calling a top level window, these don't have any other window > containing > them. > > My feeling is: > * BrailleBlaster will have a top level window containing the menus > and > > such like which are common to all situations. > * The daisy viewer and Braille viewers will be child windows or may > be > > even panes within a child window or may be this will all work on the > > > tab > idea. Anyway the main idea is these will be embedded into the top > level > window. > * Print and preview will be dialog boxes as these are both actions > (IE. > I go to print/emboss a document or I go and view how it will be > printed). I see no reason why print preview would need to be open > continually. > > Michael Whapples > On 08/12/10 20:13, John J. Boyer wrote: > I've never actually looked at a print preview window. Has anyone > seen > > > an > embosser preview window? I would think that programs would handle > preview by opening a temporary window that either hides the > existing > > window or minimizes them. > > John > > On Wed, Dec 08, 2010 at 12:27:33PM -0600, qubit wrote: > Regarding What happens to the windows when a print preview is > active: > I wonder if opening a new window is a good idea. > I am growing to like one feature in eclipse's UI: eclipse will > cycle > > through > all the various windows if you hold control and type F7 > repeatedly. > > It has a lot of rather busy windows. I wonder what it looks like > to > > > a > sighted person. > > As for print preview, I have no idea what to do if you are > embossing > > > a > document. The image in the braille window doesn't necessarily > look > > like > the > output of the device. Do the various embossers provide any kind > of > > API > for > knowing what the braille will look like? > Also, if viewing it on screen, you are further limited by the > display > capabilities. > > Interesting question. But do you really want there to be a hard > coded > window for print preview, print and emboss? Couldn't it just be > like > most > apps that put a command for print and emboss and print preview in > the file > menu? That could bring up a dialog. > Just wondering. > --le > > ----- Original Message ----- > From: "John J. Boyer"<john.boyer@xxxxxxxxxxxxxxxxx> > To:<brailleblaster@xxxxxxxxxxxxx> > Sent: Wednesday, December 08, 2010 9:24 AM > Subject: [brailleblaster] Thoughts on the Specification > > > I have just reread the specification carefully. It certainly hangs > together better for me than at the beginning. Here are some > thoughts. > There is a menu item for opening a list of recent documents. These > documents should be on the menu, just below the exit choice, as > they > > > are > ikn most word processors. > > The ability to open recent documents means that the users will > want > > MDI. > Fortunately, this is not hard to implement. > > We may need a third window for each document for print and > embosser > > previews. What happens to the Daisy and Braille windows when a > preview > is chosen? Are they minimized? > > John > > -- > John J. Boyer; President, Chief Software Developer > Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > > > > > > Alex Jurgensen, > VoiceOver Trainer, > ASquared21@xxxxxxxxxxxxxxxxx > > Visit us on the web at: www.vipbc.org > > > -- > John J. Boyer; President, Chief Software Developer > Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > > > > > > > Alex Jurgensen, > VoiceOver Trainer, > ASquared21@xxxxxxxxxxxxxxxxx > > Visit us on the web at: www.vipbc.org > > > -- > John J. Boyer; President, Chief Software Developer > Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > > > > > > Alex Jurgensen, > VoiceOver Trainer, > ASquared21@xxxxxxxxxxxxxxxxx > > Visit us on the web at: www.vipbc.org > Alex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx Visit us on the web at: www.vipbc.org