[CF-Devel] RE: GTK editor

[Mark Wedel]

Bob Tanner wrote:
>
     
     
     >
     
      Quoting Mark Wedel (
      
      mwedel at sonic.net
      
      ):
     
     >
     
      > > >Then we have two editors and the development effort is split
     
     >
     
      > > >in half.
     
     >
     
     
     >
     
      Isn't the above statement, the essence of open source? Walk to the bizarre, pick
     
     >
     
      what is you like. The "best" one will attack the most developers and this the
     
     >
     
      community will decide which is best.
     
     
 True - survival of the fittest in a sense.  The problem is that if there are a
lot of different projects, and hundreds of man hours go into each one, it may
very well have been more efficient to have decided what looks to be the ideal
solution, and all those man hours to go to just that one project.

 Also, the 'best' could end up being any of several of the projects.  Right now,
I would guess that interest/development in both the java and gtk client may be
enough to attract developers to each one.  It seems unlikely that either one
will end up be clearly the best.

>
     
      >  One hope is that the format of the maps (and objects) will not change that
     
     >
     
      > much, so any changes should hopefully be minor.  OTOH, from the past we have
     
     >
     
      > seen that is not the case.
     
     >
     
     
     >
     
      Ahh, thus my call to change the maps to xml, thus they are self-describing and
     
     >
     
      easily changed (ok, that is a bold statement, but I'm on the soap box now).
     
     
 Note that to some extend, this can be done now.  I think it is safe to say that
at the very basic, the form of objects will be arch something....end.  So any
loader can look for the arch and end fields.  It could then extract the other
fields it knows about (x, y, sp, msg, etc).  For everything else, it just keeps
it as a string, and then when it needs to be saved out, it also writes out that
stored string.

 This then means that if new fields are added, the editor will still read/write
them.  Now it won't know about relations (eg, if wands are changed to use a
field called charges instead of food).  OTOH, the editor could also allow
modification of these text fields by hand, so if the user knows the relation,
they can update it.


>
     
      Hmmm, tightly coupled system. Doesn't that mean a change in the server means a
     
     >
     
      change in the editor?
     
     
 Depends on the change.  The Xt editor has remained largely unchanged despite
many changes to the server.  The editor really only runs into trouble when stuff
currently in the common directory is changed, but it largely depends on the
change.

>
     
     
     >
     
      My biggest problem with any open source project (CFEditor is no exception) is
     
     >
     
      the large start up "costs" on contributing/developing a new project.
     
     >
     
     
     >
     
      It took a long time for me to understand the internals of crossfire, and even
     
     >
     
      then I only do changes to our local server. This because I don't have the
     
     >
     
      courage to make changes to the public source and know my changes have not
     
     >
     
      horrible broke something.
     
     
 This may be some matter of philosphy also.  Ideally, any new code should not
break anything, but that certainly does happen.  Requiring/assuming that that
all change will work perfectly is very difficult.


>
     
      There most important thing I learn from XP is writting unit tests before coding.
     
     >
     
      And developing a testsuite that must run 100% of the tests before a commit. This
     
     >
     
      simple rule gives developers all the courage they need jump right in and start
     
     >
     
      making changes. It also lowers the "cost" of getting into a project, by
     
     >
     
      providing immediate feedback to you on how well your change integrated into the
     
     >
     
      project.
     
     
 Test suites would be useful.  I'm just not sure how go about making good test
suites, so you then basically need some way to interact with the server to
verify behaviour.  Now I suppose you could have a test client, which does the
various things and checks for proper behaviour.  But this is much more difficult
than just running a program and making sure the output is correct.