2.0 Development

[JavaDude]

I've been using 1.9.xx builds lately on win32 and it's getting very stable. I'm extremely impressed with the feature sets they are pushing into 2.0. From the Toolbars to general UI tweaks, 2.0 rocks.

Any estimates on when we can start hacking NeoOffice/J on 2.0 source code and start the hackin' ?

JsD

[OPENSTEP]

The general idea is that we're gonna work first at getting 1.1 Final, based off of 1.1.4. Next would be a "1.5" style release, potentially, the first with aqua widgets. Then a "2.0" style release would try to move towards the latest code. The main thrust is getting something stable for users.

One of the primary goals that Patrick has carved into stone is stability. Thou shalt have a stable product...and it's worked very well for the minimal staff he's had, well, himself I think that's a very healthy approach to take, especially with a project that's such a gargantuan task that's potentially fraught with many pitfalls.

ed

[sardisson]

...and while the 1.9.x milestones can finally build from start to finish on Mac X11, I've yet to hear that the resulting binaries from those builds actually launch/run

Smokey

[OPENSTEP]

For what it's worth, moving NeoJ up to 2.0 is a nontrivial task. It will involve breakage as well as need to adapt to the underlying changes in OOo itself. NeoJ will be on a 1.1 base for its first full release, definitely, and most likely the release after that. There are two good reasons:

1) Moving to OOo 2.0 will likely break things in NeoJ. It's going to happen for sure. Not to mention that once 2.0 is released, people will start finding bugs in it on other platforms and it'll have to go through a couple "point" releases before it becomes rock-solid anywhere. By now, 1.1 is rock-solid and that helps isolate whether bugs are in OOo or in NeoJ.

2) Moving to 2.0 is "maintenance" work. And maintenance work is frightfully dull and unrewarding. Personally, I'd rather spend time making a nice Aqua product then working on maintenance...and since I don't get paid for my time...I get to spend it how I choose

For me personally, moving to 2.0 is not a high priority. Aqua is higher then it along with moving to one of the newer Java 1.4 or 1.5 virtual machines instead of crufty Carbon 1.3 (so I can start playing with new useful things that have no Carbon interface, only Cocoa). All three are gargantuan projects, all three will introduce instability and bugs

For me Aqua and opening up new Mac OS X technologies is the priority, not pandering to the folks that "need" 2.0 when they really haven't thought about adapting their work requirements to 1.1.x (which is eminently functional, I might add).

Patrick may have a much different view than I, but be warned not to "trivialize" the amount of work it will take to move to 2.0. It could easily be 1 yr+. If someone has an absolute dependency on a 2.0 feature, they can always use the X11 version. That's why it's there!

ed

[pluby]

[rays]

As one of those currently rolling out NeoOffice/J throughout our offices around the world to replace our dependency on M$ Office, I want to endorse very strongly the position taken here by Patrick et al with regard to 'stability' as the corner-stone of development, over 'additional features'.

Am I alone in having the impression that the volume of 'bug' related questions in these forums has slipped away to virtually nil since the release of Patch-4 for 1.1 beta? That being the case, I am very comfortable with the fact that Patrick and Ed can capitalise on the associated reduction in stress related to bug-fixing and choose their development path for future versions according to their perceptions of the balance between their interests and the needs of the consumers. Right now, this particular consumer has everything he needs running beta + patch 4.

More than half the 11 iMac G5s which we are currently deploying are now in the hands of end users in our office. Reaction is generally positive and, so far, not a single 'bug' to report.

Sure, we've had 'incidents' where staff report 'faults' but each of these cases have resolved to underlying differences between the more familiar M$ Office 98 features and files and those underpinning OOo. To give but two examples: a password protected Excel spreadsheet couldn't be opened in NeoOffice/J so we opened the file in M$ Excel, removed the password, opened it in NeoOffice/J and applied OOo password protection without any problem (just a little extra time); a 'printing problem' with an ex-Excel file resolved to incorrect Sheet formats defined in the original file which M$ Excel had clearly been able to workaround for itself, we just had to correct each of the worksheet sizes in the offending workbook in NeoOffice/J and the 'printing problem' was no more. Both excellent training opportunities for everyone involved as we all agreed together that there were no 'bugs' involved.

Something which helps set NeoOffice/J apart from other open-source projects is that it supports my users to begin to see the tremendous potential of open-source developments just because NeoOffice/J immediately feels so familiar to those who have worked with generations of M$ Word versions from 4.0 to the present day's offerings for the Mac.

Those working in single language settings might never appreciate the value of having such a huge range of language versions available to an international organization such as ours, and a word processor that delivers right-to-left and left-to-right language sets in the same document at no additional cost. I know that this range owes its existence to the far wider OOo community but NeoOffice/J is the conduit that delivers all that to us on Mac OS X. If I have to choose between the 40 languages currently available with 1.1.4 and (so far) 2 languages with 2.0 code, I'll not be in the vanguard of early adopters of 2.0 !

That's the breakthrough here: NeoOffice/J is the proof of concept that Mac users need no longer be dependent on a commercial office suite and can switch to open-source and gain better features than they paid for previously. Evangelising just got a whole lot easier!

Please keep it this way: rock solid!

Ray Saunders
Director, Information Technology
World Scout Bureau

[pluby]

Rays,

[moonlight]

Hello,

I'm new to NeoOffice/J and would like to contribute to it.
Well, i was thinking about the look and feel...I've read (propably on the OOo site) that the problem of porting to native MacOSX is that the message handling/windowing system doesn't work at all like X11.
Well, couldn't it be possible to use the display component of OOo alone on a document window, and build a totally new UI around it.
If you compare to Ms Office:vX, it does not have the same interface at all compared to the windows' one.
Maybe i'm wrong, but i've got the feeling that making an interface/adapter to the document object would be easier.

[OPENSTEP]

That actually is incredibly difficult to accomplish. There's no description of the API by which that could be accomplished, so that'd need to be written (OfficeBean doesn't work due to difficulties with its underlying structure). There is also a fair bit of "comingling" of the UI code with functional code inside of OOo. It doesn't have a clean split between the two.

One of the biggest reasons, though, is just the sheer immensity of the user interface. Being an office suite, huge portions of the application are nothing but UI. Hundreds of dialogs, hundreds of icons, etc. As OOo continues to evolve, new UI elements are being added all the time and old ones are being tweaked. I suspect it'd take a long time to just mockup every dialog in IB, regardless of the engineering challenges beyond that.

Still, I think it's a great suggestion and hope at some time in the future to be able to define an API to the point where OOo becomes a "framework" and can then be dropped into other Cocoa apps like what's possible with WebKit. For a number of reasons, however, that will probably be a long ways off

ed

[rays]

[techniq]

I truely respect the requirement for a stable office suite, which NeoOffice/J is providing. However, I'm currently doing a bit of work on Linux with OOo 2.0beta using the Base portion with forms. Unfortunately, these are not usable by the OS X users. Any chance of providing Base support?

Thanks.

[ovvldc]

[pvmstg]

Hi, With the x86 base mac around the corner do that will ease or reduce the speed of stabilisation and adoption of the code from v 2.o?

In clear, do the macintel will bring sooner the v2 neooffice java or if the type of port to aqua whon't chage a thing?

[val1984]