NetBeans does run on OS-X, as do other Java applications. But there are
a number of ways in which it does not meet the expectations of macintosh
users. We will explore the problems and potential solutions, starting with
those which are glaring but requiring the least work, and moving
into greater detail.
This document is a preliminary survey of areas known to be problematic
in NetBeans on OS-X. Difficulty is rated on an ad-hoc scale from 1 to
ten - these are off-the-cuff estimates trying to take into account as
much as I know about the problems involved as possible.
Feedback is welcomed - I am new to the Mac, so no doubt there are both
some omissions and errors.
As much as I am able, I will try to take the perspective of an
OS-X user in terms of the problems and solutions discussed here. Some
will be clearly beyond the scope of what we should do, but it is helpful
to review all of the options when prioritizing them.
The status notes "not started" vs. "not planned" should
at this time be considered recommendations - those that are not
started are ones I believe we could and should do; those marked
not planned are more questionable or more far-reaching changes.
To platform-specific code or not
NetBeans is by definition, a Java application - write once, run anywhere.
But, particularly with regard to the differences between the Macintosh
UI and other platforms, providing an optimal user experience requires
paying at least some attention to the expectations of users on a given
platform.
While the number of NetBeans users on OS-X is a small (but growing)
percentage, if we are to support a platform well, that means doing
the work to create a good user experience. It is my opinion that, while
we shouldn't go to the extreme of, say, providing an alternate Window
System based on Java-Cocoa, we owe it to our users to do what it takes
to make NetBeans feel like a natural part of their desktop. After all,
if we don't, they'll simply use a competing IDE.
The obvious stuff
The first items to mention are things that stick out like sore thumbs.
Many of them do not require heroic efforts to fix.
Does not use the screen menu bar
â Mac apps use a single menu shared between all
frames, displayed by the OS at the top of the screen.
NetBeans displays its own menu in its main window. This
can be fixed using a line switch, but there are currently
problems with context sensitive actions not appearing
enabled or disabled as they should be.
Solution: Locate and fix the menu enablement
problems, and set the system property to use the system menu
bar on startup.
Complications: None, other than diagnosing
what's wrong with our menus - possibly could be rolled into
other menu fixes mentioned below.
Hardcoded colors in window system (black text on dark blue)
and mix of Metal and Aqua components when using Aqua
â As of December 2003, the appearance of NetBeans on
OS-X with Aqua look and feel was embarrasing - unreadable text,
custom components showing up as Metal Look and Feel, etc.
Figure 1. NetBeans trunk as of 12-15-2003 in Aqua
Solution: Write Aqua-friendly UI delegates for
custom window system components.
Complications:
Best ways to do Aqua friendly UIs, access to Aqua classes.
Look and feel
â NetBeans needs to
default to Aqua look and
feel. This has already been provisionally changed, and it remains
to be seen if there are significant problems that should cause this
change to be rolled back. Solution: Make sure NetBeans works
properly with Aqua look and feel, provides UI delegates for
custom components that fit well in Aqua.
Figure 2. NetBeans trunk as of 12-30-2003 in Aqua
Note
The above screenshot does not perfectly match the development
trunk; it uses the brushed metal look, which, while attractive,
causes problems in dialogs, and contains the in progress implementation of
finder-style toolbars, which is not in the trunk, and should not be
used until after icon redesign. There is a different toolbar UI
which is also Aqua friendly which is in the trunk and should ship
with 3.6.
Complications:
Access to
Apple L&F classes, graphic elements (gradients, etc.) - we
should minimize the amount of code that might need to
be modified as Aqua evolves.
Keyboard shortcuts and menu accelerator
â On Apple machines, the role of the
control key on PC's is traditionally performed by the Command key -
positioned where the ALT or META keys are found on PC keyboards. Users
have cited this as a reason for switching to Eclipse - CTRL-based
shortcuts simply feel unnatural to Mac users.
Solution:
Switch to
using Command for all shortcuts when on Mac (probably make this
a line switch which is on by default for Mac). Scan entire
codebase for occurances of KeyEvent.VK_CONTROL â this can
be substituted with a call to Toolkit to find the appropriate key.
Complications:
Do we have any cases where
CTRL is mapped declaratively (layer files, etc.)? I don't know.
Also AFAIK editor shortcuts are defined completely independently
of the rest of the GUI - any problems here?
Documentation is affected -
apparently many applications simply include a caveat that on
the Macintosh, âcontrolâ means âcommandâ.
This needs to be evaluated by the docs writers and alternatives
also considered.
Any solution should not do strange things to the shortcut
and macro dialogs (such as either swapping Command and CTRL or
causing keystrokes that are entered using one key to show up as
if they were entered with the other).
OS vs. NetBeans keybinding collisions
â A number of standard NetBeans key bindings already
have mappings used by the OS. This problem gets worse if
we do switch to using the Command key as the menu accelerator -
this will cause more such collisions. For example, NetBeans
maps Ctrl-H to Search and Replace, while Command-H minimizes
the current window.
Solution:
Two classes of solution are possible: Automated solutions,
in which alternate keybindings are programmatically generated,
or manual solutions, in which NetBeans ships with multiple
keybinding mappings for different platforms. Using only
key bindings not mapped on any platform is not an option - that
leaves only obscure and inconvenient mappings, and few of them.
What I would recommend as an interim, low cost solution:
Keep a small list of platform-specific keys that should not
be mapped. When keybindings are loaded/created, remap those
that cause problems (the main problem on Mac will be the
Command key, so the logical solution for those cases is to
keep the conflicting ones bound to Ctrl). In the process,
also implement a long-standing enhancement request: The
ability to print a nicely formatted Keybinding Quick Reference
Card from the Welcome Screen. This way we can both provide a
reference which is accurate and document the differences with
minimal overhead for the documentation group.
Longer term, per-platform keybindings and using mappings that
better match per-platform user expectations is the way to go;
it is up to the editor team to evaluate if it is more work to
just do that up front, or amortize the cost over a longer
period by providing only programmatic remapping in the near term.
Complications:
Any programmatic rebinding of keys needs sanity checking by HIE and
real users.
Finder menu problems
â Finder, essentially OS-X's desktop shell, provides a
menu in the leftmost position which has application name and
a series of standard items such as About and Preferences. There
are a few problems: 1. The title of the menu is âorg.netbeans.Mainâ,
which is weird, and 2. The menu items do nothing useful (for
example, the About item shows a little dialog that just says
âJavaâ. 3. The Quit menu item does not invoke
NetBeans shutdown sequence, but brutally stops the process.
Solution: Implement Apple's ApplicationListener
class, and hide menu items (Options and About) in NetBeansâ
menus which properly belong on the application menu in OS-X and
put them there instead.
Complications: 1. Involves implementing Apple-specific
classes. Apple does offer a stub library that makes code using
their libraries compilable on other platforms. This would mean
a scrambler request/legal review to include it in the build process.
This issue also affect docs - the documentation would need to
somehow reflect the changed locations of these items, preferably
without requiring Apple-specific documentation. 2. The finder-menu
title can be specified by a system property, but it must be a
command line option - once the application has started, it's too
late to change it with System.setProperty().
Strange spacing in popup menus
â NetBeansâ popup menus on OS-X show up with
some menu items jammed together, some spaced as many as
20 pixels apart, with no apparent rhyme or reason to it.
This problem is visible on Windows and Metal Look and Feels as well,
but there it is a matter of 2-3 pixels, not 20. It is
probably an artifact of org.openide.awt.JPopupMenuPlus,
a class which works around some JDK 1.3 menu problems,
which also causes problems on all platforms using multiple
displays.
Figure 3. Popup menu spacing in Aqua
Solution: Assuming the diagnosis is correct,
to as great a degree as possible, eliminate NetBeans custom menu
classes.
Complications: Depends if our odd menu
code (a legacy of menus which were displayed, then added to by
other threads) is still doing anything we can't do another way.
Comments: As mentioned above, a solution of
switching to declarative actions could go hand in hand with solving
this issue
Metal-centric icon design
â NetBeans icons are designed in accordance with the
Java Look and Feel guidelines â assuring they only really
fit well when running Metal L&F, due to their âflush-3dâ
borders. They are also fairly dated, most having been last
revisited in 1999-2000.
In Figure 1. below, note the extreme simplicity of the icons
in the Finder toolbar â they do not even use color, and
both look attractive and communicate their functions clearly.
Solution: Hire a graphic artist to review/improve/
de-flush-3d-ify NetBeans icons.
Browser integration
â The default browser on 1.4.1 is the Swing browser;
it does not work at all for Javadoc in 1.4.1 - the html
source opens in a frame. The External unix browser might
work, but does not come configured properly. I've already
written an externalEditor extension using apple.eio.FileManager.showURL()
which handles the basics.
Solution: More complete integration is possible
via CocoaComponent to embed the OS-X Safari browser directly in
NetBeans. I have already written a trivial implementation which
does the most important thing - launches the system browser for
documentation or bookmarks - it is on a branch in the ExternalEditor
module.
Complications: Window system not tested with
heavyweight components; anticipate problems.
Difficulty: Basic impl: 1
Status: Basic impl completed, tighter integration
nice to have but not started.
The issues below would help NetBeans feel more natural on OS-X, but are
non-critical.
Help integration
â Even Java apps on OS-X are encouraged to use the
operating system's help viewer. We use JavaHelp in our own
help window.
Solution: The OS-X help browser uses HTML;
it needs to be investigated how well it could work with
JavaHelp content. We might be lucky and the integration
could be fairly easy. It probably wouldn't be easy.
Complications: Interprocess communication,
help file format compatibility.
Windows-centric window system
â OS-X UI guidelines stress a âdocument-centricâ
approach to user interface. NetBeans has moved in the
direction of document-centricness, but the UI is clearly
designed (or evolved) from MDI (anathema to mac users) and
reflects an different approach than would lend itself on the
Mac. Probably if NetBeans were originally designed for OS-X,
the following things would be true: There would be no main
window or toolbars. Each file would open in its own window.
The explorer, property sheet and other components would be
floating palettes aligned around the document window, which
would disappear when NetBeans was not active.
Solution: Possible solutions range from doing
nothing, to defaulting to an enhanced (or maybe dis-enhanced) SDI
mode for OS-X, to the extreme of a custom window system implementation
for OS-X.
Complications: Doing this right almost surely
involves Apple-specific classes, etc.
Comments: The idea of taking less responsibility
for window/document management and placing that responsibility squarely
on the window manager is appealing, and on OS-X, we have a window manager
that might be up to the job. That's much less true on other OSs, so
such a change could not be done across the board. But to move in a
Mac-friendly direction might not be a bad future direction for our
SDI support.
It is not clear that any window manager is
up to managing the volume of documents opened when, say, debugging.
However, we have long recognized the need to better understand which
files the user is actually using and which are simply opened for
transient use. So the number of documents we ask the OS to manage could
be made much more reasonable with some thoughful design.
Too many toolbars
â Macintosh UI guidelines specifically discourage the
use of toolbars; if they must be present there should be
few of them, with large icons and obvious uses. NetBeans
starts up by default with an icon salad above the editor. This
makes it look significantly different than normal OS-X
applications.
Figure 4. Toolbars in OS-X Finder
Note in the screenshot above the lack of complexity
of the icons (good heavens, they're monochrome!), and how
few there are.
Note
We have
an implementation of Finder-style toolbars that could be
put in place now, but it tends to emphasize just how
badly our icons fit on the desktop more than the current UI.
You can see it in the 12-30 development build screenshot
above.
Solution: Reconsider the use of toolbars in
general in NetBeans; either revamp them across the board, or
offer a smaller subset via defaulting some to hidden if os == os-x -
this is easy to do - modules like the External Browser module already
do similar things to offer per-platform configurations.
Complications: This needs to be approached by
someone willing to slay sacred cows.
Comments: This could be an opportunity
to revisit NetBeans approach to toolbars and measure how well
they serve our target audience on all platforms.
Window system layout incorrect after restart
â On every restart with the new window system, the
editor comes up 0 pixels wide, completely invisible between
two splitters.
Solution: Probably this is some different
behavior in the UI for JSplitPane. Diagnose it and fix it.
Use of Apple filesystem extensions
â HFS uses extension such as "creator" and "type" (similar
to mime types using Apple's proprietary system) - these are a
mechanism for ensuring that program that created a file is launched
when it is clicked, etc. Some Filesystem support for this would
be nice, to better integrate NetBeans with other desktop applications.
Solution: Possible custom LocalFileSystem for Apple?
This is far from critical.
Kill the launcher
â NetBeans currently ships with a launcher app which
supplies its own menu, etc. It sounds good until you use it -
all in all the idea of starting one program to start another is
strange and non-intuitive, and one system menu and another
application window menu is just weird. A better installer should be able
to simply call runide.sh to start NetBeans; this change should
be made as soon as it's possible to integrate NetBeans properly with
the system menu bar.
Solution: Better integrated launcher than the
current app.
Poor use of progressive disclosure
â Mac UI guidelines recommend âprogressive disclosureâ
to avoid a cluttered UI and present more information to the
user as it is needed. NetBeans (especially older portions of
it) tend to slam the user with all the detail they could possibly
need, whether they understand it or not (e.g. the CVS mount dialog).
A good example of progressive disclosure is the close buttons on
window frames in OS-X. Initially you see red, green and yellow
(a visual traffic-light metaphor)
blisters on the frame. Moving the mouse over them causes the
icon content to appear, indicating their function.
Figure 5. Progressive disclosure â Window controls on an unfocused window
Figure 6. Progressive disclosure â Window controls in a focused
window - they also serve as a visual cue indicating which window has focus
Figure 7. Progressive disclosure â Window controls in a focused window with the mouse within the drag bar
Better use of a progressive-disclosure approach could improve
NetBeans UI across all platforms.
Solution: Identify user interface components that
either do not need to be shown all the time, or could be simplified
considerably. The same for settings, etc. Hide controls like the
editor toolbar, when it does not have focus or NetBeans is inactive.
Complications: Basically means redesigning a lot
of stuff - generally, though, stuff that needs redesigning.
