Nils Kneuper <[EMAIL PROTECTED]>:
> Mordante plans to refactor the gui system to make it easier themeable and to
> reduce the maintance load. Currently the GUI section seems to be a mess which
> makes adding new features like tabbed view and changes to dialogs very
> difficult.
I'll help Mordante with this if I can. I probably know the GUI code
better than anyone else except Sapient, because I refactored a lot of
the upper level of the GUI code once before while implementing the
lightweight message popups. However, my understanding of the lower
levels entwined with SDL is minimal -- not zero, but minimal.
> - - odd-on server revamp
> Mordante wants to takle some changes for the add-on server to
> introduce the long wanted things like "content type" and to allow
> running tools like wmllint on severside or on clientside right
> before uploading to reduce the amount of problems with add-ons. Many
> of those changes will require changes to the GUI system so that they
> can be displayed in a usable way.
I will fully cooperate with this. If wmllint needs modifications to run in
that environment I will cheerfully deliver them.
> - - new build system
> Post 1.4 esr and I will work on switching the build system from
> autotools to something "better". At the moment it is not sure which
> build system will be used, the basic two alternatives are scons and
> cmake. There was a talk at FOSDEM about each of them, videos of
> these talks will be available at fosdem.org in the foreseeable
> future. grzywacz and I attended the talks and our impression was
> that the syntax of cmake looks a little uglier than the syntax of
> scons. But on the other hand the featureset of cmake seems to be
> really superior. For example it directly offers many tests and might
> make life for packagers easier. It could be used to easily allow
> creation of lite packages without much extra work. We will have to
> evaluate and testimplement so that we see which of those is better
> for Wesnoth.
I plan to do an scons recipe. I suggest that someone else do a cmake
recipe and we then evaluate them against each other. (I think I have
already explained sufficiently my reasons for being dubious about cmake.)
> - - formula AI integration Dave has been working on allowing some
> formulas for AIs to be coded in WML. This is some kind of functional
> programming inside WML to better control the behavior of the AI. For
> example it would be possible to hardcode mapspecific behavior of the
> AI in the first turns for some maps. Dave also demonstrated how the
> current branch already does work to the developers that were still
> around when FOSDEM was almost over. So far it seems to already work
> nicely and can probably be merged into trunk after 1.4 is
> tagged. This AI also requires some additional dependencies from
> boost. This is mentioned further below.
I'll go further -- I think that if formula AI lives up to its billing
we ought to find a formula setting that approximates the default
AI and then just *delete* the default AI. I don't see any point in keeping
two large masses of AI code
> - - savegame format revamp
> Currently the savegames seem to be a rather big mess. Mordante plans
> to have a look at it and reimplement some of the logics. The benefit
> of this would be that savegames should look more uniform. At the
> moment for example start of scenario saves in MP look different than
> Turn1 saves. This revamp will also be needed to cleanly fix some
> replay and mp-campaign savegame problems.
I don't think I can help much with this, but I want to note that this is
probably the most important post-1.4 issue from a bug-fixing perspective.
I can't allocate Mordante's time, but -- if my request has any weight --
I'd like him to work on this before tackling major new features.
> - - prevent UMC namespace collision
> Currently it is possible that namespaces of UMC collide. This should
> be prevented since it can lead to strange bugs. A nice and good way
> to do so has to be found.
Now *this* one sounds like something I should perhaps take the lead
on. I think I was worrying about managing namespaces in the WML &
resource tree before anyone else realized this might be an issue.
Can you describe the problem more completely? What collision symptoms
are you worrying about?
> - - money/ads/hosting discussions
> Boucman said that there was some offer in
> France for rather string 2GHz machines with many GB harddrive and
> unlimited bandwidth usage. On such a server we could host the
> website including forum and wiki, a mailserver to allow @wesnoth.org
> email addys/aliases for devs, the multiplayer and
> content-servers. Currently there seem to be some problems with the
> confirmation mails at the forum registration. In the last year
> every now and then we had some problems with the servers, so it
> might be a valid idea to change to a server we have full control
> about.
I don't have much of an opinion about the money/ads issue. But
I have already found us better hosting.
We have been invited to move our project to ibiblio.org, physically
located at the University of North Carolina. This is one of the
largest open-source hosting sites in the world and the home of many
major projects including Groklaw and the Linux Documentation Project.
My personal site is hosted there, too. If you meet their nonprofit
requirement, use of the site is completely free.
The site has multiple T3s. It is very well and professionally
administered. We will be able to get shell access, effectively
unlimited disk storage, and I've found them pretty good about
installing site support for whatever tools a project needs. I do not
think our requirement for PHP5 and an up-to-date wikimedia instance
will be any problem at all.
Ten years ago I did some work on the site that the ibiblio site admins
valued a lot, and I have maintained very friendly relations with them
since -- when I emailed a query about Wesnoth to the chief site admin
he called me back personally less than two hours later to assure me
they'd love to have us.
So on top of everything else good about the site, we have personal pull
there. I really cannot imagine a better situation.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
