On Tue, Jan 25, 2011 at 11:02, Richard Frith-Macdonald < [email protected]> wrote:
> > > But ... that shouldn't really be a big issue ... you can write one set of > socket code for OSX and another set for GNUstep since the GNUstep APIs > should be hiding the operating system dependencies from you. > If the app is already written, or if it's easier writing the netcode with sockets, you do that. Switching to NSStreams may be a pain. > > GNUstep has NSNetServices (Bonjour), Whoops :-) I did not check while writing the mail; everyone, accept my apologies. (I was quickly responding from my phone.) > but for sure there are things it does not have. We welcome contributions > to fill in any gaps. However, the fact that there are and always will be > gaps does not mean that the vast majority of funtionality is already > provided and porting is therefore immensely easier than it might otherwise > be. > Yes, but please consider the difficulty from the app writer's point of view: despite having most of the functionality, unless you write the app from scratch and are very careful writing it (which most people won't be), you're bound to run up against the wall when porting to a new platform or a new API, or even a different implementation of the same API. Anecdotal example: When choosing an engine for writing games, at work we picked Ogre3d, a cross-platform 3D engine, and Python, a cross-platform language. Things worked flawlessly on Windows. On Mac, we ran up against the wall of not having an official set of binaries, and build instructions being completely broken. Port time? A few months, involving mostly compiling Ogre3d, and then patching the game according to publisher's desires (stuff like: mouse must not be locked into the window). On Linux, we ran up against the wall of not being able to nicely perform statical linking of the binaries, or at least nicely update the search path. Things were moving a bit nicer than on Mac, and everything would probably take less time, but different projects took priority. Result? Since I was doing the porting, I will never look at it as something trivial again, unless the project was started with the intention of porting to other platforms from the start, and was verified to actually run on other platforms, and the work would be done by someone experienced on all platforms in question and experienced with *all *underlying technologies. > Sure ... but the point of GNUstep is to provide cross-platform APIs etc ... > so it *does* minimise the trouble with porting ... most of your code should > use the Cocoa APIs, and GNUstep provides additions for the common cases > where the Cocoa APIs are not sufficient (and we can always add to that). > > Porting is always extra ... but GNUstep lowers the boundary in a major way. > Unfortunately that still doesn't necessarily mean that people consider > porting worth the effort. GNUstep is excellent compared to a lot of other development environments! If nothing else, just having Foundation would be great. But most businesses cannot, and will not, sacrifice the development time to grab *potential* users when the *proven* money-spenders sit on their primary platform. This is the same reason why Mac didn't get a lot of software written for it for many years (compared to Windows), this is the same reason why Linux still overall doesn't get almost any commercial software written for it. I'm talking about greater public, not the enterprise environments; one of the biggest retail chains in Croatia runs their POS machines on Linux, and writing POS software is about as commercial as you can get. But that software is not targeted for the private citizen, and is not sold en-masse. And… I do believe the original question was about why there is so little ports of Mac software to GNUstep platforms. -- Regards, Ivan Vučica
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
