I knew about the donation and it is up and running (they now have a G5 system at Eric B's University where he teaches.)
Something else to do whilst I sit at the Laundry waiting, waiting, waiting. BTW, the move is finished, I handed the keys over to the new owners on Friday. Something tells me that I'm not to be a homeowner.
I have just been listening to Eric's presentation at OOo and I heard it there. Ed, Patrick, and other NeoOffice devlopers what is your feelings on the subject. Do you feel it would be best to continue the direction you are going?
If they are able to get a cocoa based version out how will that effect your development? _________________ Adam Moore
OpenDocument Fellowship
Adam.Moore@opendocumentfellowship.org
Demand Microsoft Support OpenDocument
http://opendocumentfellowship.org/petition/
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 02, 2005 10:32 am Post subject:
Well, it doesn't affect us since really the idea of moving OOo to Cocoa is one of those ideas that is an utter waste of time. Cocoa is a framework and is not suitable for building other frameworks. If an appliation isn't written according to the world-view of Cocoa it's not really going to work.
It's already been tried my myself and I abandoned it because most of the time it required Cocoa hacking...and Cocoa hacks aren't really supported by Apple and break when OSes get updated.
Replacing the Java+Carbon VCL implementation with Cocoa brings no benefits since they're just wrappers around the same system libraries anyway. Essentially, any work on recreating another VCL layer is just replicating the work Patrick's already done. They will fact the same years of bug fixing regarding font handling and kerning, print support, and the like. We've been trying to convey that for years.
Then again, perhaps they won't understand until they try to start on their own, read through all the code, and suddenly realize the futility of the task at hand and recreating something that's already finished.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 02, 2005 10:36 am Post subject:
FWIW I also have access to an x86 build machine and am commencing on work as soon as the gcc4 porting is finished. Right now I'm debugging issues in the type system as something either isn't loading type descriptions properly, isn't retaining references, or the like.
And no way in hell would I decide to do a universal binary. Doubles the size of the download, and there's no way that NeoJ would be able to run in Rosetta anyway.
FWIW I also have access to an x86 build machine and am commencing on work as soon as the gcc4 porting is finished.
Good to know. Good luck with that!
OPENSTEP wrote:
And no way in hell would I decide to do a universal binary. Doubles the size of the download, and there's no way that NeoJ would be able to run in Rosetta anyway.
Why would it exactly double the size? I understand that there is a lot of code involved, but I would think suppose a large portion of the package is artwork, dictionaries and so on. These should be the same under any CPU.
And I shudder to think that someone would write code that compiles into 100MB of pure routines. The complexity would be breathtakingly difficult to handle. Then again, this has been proven to be the case with OOo.. Hmm..
-Oz
P.S. Saw Howl's moving castle this afternoon. Really nice and a recommended film if like fairy tales and you haven't seen it yet. _________________ "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: Sun Oct 02, 2005 1:24 pm Post subject:
And to further judge the eventual success and technical choice, neither of the Erics are admitted programmers and frankly don't have the skillset to really tackle this problem or even come up with a good technical spec for its implementation:
They really have no knowledge of what Cocoa is, otherwise they would never announce they're going to rewrite using it. Even if they scrap the "chrome", the underlying VCL still needs to be ported. And you don't do framework porting in Cocoa.
Patrick's got decades of experience in Java and other environments and I'm a professionally employed Mac programmer with 14+ years of experience and have Cocoa experience back from NeXTSTEP days (thus the nick). We're both proponents of an incremental approach due to the largesse of this application and the underlying difficulty of this project:
Incremental engineering is the only approach to maintain application stability as well as continually provide an end-user suitable project.
Everone can choose to believe who you want to believe, but I know the futility of trying to mash the square OOo peg into the round Cocoa hole. And all of my old /C code is GPL...so they better not start looking at it for hints...
ed
Last edited by OPENSTEP on Sun Oct 02, 2005 1:39 pm; edited 1 time in total
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 02, 2005 1:32 pm Post subject:
ovvldc wrote:
Why would it exactly double the size? I understand that there is a lot of code involved, but I would think suppose a large portion of the package is artwork, dictionaries and so on. These should be the same under any CPU.
No, it wouldn't double the size exactly...that's just a slipshod estimate. It might come to 1/3 or something. FWIW, the OOo 1.1.2 X11 program directory comes to 169 MB while the resources subdirectory directory (one language) comes to only about 6 MB. While PowerPC code is expected to be somewhat larger (RISC vs. CISC), in my experience at my real job with the gcc 4 compiler is that the produced binaries are roughly on the same order of magnitude for both architectures. Thus roughly the size will double.
For a CD it's one thing, but for downloads each MB counts
The only real reasons to provide universal binaries are to ease deployment and to allow applications with third-party plugins to still run in Rosetta if the plugins aren't updated to run on the new platform (think Photoshop, Quark). Since the additional MB complicate electronic distribution and since there aren't really any compiled extensions for OOo OS X (macros, of course, are interpreted) the second reason doesn't apply. Carrying around the PPC code is just a waste of space on an x86 machine and vice versa.
The answer to whether to lipo the libs or not should be an obvious one
Well, it doesn't affect us since really the idea of moving OOo to Cocoa is one of those ideas that is an utter waste of time. Cocoa is a framework and is not suitable for building other frameworks. If an appliation isn't written according to the world-view of Cocoa it's not really going to work.
Sounds like they will have to go back and build a MacOSX specific version of OpenOffice, something they (the OOo community) will not like. But if that is what it takes, that is what it takes.
OPENSTEP wrote:
It's already been tried my myself and I abandoned it because most of the time it required Cocoa hacking...and Cocoa hacks aren't really supported by Apple and break when OSes get updated.
Replacing the Java+Carbon VCL implementation with Cocoa brings no benefits since they're just wrappers around the same system libraries anyway. Essentially, any work on recreating another VCL layer is just replicating the work Patrick's already done. They will fact the same years of bug fixing regarding font handling and kerning, print support, and the like. We've been trying to convey that for years.
You do have a valid point there. However, if it takes someone else looking at the situation, that may be what it takes. I used to work with a long term programmer (I'm a Systems Engineer by trade) and I had come up with solutions to problems he stated could not be fixed without years of work. My solutions took about two weeks. However, you have something he did not, actual experience trying to solve the problem. However, it never hurts to have a second (or third) set of eyes look at the problem.
OPENSTEP wrote:
Then again, perhaps they won't understand until they try to start on their own, read through all the code, and suddenly realize the futility of the task at hand and recreating something that's already finished.
True. But the real question is how much and how long will Carbon/Java be supported on the MacIntel version of MacOSX? Will Apple abandon us to the Cocoa world? If the latter is true, then work on a Cocoa version of OpenOffice makes sense, otherwise it may well turn out to be a waste of effort.
But the real question is how much and how long will Carbon/Java be supported on the MacIntel version of MacOSX? Will Apple abandon us to the Cocoa world? If the latter is true, then work on a Cocoa version of OpenOffice makes sense, otherwise it may well turn out to be a waste of effort.
Too many sine qua non platform apps (Adobe everything, MS Office, Quark, Macromedia, the Finder, iApps, etc.) are Carbon. Carbon's not going anywhere (plus many "pure" Cocoa apps have to use bits of Carbon to do things, since not everything can be done in Cocoa). Nor is Java, at least if you believe the "hype", it's attracting developers to the Mac (although do I hope Apple throws some resources into improving its Cocoa versions of Java, because, as we can tell from the PT patches, there are still bugs and slowdowns...).
And anyway, Ed and Patrick have already almost covered our you-know-whats with respect to MacIntel. We have Java 1.4.x and we almost have gcc 4. It's just a small step (well, a giant leap, I'm sure, but way smaller than 3 months ago) to MacIntel from there.
I don't wish anyone ill, but at this point a "native/Cocoa OpenOffice.org" has been proclaimed several times (not the least by the Sun clown who started the whole mess), and only NeoOffice/J has delivered a Mac-like end-user version of OOo. So until I see something else....
(And part of the reason I linked to the Daring Fireball post is because each further pronouncement that never materializes gives OOo a further black eye and makes it more of a laughing stock on Mac OS X. And that's not good for anyone. Except Microsoft.)
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Why would it exactly double the size? I understand that there is a lot of code involved, but I would think suppose a large portion of the package is artwork, dictionaries and so on. These should be the same under any CPU.
I think it depends on the app. I just did a quick and by no means complete look at Camino (unilang, so en-only). It's roughly a 22 MB app. Thereabouts of 19 MB is code and 3 MB in "resources", nibs, non-code Gecko stuff like DTDs and Gecko strings and so forth.
If we looked at Camino MultiLang or a Mac OS X app that shipped by default with support for 5-10 languages, you'd get closer to that 1/2 figure (I think each localization for Camino is about 1.3 MB)....
The latest OOo 2 version is 354 MB installed, English-only (and no converted fonts...that swells the app dir by another 200 MB). Even if half of that is "resouces", which I doubt, Universal Binaries would not be pretty....
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Oct 02, 2005 9:52 pm Post subject:
jjmckenzie51 wrote:
True. But the real question is how much and how long will Carbon/Java be supported on the MacIntel version of MacOSX? Will Apple abandon us to the Cocoa world? If the latter is true, then work on a Cocoa version of OpenOffice makes sense, otherwise it may well turn out to be a waste of effort.
Nope, Carbon and Java won't be abandoned anytime soon. Actually, some of Cocoa is implemented through Carbon too (menus, for example) adn a lot of it winds up just being callthroughs to the same foundation (HITheme, another Carbonish example...the button drawing is only implemented once and is then shared by all frameworks, Carbon, Cocoa, and Java). Plus MS Office uses Carbon
Cocoa has been positioned as a magic bullet and indeed for some things it is. It's a great RAD environment that works really well if you know how to incorporate your application's world view with its object structure, and Cocoa Bindings are the shiznit. That said, things that don't fit into its world view are really unwelcome. It's the achilles heel of framework design (also shared by svx/vcl, Qt, et. al.)...it's easy to tie things into the framework and its design patterns (MVC vs slots, etc.) that it can be difficult to fit it to another.
True. But the real question is how much and how long will Carbon/Java be supported on the MacIntel version of MacOSX? Will Apple abandon us to the Cocoa world? If the latter is true, then work on a Cocoa version of OpenOffice makes sense, otherwise it may well turn out to be a waste of effort.
Nope, Carbon and Java won't be abandoned anytime soon. Actually, some of Cocoa is implemented through Carbon too (menus, for example) adn a lot of it winds up just being callthroughs to the same foundation (HITheme, another Carbonish example...the button drawing is only implemented once and is then shared by all frameworks, Carbon, Cocoa, and Java). Plus MS Office uses Carbon
Ok. I get it now. Let's see: Two guys (and maybe more) who know a lot about programming try to get OOo to Cocoa. They work for man-months on it and finally abandon it. They pick up Carbon/Java and in a few weeks get a working demo out. A few more months and they actually have a release candidate and a few more months it is done. What's wrong with this? The effort was not completed by OO. So, OO goes back and tries to get the wheel moving again....
OPENSTEP wrote:
Cocoa has been positioned as a magic bullet and indeed for some things it is. It's a great RAD environment that works really well if you know how to incorporate your application's world view with its object structure, and Cocoa Bindings are the shiznit. That said, things that don't fit into its world view are really unwelcome. It's the achilles heel of framework design (also shared by svx/vcl, Qt, et. al.)...it's easy to tie things into the framework and its design patterns (MVC vs slots, etc.) that it can be difficult to fit it to another.
Yes, it can be a real pain. I've worked with a few projects that were supposed to work with gtk as well. Not fun when they 'blew up' and you were left with the results.
In any case, it looks like the MacOSX OO porting team is going ahead with the Cocoa work. Should be interesting to watch.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Oct 03, 2005 9:23 am Post subject:
<hits nail on head>
jjmckenzie51 wrote:
What's wrong with this? The effort was not completed by OO.
</hits nail on head>
It really comes down to being just a pissing contest that will result in a waste of resources. They will spend years replicating Patrick's work not for any underlying technical reason but only for the sake of putting it under a different name.
<tin foil hat>
I wonder if Sun is really behind this because we refuse to play ball by their rules.
</tin foil hat>
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
