Posted: Wed Nov 24, 2004 6:35 am Post subject: What is in a Name? (or a /j)
NeoOffice, NeoOffice/J
To J or not to J
Here is my thought. It is kinda long about Names and Products.
First, what is the product of this group? NeoOffice. Neolithic Office to be specific. NeoOffice is the Mac OS X port of OpenOffice.org. NeoOffice is our product.
What about the versions? Well, right now there are two. (OO.oX11 is OpenOffice.org, not NeoOffice, for now at least) We have two versions of software, NeoOffice and NeoOffice/j.
Here is my thought. The product, despite methods, is NeoOffice. This is how the page should reflect the name.
However, the Version of NeoOffice currently usable and stable is NeoOffice/j 1.1 Alpha 2. The /j should be there for the version name/number, since it a distinguisher between the two versions.
As for the other NeoOffice, I propose we modify its name to be NeoOffice Aqua (or NeoOffice/a if you want to be consistant) and again, that would be its version name/number.
So for example, if you download the newest NeoOffice it would be version NeoOffice/J 1.1 alpha 2 (patch-5).
Thus the name, NeoOffice is the product, but the method of that product (Java or Aqua) is designated not in the product name, but the version name. I think this will help keep confusion to a minimum wrt our NeoWorld.
The discussion is scattered around in various forum topics, but I believe that NeoOffice is pretty much dead. That is why Neo/J has Aqua menus: Ed found it easier to add Aqua stuff to Neo/J than to add printing, save to PDF, copy and paste, etc. to NeoOffice.
So (correct me if I'm wrong Ed), we are really down to just one product: Neo/J. Also, there has been the suggestion to drop the /J from Neo/J and just call it NeoOffice. However, I felt that we should keep the /J through this release and then drop it when I port Neo/J to the OOo 2.0 codebase.
I'm very sad to see that we're not going to get a Cocoa/Aqua port anytime soon, if anytime at all. I always thought that this was the ultimate goal, especially with the 2.0 codebase. I was hoping that the learning from Neo/J would serve that goal. I still believe that you guys made tremendous work though, and I hope we'll see more of that in future iterations of Neo or Neo/J.
I'm very sad to see that we're not going to get a Cocoa/Aqua port anytime soon, if anytime at all. I always thought that this was the ultimate goal, especially with the 2.0 codebase.
I think you might have misunderstood my post. While NeoOffice is dead, that doesn't mean Aquafication is dead. Instead, we are Aquafying NeoOffice/J because it is much less work. NeoOffice and NeoOffice/J aren't really that different, they just started at different ends of the Aquafication task list. While NeoOffice jumped straight to getting Aqua menus, buttons, etc. working, NeoOffice/J started with getting the more time-consuming and less-exciting stuff (e.g. text layout, save as PDF, printing, copy and paste, etc.) fully native.
What many people don't realize is that implementing native code for all of that non-Aqua stuff like text layout, line and shape drawing, save as PDF, printing, copy and paste, etc. takes a huge amount of time. Every developer wants to jump straight to the Aqua stuff, but you can't do any of that until you get rid of the X11 code dependency. Sure, Apple's X11 has Aqua buttons, but then you have eliminated Jaguar support and you still won't have decent copy and paste or printing.
Contrary to what some people on the OOo dev@porting.openoffice.org say (most of whom have never even built OOo on a Mac), OOo 2.0 won't make this work any easier. That's why we are going to slowly Aquafy Neo/J.
Please correct me if I'm wrong (and regardless, this is another topic for the FAQ/wiki), but Neo/J is going to end up in exactly the same place as Neo "hoped" to end up, a fully-native, good-Mac-citizen office suite, no X11 needed, OOo-compatible (indeed, 99% identical to OOo!) and with Aqua menus, buttons, scrollbars, dialogues, etc. The only difference between the two is that Neo was to be purely Cocoa/ObjC in its native Mac-only code (the core of OOo is primarily C or C++?) while Neo/J's native Mac-only code is largely Java (with C, C++, and ObjC as well).
Do I have that right? If so, there's really no difference between them (from an end-user pov) and that brings us back to Oscar's duck analogy: 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.
(I'd always found the standard "difference between Neo--NeoCocoa?--and Neo/J" statements confusing, because NeoCocoa obviously had to remove the X11 dependency as well, so it was doing both X11 removal and Aqauafication, right? Except the first focus was more on the pretty blue objects than on getting the core stuff working properly without X11.)
Pardon my bluntness here, but I think the "/J" is an imposing, technical-sounding, and entirely unnecessary addition to what is otherwise a clean and appealing product name.
Now, I'm not a marketing person, but I very strongly suspect that if you put the two names "Neooffice" and "Neooffice/J" side-by-side in front of a layperson and say "which of these two products is going to be easier to use, the "slash J" thing is simply going to confuse them.
"Neooffice" - new office. It's much cleaner. If the "aqua" version (and by that I mean the dead-end other version) is truly going nowhere, then can we please, PLEASE drop the techiespeak "/J" and append a modifier to THAT version?
Even from a technical POV, adding the "/J" sounds like a caveat that it is in some way "less" than the real port. I mean you've got plain old "Neooffice" and then there's this strange other version.
Also, for whatever reason, "Java" has some baggage that will unnecessarily hamper adoption of Neooffice for many users. It's bad enough that some people respond to the non-Apple interface with the assumption that (1) this is written in java, and (2) therefore it is slow. I think there may even be a residual memory of the horrible Word 6.x port running through people's heads that because it's not 100% "native", it's going to suck. The Java bias makes it worse.
In short, I think the current "/J" version has demonstrated itself to be "the way" for aquifying OO.o, and as I understand will be the method pursued into the future.
So for god's sake, for all that is decent and holy, for the children and rainbows and puppies, I beg of you-- drop that "/J".
Posted: Wed Nov 24, 2004 12:49 pm Post subject: what exactly is Aqua?
In any case I am wondering if we are falling into a nasty bit of semantic confusion:
What exactly makes an Aqua application?
I decided to consult the Apple introduction.
AFAICT, and correct me if I am wrong:
Aqua is a way of interacting with the user. To be an aqua application, the program must conform to Aqua Human Interface Guidelines.
This can be achieved through constructing the program in:
-Java (cross platform in principle, used by NeoOffice/J)
-Carbon (sort-of OS9 compatibility mode, used by Mozilla/Firefox)
-Cocoa (new framework developed for NeXT/Mac OSX)
While Cocoa is the fastest and most integrated way of having an Aqua application, this doesn't seem to be required. Currently, for reasons Ed and Patrick have explained several times by now, the Java road is going to lead most quickly to the prettiest results. I suspect a significant performance hit, but I am curious if anyone has made projections. OpenOffice is rather slow as well.
If I have read and remembered properly, the main reason is because OpenOffice.org is built around a UNIX and X11 event model, which is not easily integrated into the Cocoa model.
So I'd prefer to call what we currently describe as NeoOffice as NeoOffice/C (cocoa, carbon, whatever it exactly uses). This is because NeoOffice/J is (going to be) just as Aqua.
Jacob, you seem to work with Apple, please correct me if I am widly off the mark here.
So I agree in principle with Jacob about the names (with a different letter). In any case, Patrick and Ed think /J can be dropped by version 2.0 and I happily defer to their expertise, even if I would personally like to see it by 1.1 Beta .
In the mean time, Ed might be able to prepare for this switch by renaming the 'classic' NeoOffice to NeoOffice/C. Then the whole project (both forks) can be called NeoOffice. Then when 2.0 comes out, NeoOffice/J, by then equipped with text drag and such, can be released as the NeoOffice 'main product'.
This to reduce shock and keep people's perception in tune.
(and now I wonder if this should go on the Wiki somewhere...)
I don't work for Apple. but i'll take that as a compliment.
Basically what I said above goes like this.
There is a product, Microsoft Office.
There are versions, Microsoft Office v.X
so.
There is a product, NeoOffice
and there are versions, NeoOffice/j Alpha2
I do like the /C better than /A, i was never too sure about the 'aqua' thing, so thanks for clearing up.
ANd Yes, Patrick, Neo/C is on hold, I don't see it as dead though. We may see Longhorn before Neo/C... But we should still have a consise way of refering to it, even if it is how we talk about Ancient Spartans.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Thu Nov 25, 2004 6:00 am Post subject:
Personally, I believe it would be a shame to drop the /J entirely as it reflects the history of the development of the app. However, a very simple solution would be to call the product a simple "NeoOffice" and transpose the J to the version number so it becomes:
NeoOffice J-1.x or NeoOffice 1.x/J
(which I think is similar to what Jake is suggesting?). So in writing about the application, you can simply refer to "NeoOffice" and everyone will know what you mean. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Personally, I believe it would be a shame to drop the /J entirely as it reflects the history of the development of the app.
I'm in agreement here, but there certainly has been an indication that some people find the /J off-putting.
JKT wrote:
However, a very simple solution would be to call the product a simple "NeoOffice" and transpose the J to the version number so it becomes:
NeoOffice J-1.x or NeoOffice 1.x/J
(which I think is similar to what Jake is suggesting?)
The only problem with that (and really only with the J; any other letter would have been fine) is the historical Mac OS precedent of using J with a version number to indicate a wholly-Japanese-localized version of a software product (Mac OS 8.1J, etc.). So that might add to the confusion.
I think, ultimately, the best path might be to do as Patrick suggests: when we get to 2.0, call the product (presumably close to fully Aquafied) NeoOffice 2.0. We can make an argument at that point that NeoOffice 2.0 is the successor, and contains parts of, both NeoOffice O.O and NeoOffice/J 0.x/1.x
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.
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.
ROFL. Dude, you crack me up!
Wouldn't have been possible without you! Just paying homage to the duckmaster
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Nov 27, 2004 8:13 pm Post subject:
Boukman wrote:
I'm very sad to see that we're not going to get a Cocoa/Aqua port anytime soon, if anytime at all.
A lot of that is just difficulty and effort...basically...time. It's easier to achieve an Aqua look without Carbon or Cocoa due to the stability of Patrick's foundations. A relatively good summary is in this forum therad:
I basically made the decision to let the Cocoa stuff stagnate so i could lend a hand on the java stuff which was much more promising. Re-executing all of Patrick's work in Cocoa just isn't really feasible with our limited manpower since there are literally years of man-effort in it.
As to the /J or not to /J...
The big reason we did that originally was to differentiate the products but, of course, as one is becoming more then just a toy and a curiousity, thus the name change may eventually make sense. I think a good time to drop the /J is really whenever patrick feels like it (of course) but I think it'd be good to wait until we have other Aqua control bits in place and not just the menus. The moment it looks like a duck, I say we swim!
If I could be the devil's lawyer, the neooffice/j duck is FAT, and hungry.
The only doubt I have about the neooffice/j project is that there are not programmers that could work for code optimization, and Java richiest(s) for ram and virtual memory are high.
I buyed 512mb of ram for my powerbook 12'', only for use neooffice/j on my office, 'cause with standard 256mb it was useless.
I think this is a big gap in neooffice/p wall, 'cause neooffice/j works 'fine' only in new macs with a lot of ram. A lot of users I try to introduce to neooofice/j tells me 'sorry, TOO slow on my mac'.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
.
