Re: [crossfire] Am interested in porting to Mac
Le Jeudi 11 Août 2005 01:25, Amorya North a écrit : > I'm interested in porting Crossfire to MacOS. > > I know that the existing client can be made to run on MacOS - I am > using it myself. However, it requires Apple's development tools to be > installed, an X server running and a lot more technical knowledge > than most users possess. If we had a native client, it might become > more popular amongst Mac users. > > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C > object. That does depend on my learning exactly how the existing > client works though! > > I write this message looking for opinions. Do you think it's a good > idea? Anyone interested in seeing such a thing? One reason for taking > on the project is for me to learn more about Cocoa, especially > relating to graphics - so all is not lost if I'm the only one using it! > > Please post your thoughts. > > > Amorya > Just from my experience compiling the sdl-alpha releases of client on mac os x, the common part compiles without any problems using x-code IDE, the most difficult part, i'll say, was to get the sdl libs and dependencies to compile statically (so mac os x users don't need to install bunch of libraries before using it) and get xcode to use relative paths for includes instead of absolute ones (never achieved it but didn't search much). However, a cocoa based client would be cool :) If ya need help for beta testing don't mind asking but i unfortunately have no time to help early developpement (i simply don't have time to learn cocoa & such) > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
Quick notes on how the common stuff works: The GUI aspect of the client controls its own event loop. All it needs to do is check the network socket to see if it has input, and call do_network(). do_network() then reads the data and parses it, taking care of the protocol and making function calls on its own. In some cases, this results in function calls back to the GUI area. the common/external.h lists the functions the common area will call. In some cases, the gui functin call may do nothing at all - it may just provide that function because _some_ clients do something with that. The common area also sets up data structures - the most notable of these is the_map structure which is what the map looks at. Other things it maintains is the players inventory, stats, etc. In the case of the opengl client, it basically doesn't do anything with the disaply_map_..() functions, other than to set that the map has changed. It then just redraws the map on its own timeframe (basically when there is no input left on the socket). I have no idea if this callback method works with objective C. But as others have said, if you can continue to use the common area, it certainly will save you work in the long run - while the protocol may change, these functions and data structures are less likely to change. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
Amorya North wrote: You may want to build it within the existing framework and link directly to the C code in the common directory, because that way this native MacOS client could eventually become an official part of the source tree, and one advantage of that is that many protocol changes would be handled from the code in the common directory which would then make handling such changes in the MacOS port very easy. Yeah, that'd be good. I use an IDE instead of makefiles, so it wouldn't be tied into the build system (unless someone else helps me out there), but I could keep all my code in one folder (macos/ or something) and any Mac users who want to compile from source could open the project file from within there. It absolutely doesn't need to be tied into the make build system, the win32 compile of the gtk client for one uses a MSVC project file for the building, though I'm sure that there would probably be someone willing to attempt to help integrate it into the make build system. For a location to put your project file for your IDE I would personally suggest making something along the lines of what the make_win32/ directory does for the win32 builds. Also, yes I highly suggest putting it in one folder as you say in something like a macos/ directory. (personally I would suggest calling it cocoa/ instead as it's not so much a macos port as much as a cocoa port IMHO) Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
On 11 Aug 2005, at 01:00, Alex Schultz wrote: Another option is that someone could build the existing GTK client with gtk-cocoa (http://gtk-cocoa.sourceforge.net/), which would allow it to run without the X server running and such. It's worth looking into. I don't know specifics about gtk-cocoa but most cross-platform widget converty things tend to give back a bizarre amalgamation of the original look-and-feel and the Mac one, which is often worse than either of the two extremes! The test image shows a fair few things which just look 'wrong' to a Mac user - even if many of them can't put their finger on why. (It's mainly things where the original app goes against Apple's interface guidelines - like having boxes within boxes, or centre aligned field labels, or a series of buttons within a scrollview. All fine (I guess!) for a GTK app, but makes the app feel out of place on a Mac.) The advantage of such a port would be that it'd be quicker to make, and it'd make the finished product as simple as a drag-and-drop install for users. The latter is my main goal, so it's worth considering. However, at the moment I'm thinking that if it's worth doing it's worth doing properly. This is partly because of this quote: "At present, Gtk+-Cocoa is functional but incomplete. Because of the approach chosen for the port, each Gtk widget had to be mapped to the corresponding Cocoa control. Given the number of Gtk widgets, many of them have not been mapped yet or only provide partial functionality." Also, if I'm making an effort to bring Crossfire to Mac users, I may as well do so in a form that as many of them as possible will find easy to use and free from niggles. You may want to build it within the existing framework and link directly to the C code in the common directory, because that way this native MacOS client could eventually become an official part of the source tree, and one advantage of that is that many protocol changes would be handled from the code in the common directory which would then make handling such changes in the MacOS port very easy. Yeah, that'd be good. I use an IDE instead of makefiles, so it wouldn't be tied into the build system (unless someone else helps me out there), but I could keep all my code in one folder (macos/ or something) and any Mac users who want to compile from source could open the project file from within there. Thanks for your help! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
On 11 Aug 2005, at 01:24, Brendan Lally wrote: In theory all C code compiles to objective C as well. (I say in theory, I have never tried it in practise). If this is so, it should be sufficiant to take the common/ directory, and compile the C files there as if they were objective C and then add a cocoa/ directory to replace the functions provided by the existing x, gtk and gtk2 libraries. This should be easier than writing from the ground up, the common/ directory deals with things like command parsing, metaserver communications, client scripting, and various other bits too. alternitively, you might want to speak to techII who has a python client in some state of existance, it might be easier to go over that and replace the api calls with cocoa equivilents. And yes, I am aware that what I suggest is not the way that it is supposed to be done, but it is one that would probably work if your Makefile-fu is strong enough. I'll probably go for the common/ route if at all possible. I can definitely see the advantages... both for less coding on my part, and for easy updates. Am I correct that all the files in there are functions, and that the main event loop is specific to each different client? If so, it shouldn't be too hard to do things that way - I simply build objects which call the C functions directly when needed. It'll probably take a bit of a perspective change to work out how to read data from the socket in that way though! My last app that used sockets used a library that split off another thread to handle polling the socket, and whenever it found new data it messaged my main thread, giving me an event handler to respond to. I didn't code it myself - the instructions were just drop it in, and implement the newData: method, which will be called each time new data arrives. As far as I can see from a preliminary reading of the files in common/, then SockList_ReadPacket() is called to read data from the socket, and it returns true when there's a full packet ready to be processed. So I imagine somewhere in the event loop there is a call to that function, so it tests for new data each time through the loop... am I correct? This is starting to look like it could be a reality. I'll have to learn a bit more C (of the non-objective variety), and it may take a while, but the separation of your common/ code from the stuff specific to each client looks a big help! Amorya ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
On Thursday 11 Aug 2005 00:25, Amorya North wrote: > I'm interested in porting Crossfire to MacOS. > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C > object. That does depend on my learning exactly how the existing > client works though! In theory all C code compiles to objective C as well. (I say in theory, I have never tried it in practise). If this is so, it should be sufficiant to take the common/ directory, and compile the C files there as if they were objective C and then add a cocoa/ directory to replace the functions provided by the existing x, gtk and gtk2 libraries. This should be easier than writing from the ground up, the common/ directory deals with things like command parsing, metaserver communications, client scripting, and various other bits too. alternitively, you might want to speak to techII who has a python client in some state of existance, it might be easier to go over that and replace the api calls with cocoa equivilents. And yes, I am aware that what I suggest is not the way that it is supposed to be done, but it is one that would probably work if your Makefile-fu is strong enough. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
Amorya North wrote: I'm interested in porting Crossfire to MacOS. I know that the existing client can be made to run on MacOS - I am using it myself. However, it requires Apple's development tools to be installed, an X server running and a lot more technical knowledge than most users possess. If we had a native client, it might become more popular amongst Mac users. If I go ahead with this, I'll write the client in Objective-C using the Cocoa API. Hopefully I'll be able to reuse some of the backend code (such as packet parsing) by wrapping it in an objective-C object. That does depend on my learning exactly how the existing client works though! I write this message looking for opinions. Do you think it's a good idea? Anyone interested in seeing such a thing? One reason for taking on the project is for me to learn more about Cocoa, especially relating to graphics - so all is not lost if I'm the only one using it! Please post your thoughts. Amorya Another option is that someone could build the existing GTK client with gtk-cocoa (http://gtk-cocoa.sourceforge.net/), which would allow it to run without the X server running and such. If you do make a native MacOS port with Cocoa, then remember to look in the 'common' directory in the client source tree, as stuff there is supposed to be applicable to all clients no matter the graphics toolkits and such used. You may want to build it within the existing framework and link directly to the C code in the common directory, because that way this native MacOS client could eventually become an official part of the source tree, and one advantage of that is that many protocol changes would be handled from the code in the common directory which would then make handling such changes in the MacOS port very easy. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Am interested in porting to Mac
I'm interested in porting Crossfire to MacOS. I know that the existing client can be made to run on MacOS - I am using it myself. However, it requires Apple's development tools to be installed, an X server running and a lot more technical knowledge than most users possess. If we had a native client, it might become more popular amongst Mac users. If I go ahead with this, I'll write the client in Objective-C using the Cocoa API. Hopefully I'll be able to reuse some of the backend code (such as packet parsing) by wrapping it in an objective-C object. That does depend on my learning exactly how the existing client works though! I write this message looking for opinions. Do you think it's a good idea? Anyone interested in seeing such a thing? One reason for taking on the project is for me to learn more about Cocoa, especially relating to graphics - so all is not lost if I'm the only one using it! Please post your thoughts. Amorya ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
