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.

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 first items to mention are things that stick out like sore thumbs. Many of them do not require heroic efforts to fix.

  1. 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.

    Difficulty: 3

    Status: Not started

    Issuezilla: pending

  2. 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.

    Solution: Write Aqua-friendly UI delegates for custom window system components.

    Complications: Best ways to do Aqua friendly UIs, access to Aqua classes.

    Difficulty: 2

    Status: Provisionally solved

    Issuezilla: pending

  3. 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.

    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.

    Difficulty: 5

    Status: Provisional OS-X delegates pending review

    Issuezilla: pending

  4. 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:

    Difficulty: 2-5

    Status: Not started

    Issuezilla: pending

  5. 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.

    Difficulty: 3

    Status: not started

    Issuezilla: pending

  6. 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().

    Difficulty: 5

    Status: Not started

    Issuezilla: pending

  7. 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.

    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.

    Difficulty: 4

    Status: Not started

    Issuezilla: pending

    Comments: As mentioned above, a solution of switching to declarative actions could go hand in hand with solving this issue

  8. 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.

    Complications: None.

    Difficulty: $$

    Status: Not started

    Issuezilla: pending

  9. 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.

    Issuezilla: pending

The issues below would help NetBeans feel more natural on OS-X, but are non-critical.

  1. 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.

    Difficulty: 8

    Status: Not planned

    Issuezilla: pending

  2. 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.

    Difficulty: 10

    Status: Not planned

    Issuezilla: pending

    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.

  3. 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.

    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.

    Difficulty: 2

    Status: Not started

    Issuezilla: pending

    Comments: This could be an opportunity to revisit NetBeans approach to toolbars and measure how well they serve our target audience on all platforms.

  4. 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.

    Complications: ?

    Difficulty: 1

    Status: Not started

    Issuezilla: pending

  5. 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.

    Complications: More code to maintain.

    Difficulty: 4

    Status: Not planned

    Issuezilla: pending

  6. 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.

    Complications: Probably requires installer changes.

    Difficulty: 4

    Status: Not started

    Issuezilla: pending

  7. 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.

    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.

    Difficulty: 8

    Status: Not planned

    Issuezilla: pending

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 38 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close