Novell is still working on improving the VBA support of its OpenOffice submission, and is therefore open to all sumbmissions of VBA macros which are not working on the OOo version of SLED 10. In the meantime the question is when – or even if – Sun will accept the patches for OpenOffice to get VBA support.
Sun may choose to accept the patches or not for its own StarOffice, but how would that matter for OpenOffice? Or is OpenOffice still tied to Sun somehow, and Sun calls the shots to what gets accepted in this community project? If so, something needs fixing, pronto.
Calc is maintained by Sun employees, as indicated here:
http://sc.openoffice.org/
–Ted
http://reverendted.wordpress.com
Sun may choose to accept the patches or not for its own StarOffice, but how would that matter for OpenOffice? Or is OpenOffice still tied to Sun somehow, and Sun calls the shots to what gets accepted in this community project? If so, something needs fixing, pronto.
I guess Sun has the last word of what comes in and what does not, someone has to take the lead in an open source project or it will become a big mess.
I don’t think Sun will not accept the patches because it’s a very important/wanted feature.
If they don’t, Novell and others are always free to create a fork of OOo, which is I think one thing Sun wouldn’t be very happy with, but as said, I think Sun will only be stimulating and supporting this kind of patches.
mkools:
It’s very unlikely that Novell would fork the OOo code. Novell has been a staunch advocate of OpenOffice.org since they bought Ximian a few years ago. It be against both OOo and Novell’s best interest to fork it up.
–Ted
http://reverendted.wordpress.com
P.S. Thanks for opening up an opportunity for me to call forth my inner Beavis.
I think it would be a mistake to not get full VBA support in OOo.
Especially considering that Mac Office is going to drop VBA support entirely in the coming version :/
Python would be more gooder.
No, it would’nt.
The need for VBA support in OOo is for people or enterprises that has many VBA macross doing a good job and does’nt want to rewrite all.
For new macross the language is secondary.
but in my opinion (as a daily user of both OO and MS Office for years), the single biggest lack of OpenOffice Writer as far as a serious word processing production tool is its horrible (and when I say horrible I mean downright terrible, bug-ridden, half-baked) implementation of comments/annotations, as well as tracked changes (though a bit better on that score), not to mention lack of a view akin to “normal” view in MS Word (and no, “web view” is not at all the same). It’s almost impossible to use in a collaborative environment (where documents must undergo review, as in many businesses/organization) for that reason alone. How about fixing the critical word processing functions first, and save some of the extra niceties for later. Of course OO is free so no complaints, but still I find the lack of focus on the real important stuff frustrating.
Zerohalo:
I agree with you that Writer seriosly needs comment/revisions to work for the people who need them. However, VBA macro support in Calc is something many customers have reported to us to be major adoption barriers within the business world. Far from being “extra niceties,” Pivot Tables and Excel macros were raised as the top adoption barriers by large enterprises and governments who wanted to adopt OpenOffice.org in Novell’s previous desktop. That’s why Novell chose to attack that problem.
–Ted
http://reverendted.wordpress.com
My bad, I should have been more specific in my post. You’re right that VBA macros in Calc is more than an “extra nicety”. I was referring to the implementation of VBA macros in Writer.
Since Novell is targetting businesses (particularly with SLED), I’m hoping that maybe they’ll see the value of fixing the comments/revisions implementation in OO so that they can promote OO (and by extension SLED) more with businesses and organizations, as Sun seems have dropped the ball on that one. I can tout the benefits of open-source until I’m blue in the face, but without proper comments/revisions, OO Writer will never be implemented in my company or others that I know of.
Zerohalo:
Thanks for clarifying. I’ll bring up the commments/revising tools next time I chat with Mr. Meeks.
–T
Thanks, Ted!
I hear ya brother! Though it’s more or less offtopic, these are the three things that I as a technical translator absolutely need – normal view, comments and change tracking. In that order of importance. I filed several issues related to them (some I think date back to 2001), but they still go unfixed.
Also, OOo Writer has the basic paragraph model wrong. Select a paragraph and you’ll see what I mean. You cannot reliably select only paragraph text or the paragraph as a whole with the associated formatting. Aaaaand don’t let me start on bullets and numbering, nested tables and cell merging 🙂
“Or is OpenOffice still tied to Sun somehow”
Sun has patents that really make OpenOffice their property.
mono clones VB, OpenOffice clones VBA. Such ambition!
Troll?: yes. True?: sadly.
While it may be sad, it’s reality. In order for businesses to migrate over to OO they need to have tools that are familiar to their users (who they don’t want to have to spend lots of time/money retraining), and they want to be able to use whatever little customizations they have without spending time/money rewriting them. Then, once you’ve weaned them, you can begin to introduce better concepts and take it from there.
Actually. unless I’m mistake, OpenOffice already has bindings for external languages. In theory, it should be possible for VBA to be done in Mono using Mono VB.
“Python would be more gooder.”
Tools/Macros/Organise Macros/Python
(Or you can select OpenOffice.Basic, JavaScript, or BeanShell)
I have used the OOo change tracking features when writing a book in MS Office format. Did everything I expected and the people at the other end had no idea I was not use MS Office.
Edited 2006-08-21 21:08