[CF-Devel] RE: GTK editor

[Bob Tanner]

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.

>
     
       The above is all true of course.  The problem is that if the java editor is
     
     >
     
       too slow/too memory hungery or you just don't have a good jvm, people won't
     
     >
     
       use it at all.
     
     
These are technical issues that can be solved in a variety of ways. You bind the
the GTK toolkit instead of the Swing toolkit. There is a project out that is is
fairly complete that let's you program to Swing API, but it uses JNI to bind the
GTK. It's lightening fast.

I think the bigger issue, is what aren't people using the Java editor.

>
     
       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).

>
     
       The one advantage of a C client (beyond speed) is that it has the potential to
     
     >
     
      share a lot of the code currently in the server (similar to how the Xt editor
     
     >
     
      currently does so).  This then means that it is just a matter of copying code
     
     >
     
      over vs a reimplementation.
     
     
Hmmm, tightly coupled system. Doesn't that mean a change in the server means a
change in the editor?

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.

Part of this problem is me, but the bigger problem is "us" and the development
style that is used in crossfire (and most open source projects).

Now, this is not a flame. Up until 3 weeks ago I developed code in a very
similar style. But then I read about Extreme Programming (XP). And all sorts of
lights went off. I had an epiphany (really)! I don't want to go off on a
tangent, you can find more info on XP at 
     
     http://www.extremeprograming.org.
     
     

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.

Getting off my soap box now...

-- 
Bob Tanner <
     
     tanner at real-time.com
     
     >         | Phone : (952)943-8700
     
     http://www.mn-linux.org,
     
      Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9