From kevinz5000 at gmail.com Wed May 7 20:25:59 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 07 May 2014 20:25:59 -0500 Subject: [crossfire] Update client GLib dependency Message-ID: <536ADD27.50501@gmail.com> Hi there, The GTKv2 client sources are split up into two parts, one for "common" code that can be shared across different clients, and a "gtk-v2" part that implements the GTK+ client itself. GLib is a very useful library that provides portable data structures, lexical scanners, threads, mutexes, timers, hook functions, and sockets. Currently it is only used in the GTKv2 client because it is a dependency of GTK+. I propose that GLib should be a dependency for the entire client. 1. There are lots of cool things that GLib will let us have that we don't have now. Dynamically allocated strings, advanced data types, and even a config file parser are all available from GLib. 2. GLib will make things more portable. I've been able to get the client building on Windows again, but it's still very messy, particularly due to excessive conditional compilation. GLib implements its own portable sockets that can be used on multiple platforms. 3. GLib will make things less broken. Connecting to a server is a mess, and sometimes freezes the client given the right circumstances. Threading, callbacks, and parsing are messy, too. 4. GLib is already a dependency. Besides, on my system, the library and all development files takes only 17 MB. Most people already have it installed, because it is a dependency for Gtk, Qt, and more. 5. Even if somebody decides to write another client using SDL, OpenGL, or maybe even Tcl, GLib can still be used and will still provide all of its happy shiny benefits. 6. You probably don't care, since you're using the must shinier and prettier and portable JXClient. So you should let me do whatever satisfies my evil wishes. Thanks, Kevin Zheng From tolga.dalman at googlemail.com Fri May 9 14:57:51 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Fri, 09 May 2014 21:57:51 +0200 Subject: [crossfire] Update client GLib dependency In-Reply-To: <536ADD27.50501@gmail.com> References: <536ADD27.50501@gmail.com> Message-ID: <536D333F.5090007@project-psi.org> Hi Kevin, On 05/08/2014 03:25 AM, Kevin Zheng wrote: > GLib is a very useful library that provides portable data structures, > lexical scanners, threads, mutexes, timers, hook functions, and sockets. > Currently it is only used in the GTKv2 client because it is a dependency of > GTK+. I propose that GLib should be a dependency for the entire client. I like the idea and agree to all your arguments (with one comment below). > 2. GLib will make things more portable. I've been able to get the client > building on Windows again, but it's still very messy, particularly due to > excessive conditional compilation. GLib implements its own portable sockets > that can be used on multiple platforms. We should investigate, whether the socket code should be aligned with the server part. That said, I'm reluctant to make glib a dependency for the server as well. However, I agree that portability (and, thus, better code) should be in the focus. What alternatives do we at least for the socket code have ? As discussed previously, SDL Net could be one such option amongst others. Best regards Tolga Dalman From kevinz5000 at gmail.com Fri May 9 15:21:04 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 09 May 2014 15:21:04 -0500 Subject: [crossfire] Update client GLib dependency In-Reply-To: <536D333F.5090007@project-psi.org> References: <536ADD27.50501@gmail.com> <536D333F.5090007@project-psi.org> Message-ID: <536D38B0.7010301@gmail.com> On 05/09/2014 14:57, Tolga Dalman wrote: >> 2. GLib will make things more portable. I've been able to get the client >> building on Windows again, but it's still very messy, particularly due to >> excessive conditional compilation. GLib implements its own portable sockets >> that can be used on multiple platforms. > > We should investigate, whether the socket code should be aligned with the > server part. > That said, I'm reluctant to make glib a dependency for the server as well. > However, I agree that portability (and, thus, better code) should be > in the focus. What alternatives do we at least for the socket code have ? > As discussed previously, SDL Net could be one such option amongst others. There isn't exactly a whole lot to share. The protocol for the client and server are different enough to require separate parsers for each. I have seen command-line programs use GLib, for example, irssi comes to mind. I have not seen purely command-line programs use SDLNet, probably because it depends on SDL which in turn requires X11. That said, I do not plan on making significant changes to the server at this point. Right now I'm working on connection drop detection, integrating Tolga's patches, and fixing Coverity detections. Thanks, Kevin Zheng From nicolas.weeger at laposte.net Sun May 11 08:23:25 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 11 May 2014 15:23:25 +0200 Subject: [crossfire] Update client GLib dependency In-Reply-To: <536ADD27.50501@gmail.com> References: <536ADD27.50501@gmail.com> Message-ID: <201405111523.34482.nicolas.weeger@laposte.net> Hello. I'm ok with using glib everywhere on the client, as long as you have fun with that :) Regards Nicolas Le jeudi 8 mai 2014 03:25:59, Kevin Zheng a ?crit : > Hi there, > > The GTKv2 client sources are split up into two parts, one for "common" > code that can be shared across different clients, and a "gtk-v2" part > that implements the GTK+ client itself. > > GLib is a very useful library that provides portable data structures, > lexical scanners, threads, mutexes, timers, hook functions, and sockets. > Currently it is only used in the GTKv2 client because it is a dependency > of GTK+. I propose that GLib should be a dependency for the entire client. > > 1. There are lots of cool things that GLib will let us have that we > don't have now. Dynamically allocated strings, advanced data types, and > even a config file parser are all available from GLib. > > 2. GLib will make things more portable. I've been able to get the client > building on Windows again, but it's still very messy, particularly due > to excessive conditional compilation. GLib implements its own portable > sockets that can be used on multiple platforms. > > 3. GLib will make things less broken. Connecting to a server is a mess, > and sometimes freezes the client given the right circumstances. > Threading, callbacks, and parsing are messy, too. > > 4. GLib is already a dependency. Besides, on my system, the library and > all development files takes only 17 MB. Most people already have it > installed, because it is a dependency for Gtk, Qt, and more. > > 5. Even if somebody decides to write another client using SDL, OpenGL, > or maybe even Tcl, GLib can still be used and will still provide all of > its happy shiny benefits. > > 6. You probably don't care, since you're using the must shinier and > prettier and portable JXClient. So you should let me do whatever > satisfies my evil wishes. > > Thanks, > Kevin Zheng > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tolga.dalman at googlemail.com Sun May 11 08:39:42 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sun, 11 May 2014 15:39:42 +0200 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 In-Reply-To: <535B5719.4030005@project-psi.org> References: <535B5719.4030005@project-psi.org> Message-ID: <536F7D9E.4050901@project-psi.org> Hi all, On 04/26/2014 08:50 AM, Tolga Dalman wrote: > With Python 2.7, we have the opportunity to cleanup some very old Python > conditional stuff. This way we should be able to replace cjson by the > Python standard library JSON implementation. What do you think ? attached you can find a patch for the existing Python scripts could look like. It is completely untested, however, it can be seen that the change itself is really non-disruptive. Comments ? Best regards Tolga Dalman -------------- next part -------------- A non-text attachment was scrubbed... Name: python_json.patch Type: text/x-patch Size: 5370 bytes Desc: not available URL: From kevinz5000 at gmail.com Sat May 17 10:15:43 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 17 May 2014 10:15:43 -0500 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 In-Reply-To: <536F7D9E.4050901@project-psi.org> References: <535B5719.4030005@project-psi.org> <536F7D9E.4050901@project-psi.org> Message-ID: <53777D1F.6000706@gmail.com> Hi Tolga, Sorry for the very belated response. > On 04/26/2014 08:50 AM, Tolga Dalman wrote: >> With Python 2.7, we have the opportunity to cleanup some very old Python >> conditional stuff. This way we should be able to replace cjson by the >> Python standard library JSON implementation. What do you think ? > > attached you can find a patch for the existing Python scripts could look like. > It is completely untested, however, it can be seen that the change itself is > really non-disruptive. > > Comments ? Unfortunately for some reason after applying the patch the dialog system no longer works. I'm not exactly certain why, and I won't be able to provide many details since I'm not good with Python. You can test the patch on your local server by talking to Milton, who works at the north gate house in Scorn. Thanks, Kevin Zheng