Re:Wrong...will actually make native OOo wait long
on
Apple Switching to Intel
·
· Score: 2, Informative
The problem isn't necessarily gcc 4.0, but Apple's gcc 4.0. The ABI is different between PowerPC and x86. It's also a different linker and slightly different compiler. We've frequely had ICEs with the Apple gcc that didn't happen on Linux or Solaris. I suspect gcc 4 is in better shape than Apple's first gcc 3 releases on 10.2, but I wouldn't hold my breath until I can throw the templates with > 200 template arguments at it (yes, when expanded, several templates go that wild in the code).
ed
Wrong...will actually make native OOo wait longer
on
Apple Switching to Intel
·
· Score: 4, Informative
Disclaimer: I am an OpenOffice.org Mac OS X devleoper and a founder of the NeoOffice project
Quote: This means OpenOffice.org 2.0 will work *now*.
This means no more second-class Mac versions of popular OS apps.
This statement couldn't actually be farther from the truth. In fact, it will actually make the push for OpenOffice.org, at least, more difficult. If you dig into the details it means there's much more work ahead:
Most Unix based apps don't use XCode. Just about all Linux and Unix derived applications use command line build systems. According to the information from Apple, universal binary support only applies to XCode based projects. With hundreds of thousands of files and a custom build system, it would take years just to get OpenOffice.org to build with XCode and it may not even be possible.
Delivery of fat binaries is impractical for large open source applications. A single platform binary of OOo already clocks in at greater than 100 MB. People already complain about that size. A true integrated universal binary would probably close to double that size (though perhaps less due to use of cisc). Downloaders will love that.
To compile will require the use of GCC 4.0. I don't know about other projects, but moving OpenOffice.org to new GCC versions is a real pain in the butt. Code doesn't compile, options change, the way things link change, but, more importantly...
Apple is using their own ABI. OpenOffice.org requires knowledge of the ABI in order to get UNO objects to communicate (the OOo incarnation of COM). This ABI glue is coded in assembly and is unique for each compiler on each architecture (e.g. the gcc 2 C++ ABI is different from 3, which is different from 4, etc.). Since Apple is using their own ABI, code from Linux or Windows can't simply be moved over even if it is the same compiler. No work can begin on an Intel port until the ABI is solidified.
Linux apps don't use Carbon/Cocoa. The transition to a native OpenOffice.org will still require the type of work we're doing in the NeoOffice project, the piecemeal replacement of X11 dependencies with native code. Most people who speak of a native OOo on a Mac don't give a hoot about X11, they want the one with the blue buttons.
Apple isn't offering hardware to people not in their developer programs. Few contributors to open source projects have funds already, but the fact that one has to be a member of one of their paying developer programs will make it even more difficult for Mac open source contributors to get a grasp on the Intel switch. It was bad enough with Tiger where we didn't have access to test things before it got released, and that was just software!
Changing processors does nothing to help OpenOffice.org development on Mac OS X except slow it down yet again. Chances are you'll probably see it running in an emulator for a long time before it's running on Mactel hardware.
The difference was more that a much higher percentage of Netscape code was developed in private (skins, etc.). Very little of StarOffice is actually withheld from the community besides those import filters, clip art, and dictionaries. StarOffice, by contrast, actually even has tags in the OpenOffice.org repository indicating the exact code from which it's being built:)
We can't address startup time too much as a significant portion of it is taken up by both the Java 1.3.1 VM overhead and the parsing of all of the Mac font info. This is one of multiple reasons we need to consider moving to Java 1.5 (no small task given the amount of 1.3.1 VM specific Carbon workarounds in the code).
In the meantime all we can do is recommend to users that they leave Neo/J running. Patrick recently made this a bit more common since closing the last document using the red close button in the window no longer exits the application; the user has to explicitly use Quit from the menus to exit.
The release times are dfiferent primarily because we have different priorities. It's difficult enough to work out all the bugs in our existing graphics layer. Moving to 2.0 requires significant amounts of re-engineering, yet again. There are also a number of equivalent major tasks that have to be weighed against each other:
Getting things stable enough so we can have a Neo/J 1.1 Final release!
Fixing crashes that occur when operating system updates occur
Getting font layouts to match other Mac applications (this has taken years already and is still not perfect)
Adding in Aqua widgets beyond menus
Integrate with standard Mac OS X file dialogs
Continuing to support all of our supported languages (2.0 hasn't been fully translated yet)
Moving to Java 1.5 (requires moving from Carbon to Cocoa)
All of these tasks are at least as complicated as moving to 2.0. We've decided that higher priorities are getting to our Final release and improving our Mac OS X integration with things like our Spotlight & Aqua control integration. If someone really needs a 2.0 feature, the X11 version will be available for them to use. We'll start using 2.0 in Neo/J eventually, but it's going to require a lot of engineering and, being two people, we don't have the time.
For some more info you can check out this forum thread. There's some more stuff in previous/. comments I've posted as well.
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
One of the biggest reasons behind the SISSL license is of course StarOffice. When Sun open sourced StarOffice, not all of the code could be opened due to licensing agreements or third party contracts. Two prime examples are the dictionaries and spellcheckers in StarOffice 6 (L&H, I believe...they were replaced in OOo by Kevin H.'s spelling libraries) and the WordPerfect filters of StarOffice 6 (just finishing being replicated in an open source fashion).
So it's slightly different then Mozilla and Netscape...it was more of a solution that allowed them to open source as much of SO as possible without having to cripple their commercial product by removing code that was incompatible with the open soruce license. While all of the development is essentially publicly accessible (unlike Netscape), the SISSL license is still required to allow all of the contracted libraries to be included in the final commercial StarOffice product.
Originally OpenOffice.org was going to be released under the SISSL license only. LGPL was actually thrown in as an afterthought by the now departed former head of StarDiv. I'm glad it was since it let me make the transition to full GPL to avoid all of the closed source proprietary nonsense that SISSL allows:)
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
One thing about Neo is that we've never marketed it as a replacement for Office.mac. We've never marketed it really at all. You'll also find that we're very candid about saying that folks who want a great Mac experience should go out and buy Office.mac and that really, for its price, Office.mac is quite a good deal.
I personally enjoy using Neo because I don't have to worry about going to edit a document with Office.mac only to try to launch it and find out all of our licenses are in use on the network. Since I kicked Office.mac off of my machine I've never lost productivity due to someone forgetting to quit Word on another machine. I've also never had to rummage through to find a CD key when installing it on new partitions, portables, etc. and have never caught a Word macro virus from all of the infected files that run around as attachments in my e-mail folder.
Enjoyment is always relative to ones' needs, I guess. Office:mac is quite enjoyable, though, and I highly recommend it. It's nicer than the Windows Office versions, IMHO.
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
I personally agree with the parent...marketing something that's not yet ready is a horrible idea and bad impressions have worse long term damage than no impressions at all. Part of the problem lies with the way that OpenOffice.org was built as a community. Unlike Linux and some other FOSS projects, the community wasn't built up around engineers. There are very few engineers outside of Sun that actually are real major contributors to the project.
The OOo community was built around marketing. Finding community members to assist with marketing was one of the first and most successful community building drives for OOo. The marketing community behind OOo has done some amazing things and may be the reason why OOo has such mindshare over other open source office suites like KOffice (and Sun marketing has helped push OOo as well).
Honestly, OOo didn't get as recognized as it is today due to its underlying technical merit. It got there as the result of a lot of hard work by that marketing community. If any fault can be found, it may just be that they are overexuberant about OOo and may oversell it at times.
Neo's slightly different in that it was founded by engineers. There's no marketing push for Neo in any kind of organized fashion. There's no money spent on marketing it at all (all donations go to host our servers and for helping allow Patrick to work on it full-time). It's technical merit over OOo X11 is the only reason why it's known today. To me that seems like the logical path for FOSS.
I really don't see the necessity in marketing something that's free.
I know the plugin right now successfully extracts most of the metadata people insert into "File > Properties" dialog as well as some of the other metadata (like last person editing the doc). The text extraction from Writer, Draw, Impress, and Calc documents is in place but I have been unable to verify if it's working properly. I'm hoping that the dev tools in the release will provide a better way to get a handle on what the metadata server is doing with the MDTextContent keys as earlier builds gave no feedback for text content, only read/write metadata keys.
If you try it out, please give feedback in the NeoLight Development forum on trinity. While I know it's functional on prerelease builds, I haven't had the ability to check it on the release builds (my seeding key expired last Oct. prior to the newer Tiger builds).
One that probably isn't on the page may be the Spotlight plugin to allow for indexing of OpenOffice.org 1.x and NeoOffice formatted files. Unfortunately, I couldn't open source it prior to the Tiger release because the APIs were covered under NDA, but no longer!
The NeoLight metadata importer is licensed under LGPL and illustrates basic parsing of OOo 1.x formatted documents using CoreFoundation XML utilities. It's still in development and could use some developers to lend a hand testing, optimizing, and determining if we're extracting all the relevant content properly.
While I may be wrong on this one, my memory tells me that TigerDirect is a retailer and reseller. I would think their claim would fall under service mark categories. An operating system falls under material categories and would be a different classification then reseller services. If a court interprets it that way it'd be perfectly legit. For example, if I wanted to make a new pair of jeans and call them "Liquid Plumbr", it's all good since jeans are in a different class than household products. No one will confuse clothing with cleaners. The only thing preventing it is pragmatism...it'd be a stupid name for jeans.
What may blur the lines in this case is that Apple does have a retail division. I still think the "Tiger" name would fall in the realm of different classes of marks.
In a way both of them are really screwed since Princeton's used the Tiger name for a lot longer period of time then either Apple or TD has existed.
OS/2 actually wasn't a community porting project. It was killed before OOo was open sourced.
I'm not actually sure why the OS/2 work was dropped by Sun. It was deep sixed after StarDivision got bought out, so it may have been for some corporate reasons. The OS/2 versions of the underlying libraries were still in the old CVS branches, but no one stepped up to maintain them or revise them to the newer code bases. In theory, they could still be resurrected and brought up to SO 6.0/7.0 standards instead of the Odin (?) Win32 emulation that's being used by innotek for their OS/2 variant.
With crazy Java dependencies, however, it may be a bit more difficult now. I believe the last version of Java available for OS/2 was 1.3.1 but may be mistaken.
Disclaimer: I am an OpenOffice.org Mac OS X developer and a founder of the NeoOffice project
One of the biggest problems with Java in OOo is the way that it's being used. Probably the largest volunteer developer community outside of Sun is in the porting project which mostly aims to recompile OOo onto other Unix and Unix-like platforms. Part of the portability lure is that the older architecture of OOo made porting easy; OOo itself has its own internal complete abstraction layers for operating system functionality, windowing, widgets, and the kitchen sink. By simply porting those layers, OOo could run anywhere and even the most obscure Unix variant could have access to a MS Office compatible office suite.
Java breaks that. Why? Not all of the platforms on which previous versions of OOo could be built have any official Java implementation (e.g. Linux/PPC).
Now, Java is no longer optional. Java is actually becoming a requirement not only for running OOo. Some of the build tools are becoming implemented in Java. What's worse, many of these newer Java-dependent features and build tools actually require a specific version of the VM in order to be functional (e.g. reliances on libraries distributed with Java 1.4+).
This choice leave platforms without Java in the cold, but sadly it also leaves platforms with outdated Java VM versions in the cold. I only hope this doesn't further cause headache for some of the intrepid 64 bit porters out there since I don't know of any VM that can be safely embedded in 64 bit apps yet.
Porting developers have raised this issue as far back as 2002 and earlier. There's no excuse for the Sun-dominated engineering of OpenOffice.org to have been ignorant of them. Instead of lowering the bar for the build process, the dependencies have just been injected into core functionality! It's sad when the pleas of some of the most prominent non-Sun volunteers to the project get blissfully ignored by the powers that be.
I don't have a problem with using Java for open source software since, after all, NeoOffice/J is dependent on Java. As NeoOffice/J is focused solely on Mac OS X, however, portability isn't one of the NeoOffice/J goals. For OOo, however, portability used to be one of its strengths and is still one of the strongest development communities within the project that doesn't originate from Sun. It's sad to see decisions made that alienate one of the only vibrant non-Sun communities.
While OOo has built a great community of marketing, translation, support, and evangelization volunteers, there is no substantial core developer community outside of Sun. Alienating the precious little that exists doesn't help the situation either. Unless there is serious effort to build up a non-Sun developer community, the project can only be doomed for failure when Sun cuts their development team (or goes out of business).
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.
For the latest news, click the "News" link off of the NeoOffice homepage which will take you to trinity where our headlines and forums are posted. You'll find that there's new content in the forums every day:)
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.
It's not on pause at all, rather, we're essentially roaring towards our first final release. We actually released 1.1 Beta Patch 6 about a week or two ago which fixed many of the crashes introduced by the 10.3.8 update along with other font fixes (particularly asian languages) and some other stuff thrown in. Technically, that's the 6th major update to the Beta version this year.
An anonymous donor also recently raised funding to implement inter-application drag and drop between NeoOffice/J and other OS X applications, so work is commencing on that requested feature.
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
There's no support for them in Mac OS X because OpenOffice.org itself still runs in X11 on Mac OS X. The Native Widget Framework doesn't actually use native widgets at all. The way the NWF works is by introducing a new abstraction layer (first pioneered by NeoOffice/C) that allows the OOo SFX/VCL based widgets to call a platform-specific function that essentially translates to "draw a button background here" or "draw a scrollbar thumb here". On Mac OS X you can only get access to low-level widget rendering routnies through the Appearance Manager (Carbon) or the HIToolbox (Carbon/CG). Neither of those are available to X11 applications.
Besides...I think it'd be frustrating to have "Aqua-ish" buttons in an X11 app that can't even copy to the clipboard correctly. Kinda defeats the purpose putting the look onto an app that doesn't even have the right Mac OS X functionality, not to mention the "feel/UI design":)
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.
I don't mean to be a curmudgeon, but NeoOffice/J won't be available in a 2.0 beta anytime soon. There are a number of reasons:
2.0 isn't finished yet on any platform! We've already got so much on our plate that we simply can't spend our time working on such a large codebase that hasn't even yet reached code-freeze.
Mac OS X (X11) build support and testing for 2.0 isn't finished yet! In fact, it's only just begun. Because NeoOffice/J is built on top of the X11 base, we need to have a solid X11 version running and compiling before we can isolate whether bugs are inherent to Mac OS X or whether they are unique to the GUI replacement layer.
We haven't even finished NeoOffice/J 1.1! We're still working on trying to iron out all the bugs in the 1.1 based product. Moving to 2.0 is obviously going to introduce new bugs, and we can't consciously shoot ourselves in the foot right before a final release.
Translation of 2.0 isn't complete. NeoOffice/J supports localizations in over 40 languages, and we definitely don't want to leave any languages behind. We won't be considering moving until all of our supported languages are available.
2.0 is not the final 2.0.x release. This is just a matter of fact...2.0 will probably have bugs after it is introduced and will have another 2.0.1 release, a 2.0.2 release, etc. It's easy to get caught up in the hamster wheel of keeping up with the torrent of patches and point releases from Hamburg and we can't afford to lose focus and let native porting suffer.
Moving to 2.0 is going to be a lot of work. Definitely months worth of dedicated work, actually, perhaps even more than a year. Just going from 1.0 to 1.1 took Patrick over a year easy and we're still not finished with that jump yet.
There are higher priorites than moving to 2.0. While folks love to clamor for "feature parity", we have different priorities (well, I do, perhaps Patrick disagrees). I am more than happy to trade 2.0 features in exchange for working on and completing the equally complex Mac OS X specific tasks, including:
getting the first "Final" release of NeoOffice/J!
moving to Java 1.4/1.5...crucial for the long-term viability of Neo/J on Tiger and future operating system revisions. There's no sense in spending a year perfecting 2.0 only to find it won't run on the latest and greatest. We already have to work around crashing bugs in the 1.3.1 VM every time there's just a minor update (e.g. 10.3.7 -> 10.3.8), and there's gotta be only so many more updates for which we can find workarounds until the VM just plain no longer works.
implementing the NWF and other Aqua widgets
using native file dialogs
beginning to redesign the interface to adhere to Aqua HIG
We only have so much time available! Although Patrick is truly astounding, there really is only so much time available as we need to feed our families and pay the rent from time to time. With limited resources available and several large and very technical projects looming on the horizon, they need to get prioritized.
We're intending to backport the major feature of 2.0 that is required...OpenDocument format support. There are plans for an OpenOffice.org 1.1.5 release on other platforms that provides OpenDocument support which we hope to incorporate.
What's most likely going to happen is that we'll try doing a NeoOffice/J 1.5 release with Aqua widgets and other Mac-specific features and technical enhancements. Our #1 goal isn't to keep up with the most up to date OOo release, but rather, to make a great Mac OS X office suite. NeoOffice/J 1.1 is the most solid foundation upon which to build it since it's the most bug free.
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
The DLS was held right across from a gun show (credit to The MacRat for the photo. I'm impressed the guy in the penguin suit at the door didn't go bonkers from the sun, run on over and get a semi and proceed to mow down geeks at will.
<shameless plug>
Of course, for me the highlight was Simon Phipps call for recognition of NeoOffice admist a truly wonderful presentation arguing that open source is a natural evolution of a connected society that will effect a societal transformation, similar to the rise of artisan guilds. But I very well may be just a tad bit biased having been a visual aid...;)
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
The printing problem really isn't related to Apple X11 at all but is rather a problem with Unix application porting in general since there's no good standardized way to do printing for Unix apps. Each large Unix app tends to print things a little differently, usually relying on either Xprint or on other low level tools like lpr to get access to the Unix print queue.
OpenOffice.org/X11 doesn't use Xprint...rather, it generates its own PostScript. This PostScript then has to get converted into PDF which is inserted into the Mac OS X print queue using CUPS. This is the only way to port the printing system as used on OOo for Linux & Solaris. It is fragile for obvious reasons.
If you're having trouble printing with OOo the recommended workarounds are to either use another application to print out that PDF (like you're doing above) or to use NeoOffice/J. Because NeoOffice/J is using native graphics, it provides access to the native print system of Mac OS X as well. NeoJ will give you access to normal Mac OS X print and page setup dialogs along with the additional access to specific printer extensions and the Mac OS X PDF save, Fax, and Preview functionality. That really is the correct solution.
Even if Apple does provide better X11 printing functionality through Xprint or other frameworks, unfortunately OOo/X11 is not able to use them since that's just not how it prints.
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
That very well may be an interesting solution for the software restore CDs as well as addressing changes in layout of the CDs or OS versions (e.g. locating X11 on Tiger CDs which will become needed at some point this year). I hadn't thought about that and will check out some sets from computers that shipped with 10.3. I don't have any since I've not yet purchased a mac that had 10.3 preloaded. Thanks for the suggestion!
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
That's actually what the 1.1.2 GM installer does do. When installing on 10.3, if it detects Apple X11 isn't installed it prompts the user for the appropriate CD from the Panther retail set and searches for the package.
Only problem is that the installer is only intelligent enough to work with retail 10.3 CD sets...it doesn't have the ability to go through the software restore CDs that ship with computers since we don't have the CD layouts. Unfortunately, in the time since we've released it that's much more common for users as there are less and less users upgrading machines via retail CDs. The installer still prompts users without CDs to go to the Apple X11 website and has the URL displayed in a dialog.
Next installer I put together I'm going to see if I can make it a bit more helpful or at least be able to redirect users straight to the website to download the.pkg. Apple does have registration forms to fill out prior to download, so the procedure unfortunately can't be automated using a simple curl command.
Disclaimer: I am a developer of Mac OS X OpenOffice.org and a founder of the NeoOffice project.
FWIW, the screenshot that appears with that text is actually showing the package descriptions from the Fink project through the FinkCommander GUI and the article text is representative output from a Fink command line. Apple didn't write Fink (and certainly not its package descriptions) nor a bunch of the other software mentioned in the article (e.g. OpenOffice.org, xgalaga).
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
Yes, we could ship a different X11 environment, and this is what we do already to automatically install XFree86 + OroborOSX on 10.2 machines. There are really two problems with 10.3 machines however...
First off, Apple X11 really is nice in that you get your full quartz-wm that allows X11 windows to be minimized into the Dock and used via Exposé. Not many of the other X servers support this type of integration. I don't know myself since I haven't really investigated using too many other X servers on 10.3 systems. But, like other Apple software too, non-technical Mac users tend to want to use an Apple alternative if it exists.
Secondly, both Apple X11 and XFree86 do wind up using the same locations to install themselves:/usr/X11R6,/etc/X11,.xinitrc, and so on. As a result, you can't really install the two different X11 environments side by side as there are differences in some of the libraries (such as Open GL). This makes it difficult to include a different X11 environment in the distribution since there's a strong possibility of potentially horking someone's pre-existing Apple X11 install on the machine or the opposite of the user installing Apple X11 after the other environment and horking it.
The general feedback we got from users is that they really do prefer using Apple X11, so that's why the OOo installer only supports Apple X11 when installing on 10.3. Heck, there are still users who are still using the Apple X11 Public Betas that ran on 10.2! (note, if you do that, search out Beta 2 and not Beta 3...Beta 3 has window positioning bugs that can't be worked around since quartz-wm doesn't really have source shipped for it IIRC. good luck finding it, tho).
Disclaimer: I am a developer of Mac OS X OpenOffice.org and a founder of the NeoOffice project.
If the X11 server was preloaded onto all Apple systems, it would also solve quite a number of distribution problems for OpenOffice.org and other X11 applications. The license for Apple X11 doesn't allow third parties to bundle it and redistribute it. That makes it really frustrating from an installation perspective. Instead of being able to automatically install the X11 server (like we do using XFree86 for 10.2) we have to prompt the user to either go out and find where the X11User.pkg is on their Panther CDs or Software Restore CDs or even go and download it from Apple to install. Our installers can automatically install all of the other 6 applications OOo requires to run, but we just can't get Apple X11 so it kind of puts a dent in the installation experience.
I'm sure that other commerical appliactions like MATLAB would like to be able to auto-install X11 as well.
Preloading X11 onto all shipping systems would allow us to not have to worry about users getting confused by the additional steps of the process. Traditionally, Mac installers are very simple and it's rare they require other software to be installed first.
Another solution which would be equally good IMHO is if Apple could come up with some type of distribution clause in their license to allow X11User.pkg to be bundled with installers for other applications. I don't think the problem is the underlying XFree86 based stuff, but rather quartz-wm and maybe other components. Last I knew quartz-wm wasn't open sourced, only the XFree86 derived stuff under the MIT license.
Slashdot Mirror
The problem isn't necessarily gcc 4.0, but Apple's gcc 4.0. The ABI is different between PowerPC and x86. It's also a different linker and slightly different compiler. We've frequely had ICEs with the Apple gcc that didn't happen on Linux or Solaris. I suspect gcc 4 is in better shape than Apple's first gcc 3 releases on 10.2, but I wouldn't hold my breath until I can throw the templates with > 200 template arguments at it (yes, when expanded, several templates go that wild in the code).
ed
Disclaimer: I am an OpenOffice.org Mac OS X devleoper and a founder of the NeoOffice project
Quote: This means OpenOffice.org 2.0 will work *now*. This means no more second-class Mac versions of popular OS apps.
This statement couldn't actually be farther from the truth. In fact, it will actually make the push for OpenOffice.org, at least, more difficult. If you dig into the details it means there's much more work ahead:
Changing processors does nothing to help OpenOffice.org development on Mac OS X except slow it down yet again. Chances are you'll probably see it running in an emulator for a long time before it's running on Mactel hardware.
ed
The difference was more that a much higher percentage of Netscape code was developed in private (skins, etc.). Very little of StarOffice is actually withheld from the community besides those import filters, clip art, and dictionaries. StarOffice, by contrast, actually even has tags in the OpenOffice.org repository indicating the exact code from which it's being built :)
ed
We can't address startup time too much as a significant portion of it is taken up by both the Java 1.3.1 VM overhead and the parsing of all of the Mac font info. This is one of multiple reasons we need to consider moving to Java 1.5 (no small task given the amount of 1.3.1 VM specific Carbon workarounds in the code).
In the meantime all we can do is recommend to users that they leave Neo/J running. Patrick recently made this a bit more common since closing the last document using the red close button in the window no longer exits the application; the user has to explicitly use Quit from the menus to exit.
ed
The release times are dfiferent primarily because we have different priorities. It's difficult enough to work out all the bugs in our existing graphics layer. Moving to 2.0 requires significant amounts of re-engineering, yet again. There are also a number of equivalent major tasks that have to be weighed against each other:
All of these tasks are at least as complicated as moving to 2.0. We've decided that higher priorities are getting to our Final release and improving our Mac OS X integration with things like our Spotlight & Aqua control integration. If someone really needs a 2.0 feature, the X11 version will be available for them to use. We'll start using 2.0 in Neo/J eventually, but it's going to require a lot of engineering and, being two people, we don't have the time.
For some more info you can check out this forum thread. There's some more stuff in previous /. comments I've posted as well.
ed
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
One of the biggest reasons behind the SISSL license is of course StarOffice. When Sun open sourced StarOffice, not all of the code could be opened due to licensing agreements or third party contracts. Two prime examples are the dictionaries and spellcheckers in StarOffice 6 (L&H, I believe...they were replaced in OOo by Kevin H.'s spelling libraries) and the WordPerfect filters of StarOffice 6 (just finishing being replicated in an open source fashion).
So it's slightly different then Mozilla and Netscape...it was more of a solution that allowed them to open source as much of SO as possible without having to cripple their commercial product by removing code that was incompatible with the open soruce license. While all of the development is essentially publicly accessible (unlike Netscape), the SISSL license is still required to allow all of the contracted libraries to be included in the final commercial StarOffice product.
Originally OpenOffice.org was going to be released under the SISSL license only. LGPL was actually thrown in as an afterthought by the now departed former head of StarDiv. I'm glad it was since it let me make the transition to full GPL to avoid all of the closed source proprietary nonsense that SISSL allows :)
ed
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
One thing about Neo is that we've never marketed it as a replacement for Office.mac. We've never marketed it really at all. You'll also find that we're very candid about saying that folks who want a great Mac experience should go out and buy Office.mac and that really, for its price, Office.mac is quite a good deal.
I personally enjoy using Neo because I don't have to worry about going to edit a document with Office.mac only to try to launch it and find out all of our licenses are in use on the network. Since I kicked Office.mac off of my machine I've never lost productivity due to someone forgetting to quit Word on another machine. I've also never had to rummage through to find a CD key when installing it on new partitions, portables, etc. and have never caught a Word macro virus from all of the infected files that run around as attachments in my e-mail folder.
Enjoyment is always relative to ones' needs, I guess. Office:mac is quite enjoyable, though, and I highly recommend it. It's nicer than the Windows Office versions, IMHO.
ed
Disclaimer: I am a Mac OS X OpenOffice.org developer and a founder of the NeoOffice project.
I personally agree with the parent...marketing something that's not yet ready is a horrible idea and bad impressions have worse long term damage than no impressions at all. Part of the problem lies with the way that OpenOffice.org was built as a community. Unlike Linux and some other FOSS projects, the community wasn't built up around engineers. There are very few engineers outside of Sun that actually are real major contributors to the project.
The OOo community was built around marketing. Finding community members to assist with marketing was one of the first and most successful community building drives for OOo. The marketing community behind OOo has done some amazing things and may be the reason why OOo has such mindshare over other open source office suites like KOffice (and Sun marketing has helped push OOo as well).
Honestly, OOo didn't get as recognized as it is today due to its underlying technical merit. It got there as the result of a lot of hard work by that marketing community. If any fault can be found, it may just be that they are overexuberant about OOo and may oversell it at times.
Neo's slightly different in that it was founded by engineers. There's no marketing push for Neo in any kind of organized fashion. There's no money spent on marketing it at all (all donations go to host our servers and for helping allow Patrick to work on it full-time). It's technical merit over OOo X11 is the only reason why it's known today. To me that seems like the logical path for FOSS.
I really don't see the necessity in marketing something that's free.
ed
I know the plugin right now successfully extracts most of the metadata people insert into "File > Properties" dialog as well as some of the other metadata (like last person editing the doc). The text extraction from Writer, Draw, Impress, and Calc documents is in place but I have been unable to verify if it's working properly. I'm hoping that the dev tools in the release will provide a better way to get a handle on what the metadata server is doing with the MDTextContent keys as earlier builds gave no feedback for text content, only read/write metadata keys.
If you try it out, please give feedback in the NeoLight Development forum on trinity. While I know it's functional on prerelease builds, I haven't had the ability to check it on the release builds (my seeding key expired last Oct. prior to the newer Tiger builds).
ed
I released the NeoLight plugin yesterday which can index OpenOffice.org and NeoOffice/J formatted documents.
I had already posted this in an earlier comment in this article.
ed
One that probably isn't on the page may be the Spotlight plugin to allow for indexing of OpenOffice.org 1.x and NeoOffice formatted files. Unfortunately, I couldn't open source it prior to the Tiger release because the APIs were covered under NDA, but no longer!
The NeoLight metadata importer is licensed under LGPL and illustrates basic parsing of OOo 1.x formatted documents using CoreFoundation XML utilities. It's still in development and could use some developers to lend a hand testing, optimizing, and determining if we're extracting all the relevant content properly.
More information can be found in this trinity article.
ed
While I may be wrong on this one, my memory tells me that TigerDirect is a retailer and reseller. I would think their claim would fall under service mark categories. An operating system falls under material categories and would be a different classification then reseller services. If a court interprets it that way it'd be perfectly legit. For example, if I wanted to make a new pair of jeans and call them "Liquid Plumbr", it's all good since jeans are in a different class than household products. No one will confuse clothing with cleaners. The only thing preventing it is pragmatism...it'd be a stupid name for jeans.
What may blur the lines in this case is that Apple does have a retail division. I still think the "Tiger" name would fall in the realm of different classes of marks.
In a way both of them are really screwed since Princeton's used the Tiger name for a lot longer period of time then either Apple or TD has existed.
ed --- hates frivolous litigation
OS/2 actually wasn't a community porting project. It was killed before OOo was open sourced.
I'm not actually sure why the OS/2 work was dropped by Sun. It was deep sixed after StarDivision got bought out, so it may have been for some corporate reasons. The OS/2 versions of the underlying libraries were still in the old CVS branches, but no one stepped up to maintain them or revise them to the newer code bases. In theory, they could still be resurrected and brought up to SO 6.0/7.0 standards instead of the Odin (?) Win32 emulation that's being used by innotek for their OS/2 variant.
With crazy Java dependencies, however, it may be a bit more difficult now. I believe the last version of Java available for OS/2 was 1.3.1 but may be mistaken.
ed
Disclaimer: I am an OpenOffice.org Mac OS X developer and a founder of the NeoOffice project
One of the biggest problems with Java in OOo is the way that it's being used. Probably the largest volunteer developer community outside of Sun is in the porting project which mostly aims to recompile OOo onto other Unix and Unix-like platforms. Part of the portability lure is that the older architecture of OOo made porting easy; OOo itself has its own internal complete abstraction layers for operating system functionality, windowing, widgets, and the kitchen sink. By simply porting those layers, OOo could run anywhere and even the most obscure Unix variant could have access to a MS Office compatible office suite.
Java breaks that. Why? Not all of the platforms on which previous versions of OOo could be built have any official Java implementation (e.g. Linux/PPC).
Now, Java is no longer optional. Java is actually becoming a requirement not only for running OOo. Some of the build tools are becoming implemented in Java. What's worse, many of these newer Java-dependent features and build tools actually require a specific version of the VM in order to be functional (e.g. reliances on libraries distributed with Java 1.4+).
This choice leave platforms without Java in the cold, but sadly it also leaves platforms with outdated Java VM versions in the cold. I only hope this doesn't further cause headache for some of the intrepid 64 bit porters out there since I don't know of any VM that can be safely embedded in 64 bit apps yet.
Porting developers have raised this issue as far back as 2002 and earlier. There's no excuse for the Sun-dominated engineering of OpenOffice.org to have been ignorant of them. Instead of lowering the bar for the build process, the dependencies have just been injected into core functionality! It's sad when the pleas of some of the most prominent non-Sun volunteers to the project get blissfully ignored by the powers that be.
I don't have a problem with using Java for open source software since, after all, NeoOffice/J is dependent on Java. As NeoOffice/J is focused solely on Mac OS X, however, portability isn't one of the NeoOffice/J goals. For OOo, however, portability used to be one of its strengths and is still one of the strongest development communities within the project that doesn't originate from Sun. It's sad to see decisions made that alienate one of the only vibrant non-Sun communities.
While OOo has built a great community of marketing, translation, support, and evangelization volunteers, there is no substantial core developer community outside of Sun. Alienating the precious little that exists doesn't help the situation either. Unless there is serious effort to build up a non-Sun developer community, the project can only be doomed for failure when Sun cuts their development team (or goes out of business).
ed
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.
:)
For the latest news, click the "News" link off of the NeoOffice homepage which will take you to trinity where our headlines and forums are posted. You'll find that there's new content in the forums every day
ed
Disclaimer: I am a developer of OpenOffice.org for Mac OS X and a founder of the NeoOffice project.
It's not on pause at all, rather, we're essentially roaring towards our first final release. We actually released 1.1 Beta Patch 6 about a week or two ago which fixed many of the crashes introduced by the 10.3.8 update along with other font fixes (particularly asian languages) and some other stuff thrown in. Technically, that's the 6th major update to the Beta version this year.
An anonymous donor also recently raised funding to implement inter-application drag and drop between NeoOffice/J and other OS X applications, so work is commencing on that requested feature.
ed
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
:)
There's no support for them in Mac OS X because OpenOffice.org itself still runs in X11 on Mac OS X. The Native Widget Framework doesn't actually use native widgets at all. The way the NWF works is by introducing a new abstraction layer (first pioneered by NeoOffice/C) that allows the OOo SFX/VCL based widgets to call a platform-specific function that essentially translates to "draw a button background here" or "draw a scrollbar thumb here". On Mac OS X you can only get access to low-level widget rendering routnies through the Appearance Manager (Carbon) or the HIToolbox (Carbon/CG). Neither of those are available to X11 applications.
Besides...I think it'd be frustrating to have "Aqua-ish" buttons in an X11 app that can't even copy to the clipboard correctly. Kinda defeats the purpose putting the look onto an app that doesn't even have the right Mac OS X functionality, not to mention the "feel/UI design"
ed
I don't mean to be a curmudgeon, but NeoOffice/J won't be available in a 2.0 beta anytime soon. There are a number of reasons:
We're intending to backport the major feature of 2.0 that is required...OpenDocument format support. There are plans for an OpenOffice.org 1.1.5 release on other platforms that provides OpenDocument support which we hope to incorporate.
What's most likely going to happen is that we'll try doing a NeoOffice/J 1.5 release with Aqua widgets and other Mac-specific features and technical enhancements. Our #1 goal isn't to keep up with the most up to date OOo release, but rather, to make a great Mac OS X office suite. NeoOffice/J 1.1 is the most solid foundation upon which to build it since it's the most bug free.
Without substantial assistance (e.g. perfecting
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
The DLS was held right across from a gun show (credit to The MacRat for the photo. I'm impressed the guy in the penguin suit at the door didn't go bonkers from the sun, run on over and get a semi and proceed to mow down geeks at will.
<shameless plug>
Of course, for me the highlight was Simon Phipps call for recognition of NeoOffice admist a truly wonderful presentation arguing that open source is a natural evolution of a connected society that will effect a societal transformation, similar to the rise of artisan guilds. But I very well may be just a tad bit biased having been a visual aid... ;)
</shameless plug>
ed
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
The printing problem really isn't related to Apple X11 at all but is rather a problem with Unix application porting in general since there's no good standardized way to do printing for Unix apps. Each large Unix app tends to print things a little differently, usually relying on either Xprint or on other low level tools like lpr to get access to the Unix print queue.
OpenOffice.org/X11 doesn't use Xprint...rather, it generates its own PostScript. This PostScript then has to get converted into PDF which is inserted into the Mac OS X print queue using CUPS. This is the only way to port the printing system as used on OOo for Linux & Solaris. It is fragile for obvious reasons.
If you're having trouble printing with OOo the recommended workarounds are to either use another application to print out that PDF (like you're doing above) or to use NeoOffice/J. Because NeoOffice/J is using native graphics, it provides access to the native print system of Mac OS X as well. NeoJ will give you access to normal Mac OS X print and page setup dialogs along with the additional access to specific printer extensions and the Mac OS X PDF save, Fax, and Preview functionality. That really is the correct solution.
Even if Apple does provide better X11 printing functionality through Xprint or other frameworks, unfortunately OOo/X11 is not able to use them since that's just not how it prints.
ed
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
That very well may be an interesting solution for the software restore CDs as well as addressing changes in layout of the CDs or OS versions (e.g. locating X11 on Tiger CDs which will become needed at some point this year). I hadn't thought about that and will check out some sets from computers that shipped with 10.3. I don't have any since I've not yet purchased a mac that had 10.3 preloaded. Thanks for the suggestion!
ed
Disclaimer: I am a developer for Mac OS X OpenOffice.org and a founder of the NeoOffice project.
.pkg. Apple does have registration forms to fill out prior to download, so the procedure unfortunately can't be automated using a simple curl command.
That's actually what the 1.1.2 GM installer does do. When installing on 10.3, if it detects Apple X11 isn't installed it prompts the user for the appropriate CD from the Panther retail set and searches for the package.
Only problem is that the installer is only intelligent enough to work with retail 10.3 CD sets...it doesn't have the ability to go through the software restore CDs that ship with computers since we don't have the CD layouts. Unfortunately, in the time since we've released it that's much more common for users as there are less and less users upgrading machines via retail CDs. The installer still prompts users without CDs to go to the Apple X11 website and has the URL displayed in a dialog.
Next installer I put together I'm going to see if I can make it a bit more helpful or at least be able to redirect users straight to the website to download the
ed
Disclaimer: I am a developer of Mac OS X OpenOffice.org and a founder of the NeoOffice project.
FWIW, the screenshot that appears with that text is actually showing the package descriptions from the Fink project through the FinkCommander GUI and the article text is representative output from a Fink command line. Apple didn't write Fink (and certainly not its package descriptions) nor a bunch of the other software mentioned in the article (e.g. OpenOffice.org, xgalaga).
ed
Disclaimer: I am a developer of OpenOffice.org Mac OS X and a founder of the NeoOffice project.
/usr/X11R6, /etc/X11, .xinitrc, and so on. As a result, you can't really install the two different X11 environments side by side as there are differences in some of the libraries (such as Open GL). This makes it difficult to include a different X11 environment in the distribution since there's a strong possibility of potentially horking someone's pre-existing Apple X11 install on the machine or the opposite of the user installing Apple X11 after the other environment and horking it.
Yes, we could ship a different X11 environment, and this is what we do already to automatically install XFree86 + OroborOSX on 10.2 machines. There are really two problems with 10.3 machines however...
First off, Apple X11 really is nice in that you get your full quartz-wm that allows X11 windows to be minimized into the Dock and used via Exposé. Not many of the other X servers support this type of integration. I don't know myself since I haven't really investigated using too many other X servers on 10.3 systems. But, like other Apple software too, non-technical Mac users tend to want to use an Apple alternative if it exists.
Secondly, both Apple X11 and XFree86 do wind up using the same locations to install themselves:
The general feedback we got from users is that they really do prefer using Apple X11, so that's why the OOo installer only supports Apple X11 when installing on 10.3. Heck, there are still users who are still using the Apple X11 Public Betas that ran on 10.2! (note, if you do that, search out Beta 2 and not Beta 3...Beta 3 has window positioning bugs that can't be worked around since quartz-wm doesn't really have source shipped for it IIRC. good luck finding it, tho).
ed
Disclaimer: I am a developer of Mac OS X OpenOffice.org and a founder of the NeoOffice project.
If the X11 server was preloaded onto all Apple systems, it would also solve quite a number of distribution problems for OpenOffice.org and other X11 applications. The license for Apple X11 doesn't allow third parties to bundle it and redistribute it. That makes it really frustrating from an installation perspective. Instead of being able to automatically install the X11 server (like we do using XFree86 for 10.2) we have to prompt the user to either go out and find where the X11User.pkg is on their Panther CDs or Software Restore CDs or even go and download it from Apple to install. Our installers can automatically install all of the other 6 applications OOo requires to run, but we just can't get Apple X11 so it kind of puts a dent in the installation experience. I'm sure that other commerical appliactions like MATLAB would like to be able to auto-install X11 as well.
Preloading X11 onto all shipping systems would allow us to not have to worry about users getting confused by the additional steps of the process. Traditionally, Mac installers are very simple and it's rare they require other software to be installed first.
Another solution which would be equally good IMHO is if Apple could come up with some type of distribution clause in their license to allow X11User.pkg to be bundled with installers for other applications. I don't think the problem is the underlying XFree86 based stuff, but rather quartz-wm and maybe other components. Last I knew quartz-wm wasn't open sourced, only the XFree86 derived stuff under the MIT license.
ed