FLTK native in 'D'. Would that be useful?

[MatthiasM]

Status quo:

I was busy doing other stuff in the last weeks, so no advance yet. I 
will continue my port during the next weeks.

Some thoughts though:

It was mentioned in another mail. After a while, there is a big 
temptation to give up. The reasons are simple. The port is working so 
far and I have prooven to myself that it is possible. But since I am not 
experienced D, I find many places that I should have done different, and 
I also know by now that things take a *lot* longer than anticipated. The 
fun is over - it is hard learning now. I am sure many developers reached 
exactly this point on various D porting projects.

So what to do:

I am wrapping up FLTK 1.1.8 for a final 1.1 release these days. After 
that, I'll get back to D-FLTK - with a few changes.

1: It is impossible to move that much text without some automation, so I 
will write a bunch of macros that make life a lot easier. Automated 
translation is not possible though. A human has to see every line of 
code IMHO. (->macros, editor)

2: For a "D" starter, it is important that someone is looking over my 
code and stops me right away when I am on a wrong path, preferably after 
every "svn commit", probably twice a day. This saves me from building 
dead ends and doing double work. (->dedicated mailing list, wiki)

3: The first iteration *must* stick with the original as close as 
possible, or I will end up with a huge port that doesn't run as expected 
and I spend months in debugging. Example: the "Fl_Widget::handle(int)" 
function is virtual, and the parameter is an event. For D, I changed it 
to "Fl_Widget::handle(Fl_Event)" with "typedef int Fl_Event". Man, did I 
regret doing that! I forgot  to change "int" into "Fl_Event" in one 
single instance, but it took me over three hours to find out, why 
"handle(int)" was never called. (->don't diverge)

4. follows from 3. Do architectural changes later! Change char* to 
char[], but do it *later*, After you know that /all/ code works fine. 
Then optimize step by step. ALways keep a running system, always have 
users around who will point out bugs right away. (->modify later)

5. and last point. The interest in a Mac port is relatively low. SInce 
FLTK is tri-paltform, I should do all three ports in parallel. That will 
keep me from visiting the same code three times, and it will also give 
more dearly needed feedback (see 2.). (->port everything)

Nachtisch (Dessert):

Alrighty, if you made it here, then this is the treat: D is an awesome 
language and it has a great community around it. Following 
"d.D.annonce", find myself proud in the middle of a bunch of very smart 
people. Woderful and addictive.


Thanks,

  Matthias