Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 15:40:32 -0500, Rick Tanner [EMAIL PROTECTED] wrote: A couple of questions: At what state of completion(?) is a user HOWTO manual for the map editor? As I said in a previous message, the current code is not very friendly to first-time users. Although there is a tutorial available on the web (http://www.deliantra.net/editor_tut.html) explaining how to set up the editor and start editing your first maps, I think that some of these instructions should be part of the source tree. So although that web page provides some material that could be used as a starting point for creating a HOWTO, there isn't one yet in the package. I think an install HOWTO is probably the most critical, then followed by ~ a user manual (which is very important as well.) I agree. Like in other free software projects, I am planning to add two files at the top of the source tree: INSTALL (describing how to build and install the stuff) and HACKING (giving recommendations to whoever wants to contribute). Currently, there is not even a README. Note that building it is not very difficult. Basically, you do: perl Makefile.PL make make install You can also add PREFIX=/some/path to change the default installation path. But the INSTALL file should explain more than that: it should list the dependencies and explain how to install them if they are missing, give advice about where to install the editor, etc. Also, building the editor is one thing, but you also have to run it. The current version requires that you set the environment variable CROSSFIRE_LIBDIR at least for the first time you start it. This something that I would like to change so that the initial start would be a bit more user-friendly. What about official releases? Is there a volunteer to manage those? Well, I guess that I will be the first volunteer. Making a source code release is easy. I don't know what to do about the Windows binary releases, though. The Deliantra guys provide a package for Windows users, but currently I don't have the tools for doing that myself. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
On Wed, 16 Jul 2008 21:01:07 -0700, Mark Wedel [EMAIL PROTECTED] wrote: I have no issues with it being added to part of SVN. Thanks! [...] - With that above note, it means that all that crossfire can really limit is if it is in SVN or not. Raphael can continue to work on it in either case. And for that matter, could create another project on sourceforge to hold the editor. Exactly. I was surprised by some of the previous comments questioning if we need a new editor. But this is not a new editor: it has existed since several years (although not very visible due to the tension caused by the CFplus project). The code is only looking for a new home after its current maintainers have confirmed that the only option for restoring the support for the original crossfire (broken a few months ago) is to fork the libraries used by the editor. So question is not about whether it should exist or not, but whether it should be imported in the crossfire SVN tree or if a new project should be started in sourceforge or elsewhere. I think that the first option is much better, that's why I asked. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] GTK V2 Client (libglade) Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This sounds nice, would this be a 2.0 client or a branch/1.x client? As far as I can see you are suggesting separate releases of server/maps/arch and client? Is that correct? I see no need to keep them synced apart from making sure last stable client and stable server work with each other. Regards, Arvid Norlander Kevin R. Bulgrien wrote: | Speaking of releases... It sure would be nice to see the libglade client | packaged up after spending all that time working on it and debugging it. | The original GTK V2 client was released far sooner and buggier. Another | two cents that's not worth much in a free project, is that a client | release would be a heck of a lot easier and faster than rebalancing, | albeit not as much fun for the releaser. | | I've already toyed around a bit with glade3 and the client layouts. | with thoughts of resuming development some time. No reason to | artificially keep that client out of distribution. I'm not | ready to start using the other client. | | Kevin Bulgrien -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkh/fcsACgkQWmK6ng/aMNm9FQCfWiCIFS75nF9lBIx7BUancyCx Jh0An3s2rCmH1ioJYPB9F/oYkHl67w/7 =4iql -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Importing the GTK+ editor in SVN
*sigh* if only the list could be so lively for content-related stuff... I globally agree with Yann. Also this is code no one here knows, it'll take a while to get into it, bla bla, but you do what you want with your time :) *goes back to his hole* -- 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] GTK V2 Client (libglade) Release
Kevin R. Bulgrien wrote: Speaking of releases... It sure would be nice to see the libglade client packaged up after spending all that time working on it and debugging it. The original GTK V2 client was released far sooner and buggier. Another two cents that's not worth much in a free project, is that a client release would be a heck of a lot easier and faster than rebalancing, albeit not as much fun for the releaser. Since (except for the window binaries), I seem to the be sole releaser, on my wishlist would be more people willing to make releases. That said, it probably is about time for another 1.x release, even though not a huge amount of stuff has changed, but just to get it out there. And putting out a 2.x client is probably reasonable. Save for having other people do releases, next on my wish list would be for people to periodically try the release process (make archive from the top level dir - same place you run configure). If everything 'works', doing a release isn't that time consuming. But often, things don't work, and it then takes a considerable amount of time to track down the problems. Most common is new files getting added to SVN, but not the actual makefiles (things like header files, but could also be config files). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
