Re: [crossfire] Qt experiments

2015-05-25 Thread Kevin Zheng
-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
kevinz5...@gmail.com | kev...@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-
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Qt experiments

2015-05-25 Thread Nicolas Weeger
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


signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Qt experiments

2015-05-25 Thread Tolga Dalman
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
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


Re: [crossfire] Qt experiments

2015-05-25 Thread Mark Wedel


 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.



___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire