Dieter Dannerbeck wrote:
> matthiasm schrieb:
>> Hi,
>>
>> I am one of the co-authors of FLTK. I like 'D' and as a test I have manually
>> translated parts of FLTK into native 'D' code. This is obvioulsy very different from just writing a wrapper,
>> more involved, but also more rewarding.
>>
>> Before I jump into manually porting a few hundred thousand lines of code, I
>> would really like to know first if the 'D' community is interested in such a thing at all and if I can get
>> sufficient support and a reasonable number of users.
>> What do you folks think?
>>
>> Matthias
>>
>>
>> FLTK is a Fast and Light user interface Tool Kit. It sets directly onto the low
>> lever interfaces of the three main supported platforms (MSWindows:WIN32, Unix including Linux: X11, Mac OS X:
>> Carbon/Quartz). FLTK is in use by several thousand people all over the world. It comes with a
>> visual user interface designer that spews out readable C++ (and after the coversion 'D').
>>
>> Come check it out at http://www.fltk.org/
>>
>>
> Oh yeah go for it!

Here's a link for a few nice tutorials on FLTK:

http://seriss.com/people/erco/fltk-videos/

Anders F Björklund wrote:
> Charles D Hixson wrote:
> > ...
> Not sure I follow, DMD uses "gcc" to link on Linux and GDC is currently just one version behind (0.162 instead of 0.163) ?
> 
> There are several advantages of having a native D toolkit instead of linking to one in another language, just not sure this was it...
> 
> 
> As mentioned, the only problem I see (saw) with a native D toolkit is that it can't use any system C/C++ header files just as they are.
> 
> In e.g. wxD, those are all kept in C++ so they are not really much of a problem - whileas they are a big issue when porting instead of wrapping.
> 
> --anders

I know that *I* don't follow.  And I saw the wxd compilation linking with wxd.  But there's something involving *.so files that I ran into trouble with awhile back, and was told that "dmd doesn't handle that".  I never did understand what the problem was, just that I couldn't make the linking work.

Now I'll freely admit that I'm no expert at gcc.  I've done MVS (IBM 360) and Scope and Scope2 (CDC), and cut my teeth on Fortran and PL/1 but on personal computers, but the time I switched to Linux I was using Python, and I've never picked up more than a few bits around the edges of using gcc, make, et al.  Maybe the guy who told me that "dmd won't handle *.so files" was wrong.  Maybe I misunderstood him. But without decent documentation I'm reluctant to enter that tunnel again.  With gdc I have the gcc manuals.  They could be improved, but they have LOTS of info.  But dmd is different, and at my level of expertise I can't tell how.

OTOH, given a template (such as is provided by wxd), I and tweak it and make minor adjustments.  In time I'll make progress.  And I've got the gcc manuals, so I can figure out just what a particular option in the make file means ... but there's NO WAY that I could write it.  Not this year. Probably not next.

I truly miss those long shelves of manuals that told
everything you wanted to know about the system in nicely
crossreferenced form.  We don't yet have a good replacement.
 A good replacement would be (possibly) a combination of
grep and a browser, so that you could search for any term
anywhere in the documentation, without losing your place.
(I manage a crude form of this with grep and either a text
editor or a browser depending on what kind of file it is,
but it's a clumsy substitute.)  Also, things have probably
gotten too complex now for the long shelf of books to do the
job, so this is partially nostalgia speaking.  (But it's
also a frustration with the pervasive lack of documentation.
 Man pages just don't suffice.)

On Fri, 21 Jul 2006 12:17:16 -0700, matthiasm <matthiasm_member@pathlink.com> wrote:

> Hi,
>
> I am one of the co-authors of FLTK. I like 'D' and as a test I have manually
> translated parts of FLTK into
> native 'D' code. This is obvioulsy very different from just writing a wrapper,
> more involved, but also
> more rewarding.
>
> Before I jump into manually porting a few hundred thousand lines of code, I
> would really like to know
> first if the 'D' community is interested in such a thing at all and if I can get
> sufficient support and a
> reasonable number of users.
>
> What do you folks think?
>
> Matthias
>


An excellent project that could have a significant impact on the D world.  I'll be excited to see the results!

Welcome to D. :)

-JJR

matthiasm wrote:
> Hi,
> 
> I am one of the co-authors of FLTK. I like 'D' and as a test I have manually
> translated parts of FLTK into native 'D' code. This is obvioulsy very different from just writing a wrapper,
> more involved, but also more rewarding.
> 
> Before I jump into manually porting a few hundred thousand lines of code, I
> would really like to know first if the 'D' community is interested in such a thing at all and if I can get
> sufficient support and a reasonable number of users. 
> 
> What do you folks think?
> 
> Matthias

Definitely.
Anything 'Fast and Light' is a natural match for D.

Dave wrote:
> Dave wrote:
>>
>> A potential drawback would be if the GPL licensing wouldn't allow for something like a 3rd party RAD tool to distribute FLTK with it, without also distributing the application source (but I don't know, I'm not a lawyer).
> 
> Anyone have experience / knowledge on this? The FLTK license is here:
> 
> http://fltk.org/COPYING.php
> 
> Actually, after looking over that my concern above isn't valid (right? anyone, anyone <g>). Reason: The RAD tool would just be writing out code that imported the FLTK modules and then statically link the app. to the FLTK lib. The RAD tool itself would not be using modified FLTK code so the tool source code would not need to be GPL'd (but of course FLTK itself would still be distributed w/ the tool). Cool.

The FLTK team is pretty liberal about the license (LGPL, btw.). We event modified it to explicitly allow the usage of a statically linked FLTK library in commercial projects. As for RAD tool, I see no problems, however, IANAL.

Matthias

David Medlock wrote:
> matthiasm wrote:
>> Hi,
>>
>> I am one of the co-authors of FLTK. I like 'D' and as a test I have manually
>> translated parts of FLTK into native 'D' code. 

> I have used FLTK before and it was great.  A port would perhaps be just the base-GUI that D needs.

Thanks for all the kind words in this and other mails.

So it is decided: we will set up an SVN repository entry for D-FLTK on fltk.org and start porting away. Yes, it will be a full port, not a wrapper. Anything else would be silly in the long run.

I am using gdc (0.18, IIRC) on OS X and this is how far I got:

I wrote headers for about 70% of the Carbon functions that FLTK uses plus a few more. However, I would love to automate that. Any suggestions? Is h2d alive? The same would need to be done for X11 and WIN32.

I ported most of the windowing code, some of the window messaging code and a little bit of the drawing code. It took a while to get used to dropping those asterisks everywhere and not to worry about it. After all, I am new to "D" - and I like it very much.

So, I am able to open windows (Fl_Window, Fl_Group, Fl_Widget support) and draw rectangles and lines. This is good enough for me to show that it can be done - so I will do it.

More information to follow. Any help is greatly appreciated.

> PS.  Please do not take this as criticism of any kind, but why does FLTK use a modified LGPL instead of just using Mozilla License, which basically the same thing?

Historical reasons. It was originally LGPL even before Mozilla existed, then modified LGPL.

Matthias

MatthiasM wrote:
> I ported most of the windowing code, ...

Here's the link to the source code archive:

http://fltk.matthiasm.com/fltk.pl?DeeFltk

*it is a total mess, since it is only a proof of concept*

Nevertheless, it does open a window and handles some events, so the Carbon interface works. Please feel free to comment and give me tips on how to improve my "D".

Matthias

On Thu, 27 Jul 2006 11:20:05 -0700, MatthiasM <dm@matthiasm.com> wrote:

> MatthiasM wrote:
>> I ported most of the windowing code, ...
>
> Here's the link to the source code archive:
>
> http://fltk.matthiasm.com/fltk.pl?DeeFltk
>
> *it is a total mess, since it is only a proof of concept*
>
> Nevertheless, it does open a window and handles some events, so the Carbon interface works. Please feel free to comment and give me tips on how to improve my "D".
>
> Matthias
>


I think one improvement would be to drop all Fl_* prefixes on class names like FLTK 2.0 does.  I looked and 2.0 and found it world's better looking than the older 1.1.

Is that possible?

-JJR

MatthiasM wrote:
> I wrote headers for about 70% of the Carbon functions that FLTK uses plus a few more. However, I would love to automate that. Any suggestions? Is h2d alive? The same would need to be done for X11 and WIN32.
> 

I ported some of the X11 Windows headers a while back, a little messy but they can be found here (the file is X Windows Files):
http://lgoss007.googlepages.com/dprogramming

Lucas

MatthiasM wrote:
> MatthiasM wrote:
>> I ported most of the windowing code, ...
> 
> Here's the link to the source code archive:
> 
> http://fltk.matthiasm.com/fltk.pl?DeeFltk
> 
> *it is a total mess, since it is only a proof of concept*
> 
> Nevertheless, it does open a window and handles some events, so the Carbon interface works. Please feel free to comment and give me tips on how to improve my "D".
> 
> Matthias
> 

Hey, if there is /anything/ I can do to help port FLTK (I've had my fair share of experience porting C++ code to D) then I'd be glad to, as this is a worthy D project.

I suggest you get some forums (www.dsource.org could easily provide you with forums and an SVN repository if you wish, just ask in the 'potential projects' dsource forums), and make the development process as transparent as possible to generate interest in future users.

If you are using GDC make sure to specify either 'public import' or 'private import' or else your code will break on the next GDC upgrade.

Currently I can not look at your code because my Windows QuickZip was having trouble with it.

Goodluck with this.
~ Clay