From nicolas.weeger at laposte.net Mon May 25 04:43:17 2015 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 May 2015 11:43:17 +0200 Subject: [crossfire] Qt experiments Message-ID: <201505251143.22525.nicolas.weeger@laposte.net> Hello. I'm experimenting with Qt (core only, no graphical stuff for now) for the server, and would like to share that. I can either work on a specific branch in SVN, or in trunk, as people want. And no, massive OO refactoring is not planned for now - just using base functions to clean the code & remove cruft. And yes, if things don't work too badly, I fully intend to submit that as a patch for use in regular trunk. Regards Nicolas -------------- 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 Mon May 25 05:04:32 2015 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Mon, 25 May 2015 12:04:32 +0200 Subject: [crossfire] Qt experiments In-Reply-To: <201505251143.22525.nicolas.weeger@laposte.net> References: <201505251143.22525.nicolas.weeger@laposte.net> Message-ID: <5562F3B0.8020709@project-psi.org> Hi Nicolas, I have a couple of questions: * Which Qt version have you chosen and which ones are we going to support in future ? * Which Qt classes are you using ? Which crossfire server parts are you going to replace ? * What are the exact arguments for Qt in comparison to, say, pure C++11 or Boost ? * What are the unique features that only Qt provides ? That said, I am not sure whether Qt Core is the right choice for cleaning up the crossfire server code base. However, I am grateful that you are working on this and I am looking forward for your changes :) Best regards Tolga Dalman On 05/25/2015 11:43 AM, Nicolas Weeger wrote: > Hello. > > > I'm experimenting with Qt (core only, no graphical stuff for now) for the > server, and would like to share that. > > > I can either work on a specific branch in SVN, or in trunk, as people want. > > > > And no, massive OO refactoring is not planned for now - just using base > functions to clean the code & remove cruft. > > > And yes, if things don't work too badly, I fully intend to submit that as a > patch for use in regular trunk. > > > > Regards > > > Nicolas > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From nicolas.weeger at laposte.net Mon May 25 08:17:00 2015 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 May 2015 15:17:00 +0200 Subject: [crossfire] Qt experiments In-Reply-To: <201505251143.22525.nicolas.weeger@laposte.net> References: <201505251143.22525.nicolas.weeger@laposte.net> Message-ID: <201505251517.05133.nicolas.weeger@laposte.net> Someone asked me a few questions, and I guess it's worth replying on the list :) > * Which Qt version have you chosen and which ones > are we going to support in future ? Qt4 (I'm at version 4.8.2), and Qt5 (not sure the exact version), unless something unexpected happens. > * Which Qt classes are you using ? Which crossfire server > parts are you going to replace ? Only classes in QtCore and QtNetwork for now, but not the graphical ones (at least in the server itself). Maybe some other parts, not sure yet (QtTest, possibly). Going to replace socket stuff, shared strings, and various other things - can't tell yet, it'll depend on what I feel like breaking :) And new features are planned, that's the whole point of cleaning. > * What are the exact arguments for Qt in comparison to, > say, pure C++11 or Boost ? > * What are the unique features that only Qt provides ? C++11 I'll discard, because it doesn't have, afaik, a cross-platform build system, which is something really nice to have (and don't tell me autoconf works :)). As for Qt vs Boost, I'm more familiar with Qt, but I guess they both are equivalent. Though I don't think Boost has a graphical library, whereas Qt has one, which I'm using for CRE too. Kind regards Nicolas Le lundi 25 mai 2015 11:43:17, Nicolas Weeger a ?crit : > Hello. > > > I'm experimenting with Qt (core only, no graphical stuff for now) for the > server, and would like to share that. > > > I can either work on a specific branch in SVN, or in trunk, as people want. > > > > And no, massive OO refactoring is not planned for now - just using base > functions to clean the code & remove cruft. > > > And yes, if things don't work too badly, I fully intend to submit that as a > patch for use in regular trunk. > > > > Regards > > > Nicolas -------------- 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 kevinz5000 at gmail.com Mon May 25 08:34:22 2015 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 25 May 2015 08:34:22 -0500 Subject: [crossfire] Qt experiments In-Reply-To: <201505251143.22525.nicolas.weeger@laposte.net> References: <201505251143.22525.nicolas.weeger@laposte.net> Message-ID: <556324DE.2060207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/25/2015 04:43, Nicolas Weeger wrote: > I'm experimenting with Qt (core only, no graphical stuff for now) > for the server, and would like to share that. Sounds interesting. Anything to remove Winsock and "#ifdef WIN32"! > I can either work on a specific branch in SVN, or in trunk, as > people want. For the time being, I'd prefer a separate branch. > And yes, if things don't work too badly, I fully intend to submit > that as a patch for use in regular trunk. I'm excited to expunge Winsock. Best, Kevin Zheng - -- Kevin Zheng kevinz5000 at gmail.com | kevinz at kd0lgh.mooo.com | PGP: 0xC22E1090 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYyTcAAoJEOrPD3bCLhCQTBAH/3/A6OrQLZU7XGp+Xl3QBkbQ WZylAptyTM9hRMbC6xCEZTZLcbGkHuW+pvJtZjO1b0sxUW/fsJznMEqfplH6ZwKV /ZWCGEZH/YRuF4fkiFNeu6Zg96DwJSjAT/GkX4RdoeLD7aqoerkvYtFW1Y85Kt4N J5YAE+bGTDDT1HUuww+Djz73QMMFVQ43ku+0rQB3nuiqWKLfrvDLSPqObvyjhhWR O2f7tgVy28ojvw8B1CwvW6O8PMxrtGxymfYJaYq58Lq47qlIcWIFUcbkdt+aVFTA /QxCtfMMfos0fGNlrtDTSXvSeq7G3nVCtjotDbyPTbc2nXiawrwRg88Zos/weZk= =fFfY -----END PGP SIGNATURE----- From tolga.dalman at googlemail.com Mon May 25 12:37:38 2015 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Mon, 25 May 2015 19:37:38 +0200 Subject: [crossfire] Qt experiments In-Reply-To: <201505251517.05133.nicolas.weeger@laposte.net> References: <201505251143.22525.nicolas.weeger@laposte.net> <201505251517.05133.nicolas.weeger@laposte.net> Message-ID: <55635DE2.8010903@project-psi.org> Hi, from what I understood, you are searching for a replacement (or even a proper solution) for these functionalities: 1) platform independent networking 2) a test framework 3) a platform independent build system 4) a graphical framework 5) misc. utility classes (which ones ?) I think, there are a couple of advantages with Qt. * Qt is a really great GUI framework. Especially Qt5 has evolved to a very good framework IMHO. * portability is greatly eased. In future, we could also easily provide an Android or IOS crossfire client. * You seem to have some experience with Qt with CRE. * The crossfire code would have to be converted to be C++ (at least compilable). However, it really depends where the Crossfire project is heading towards. My concerns are these (hence, I'm asking so many questions): * Qt is actually quite big (on my system libQt5Core is 5MB large - stripped!). I have always liked the light-weight nature of crossfire. * Over the years, the API changes caused some headaches, e.g., from 3 to 4 and from 4 to 5. I don't think it is feasible to support all different versions. * we would (at least in the interim) have to support Qt AND the current GTK+ client. This seems unfortunate as both frameworks have a similar functional scope. Finally, let me again mention that there are alternatives to the above requirements: 1) SDL provides a good networking abstraction (SDLnet) 2) I really like GoogleTest. Other alternatives include Boost::Test and CPPUnit 3) CMake is a great cross-platform build system. Other alternatives include, e.g., scons. 4) Qt is really the best choice here. As mentioned above, I would harmonize all graphical tools, i.e., CRE and the client should be based on the same framework. We could even think about using a Python Qt binding (PyQt or PySide). 5) Depends on which classes you actually need. Opinions ? Best regards Tolga Dalman From nicolas.weeger at laposte.net Mon May 25 13:46:06 2015 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 May 2015 20:46:06 +0200 Subject: [crossfire] Qt experiments In-Reply-To: <55635DE2.8010903@project-psi.org> References: <201505251143.22525.nicolas.weeger@laposte.net> <201505251517.05133.nicolas.weeger@laposte.net> <55635DE2.8010903@project-psi.org> Message-ID: <201505252046.12291.nicolas.weeger@laposte.net> Honestly, I'm not concerned about executable size, or other things. Yes, there are other frameworks (and maybe I'll use eg Google Tests instead of Qt's test stuff). But I've decided to use Qt :) If you want to experiment with SDL, or anything else, be my guest & provide patches :) Kind regards Nicolas Le lundi 25 mai 2015 19:37:38, Tolga Dalman a ?crit : > Hi, > > from what I understood, you are searching for a replacement (or even a > proper solution) for these functionalities: 1) platform independent > networking > 2) a test framework > 3) a platform independent build system > 4) a graphical framework > 5) misc. utility classes (which ones ?) > > I think, there are a couple of advantages with Qt. > * Qt is a really great GUI framework. Especially Qt5 has evolved to a very > good framework IMHO. * portability is greatly eased. In future, we could > also easily provide an Android or IOS crossfire client. * You seem to have > some experience with Qt with CRE. > * The crossfire code would have to be converted to be C++ (at least > compilable). > > However, it really depends where the Crossfire project is heading towards. > My concerns are these (hence, I'm asking so many questions): * Qt is > actually quite big (on my system libQt5Core is 5MB large - stripped!). I > have always liked the light-weight nature of crossfire. * Over the years, > the API changes caused some headaches, e.g., from 3 to 4 and from 4 to 5. > I don't think it is feasible to support all different versions. * we would > (at least in the interim) have to support Qt AND the current GTK+ client. > This seems unfortunate as both frameworks have a similar functional scope. > > Finally, let me again mention that there are alternatives to the above > requirements: 1) SDL provides a good networking abstraction (SDLnet) > 2) I really like GoogleTest. Other alternatives include Boost::Test and > CPPUnit 3) CMake is a great cross-platform build system. Other > alternatives include, e.g., scons. 4) Qt is really the best choice here. > As mentioned above, I would harmonize all graphical tools, i.e., CRE and > the client should be based on the same framework. We could even think > about using a Python Qt binding (PyQt or PySide). 5) Depends on which > classes you actually need. > > Opinions ? > > Best regards > Tolga Dalman -------------- 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 mwedel at sonic.net Tue May 26 00:25:21 2015 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 May 2015 22:25:21 -0700 Subject: [crossfire] Qt experiments In-Reply-To: <201505252046.12291.nicolas.weeger@laposte.net> References: <201505251143.22525.nicolas.weeger@laposte.net> <201505251517.05133.nicolas.weeger@laposte.net> <55635DE2.8010903@project-psi.org> <201505252046.12291.nicolas.weeger@laposte.net> Message-ID: <556403C1.6030307@sonic.net> Just my one slightly relevant data point on Qt: The few times I compiled Qt for Solaris, it was a lot of work. Its been a while now, but some of this was the large number of dependencies to install before compiling Qt, but Qt itself had some oddities. That said, the number of people running the server on solaris is near 0, and I don't think it even compiles right now due to changes/removals of various checks from configure (in most cases, there was a reason behind why those checks where put in the configure scripts in the first place). But my thought is that if some new platform (non linux/bsd/windows) shows up and someone wants to run the server on it, from my experience above, using Qt may be as much a hindrance as a help. And while there is some amount of platform/OS specific code in crossfire, it is fairly minor and probably a fair amount of the remaining bits could be cleaned up. The computer world is much different now than it was 20+ years ago (when there was a dozen different varieties of unix, POSIX standards were not as complete, etc). My personal philosophy when I had time to spend time on crossfire was to try and keep the dependencies that the server needs to a minimum, simply because in many cases, the environment where the server would run had a more minimal installation or were a loaned resource such that it wasn't easy for the person running the server to install additional dependencies.