is just too big, and its API is too different from Cocoa, to make this a realizable goal–unless Sun is going to start throwing as many programmer-hours at the Mac version as they do the Windows version. I’ve heard this before, and I’ll believe it when I see it.įrom what I understand, a Cocoa port is a project of unbelievable complexity.
– Because it’s difficult, time-consuming and expensive, given the fact that open source development DOES cost money unless it’s done by volunteers, which is not the case here – Because Macintosh developers are not very much interested in – Because Sun is not very much interested in the Macintosh platform > I am curious why a native port hasn’t been So it will be variant 1, this is the best from the users’ point of view, but the worst from the developers’ because ’s GUI actually needs to be rewritten. Variant 2 implies that the Windows and UNIX targets would have to be ported as well, which is too dangerous if we consider that the effort can actually fail. The best solution is variant 3, but it’s not possible because Qt’s licensing terms don’t allow it. What the guys did until now is variant 4. Use an API of another platform you already support on the target platform, even if it’s not native to the target platform. Use a library that implements a GUI completely independent from the platforms’ natives ones, like Qt.Ĥ.
Use a library that wraps around the target platforms’ GUI and hides it behind a platform-neutral one, like wxWidgets.ģ. Rewrite your application for every target platform.Ģ.
#NEOOFFICE FOR PC CODE#
Just recompiling the source code is absolutely impossible for GUI applications because there is no standard GUI! Every platform implements the GUI in a completely different way, therefore all GUI applications need to be rewritten for the target platform.ġ.
#NEOOFFICE FOR PC PORTABLE#
Source code is only portable if it uses standard libraries like the standard C library or the standard C++ library only, or if it’s an interpreted language and only build-in features from the interpreter are used. This is a frequent misunderstanding: “It’s open source and source code is machine-independent, so everyone with a compiler can compile the source code into a binary and that’s it.” > Openoffice is open source and Xcode ships with Tiger. You can see there is a hell of a lot of work involved in getting OO.o working and Xcode doesn’t do any of the work, its all done by the programmer. Why didn’t the programmers do that work before? First, there was only 2 of them back then (don’t know about that now), second, with OO.o the abstraction layer changed, so if they would have continued their work back then they would have had to do the work twice!
OO.o has an abstraction layer for this now what the programmer has to do is basically write the equivalency of all of that code NEW for MacOSX (or any other native port), that’s a hell of a lot of work. The GUI you see needs to be talked to and the API it speaks is deferent from OS to OS. Once that’s done OO.o runs on MacOSX so long you have X11, this is an important step, but now the hard part comes. Its not like Operating Systems are standardized on what they provide for programmers even with MacOSX being a Unix. To do that you sort out the non graphical parts, the build system and what not. First you actually get it to compile with something (X11 in this case). A native version of OO.o is not a recompile away.
0 kommentar(er)
