[brailleblaster] Re: Thoughts on the Specification
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Wed, 8 Dec 2010 19:49:34 -0600
Since the spec says the user can drag and resize the daisy and braille
windows, they should be windows and not just panes. A window pane can't
cover another pane. (Unless it's a pain.;)
I agree the preview window doesn't need to be -- and probably shouldn't
be -- open continually.
But that also applies to print and emboss windows -- I mean, all you need is
either a menu selection for print and emboss and preview, or icons can be
put in a toolbar, if brailleblaster has one. Either way, clicking one opens
something.
--le
----- Original Message -----
From: "Michael Whapples" <mwhapples@xxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Wednesday, December 08, 2010 2:45 PM
Subject: [brailleblaster] Re: Thoughts on the Specification
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
>>
>>
Other related posts:
