FLTK native in 'D'. Would that be useful?
dm at matthiasm.com
Thu Aug 24 23:27:54 PDT 2006
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)
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.
More information about the Digitalmars-d-dwt