NeoOffice and Aqua

From NeoWiki

Revision as of 22:03, 23 July 2005 by Sardisson (Talk | contribs)
Jump to: navigation, search

Frequently-asked questions about the design and development of NeoOffice/J, or "Everything You Don't Know About NeoOffice/J (and Should Read Before Posting on [Mac]Slash[Dot])"

Contents

Aquafication and Mac OS X Integration

Why doesn't NeoOffice/J have the typical Mac OS X "blue button" Aqua user interface?

Currently, NeoOffice/J does not yet include much "Aquafication". However, the developers are working on it!

The goal is to slowly add Aqua features to NeoOffice/J so that it becomes more and more Mac-like until there is no evidence left that it ever was anything but a Mac OS X application.

Over the past few months, NeoOffice/J has seen bit-by-bit improvements.

What are some recent Aquafication breakthroughs?

As of June 2005:

  • Dock menu with items from the "Quickstart" service (also found in the NeoOffice/J menu) (06/2005)
  • NeoOffice/J no longer shows the "grey window" when closing the last document window, but the application remains open, just like normal Mac apps (05/2005)
  • Spotlight integration on Mac OS X 10.4 "Tiger" via NeoLight (05/2005)
  • Uses colors defined in the Appearance pane of System Preferences (04/2005)
  • Support for Indic languages (04/2005)
  • Support for Eudora, Entourage, and Mail as external mailer applications (03/2005)
  • AppleScript for drag-and-drop installation of help files for non-English languages (03/2005)
  • Drag & drop between NeoOffice/J and other applications (03/2005)
  • NeoOffice/J no longer exits when clicking the red "close" widget on the last document window (03/2005)
  • "About NeoOffice/J" and "Preferences" items in the "NeoOffice/J" menu (02/2005)
  • Localized interfaces for 40 languages (12/2004)
  • New Aqua application icon and splash screen (12/2004)
  • Optimized/smaller PDFs (12/2004)
  • Text drag & drop (12/2004)
  • Scroll-wheel support (11/2004)
  • Native menus now appear in the white bar at the top of the screen, just like any other Mac program (previously, they appeared at the top of the same window as the document) (11/2004)
  • Automatic notification of new patches and versions (11/2004)
  • Patches available as standard Mac OS X installer packages (09/2004)
  • Support for Macintosh file aliases in open and save dialogues (09/2004)

Stay tuned as new features continue to be added!

Technologies and Toolkits

What technologies are used in the Aquafication of NeoOffice/J?

Aqua is the "look and feel" developed by Apple for OS X. Apple provides three frameworks for developing applications with an Aqua user interface:

  • Carbon (sort-of OS 9 compatibility mode, also used by Mozilla/Firefox)
  • Cocoa (new framework that was adapted from NeXT for Mac OS X)
  • Java (cross-platform language, includes JFC/Swing for native-looking UI elements)

NeoOffice/C (the original prototyping project) was an attempt to use Cocoa and Carbon. The more successful project, NeoOffice/J, currently uses a mix of Java 1.3 and Carbon.

So...is NeoOffice/J written in Java?

No.

NeoOffice/J is a Mac OS X native version of OpenOffice.org that uses small amounts of Java code for graphics drawing and configuration.

OpenOffice.org is written primarily in platform-agnostic C++. However, NeoOffice/J takes advantage of Mac OS X's advanced Java integration to tap into the Mac OS X look-and-feel. In other words, the "J" in NeoOffice/J primarily has to do with operations that affect how the application appears to the user. The "guts" of the office suite are written in C++. (The code that makes up NeoOffice/J is 99% OpenOffice.org code shared among all OpenOffice.org platforms and 1% Mac OS X-specific code in Java, C++, C, and Objective-C.)

Thus NeoOffice/J will only run on Macintosh computers running Mac OS X 10.2.x, 10.3.x or 10.4.x—not on Mac OS 9, Windows, Linux, Darwin, or any other form of UNIX.

How is Java used in NeoOffice/J?

As mentioned above, Java is mainly used to tap into the Mac OS X look-and-feel. What makes NeoOffice/J work isn't the Java language itself but rather the libraries that come with the virtual machine like Java 2D for drawing and AWT for menus. Those are actually already "native" in the Apple VM in the sense that Java 2D is really Quartz and AWT is really Carbon.[1]

The amount of Java used has also decreased over time. When NeoOffice/J was upgraded to the OpenOffice.org 1.1.2 codebase (NeoOffice/J 1.1 Alpha), text rendering switched from Java to the Mac OS X native ATSUI APIs since they are much more suited for complex text layout than Java is.[2] Other features were never implemented in Java at all (for instance the Dock menu, which uses Carbon).

Why aren't you working on a Cocoa version of an Aqua OpenOffice.org?

There are several reasons. OpenOffice.org is not built like a native Cocoa Mac application. Translating all of the event model, font management and display routines into Cocoa would be a great deal of work. On the other hand, Apple's Java implementation provides good access to Aqua features and is easier to meld with the underlying OpenOffice.org code. NeoOffice/C proved that a Cocoa implementation was not a viable solution in the short-to-medium-term; while it looked great after a lot of hacks, it was not stable enough for even casual use.

As it stands, NeoOffice/J is very stable and quite far along towards providing a fully-Aquafied user interface, and taking a different path now would be to throw a lot of good code in the trash. The downside to using Java is that is consumes (somewhat) more resources than a Cocoa implementation would. (You need more RAM than the minimum requirements for Mac OS X—but then Mac OS X benefits from having more RAM than its minimum requirements!—and RAM is cheap; adding RAM is the most cost-efficient way to speed up your Mac.)

Isn't Cocoa better than Java?

Aqua is aqua.

This question is most often asked by developers and power users. End users, on the other hand, tend to judge by the results. As one tester put it:

"If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant."

And, as John Gruber puts it, after quoting an Apple engineer posting to Carbon-Dev, "send [the second paragraph] to anyone who claims that only 'Cocoa apps are 'truly native' Mac OS X apps."

Isn't Java slow?

The majority of NeoOffice/J is written in C++. Only those bits that facilitate an Aqua look in Mac OS X were customized to use Java. The reason is that OS X Java looks terrific and hooks right into the native Aqua "blue-button" controls.

And by the way—Java isn't really that slow any more.

Why doesn't NeoOffice/J use Java 1.4.x or 1.5.x?

There are a number of reasons why NeoOffice/J uses Java 1.3.1, both human and technical. When NeoOffice/J was initially being developed, Java 1.4.x was not available on Mac OS X. When Java 1.4.1 did finally become available on Mac OS X, it proved to be quite buggy and was missing many key features on Mac OS X 10.2.x. Java 1.5 is only available on Mac OS X 10.4.x. Moreover, Java 1.4.x and 1.5 are Cocoa-based while Java 1.3.1 is Carbon-based.

Switching to a newer version of Java would not only involve dropping support for users of older versions of Mac OS X but would also require hundreds if not thousands of hours of time reimplementing the Carbon portions of NeoOffice/J in Cocoa and working around new bugs in the new Java versions. Switching to Java 1.4.x or 1.5 was not a viable option for most of NeoOffice/J's existence given the size of the development team and the fact that Java 1.3.1 continued to work well. However, Java 1.3.1 will not make the transition to Intel-based Macs, so efforts are currently (July 2005) underway to upgrade NeoOffice/J to Java 1.4.2.

Why not use gtk or Qt or some other cross-platform toolkit?

See and  :-) The short answer is that reworking the OpenOffice.org codebase to use another toolkit would take at least as much time and work as it has taken to get NeoOffice/J to the point where it is today (two years of nearly full-time work by 1.5 developers and additional work before that), with no guarantees that it would be as stable.

Moreover, in the case of gtk, the ports to Mac OS X are older versions of gtk and fairly incomplete. Even in the case of Qt, which has a modern and complete Mac OS X port of the toolkit, the existing OpenOffice.org work would not benefit an Aqua version of OpenOffice.org at all. The Qt/KDE OpenOffice.org (Native Widget Framework effort) is not a "native Qt" implementation of vcl (OpenOffice.org's cross-platform windowing toolkit and abstraction layer). All of the underlying font handling, drawing, etc., is still done using X11; it's only the widget drawing that is using Qt's equivalent of the appearance manager.[3]

Other Questions

Has NeoOffice/J replaced NeoOffice/C?

Yes, .

Is there a Development Roadmap?

The direction of the NeoOffice/J project is typically discussed in the NeoOffice/J Development forum on trinity. The current (post-June 6, 2005) plans of NeoOffice/J's two primary developers are outlined in this topic.

Where can I learn more about NeoOffice/J?

For tips on using NeoOffice/J, see the section of this Wiki.

I have another question about the design or development of NeoOffice/J; where can I get an answer?


This article in other languages:
Retrieved from "https://neowiki.neooffice.org/index.php/NeoOffice_and_Aqua"
Personal tools