Re: [crossfire] C++/Qt server version
I have seen C++ messes that I would hate to see in CF, but then it is well known that you see current CF code as a mess in itself, so perhaps it has potential for cleaning up the code... Well, that is one of the points of the rewrite I'm proposing, indeed... I depend on trunk not being broken so that I can test and develop things on trunk. I no longer have interest in working on branch. I play only 2.x servers. I do not want trunk broken (for long periods) as that will only be a detriment to play testing and developing what is on trunk now. This is how I work on content - a topic on which you are most vociferous. Yes, I'm vociferous on content. It seems lately some moves are made in this field, so I'm trying to prepare the (bright !) future for the ambitious content people are thinking of :) (something that current CF code doesn't always enable us to write easily, IMO). But the (partial/full/total/global/[insert word]) rewrite I'm talking about is not immediately, it's in some months, after some design work and such. From the various points on this list, I think I'll work on a separate branch, so it's easier to work on content. (and as you I try to not work on branch/1.x anymore) While I recognize branching is a pain at times from my libglade effort in the client, it is my preference if I read your intentions correctly - it sounds basically like a huge rewrite. Whether the branch be of the whole project or only portions that will be broken for some time is not really a concern. 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 crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Seems like a sort of odd decision since most recent conversations have seemed to have decided that more content and less code work is what is really needed to be done, but this seems to be a big code project... Yes, it has the potential to be ambitious. And just given the size and changes of the project, I'd like to see more detailed information - this isn't a minor change being made here. I plan on having design documents before coding, so hopefully we'll have time to think things over. So I can't give much details now, as I don't know them all :) Is that a satisfactory anwser? :) I also wonder that given such a rewrite if maybe a more drastic approach is needed. IMO, one reason for the messy/bad code is to maintain compatibility - new things are added, but don't want to break old maps/archetypes/whatever. I think some things could be simplified a great deal (or made more efficient) if it was considered OK to break some of that compatibility - this may mean lots of maps need updating, but if you're going to do a major rewrite, it may be an overall plus just to give up on some of that compatility for clean code. Indeed, but then let's do the whole thing and convert *ALL* things. One of the reasons for the mess is that people (me included, quite certainly) don't do the conversion globally, and only change a few maps/archs, thus we need to keep old compatibility code. I do remember a long time ago someone else looked at doing crossfire in C++, and his decision was basically to do it from scratch - better to write something that meets the functional spec than to try and figure out what all that code does, etc. But that is clearly a larger project. A plus is that with a complete re-write, one could at least architect it for certain things. But then you start asking questions on what is crossfire really, etc. As Yann mentioned in another mail, rewriting from the ground up with copy / paste can be a solution. I think it sort of depends on the expected development model. But I'd generally say do it as a branch. If individual changes were limited in scope to a few files and were basically complete at each commit, then maybe working directly in trunk would be OK. But changing languages would seem that that is less likely case. . The flip side is also that if not many changes are being made in the trunk, it should generally be fairly easy to keep up to sync (there aren't changes be made that requires syncing up, etc) I think it'll be on a branch, yes. I do have some concerns like Kevin's, in that the rewrite could take a long time (I have no idea on your expected schedule on this, so maybe not). I'd actually be more concerned that the trunk gets left in some hybrid state - some stuff rewritten, some stuff not, and unclear if having 30% of it rewritten in C++/Qt and rest be old C is better than 100% in old C. Doesn't matter. Current C code builds in C++ easily, so no is that C or C++? philosophical question :) (and that's not a theoritical reply, I did test a few months ago - code didn't change enough to warrant another test) 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 crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
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 crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
quoth Nicolas Weeger as of Mon, 24 Nov 2008 16:50:17 +0100: So why Qt: - cross-platform - well tested through KDE and many applications - has all the basics we need: strings (including shared strings for memory reduction unless I'm mistaking), sockets, file / directory, threads and locks, multilanguage support - modular so we can only use what we need (no GUI for server, definitely) - easy to plug in GUI if needed with class coherence - signal/slot mechanism that could be used for plugins or archetype reloading - existing unit test framework (not that advanced, but enough for almost all our needs I think) All your arguments are also true of Boost, thought ;-) with the added benefit (IMHO) that probably more people already have Boost installed than Qt. (Probably more people already know it, too.) Then again, as I said before, whatever you pick is fine... you're the one writing the code! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] C++/Qt server version
Le lundi 24 novembre 2008, Alex Schultz a écrit : That said, a little searching shows that if we want similar automagical wrapping and go with Qt-core, apparently QtScript (an ECMAScript based scripting language which has been included in the Qt toolkit since 4.3.0), appears to be able to provide some kinds of similar things. Of course, it would also be plausible to use Qt-core for the bulk of the rewrite and Boost::Python for cfpython, but that could cause difficulties with differing string types and plain add redundant bloat to the dependencies. See http://pythonqt.sourceforge.net/ , which is a Python binding for QtScript. -- Lauwenmark. Drive defensively: buy a tank. 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] C++/Qt server version
Le lundi 24 novembre 2008, Lalo Martins a écrit : Before anyone gets the impression I'm turning this into a Boost holy war... let me reiterate I don't feel that strongly about it, just answering Nicolas' questions here. snip I see two good reasons for Nicolas favouring Qt over Boost: - He's more familiar with Qt, and having to learn another toolkit, especially something as complex as Boost, would be somewhat of a waste of time; - Although you mentioned several things that integrate nicely with Boost, providing Internationalization or a crossplatform building system, the whole point is that all of this is provided inside the Qt tool suite, and requires no external/3rd party dependency. This is a significant advantage to me. My own, personal tastes lean towards Qt more than Boost, mostly for the way Qt extended the C++ language to make some fundamental mechanisms more accessible. It provides a level of simplicity more in touch with the capabilities of my old braincells :). Just my 0.02€ :) -- Lauwenmark. Drive defensively: buy a tank. signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
