[crossfire] Am interested in porting to Mac

[Amorya North]

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