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