Opera 8.5 just out

[Roedy Green]

I am not aware of the keys that I would press to place the
cursor in the address bar (using a pointing device would slow
me down).

If you don't want to use mouse functions, the way you discover
keyboard shortcuts is to click Help | Keyboard and they are all there
for you, including F2.

If you wanted to put F2 on a menu, you can reconfigure the menus.
There is not much point. You can click the address bar with the mouse
faster than you could a menu item.

If you don't like clicking new page to get started, you can configure
some dummy home page.

There are two sorts of problem with a browser -- initial getting
acquainted where every difference from your old browser feels like a
bug, and things that annoy you even after you have used it for month
or two.

 

[Roedy Green]

Moreover: I have started Opera now with no initial page, so
the main window is empty. And both "Address bar" and
"Navigation bar" are grayed out in this state. Now, I am not
able to turne on the address bar, even if this would help me
to enter an address without a pointing device in this state.

I found that confusing too. You have to click new page first. There
is not much else you can click at that point . I have put in a "wish
list" to the Opera Forums to correct that.

 

[Oliver Wong]

If you don't want to use mouse functions, the way you discover
keyboard shortcuts is to click Help | Keyboard and they are all there
for you, including F2.

If you wanted to put F2 on a menu, you can reconfigure the menus.
There is not much point. You can click the address bar with the mouse
faster than you could a menu item.

If you don't like clicking new page to get started, you can configure
some dummy home page.

There's also the issue of users with disabilities which make using a
pointing device (whether a mouse, trackball or otherwise) inconvenient or
even impossible.

I've recently tried setting up a custom "Media PC" using Windows XP (as
opposed to Windows Media Center Edition), and because of the lower
resolution of the TV, I had to rely on WinXP's accessibility features for
the visually impaired to globally increase font and widget size, and sadly
(though not unexpectedly), most applications (particularly non-Java ones)
don't respond well having their widgets doubled or tripled in size.

Similarly, while using a keyboard generally is no problem, using a mouse
requires a flat surface which simply isn't available in this environment
(the mouse doesn't work well rolling across the surface of the couch, and
it's inconvenient to roll it across the floor), and I haven't been able to
find a place to buy trackballs for cheap, so I'm also using WinXP's built in
accessibility feature which emulates a mouse using the keyboard numpad. In
most scenarios it's much easier for me to use keyboard shortcuts (when I
actually know what they are) then to use the numpad to scroll the cursor
around and click on things.

- Oliver

 

[Stefan Ram]

Similarly, while using a keyboard generally is no problem,
using a mouse requires a flat surface which simply isn't
available in this environment

Only some minutes ago, I also became aware of the following
reason, why I prefer the keyboard:

For many operations, e.g., selecting a menu entry, I have the
keyboard sequence hard coded in my brain. For example, I type
[Alt]--[C] to mark something as "done" in my todo-list,
without conciously thinking about it anymore.

When I have to use the mouse, to select the same menu entry or
to activate a symbol in a tool bar, I have to locate the
cursor with my eyes and then I have to perform a movement
depending on the current position of the cursor. So the
movement for the same operation is different each time!
Therefore, it requires more attention of the brain -- optical
input has to be processed. In contrast, [Alt]--[C] can be
typed "blindly". Also, the whole lower arm needs to be moved
away from the keyboard and possibly back again.

 

[Oliver Wong]

When I have to use the mouse, to select the same menu entry or
to activate a symbol in a tool bar, I have to locate the
cursor with my eyes and then I have to perform a movement
depending on the current position of the cursor. So the
movement for the same operation is different each time!

The movement depends not only on the position of the mouse cursor, but
also on the position of the window (e.g. if the window is not currently
maximized). You have to find "your current location" and "your destination",
and then move the mouse along a vector describing the subtraction of one
from the other.

- Oliver

 

[Tor Iver Wilhelmsen]

I found that confusing too. You have to click new page first. There
is not much else you can click at that point . I have put in a "wish
list" to the Opera Forums to correct that.

Since someone brought up the desire for keyboard use instead of
pointer - and Opera is one of the best keyboard-enabled GUI apps in
existence - you can also press Ctrl+N. Use F8 to focus on the
address bar and F9 to focus on the window when you have one.

To alter what Opera start up with, well it's the first choice when you
open the preferences dialog (Alt+P); to start with an empty window,
try "Start with home page" and use "about:blank".

 

[Roedy Green]

I've recently tried setting up a custom "Media PC" using Windows XP (as
opposed to Windows Media Center Edition), and because of the lower
resolution of the TV, I had to rely on WinXP's accessibility features for
the visually impaired to globally increase font and widget size, and sadly
(though not unexpectedly), most applications (particularly non-Java ones)
don't respond well having their widgets doubled or tripled in size.

Opera has from the beginning had a feature you could set the default
zoom, independent of what the website thought were good font sizes.

It has a voice interface. You can speak commands to it, or have it
read to you.

you can provide user style sheets, say for example that use high
contrast colours, large type or special fonts such as Tiresias that
override/merge with the ones provided by the website.

 

[Roedy Green]

(the mouse doesn't work well rolling across the surface of the couch, and
it's inconvenient to roll it across the floor),

A saw a laptop mouse somewhere designed for laptops you could run on
your pantleg.

 

[Roedy Green]

Also, the whole lower arm needs to be moved
away from the keyboard and possibly back again

The thing that bugs me is back and forth keyboard/mouse or worse,
needing to use both at once.

The other are these ruddy chords where you have to hold several keys
down at once. It totally breaks the rhythm of keying.

Perhaps standardizing some extra mouse buttons for ctrl and shift
would help.

 

[Roedy Green]

The movement depends not only on the position of the mouse cursor, but
also on the position of the window (e.g. if the window is not currently
maximized). You have to find "your current location" and "your destination",
and then move the mouse along a vector describing the subtraction of one
from the other.

Part of the problem is you first have to locate the mouse. I
customised my mouse cursor to be extra fat and with a drop shadow.
This tends to make it visible on both light and dark backgrounds.
The catch is it often obscures text I am trying to type. It has not
the sense to stay out of my way when I am keying.

 

[Oliver Wong]

Opera has from the beginning had a feature you could set the default
zoom, independent of what the website thought were good font sizes.

I don't know long FireFox has had this feature (perhaps "from the
beginning" too), but it certainly has that feature in the version I'm
running now. Reading webpages was not really an issue for me.

The issue is, for example, when running installers, during the license
agreement screen, the textfield which displays the text of the agreement is
enlarged 3 or 4 times, forcing the window itself to be bigger than my entire
screen. As such, the radio button marked "I agree" and the button marked
"Next" are not visible, as they lie beyond the bottom of my screen.

If only all software used LayoutManagers, instead of only Java
software...

- Oliver

 

[Roedy Green]

If only all software used LayoutManagers, instead of only Java
software...

Java is only 1/2 way there. Look at one of my Applet page with Opera
and crank up the Zoom. The applet real estate grows, but the fonts do
not.

Imagine a Java Applet rendered with paintComponent on a
phototypesetter with 1200 dpi. It would be like one of those paintings
on a grain of rice.

You want a human centred unit, something like an em, but that takes
into account legibility. You don't need fonts quite as big if they are
meticulously rendered. It has to take into account the size of the
monitor, its resolution, the visual acuity of the viewer.

So here is my solution:

One vu (visual unit) is the vertical distance between two lines of
body text than can be comfortably read. You write your code in vu
units. Layout managers compute vu units, not pixels. You specify your
fonts in vu units.. The user calibrates his monitor/eyeball
combination to define just how big a vu is in pixels, and the entire
OS and all apps honour than setting. You might have slider on the
task bar to temporarily change that setting.

In actuality you might still work in integral pixels, it is just
before you start you calibrate using the vu to pixel constant.

The vu might get started as a System.getVU() that you optionally use
in your GUIs to scale fonts, frame sizes etc. It would start out as a
system property the user could configure with a SET VU=20 parameter to
at least make conforming Java apps behave.

 

[Oliver Wong]

You want a human centred unit, something like an em, but that takes
into account legibility. You don't need fonts quite as big if they are
meticulously rendered. It has to take into account the size of the
monitor, its resolution, the visual acuity of the viewer.

So here is my solution:

One vu (visual unit) is the vertical distance between two lines of
body text than can be comfortably read. You write your code in vu
units. Layout managers compute vu units, not pixels. You specify your
fonts in vu units.. The user calibrates his monitor/eyeball
combination to define just how big a vu is in pixels, and the entire
OS and all apps honour than setting. You might have slider on the
task bar to temporarily change that setting.

In actuality you might still work in integral pixels, it is just
before you start you calibrate using the vu to pixel constant.

The vu might get started as a System.getVU() that you optionally use
in your GUIs to scale fonts, frame sizes etc. It would start out as a
system property the user could configure with a SET VU=20 parameter to
at least make conforming Java apps behave.

Excellent idea, and excellent timing, as I think the feasibility of this
idea (on the Windows platform at least) is not possible without the
additional features that Windows Vista has over Windows XP. Drawing in VUs
means that things you wish to draw might not line up neatly on pixel
boundaries, so some sort of anti-aliasing has to occur. Up until recently,
it would seem unreasonable to antialias *EVERYTHING* (e.g. the border of the
JFrame, if the top left and bottom right corners of the JFrame didn't happen
to lie exactly on a pixel boundary). But now that Windows Vista is
essentially going to treat all surfaces as planes in a 3D environment, I
expect antialiasing to happen everywhere "for free" anyway.

The only problem I can see with this is that now the developer can make
zero assumptions about screen real estate. That is, a person who has a
particularly severe sight disability with a particularly small monitor (e.g.
they're running your application on their cell phone) might choose a ratio
such that 1 VU is greater than the height (or width!) of the entire screen!

- Oliver

 

[Roedy Green]

Drawing in VUs
means that things you wish to draw might not line up neatly on pixel
boundaries, so some sort of anti-aliasing has to occur.

PostScript has dealt with this problem for a long time. Java could
use the same sorts of solution.

The problem is getting more ever more acute as the resolution range of
display devices diverges. Even $100 printers are doing over 1000 dpi
resolution. Then one the other end you have cellphones with dinky
little displays. As LCD technology cheapens, you will see meter wide
displays or virtual screens made up of several monitors.

Another sort of approach is to use a Java equivalent of CSS style
sheets that deal with specifics of size, font, placement etc. so that
code no longer deals with pixels for the most part. I would imagine
these styles/skins would let you customise the way you enter and
validate data. They would handle much of the internationalisation.

 

[Raymond DeCampo]

Excellent idea, and excellent timing, as I think the feasibility of this
idea (on the Windows platform at least) is not possible without the
additional features that Windows Vista has over Windows XP.

Windows APIs have had this mechanism for a long time. The units are
referred to as dialog units. The application deals with dialog units
and the graphics environments deals with the translation to physical
units (be they pixels on a screen or dots on a printed page).

Drawing in VUs
means that things you wish to draw might not line up neatly on pixel
boundaries, so some sort of anti-aliasing has to occur. Up until recently,
it would seem unreasonable to antialias *EVERYTHING* (e.g. the border of the
JFrame, if the top left and bottom right corners of the JFrame didn't happen
to lie exactly on a pixel boundary). But now that Windows Vista is
essentially going to treat all surfaces as planes in a 3D environment, I
expect antialiasing to happen everywhere "for free" anyway.

The only problem I can see with this is that now the developer can make
zero assumptions about screen real estate. That is, a person who has a
particularly severe sight disability with a particularly small monitor (e.g.
they're running your application on their cell phone) might choose a ratio
such that 1 VU is greater than the height (or width!) of the entire screen!

- Oliver

Ray

 

[Stefan Ram]

Windows APIs have had this mechanism for a long time. The
units are referred to as dialog units. The application deals
with dialog units and the graphics environments deals with the
translation to physical units (be they pixels on a screen or
dots on a printed page).

Possibly information one can obtain from the current
look-and-feel (from UIDefaults and UIManager) might help?

I assume that the current look-and-feel must know which font
size the user can comfortably read, so I might use this
information (about a "default" font of the current
look-and-feel). For example, the width of an "M" in that font
might become my "em" unit, the height of an "x" in that font
might become my "ex" unit and everything else might be given
in these units.

I do not really understand the meaning the argument in
UIManager#getFont(Object), I would like to use something
like "getFont(null)" to get a reasonable default font in
a reasonable size for readable text, indepently of the
specific look-and-feel used. I found code like:

font = UIManager.getFont("Button.font");

And I found this:

When colors or fonts are needed, the correct technique is
to use the methods getColor(Object key) and getFont(Object
key) of the class javax.swing.UIManager. These methods
take a key that identifies a color or a font as a
parameter, and they return the corresponding color or font
as it is defined by the current PLAF. Unfortunately, the
list of the available keys is not documented. However, the
keys are included in the source code of the class
javax.swing.plaf.basic.BasicLookAndFeel.

http://www.research.ibm.com/journal/sj/424/willuhn.html

 

[Roedy Green]

Windows APIs have had this mechanism for a long time. The units are
referred to as dialog units.

In windows what controls the conversion factor from dialog units to
pixels? Is it a fixed number for screens and one based on paper size
and printer resolution for printers?

 

[Raymond DeCampo]

In windows what controls the conversion factor from dialog units to
pixels? Is it a fixed number for screens and one based on paper size
and printer resolution for printers?

I believe the dialog units are based on the font used. But we are
treading into an area where I am far from an expert.

Ray

 

[Tim Tyler]

The problem is getting more ever more acute as the resolution range of
display devices diverges. Even $100 printers are doing over 1000 dpi
resolution. Then one the other end you have cellphones with dinky
little displays. As LCD technology cheapens, you will see meter wide
displays or virtual screens made up of several monitors.

LCD bricks. Let us build monitor walls ;-)