In article <e9rlr6$1n6h$1@digitaldaemon.com>, BCS says...
>
>BTW, does FLTK access the native GUI framework, or does it shell around them?

FLTK does not use any of the native toolkit functions. It has its own look and
feel, and the exact same API
on all platforms. There is a chiseled Windows2000 look and a more modern
"plastic" scheme. Please check
out the screen shots at http://www.fltk.org/shots.php . Also, feel free to
download one of the many  apps,
like http://robowerk.com/de/software/ (binary for Windows, Mac or Linux).

matthiasm wrote:

> 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?

I'd very much like to see this. I've used FLTK for a couple of projects in the past (and had I worked more with C++, there would have been more than a couple) and would love to have it available for D.

In article <e9sj5n$2skq$1@digitaldaemon.com>, John Demme says...
>
>Is FLTK capable of integrating with the platform's look and feel? That is, would it look out of place in my Linux Gnome or KDE desktop environment?

It does not "integrate" because it does not use KDE or Qt widgets, but it does
not look like it is from a
different planet either. It is relatively easy to add new themes to it. It does
look and feel the exact same
on all platforms though, unless it is lauched with a different scheme.

>Does FLTK have some sort of HTML renderer or advanced text display box?

FLTK has the Fl_Help_Widget which renders a subset of HTML, including local
links, tables, images,
fonts and size, etc. . It does support copy and paste.

>If the visual interface designer is any good and spat out good D code, then I'd probably use FLTK for D.  I really like the idea of a lightweight UI library to use with D- this pairs well with the way I write D code.

I like the C++ code it creates. It is readable and it also has a live preview
that reflects all visual changes
right away in a code window. So you can always control what you are doing.

>Welcome to D.

Thanks you ;-)

>Are you thinking about forking FLTK, porting it then maintaining/syncing the D version, or just moving FLTK over to D and phasing out the C++ version? (I like the last option, but some of your current users might be annoyed)

I am planning on porting FLTK1.1, then upgrading to FLTK1.2. FLTK1.1 is
feature-complete and has
very little known bugs. That way, a D and a C++ version can easily be maintained
in parallel - avoiding
getting tared and feathered by our C++ users.

It would also mean that the API is very very similar, so the mailing lists could
actually be shared. Most
discussions are about little tricks and library useage, so they would apply to
both languages.

FLTK 1.2 is the UTF-8 and slightly extended version of FLTK 1.1. Once D-FLTK1.1
is stable, I would
sync FLTK-1.2 to FLTK-1.1 (1.1 is currently slightly advanced) and then upgrade
D-FLTK1.1 to 1.2 to
get the full international font support, table widgets, etc. .

As for FLTK2, this library is very much a moving target. It would be impossible
to keep the D and C++
version in sync. Having worked extensively with 1.1 and 2.0, 2.0 is IMHO not
substentially advanced. It
has a slightly more polished API and better theme support though.

Matthias

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!

matthiasm wrote:

> 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?

Having a "lightweight" widget toolkit available for D would be a good thing, if it was native to D (i.e. not using C++ libs) - even better!

Currently we have two "heavyweight" widget toolkits in the making, that would be DWT (based on SWT / Java) and wxD (based on wxWidgets / C#).

We also have MinWin and FOX, but neither is available for Macintosh...
(unless you count running under X11, which is a bit of a cheat really)

So if FLTK was available to D (native or wrapped), that would be great!

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

Does this port require that the Windows and Carbon headers are completed first ? If so, we could have a slight bit of a problem there already...

FLTK itself (in C++) works good enough on Win/Mac, just wonder how easy it will be to port those sections over to D. Was that part of your test?

There is some movement on translating the Win32 headers, but I don't think the CarbonHeaders project (on Dsource) is making much progress.

I tried it earlier, but in the end just gave up and used C++ instead...

--anders

matthiasm wrote:

>>Is FLTK capable of integrating with the platform's look and feel? That is,
>>would it look out of place in my Linux Gnome or KDE desktop environment?
> 
> It does not "integrate" because it does not use KDE or Qt widgets, but it does
> not look like it is from a different planet either. It is relatively easy to add new themes to it. It does
> look and feel the exact same on all platforms though, unless it is lauched with a different scheme.

It definitely feels alien on Mac OS X, but as long as it works...
(and it's definitely better than having to fire up X11.app first)

Swing has a more terrestrial look-and-feel, but that's probably
because Apple has spent tons of effort on making it look that way.


As with GTK+, it's the things like file browsing that hurt the most.
The others just look "gray", but so does e.g. Firefox so that's "OK".

Then again, I am using wxWidgets and Camino just because of the looks.
But having a unified/cross-platform look-and-feel isn't all bad either.

--anders

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
> 
> 
> 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/
> 
> 

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

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?

Thanks,
DavidM

Anders F Björklund wrote:
> matthiasm wrote:
> 
>> 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?
> 
> Having a "lightweight" widget toolkit available for D would be a good thing, if it was native to D (i.e. not using C++ libs) - even better!
> 
> C...
> 
> --anders

That thing about "native to D" is more important that it at first appears.  On Linux there are two different versions of D with two different linking conventions.

dmd, the Digital Mars D, doesn't link well (at all?) with system libraries.  Some people have managed to make it work, and my hat is off to them.

gdc, OTOH, uses the standard system linkages, but is always out of step with dmd. (Naturally.  D is a moving target, and gdc is not a full time job.)

This means that things that require system libraries, like GUIs, can be very...sporadically working...when using D and Linux.  This is the more noticeable as most of the development work on graphics is happening only on MSWind (for obvious reasons).  There are a few exceptions, and I cherish them!, but a native graphics toolkit would just SOLVE the problem.

Charles D Hixson wrote:

> That thing about "native to D" is more important that it at
> first appears.  On Linux there are two different versions of
> D with two different linking conventions.
> 
> dmd, the Digital Mars D, doesn't link well (at all?) with
> system libraries.  Some people have managed to make it work,
> and my hat is off to them.
> 
> gdc, OTOH, uses the standard system linkages, but is always
> out of step with dmd. (Naturally.  D is a moving target, and
> gdc is not a full time job.)

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

Anders F Björklund wrote:
> Charles D Hixson wrote:
> 
>> That thing about "native to D" is more important that it at
>> first appears.  On Linux there are two different versions of
>> D with two different linking conventions.
>>
>> dmd, the Digital Mars D, doesn't link well (at all?) with
>> system libraries.  Some people have managed to make it work,
>> and my hat is off to them.
>>
>> gdc, OTOH, uses the standard system linkages, but is always
>> out of step with dmd. (Naturally.  D is a moving target, and
>> gdc is not a full time job.)
> 
> 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) ?
> 

Not sure I follow that either - have an example?

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

I believe the OP was speaking of a complete native port, especially because he mentioned adding D delegates for non-static member function callbacks (a limitation FLTK/C++ currently has).

> 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