> Well, one thought, is there any reason Qt-core as opposed Boost C++ > perhaps? If I understand correctly, they provide similar faculties but > Boost C++ also provides some rather nice looking python bindings that > may make it far easier to move cfpython to a C++ code style. > > I'm not saying anything is wrong with Qt-core, and I've never actually > used it or Boost C++ for that matter, but I'm just wondering if should > maybe be considered, as it may have merits. That said, as you're likely > going to be the main person in this code effort, simply having more > experience with QT-core than Boost C++ can be a significant and quite > valid factor.
I'm not a Boost specialist either (and that can have an impact on my preference for Qt), but from what I gather, here are Qt features Boost doesn't have (someone will correct me if I'm wrong): - multilanguage support - GUI classes - modular, so you can disable if not needed, and if you need you're using the same base classes - image manipulation - crossplatform build system Note that C++/Qt and Python interact decently with some tests, there doesn't seem to be any issue there. > Not too much of a strong opinion, except that if you do work on trunk > there should be either a tag or branch made for the current state of > trunk. Yup. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
