Posted: Sat Jun 11, 2005 11:59 am Post subject: Development plans for 2005 (and maybe 2006)
So now that the NeoOffice/J 1.1 official release is very near, I thought that now would be a good time to list the development plans for the next year or so.
The reason that I am posting this list is because the number of forum postings and bug filings that request changes to the standard OpenOffice.org features is increasing. After NeoOffice/J 1.1 is released, I expect that these type of requests will become more common. Hence, this posting provides a good summary of the scope of NeoOffice/J development. Note that this list assumes that Neo/J donations will continue at current levels. If Neo/J donations slow down, I will need to shorten the list:
2005
------
- Move Neo/J to Java 1.4.x - This needs to be done because it appears that Java 1.3.1 won't be available on next year's Intel version of Mac OS X.
- Implement Aqua widgets and file dialogs - This has been our goal for a long time and I would like to get this done while the OpenOffice.org volunteers are working out all of the bugs in the OpenOffice.org 2.0 X11 code.
2006
------
- Move Neo/J to the OpenOffice.org 2.0 codebase - Hopefully, by the end of 2005, the the OpenOffice.org 2.0 X11 volunteers will have a reasonably stable X11 version out. Assuming this proves true, we will upgrade the Neo/J code.
- Port the Neo/J and the OpenOffice.org 2.0 code to the Intel version of Mac OS X - It is becoming clearer and clearer that at some point, a separate Mac OS X Intel version of Neo/J will need to be needed.
In summary, NeoOffice/J development will be limited to making a native version of OpenOffice.org. No new features or changes to existing OpenOffice.org features will be done as the above list (which all need to be done to prevent Neo/J from becoming unusable on newer Apple machines) will severely strain our current development resources.
Posted: Sat Jun 11, 2005 2:33 pm Post subject: Re: Development plans for 2005 (and maybe 2006)
pluby wrote:
So now that the NeoOffice/J 1.1 official release is very near, I thought that now would be a good time to list the development plans for the next year or so.
The reason that I am posting this list is because the number of forum postings and bug filings that request changes to the standard OpenOffice.org features is increasing. After NeoOffice/J 1.1 is released, I expect that these type of requests will become more common. Hence, this posting provides a good summary of the scope of NeoOffice/J development. Note that this list assumes that Neo/J donations will continue at current levels. If Neo/J donations slow down, I will need to shorten the list:
Looks like you have you work cut out for you. As for the feature requests, I suggest we find some way to make clear that:
-Development is tough enough as it is, without plugging new features.
-Compatibility with OOo must be maintained at all costs.
And redirect all feature requests to OOo bugzilla instead. _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Jun 11, 2005 3:17 pm Post subject:
The Intel port is going to be *major* work for us, for those who aren't in the know on the technical details. After mulling over the little information that is available in the Universal Binary Guidelines, the following is now apparent:
PowerPC processes running in the Rosetta emulator from Transitive will not have access to any embeddable PowerPC virtual machine.
Not only will NeoJ be broken on Mactel machines, but also OOo X11 as a result of the decision to implement new features like base and new wizards in the Java language. It doesn't matter whether an app uses Java GUI elements or not; even non-Java GUI apps like OOo X11 won't be able to use any Java code that interacts with PowerPC based code.
To support Mac on Intel, the following is needed, though not necessarily in this order:
- Access to a Mac on Intel build machine. Without a native build platform we can't do requisite build work (either OOo X11 or NeoJ). And we don't have $1500 to pony up for a machine we can't keep, plus the extra $$ afterwards to actually buy a Mac on Intel based machine when the Apple lease expires and we have to return their machine to them!
- Ability to build on 10.4. I'm working on this right now. There's a crash in one of the build utilities on 10.4, rscdep, that I'm debugging. Important for us is that in the process of building we must continue to support compilation on Mac OS X 10.2. No way in hell are we going to abandon PowerPC or users of older operating systems unless we need to
- Ability to build on gcc 4. To qualify this more, we need the ability to build on Apple's gcc 4 that they distribute with xcode with whatever set of customizations and patches they apply or don't apply. OOo 2.0 is compiling with gcc4 on other platforms, but I'm unsure of the state of OOo 1.1.x on which NeoJ is based.
- Move to a newer VM. This has been planned for a long time since 1.3.1 is long in the tooth. It's a very non-trivial task since we have a lot of auxiliary Carbon based code that will need to move to Cocoa (the VM switched from Carbon to Cocoa between 1.3 and 1.4). It's now imperative since 1.3.1 isn't supported on Mac on Intel. It does not appear Apple is going to sublicense the source code for 1.3.1 for us to execute either an Intel compatible port or a standalone PowerPC version that can run in Rosetta.
- Implement gcc4 Apple ABI glue code for UNO. Right now Apple is using a System V based ABI (ironically including a "caldera.com" URL in their document). They make it clear that the ABI is not finalized yet, though. Unfortunately, OOo's UNO is intricately tied with the ABI and is written in assembly. It may take some clever reverse engineering to track changes to the ABI.
It's depressing because it's evident that neither NeoJ nor OOo 2.0 willbe able to run in the emulator. The depressing aspect is that we can't make them run without access to an Intel based Mac. We're an open source project and do this out of love. A $1500 + subsequent new machine purchase price (who knows what that will be, but prob. $1500+) just to compile (!)
Well positive thinking often helps.... I suppose there is some solace that some of the steps to intel are steps you'd want to take to move forward on PPC anyway.
Thought: Are you sure you want to maintain ability to build on 10.2 might it be reasonable to modify this to build for 10.2?
Crazy Thought: Is there a version of gcj for OSX that could compile the java bits and hence run under Rosetta 'cos no JVM is required? (very much not a long term solution)
Thought: Lobby Apple (perhaps along with other Open Source projects) to provide a build farm of a few OSX/Intel boxes which could be logged into remotely soley for the use of somehow approved OS projects. (I know this isn't the same as having one under your desk but it might be better than nothing)
Thanks for all your work, it's a great application,
David
Posted: Sun Jun 12, 2005 9:30 am Post subject: Re: Development plans for 2005 (and maybe 2006)
ovvldc wrote:
Looks like you have you work cut out for you. As for the feature requests, I suggest we find some way to make clear that:
-Development is tough enough as it is, without plugging new features.
-Compatibility with OOo must be maintained at all costs.
And redirect all feature requests to OOo bugzilla instead.
I would suggest that when we close these types of feature request bugs in Bugzilla (or discussion them in one of the forums), we just mention that the current scope of Neo/J is limited to keeping a native OOo version running on Mac OS X and then add a to this topic link.
It is only natural that new users will suggest new features. All that we can do is get the message out that development resources (i.e. Ed and I) are limited.
Posted: Sun Jun 12, 2005 11:30 am Post subject: Re: Development plans for 2005 (and maybe 2006)
pluby wrote:
I would suggest that when we close these types of feature request bugs in Bugzilla (or discussion them in one of the forums), we just mention that the current scope of Neo/J is limited to keeping a native OOo version running on Mac OS X and then add a to this topic link.
It is only natural that new users will suggest new features. All that we can do is get the message out that development resources (i.e. Ed and I) are limited.
Very true. But I think that quickly dismissing any deep OOo or non-aquafication related request will help in the long run, also in managing expectations.
If we just close OpenOffice issues as OpenOffice bugs, your slate can be kept relatively clean for all the work that must be done in NeoOffice. _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Posted: Sun Jun 12, 2005 12:43 pm Post subject: Re: Development plans for 2005 (and maybe 2006)
pluby wrote:
I would suggest that when we close these types of feature request bugs in Bugzilla (or discussion them in one of the forums), we just mention that the current scope of Neo/J is limited to keeping a native OOo version running on Mac OS X and then add a to this topic link.
It is only natural that new users will suggest new features. All that we can do is get the message out that development resources (i.e. Ed and I) are limited.
Posted: Sun Jun 12, 2005 5:52 pm Post subject: Re: Development plans for 2005 (and maybe 2006)
ovvldc wrote:
Very true. But I think that quickly dismissing any deep OOo or non-aquafication related request will help in the long run, also in managing expectations.
If we just close OpenOffice issues as OpenOffice bugs, your slate can be kept relatively clean for all the work that must be done in NeoOffice.
I agree completely. I was only saying that throwing in a link to the Neo/J scope topic might help give the bug filer some background as to why we close OpenOffice.org bugs and why they need to file their bug in OOo's bug tracking system.
Posted: Sun Jun 12, 2005 8:05 pm Post subject: Re: Development plans for 2005 (and maybe 2006)
pluby wrote:
I was only saying that throwing in a link to the Neo/J scope topic might help give the bug filer some background as to why we close OpenOffice.org bugs and why they need to file their bug in OOo's bug tracking system.
Indeed, new users and new bug filers often don't realize the "dividing line" between things that can be done in Neo/J and things that have to be done deep in the guts of OOo, and without a bit of explanation (and/or a pointer to the right place to file the bug) sometimes some of them get a little testy.
This will be even more important going forward since the limitations imposed by the need to get Neo/J on Java 1.4.x and so forth so it will run on future Macs will be much greater and since most people will not understand them ("Mathematica was ported in two hours and Apple already ported Firefox...").
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
thank you for the neooffice roadmap. and thank you for your work.
f.
ps. about rosetta. I'm talking about the angel's sex, but I do not know if rosetta could be a good solution for neooffice, even if it works. I read rosetta is based on Transitive software, and the translation is obliviuos more slow that a native application, and also Transitive uses a lot of ram to work to speed up the process. So, neooffice is quite slow by default and gets a lot of ram, java vm is slow on mac, rosetta is quite slow and uses a lot of ram... my fear is that neooffice could became a pachiderm.
Posted: Mon Jun 13, 2005 1:43 am Post subject: two comments
1. Rosetta shines where the application does little processing and calls a lot of OS APIs. The OS APIs run native, so the whole application is pretty fast. If the application does not call OS APIs, it will run like Windows on Virtual PC - slow. Open Office achieves its cross-platform abilities by doing most of the work (fonts, displays, windowing) all by itself. That is not a good candidate for Rosetta, even if it could run.
2. You have to find a way to get some transition kits. I wish Apple would donate some, but waiting for real machines ("products") can be very long. According to what we know, the first Macs with an Intel processor will be the laptops and maybe the mini. Cute machines, but hardly what you're looking for in a compilation server.
Posted: Mon Jun 13, 2005 2:42 am Post subject: Re: two comments
synp wrote:
1. Rosetta shines where the application does little processing and calls a lot of OS APIs. [...] Open Office achieves its cross-platform abilities by doing most of the work (fonts, displays, windowing) all by itself. That is not a good candidate for Rosetta, even if it could run.
In the case of Neo/J, Patrick has ripped a lot of that out (I think) and replaced them with native stuff. The real problem, as I understand it, is that hybrid "native-Java" apps can't run in Rosetta:
OPENSTEP wrote:
PowerPC processes running in the Rosetta emulator from Transitive will not have access to any embeddable PowerPC virtual machine.
synp wrote:
According to what we know, the first Macs with an Intel processor will be the laptops and maybe the mini. Cute machines, but hardly what you're looking for in a compilation server.
Well, IIRC Ed got OOo running on Mac OS X by building and debugging on a PowerBook and a Cube, so it's certainly possible he could port to Intel on a similar setup However, a deep-pocketed donor is still a better solution
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Mon Jun 13, 2005 3:56 am Post subject: Re: two comments
synp wrote:
2. You have to find a way to get some transition kits. I wish Apple would donate some, but waiting for real machines ("products") can be very long. According to what we know, the first Macs with an Intel processor will be the laptops and maybe the mini. Cute machines, but hardly what you're looking for in a compilation server.
Not to advocate piracy or anything, but rumour has it that the MacIntel development version of OS X has already been leaked to the piracy networks and that it works on hardware specced the same way as the official developer boxen. Hmmm, a moral dilemma? _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
it is unfortunate that rosetta will not be able to help the transition in Neo/J's case. however, if no dev box can be aquired, then we'll just have to go as we can. Those who get intel boxes can help compile and report bugs. hopefully it won't be a horrendous transition. hopefully.
All times are GMT - 7 Hours Goto page 1, 2, 3, 4Next
Page 1 of 4
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
However, a deep-pocketed donor is still a better solution 
