www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - FLTK native in 'D'. Would that be useful?

reply matthiasm <matthiasm_member pathlink.com> writes:
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/
Jul 21 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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 personally think that would be great. I eval'd FLTK a while back for a 
potential project and was impressed. It is what its name implies :)

IIRC, one of the things I didn't like about it was that event handler 
callbacks could not be non-static member functions primarily because of 
an intersection of how FLTK was designed and the lack of portable 
"delegate" type functionality in C++. Conversely, I didn't like how Qt 
handles that either (with MOC and related).

With FLTK though I think the problem could be handled well with D delegates.

Ahhh, here it is: http://fltk.org/str.php?L171

IMHO, that would especially make a port worthwhile and (again, from what 
I recall about FLTK) D and FLTK seem to be made for one another <g> FLTK 
is a small static lib., fast, light, reasonably good feature set, 
modular enough to extend with new widgets, etc... Member function 
callbacks would be a great addition I think.

Be forewarned though that a port of SWT has kind-of been tagged as 
"semi-offical" but that project seems to be be stagnant right now.

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).
Jul 21 2006
next sibling parent matthiasm <matthiasm_member pathlink.com> writes:
In article <e9rd6l$1gvt$1 digitaldaemon.com>, Dave says...

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. 


I personally think that would be great. I eval'd FLTK a while back for a 
potential project and was impressed. It is what its name implies :)

IIRC, one of the things I didn't like about it was that event handler 
callbacks could not be non-static member functions primarily because of 
an intersection of how FLTK was designed and the lack of portable 
"delegate" type functionality in C++. 


Thanks for the nice mail.

You are right, D fixes exactly that with its delegates.
Jul 21 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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.
Jul 21 2006
parent MatthiasM <dm matthiasm.com> writes:
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
Jul 27 2006
prev sibling next sibling parent mrw <mrw_member pathlink.com> writes:
In article <e9r97s$1dg2$1 digitaldaemon.com>, matthiasm says...


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


I think this is an awesome idea.  D is in desparate need of a standard and
portable GUI toolkit.

Mark
Jul 21 2006
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
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 would be interested in seeing a good GUI kit for D, FLTK looks as good 
as (or better) the others I've seen.

BTW, does FLTK access the native GUI framework, or does it shell around 
them?
Jul 21 2006
parent matthiasm <matthiasm_member pathlink.com> writes:
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).
Jul 22 2006
prev sibling next sibling parent Sai <Sai_member pathlink.com> writes:
I really think that would be wonderful.

Infact we use FLTK front-end for a software we developed inhouse to
display 'resin' flow in simulations of composite manufacturing ! Currently it is
written in C++

If a D native version of FLTK is available, I would really use it for all
front-ends from now on. 

I am really interested and would be your first user.

Thanks
Sai



In article <e9r97s$1dg2$1 digitaldaemon.com>, matthiasm says...

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/
Jul 21 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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?


If this were ported it D it would be my GUI of choice.

~ Clay


 
 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/
Jul 21 2006
prev sibling next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 22 Jul 2006 05:17:16 +1000, 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?


Yes! THIS WOULD BE USEFUL, he exclaims :-)

There would be any number of good, experienced D people to help with the  
porting issues that arise.

-- 
Derek Parnell
Melbourne, Australia
Jul 21 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
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/


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?

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

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.

It'd be especially nice to have a UI library which would work with build, so
I don't have to worry about external libraries.

Welcome to D.

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)

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Jul 21 2006
parent reply matthiasm <matthiasm_member pathlink.com> writes:
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
Jul 22 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jul 23 2006
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Jul 22 2006
prev sibling next sibling parent reply Dieter Dannerbeck <dannerbeck.dieter gmx.de> writes:
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!
Jul 23 2006
parent Dave <Dave_member pathlink.com> writes:
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/
Jul 23 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 


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
Jul 23 2006
parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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.
Jul 23 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jul 23 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
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
Jul 23 2006
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
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.)
Jul 24 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
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
Jul 23 2006
parent reply MatthiasM <dm matthiasm.com> writes:
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
Jul 27 2006
next sibling parent reply MatthiasM <dm matthiasm.com> writes:
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
Jul 27 2006
next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
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
Jul 27 2006
parent reply MatthiasM <dm matthiasm.com> writes:
John Reimer wrote:

 
 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?


Yes, that would be possible. I do agree on the looks. My original idea 
was to do the port as compatible as possible, so that existing FLTK apps 
can be easily ported, which is why I left the original class names alone.

I am still not a hundred percent familiar with the "module" keyword full 
names. My first choice would be to map class names like this: (best of 
both worlds)

   C++:           D:

   Fl_Window  ->  fl.Window (or just Window, if no name conflict)
   Fl_Group   ->  fl.Group
   fl_draw()  ->  fl.draw()

How would I implement this, assuming the fltk path would be for example:

   gui/fl/window.d

and using

   import gui.fl.window;
Jul 27 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Thu, 27 Jul 2006 12:57:56 -0700, MatthiasM <dm matthiasm.com> wrote:


 John Reimer wrote:

  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 bett=




er  =


 looking than the older 1.1.
  Is that possible?


 Yes, that would be possible. I do agree on the looks. My original idea=


  =


 was to do the port as compatible as possible, so that existing FLTK ap=


ps  =


 can be easily ported, which is why I left the original class names alo=


ne.

 I am still not a hundred percent familiar with the "module" keyword fu=


ll  =


 names. My first choice would be to map class names like this: (best of=


  =


 both worlds)

    C++:           D:

    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
    Fl_Group   ->  fl.Group
    fl_draw()  ->  fl.draw()



Yes, that would be a solution.  They are called "renamed imports" and ar=
e  =

available as of 0.163. But you would need to do it slightly different wi=
th  =

GDC 0.19 which is still based off of 0.162 (or earlier?). Version 0.163 =
 =

implements an improved import system.  In GDC 0.19, you probably can do =
 =

the same using "alias" for now.



 How would I implement this, assuming the fltk path would be for exampl=


e:

    gui/fl/window.d

 and using

    import gui.fl.window;



Using dmd 0.163, try this:













Using GDC 0.19 (equivalent to 0.162), I think you can do this for now  =

(next version should support the new import features, though):













Others might have some more suggestions.  But I think that's an  =

improvement over using Fl_ prefix.

All the best,

JJR
Jul 27 2006
next sibling parent reply MatthiasM <dm matthiasm.com> writes:
John Reimer wrote:

    C++:           D:

    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
    Fl_Group   ->  fl.Group
    fl_draw()  ->  fl.draw()


 





JJR, that's just what I need.

I have decided to port the code literally first. After all, I need to 
maintain the C++ and D version now. As soon as the literal port id 
working flawlessly, I'll pick up on the Fl_ prefix issue and possibly 
remove the Fl_ for both the C++ and D version and keep them compatible.

I'll set that as a general rule for myself: first a complete port, the 
improve on it. Otherwise, I'll lose track.

Matthias
Jul 27 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Thu, 27 Jul 2006 23:36:22 -0700, MatthiasM <dm matthiasm.com> wrote:


 John Reimer wrote:

    C++:           D:

    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
    Fl_Group   ->  fl.Group
    fl_draw()  ->  fl.draw()







ace





 JJR, that's just what I need.

 I have decided to port the code literally first. After all, I need to =


 =


 maintain the C++ and D version now. As soon as the literal port id  =



 working flawlessly, I'll pick up on the Fl_ prefix issue and possibly =


 =


 remove the Fl_ for both the C++ and D version and keep them compatible=


.

 I'll set that as a general rule for myself: first a complete port, the=


  =


 improve on it. Otherwise, I'll lose track.

 Matthias



Sounds great, Matthias. I understand. :)

-JJR
Jul 28 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
John Reimer wrote:

 On Thu, 27 Jul 2006 12:57:56 -0700, MatthiasM <dm matthiasm.com> wrote:
 

 John Reimer wrote:

  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?


 Yes, that would be possible. I do agree on the looks. My original idea 
 was to do the port as compatible as possible, so that existing FLTK 
 apps can be easily ported, which is why I left the original class 
 names alone.

 I am still not a hundred percent familiar with the "module" keyword 
 full names. My first choice would be to map class names like this: 
 (best of both worlds)

    C++:           D:

    Fl_Window  ->  fl.Window (or just Window, if no name conflict)
    Fl_Group   ->  fl.Group
    fl_draw()  ->  fl.draw()


 
 
 Yes, that would be a solution.  They are called "renamed imports" and 
 are available as of 0.163. But you would need to do it slightly 
 different with GDC 0.19 which is still based off of 0.162 (or earlier?). 
 Version 0.163 implements an improved import system.  In GDC 0.19, you 
 probably can do the same using "alias" for now.
 
 

 How would I implement this, assuming the fltk path would be for example:

    gui/fl/window.d

 and using

    import gui.fl.window;


 
 
 Using dmd 0.163, try this:
 










 
 
 Using GDC 0.19 (equivalent to 0.162), I think you can do this for now 
 (next version should support the new import features, though):
 
 










 
 Others might have some more suggestions.  But I think that's an 
 improvement over using Fl_ prefix.
 
 All the best,
 
 JJR


But there is a problem with that, it won't work if one wants to import
several gui.fl.* modules.

   import gui.fl.window;
   alias gui.fl.window fl; // rename the module namespace
   import gui.fl.group;
   alias gui.fl.group fl; // <- fl name conflict

There are some particular aspects like these when converting code from a

package+module system. The best solution I think is to create a "name
forwarding" module that will emulate the fl namespace:

   module gui.fl.flnamespace;

   public import gui.fl.window;
   public import gui.fl.group;
   public import gui.fl.draw;

Usage:

   import gui.fl.flnamespace;
   alias gui.fl.flnamespace fl;

   ...

   fl.Window ...
   fl.Group ...
   fl.draw();

Alternatively you can also redesign the way you structure FLTKs classes
and accesses in D's naming system.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 30 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Sun, 30 Jul 2006 08:57:51 -0700, Bruno Medeiros  =

<brunodomedeirosATgmail SPAM.com> wrote:



    import gui.fl.window;


   Using dmd 0.163, try this:





ace










   Using GDC 0.19 (equivalent to 0.162), I think you can do this for n=




ow  =


 (next version should support the new import features, though):










  Others might have some more suggestions.  But I think that's an  =





 improvement over using Fl_ prefix.
  All the best,
  JJR


 But there is a problem with that, it won't work if one wants to import=



 several gui.fl.* modules.

    import gui.fl.window;
    alias gui.fl.window fl; // rename the module namespace
    import gui.fl.group;
    alias gui.fl.group fl; // <- fl name conflict

 There are some particular aspects like these when converting code from=


 a


 package+module system. The best solution I think is to create a "name
 forwarding" module that will emulate the fl namespace:

    module gui.fl.flnamespace;

    public import gui.fl.window;
    public import gui.fl.group;
    public import gui.fl.draw;

 Usage:

    import gui.fl.flnamespace;
    alias gui.fl.flnamespace fl;

    ...

    fl.Window ..
    fl.Group ...
    fl.draw();

 Alternatively you can also redesign the way you structure FLTKs classe=


s

 and accesses in D's naming system.



Ah yes, you are right, of course.  I didn't think far into the problem. =
  =

Thank you for pointing that out. It's good at least, that there are  =

alternatives available.

-JJR
Jul 30 2006
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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
Jul 27 2006
parent MatthiasM <dm matthiasm.com> writes:
clayasaurus wrote:

 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.


Thanks!


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


I uploaded a zip as well.

As soon as I have a little bit more sorted code, I will publish it on 
fltk.org and see how the community will react. I'll then decide if I 
stay on fltk.org or inquire with dsource. Thanks.
Jul 27 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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*
 


Not a total mess to me<g> Nice job, and thanks for work done already!

I just happened to notice that there are no private class members in 
window.d (for example) and looking at the original window.h there 
probably should be.

(I do it often - forget about D's 'public by default' when 'porting' C++ 
code.)

Thanks,

- Dave


 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
Jul 27 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Dave wrote:

 I just happened to notice that there are no private class members in 
 window.d (for example) and looking at the original window.h there 
 probably should be.


Ouch, I did not know that. Evil little details. Yes, we assume that the 
first members without a modifier are private.

I did find two or three "friend" declarations in the source. Is there 
some equivalent in "D" or a good way to replace it?
Jul 27 2006
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
MatthiasM wrote:

 Dave wrote:

 I just happened to notice that there are no private class members in 
 window.d (for example) and looking at the original window.h there 
 probably should be.


 
 Ouch, I did not know that. Evil little details. Yes, we assume that the 
 first members without a modifier are private.
 
 I did find two or three "friend" declarations in the source. Is there 
 some equivalent in "D" or a good way to replace it?


'private' in D means module-private[1], so just putting those classes in 
the same (implementation) module should be enough.
If you want to allow users to import them separately as if they were in 
different modules, just create 'forwarding' modules that either 
selectively publicly import those classes from the implementation module 
(requires v0.163) or privately import the implementation module and then 
alias a few symbols (for v0.162 and before, for v0.163 selective import 
should be preferred).


[1] I don't like it, but that's the way it is.
Jul 27 2006
parent reply Sean Kelly <sean f4.ca> writes:
Frits van Bommel wrote:

 MatthiasM wrote:

 Dave wrote:

 I just happened to notice that there are no private class members in 
 window.d (for example) and looking at the original window.h there 
 probably should be.


 Ouch, I did not know that. Evil little details. Yes, we assume that 
 the first members without a modifier are private.

 I did find two or three "friend" declarations in the source. Is there 
 some equivalent in "D" or a good way to replace it?


 
 'private' in D means module-private[1], so just putting those classes in 
 the same (implementation) module should be enough.
 If you want to allow users to import them separately as if they were in 
 different modules, just create 'forwarding' modules that either 
 selectively publicly import those classes from the implementation module 
 (requires v0.163) or privately import the implementation module and then 
 alias a few symbols (for v0.162 and before, for v0.163 selective import 
 should be preferred).
 
 
 [1] I don't like it, but that's the way it is.


Data can also be marked "package" to have package visibility.


Sean
Jul 27 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Data can also be marked "package" to have package visibility.


Right, forgot about that one. Haven't needed to use it even once so far ;).
Jul 27 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
MatthiasM wrote:

 Dave wrote:

 I just happened to notice that there are no private class members in 




window.d (for example) and looking at the original window.h there 
probably should be.

 Ouch, I did not know that. Evil little details. Yes, we assume that 


the first members without a modifier are private.

 I did find two or three "friend" declarations in the source. Is there 


some equivalent in "D" or a good way to replace it?

D's idea of 'friend'-ship for aggregate type members is if they are in 
the same physical module (source file), or with "package" access they 
can be in the same 'package'.

'private' means private to the module. 'package' means private to the 
package. private or package member functions are never virtually 
overridden (protected or public are by default though - no need for 
'virtual').

I think 'package' would work better from what I've seen of friend being 
used in FL.

For example:

// member of "gui.fl" package
// must be specified to allow package access
module gui.fl.window;

import gui.fl.widget;

class window
{
package: // allow other modules in gui.fl to access 'window_i'
     int window_i;
private:
     widget w;
public:
     void foo()
     {
         w.widget_i = 10; // package access to 'widget_i'
     }
}

// member of "gui.fl" package
// must be specified to allow package access
module gui.fl.widget;

import gui.fl.window;

class widget
{
package: // allow other modules in gui.fl to access 'widget_i'
     int widget_i;
private:
     window w;
public:
     void foo()
     {
         w.window_i = 10; // package access to 'window_i'
     }
}

Make sense?
Jul 27 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Dave wrote:

 
 Make sense?


Yes, absolutely! Another issue solved ;-)
Jul 27 2006
parent reply Dave <Dave_member pathlink.com> writes:
MatthiasM wrote:

 Dave wrote:

 Make sense?


 
 Yes, absolutely! Another issue solved ;-)


One other note on this <g> If a member function needs to be protected or 
public but is not to be overridden, it can be made 'final'. Then the 
compiler will always call it directly and it can be inlined, etc. (the 
compiler is free to 'auto-finalize' anyhow but I don't think it does 
that now). Since private and package functions are never virtual, this 
always applies to them.

Likewise a whole class can be made 'final'.

I don't know if this would apply to FLTK, but if there are some core 
protected or public functions that are called in tight loops then it 
might make a performance difference even over the C++ implementation.

Thanks,

- Dave
Jul 28 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:

 MatthiasM wrote:

 Dave wrote:

 Make sense?


 Yes, absolutely! Another issue solved ;-)


 
 One other note on this <g> If a member function needs to be protected or 
 public but is not to be overridden, it can be made 'final'. Then the 
 compiler will always call it directly and it can be inlined, etc.


Yup.  In general, all C++ functions that are not virtual should be 
marked 'final' in D.  Also, any private virtual functions must be made 
protected instead.


Sean
Jul 28 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Sean Kelly wrote:

 One other note on this <g> If a member function needs to be protected 
 or public but is not to be overridden, it can be made 'final'. Then 
 the compiler will always call it directly and it can be inlined, etc.


 
 Yup.  In general, all C++ functions that are not virtual should be 
 marked 'final' in D.  Also, any private virtual functions must be made 
 protected instead.


I see. I do not want to finalize too many functions, simply because I 
have stumbled over a few functions in FLTK that I would love to have 
virtual, but can't change it anymore in FLTK1.1.x because we are keeping 
binary compatibility within a branch, and we are not ready yet to open a 
true 1.2 ;-)

Matthias

PS: I am really interested in what the performance of the "D" code will 
be. It won't matter too much for FLTK itself, but eventually, should I 
port my Robotics simulation, performance is a requirement.
Jul 28 2006
parent Dave <Dave_member pathlink.com> writes:
MatthiasM wrote:

 Sean Kelly wrote:

 One other note on this <g> If a member function needs to be protected 
 or public but is not to be overridden, it can be made 'final'. Then 
 the compiler will always call it directly and it can be inlined, etc.


 Yup.  In general, all C++ functions that are not virtual should be 
 marked 'final' in D.  Also, any private virtual functions must be made 
 protected instead.


 
 I see. I do not want to finalize too many functions, simply because I 


I don't want to leave the impression that D code needs to be 'tuned' to
match C++ in general, I don't think that's the case but the compilers 
are young yet <g> In general the virtual method dispatch is probably 
just as good, it's just that it's on by default so final is low hanging 
fruit if you run into call speed issues.

IMHO, it's easier to write first-cut fast code with D.


 have stumbled over a few functions in FLTK that I would love to have 
 virtual, but can't change it anymore in FLTK1.1.x because we are keeping 
 binary compatibility within a branch, and we are not ready yet to open a 
 true 1.2 ;-)
 
 Matthias
 
 PS: I am really interested in what the performance of the "D" code will 
 be. It won't matter too much for FLTK itself, but eventually, should I 
 port my Robotics simulation, performance is a requirement.


Many would be interested in that too...

Don't know if you've seen these or not:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1

They are trivial but I think it is a good reference for D apps. w.r.t. 
common library functions, etc.

DMD and GDC seem pretty close, w/ DMD maybe being a tad faster for 
integer and GDC for floating point.

The main thing with any D implementation right now is to pre-allocate 
memory if possible before tight loops.

D's easy array slicing makes it easy to do things like:

const char[] s = "hello\n";
const int n = 1_000_000;
const int l = s.length;

char[] str;
for(int i = 0; i < n; i++)
{
     str ~= s;
}

to:

char[] str = new char[n * l];
for(int i = 0; i < n; i++)
{
     str[i*l .. i*l+l] = s;
}

- Dave
Jul 28 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
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
Jul 27 2006
parent MatthiasM <dm matthiasm.com> writes:
Lucas Goss wrote:

 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


Cool. The stuff is coming together ;)
Jul 27 2006
prev sibling next sibling parent "John Reimer" <terminal.node gmail.com> writes:
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
Jul 24 2006
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
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.
Jul 25 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"matthiasm" <matthiasm_member pathlink.com> wrote in message 
news:e9r97s$1dg2$1 digitaldaemon.com...

 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 am an author of Harmonia D gui toolkit.
See: http://harmonia.terrainformatica.com/

I know FLTK and I beleive some ideas of FLTK is there
already.

It is different though. In particular event propagation schema.
It also has lightweight HTML engine (form layout manager,
renderer, form resource definition, etc. )

BTW: One of design goals of Harmonia was to create sort of FLTK
but in D and for D.

Package class map: http://harmonia.terrainformatica.com/map.htm

It would be extremely nice if someone will take care about Linux port:
http://harmonia.terrainformatica.com/pmwiki.php/Harmonia/Porting

Andrew Fedoniouk.
http://terrainformatica.com
Jul 28 2006
parent reply kris <foo bar.com> writes:
Andrew Fedoniouk wrote:

... some shameful self-promotion in someone else's thread

<shakes head, sadly>


=========================


Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
available, floating around somewhere?
Jul 28 2006
next sibling parent reply MatthiasM <dm matthiasm.com> writes:
kris wrote:

 
 Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
 available, floating around somewhere?


I am working on it now.

I have seen a few designs that are reachable via the "links" section. I 
do not know how current they are and if they require much or any core 
source code changes.

For example here:

http://www.tts-sf.com/alexeyp/index.php?act=themes

(in FLTK lingo, they are called schemes (FLTK1) and themes (FLTK2) - no 
idea why ;-)
Jul 28 2006
next sibling parent kris <foo bar.com> writes:
MatthiasM wrote:

 kris wrote:
 

 Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
 available, floating around somewhere?


 
 
 I am working on it now.
 
 I have seen a few designs that are reachable via the "links" section. I 
 do not know how current they are and if they require much or any core 
 source code changes.
 
 For example here:
 
 http://www.tts-sf.com/alexeyp/index.php?act=themes
 
 (in FLTK lingo, they are called schemes (FLTK1) and themes (FLTK2) - no 
 idea why ;-)



Sweet!
Jul 29 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
MatthiasM wrote:

 kris wrote:

 Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins 
 available, floating around somewhere?


 
 I am working on it now.
 
 I have seen a few designs that are reachable via the "links" section. I 
 do not know how current they are and if they require much or any core 
 source code changes.
 
 For example here:
 
 http://www.tts-sf.com/alexeyp/index.php?act=themes
 
 (in FLTK lingo, they are called schemes (FLTK1) and themes (FLTK2) - no 
 idea why ;-)


MathiasM, relative to most other posts, this thread has seen a very 
strong and positive reaction. Thanks again for offering this to the D 
community.

A couple of questions...

Why did you decide to base the port off of FLTK1 instead of FLTK2 (I 
don't know the history of FLTK1 vs. 2)? Is there a risk that the D port 
would basically become obsolete before it's done?

And how can I best start contributing to the port right now w/o impeding 
your progress, duplicating work or otherwise stepping on your toes? An 
answer of "you can't" is fine too <g>

Thanks,

- Dave
Jul 29 2006
parent MatthiasM <dm matthiasm.com> writes:
Dave wrote:


 A couple of questions...
 
 Why did you decide to base the port off of FLTK1 instead of FLTK2 (I 
 don't know the history of FLTK1 vs. 2)? 


FLTK2 has been forked off of FLTK1 a very long time ago (more than five 
years ago) and even though it is being used in at least one commercial 
product, it has never left alpha state. I would love to see FLTK2 
stabilize, but I don't see that happening in the next six months. FLTK1 
has been developed in parallel and has more features and is extremely 
stable (whatever that means for an OpenSource project).

There are three disadvantages to FLTK1 over FLTK2:

1: FLTK1.1 has no Unicode/UTF8 support. However, this has been 
implemented as a patch for WMSWindows and X11 already. After completeing 
the port, I could imagine to put this patch into the C++ and D source tree.

2: FLTK2 has a better theme support (but by no means "complete"). Work 
would be needed on 1 and 2.

3: FLTK2 has a better vector symbol support. Something that could be 
easily backported. I doubt that many users even know about this feature 
though ;-)


 Is there a risk that the D port 
 would basically become obsolete before it's done?


I am more concerned about trying to follow a moving target by porting 
FLTK2, then getting annoyed, and then ending up with yet another fork 
between C-FLTK2 and D-FLTK2.


 And how can I best start contributing to the port right now w/o impeding 
 your progress, duplicating work or otherwise stepping on your toes? An 
 answer of "you can't" is fine too <g>


All the replies were very exciting and encouraging. I will set up and 
SVN repository next week, hopefully with a working "Hello World" on OS 
X. I will then post the URL to this forum.

You can help by either porting core functionality for other platforms 
(X11, Win32), by porting the higher level widget code, or by 
implementing a build environment for any (or all) of those three 
platforms. Details will be in a README file.

Thanks for the support!

Matthias
Jul 29 2006
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"kris" <foo bar.com> wrote in message 
news:eaepam$2ma1$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 ... some shameful self-promotion in someone else's thread

 <shakes head, sadly>


"shameful self-promotion", nice :)

You think that to ask guy to write FLTK from scratch is honest?

Again as I said Harmonia implementation was made with FLTK in mind.

From all existing D toolkits Harmonia is closest to FLTK - it uses the same
paradigm - top level OS windows and lightweight hand made widgets inside.

As I said one day: unified GUI subsystem in D ideally should consist from 
indepedent
layers:
1) Window library - top level OS window wrapper .
2) Unified Graphics library - generic class graphics + implementations: 
native_graphics,
opengl_graphics, agg_graphics, etc.

Someone then can create DWT, FLTK on top of it or any other toolkit, 
windowed or windowless.
At least these parts will not be designed again and again.

I would be happy if at the moment of Harmonia design I was able to find 
something close.
I am not a masochist.

Why I am asking to look in Harmonia? Just for ideas of how FLTK style of UI
can be implemented exactly in D. It took me quite a while to find D-ish 
solutions for platform
independent UI design there. I think it is pretty wise approach to take a 
look on what
is done already. Why do you think this approach is wrong?

------------------------------------------
And here goes real self-promotion portion if you wish:
  htmlayout (as UI core) at the end of this year will be installed on 2.2 
mln PCs
  in various software products and vendors. Currently it serves near 
1,000,000 customers
  in America and Europe. This includes police and FD in US.
  In China I've been told that this number is around 1 mln too.
-- end of real self-promotion portion if you wish -----

Andrew Fedoniouk.
http://terrainformatica.com
Jul 28 2006
parent reply kris <foo bar.com> writes:
Andrew Fedoniouk wrote:

 "kris" <foo bar.com> wrote in message 
 

Andrew Fedoniouk wrote:

... some shameful self-promotion in someone else's thread

<shakes head, sadly>


 
 
 "shameful self-promotion", nice :)


That's rather unfortunate that you think so.

[snip incomprehensible patter]

I'm sliding this out of the FLTK thread since you apparently don't have 
the decency to do so yourself. Please let that thread /remain/ focused 
on FLTK alone
Jul 29 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"kris" <foo bar.com> wrote in message 
news:eaf29n$2uef$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 "kris" <foo bar.com> wrote in message

Andrew Fedoniouk wrote:

... some shameful self-promotion in someone else's thread

<shakes head, sadly>



 "shameful self-promotion", nice :)


 That's rather unfortunate that you think so.

 [snip incomprehensible patter]

 I'm sliding this out of the FLTK thread since you apparently don't have 
 the decency to do so yourself. Please let that thread /remain/ focused on 
 FLTK alone


I really don't understand, sorry, probably some cultural differences.
What do you think what would be the name of such thread?
Jul 29 2006
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Hi Matthias!

Yes, i think we can make it true. :D But, naturally, some D-specific 
features must be used in this new instance of FLTK. Delegates comes to 
the first place in my mind when i think about this.

In any case, i am planning working on a D GUI for more than half year... 
Now when you are around, and some other guys i know, we can actually 
start working on it.

I am glad you like D, btw. :)


Dejan
Aug 06 2006
next sibling parent reply MatthiasM <dm matthiasm.com> writes:
Dejan Lekic wrote:

 Hi Matthias!
 
 Yes, i think we can make it true. 


Hi Dejan, nice to see you here ;-)

I have so far made "test/hello" work in "D" on OS X and will post my 
source to the FLTK svn on Monday or Tuesday. All is still very 
bare-bones and un-D-ish, but the magiv of OpenSource will hopefully get 
all the features ported pretty quickly.

So far, it has been a very exciting lesson in "D".

Matthias
Aug 06 2006
parent Dejan Lekic <dejan.lekic gmail.com> writes:
Well, as you know, i am in D world for a long time... That is the reason 
i am quiet in FLTK world. I am working on some D-based projects...

I would gladly work on d-native FLTK, naturaly. :) We might move it to 
separate repository on fltk.org, or alternatively, on fltk.net . As you 
know, i have SVN server for years on my server.

Kind regards.

Dejan
Aug 07 2006
prev sibling parent reply MatthiasM <dm matthiasm.com> writes:
Hello everyone,

as promised, I have put a first attempt at D-FLTK onto our Subversion 
system. The test application "hello" runs already on OS X.

Everyone interested, please feel free to download, play, improve and 
comment! You can send patches to me directly. You can also join the 
general fltk newsgroup and discuss D-FLTK there (until the C++ folks 
complain about too much traffic ;-)

Anyway, I hop ya'll enjoy and don't get scared by my "D" style.


Here's how you get the source:


svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-D-1.1 
d-fltk-1.1.x


All "D" sources are in - um - "D". The rest of the FLTK archive is 
intact to make it easy to compare "D" and "C++" code.

Matthias
Aug 07 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
MatthiasM wrote:


 as promised, I have put a first attempt at D-FLTK onto our Subversion 
 system. The test application "hello" runs already on OS X.


Looking good! Ran into some minor problems with GDC 0.19:
fl/mac.d:295: shadowing declaration fl.mac.Fl_X.make.w is deprecated
fl/mac.d:1253: shadowing declaration fl.mac.do_queued_events.ret is 
deprecated

But they were easy enough to work around by renaming them:
http://www.algonet.se/~afb/d/fltk-mac-5282.patch


No way to quit the app but to force-quit it, but looks OK:
http://www.algonet.se/~afb/d/hello-fltk-mac.png

Great work anyway! And since it is LGPL, you can take Mac code
from the similarly licensed GTK and wxWidgets projects as needed.


BTW; Don't you want to version it "Carbon" rather than "Apple" ?
And I'd put the headers in std.c.macosx instead of std.c.osx...

And there are some Makefiles snippets in wxD, if you want to make
application bundles - rather than play around with resource forks.

--anders
Aug 07 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Anders F Björklund wrote:

 MatthiasM wrote:
 

 as promised, I have put a first attempt at D-FLTK onto our Subversion 
 system. The test application "hello" runs already on OS X.


 
 Looking good! Ran into some minor problems with GDC 0.19:
 fl/mac.d:295: shadowing declaration fl.mac.Fl_X.make.w is deprecated
 fl/mac.d:1253: shadowing declaration fl.mac.do_queued_events.ret is 
 deprecated


Thanks. I am still using 0.18. I will probably be able to upgrade tonight.


 No way to quit the app but to force-quit it, but looks OK:


True. The internal messaging in FLTK is yet to be implemented. No OS 
dependent code though, makes porting easy and quick.


 Great work anyway! And since it is LGPL, you can take Mac code
 from the similarly licensed GTK and wxWidgets projects as needed.


Yes, the OS X code is anything but nice. It was already a pretty brute 
force port from MacOS8 (!). As soon as the FLTK code itself is ported 
(1:1 right now), I will start improving the OS X implementation.


 BTW; Don't you want to version it "Carbon" rather than "Apple" ?
 And I'd put the headers in std.c.macosx instead of std.c.osx...


Good point.


 And there are some Makefiles snippets in wxD, if you want to make
 application bundles - rather than play around with resource forks.


Thanks. I have not spent any time whatsoever on Makefiles. Hoping that 
someone who is smarter than myself can do a Makefile that would work on 
all platforms.

Thanks for testing!

Matthias
Aug 07 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
MatthiasM wrote:

 Anders F Björklund wrote:

 MatthiasM wrote:


 as promised, I have put a first attempt at D-FLTK onto our Subversion 
 system. The test application "hello" runs already on OS X.


 Looking good! Ran into some minor problems with GDC 0.19:
 fl/mac.d:295: shadowing declaration fl.mac.Fl_X.make.w is deprecated
 fl/mac.d:1253: shadowing declaration fl.mac.do_queued_events.ret is 
 deprecated


 
 Thanks. I am still using 0.18. I will probably be able to upgrade tonight.
 

 No way to quit the app but to force-quit it, but looks OK:


 
 True. The internal messaging in FLTK is yet to be implemented. No OS 
 dependent code though, makes porting easy and quick.
 

 Great work anyway! And since it is LGPL, you can take Mac code
 from the similarly licensed GTK and wxWidgets projects as needed.


 
 Yes, the OS X code is anything but nice. It was already a pretty brute 
 force port from MacOS8 (!). As soon as the FLTK code itself is ported 
 (1:1 right now), I will start improving the OS X implementation.
 

 BTW; Don't you want to version it "Carbon" rather than "Apple" ?
 And I'd put the headers in std.c.macosx instead of std.c.osx...


 
 Good point.
 

 And there are some Makefiles snippets in wxD, if you want to make
 application bundles - rather than play around with resource forks.


 
 Thanks. I have not spent any time whatsoever on Makefiles. Hoping that 
 someone who is smarter than myself can do a Makefile that would work on 
 all platforms.
 
 Thanks for testing!
 
 Matthias


Have you checked out build? http://www.dsource.org/projects/build
Aug 07 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 And there are some Makefiles snippets in wxD, if you want to make
 application bundles - rather than play around with resource forks.


 Thanks. I have not spent any time whatsoever on Makefiles. Hoping that 
 someone who is smarter than myself can do a Makefile that would work 
 on all platforms.


 
 Have you checked out build? http://www.dsource.org/projects/build


It's not so much the tool used (Make vs. Build), as it is two ways
of packaging software for the inheritely "dual" Mac OS X platform.

You can either do it the Mac OS way (with resources), or you can
do it the NeXT way (with bundles), the system supports both ways.


I wrote in some more detail about it on the CodeBlocks wiki:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X#Bundle_application_for_Mac

You need to do either, after compiling a binary/exe ("as usual").
Otherwise applications will launch in the background, no events.

--anders
Aug 07 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
clayasaurus wrote:

 MatthiasM wrote:

 Anders F Björklund wrote:

 MatthiasM wrote:


 as promised, I have put a first attempt at D-FLTK onto our 
 Subversion system. The test application "hello" runs already on OS X.


 Looking good! Ran into some minor problems with GDC 0.19:
 fl/mac.d:295: shadowing declaration fl.mac.Fl_X.make.w is deprecated
 fl/mac.d:1253: shadowing declaration fl.mac.do_queued_events.ret is 
 deprecated


 Thanks. I am still using 0.18. I will probably be able to upgrade 
 tonight.


 No way to quit the app but to force-quit it, but looks OK:


 True. The internal messaging in FLTK is yet to be implemented. No OS 
 dependent code though, makes porting easy and quick.


 Great work anyway! And since it is LGPL, you can take Mac code
 from the similarly licensed GTK and wxWidgets projects as needed.


 Yes, the OS X code is anything but nice. It was already a pretty brute 
 force port from MacOS8 (!). As soon as the FLTK code itself is ported 
 (1:1 right now), I will start improving the OS X implementation.


 BTW; Don't you want to version it "Carbon" rather than "Apple" ?
 And I'd put the headers in std.c.macosx instead of std.c.osx...


 Good point.


 And there are some Makefiles snippets in wxD, if you want to make
 application bundles - rather than play around with resource forks.


 Thanks. I have not spent any time whatsoever on Makefiles. Hoping that 
 someone who is smarter than myself can do a Makefile that would work 
 on all platforms.

 Thanks for testing!

 Matthias


 
 Have you checked out build? http://www.dsource.org/projects/build


IMHO, build is great and all, but I think we're better off w/ Make to start
with because it doesn't 
require another download, etc. It'd be a pity to have to support more than one
build method at this 
early stage (Make should do the job fine) I think.
Aug 07 2006
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
I share this opinion. Everyone has GNU Make.


 IMHO, build is great and all, but I think we're better off w/ Make to 
 start with because it doesn't require another download, etc. It'd be a 
 pity to have to support more than one build method at this early stage 
 (Make should do the job fine) I think.
Aug 07 2006
parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 07 Aug 2006 22:24:57 +0200, Dejan Lekic wrote:


 I share this opinion. Everyone has GNU Make.


I don't.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Aug 07 2006
next sibling parent kris <foo bar.com> writes:
Derek Parnell wrote:

 On Mon, 07 Aug 2006 22:24:57 +0200, Dejan Lekic wrote:
 
 

I share this opinion. Everyone has GNU Make.


 
 
 I don't.
 


I don't either.

However, I'm of the opinion that the DMD front-end should incorporate a 
little of Derek's Build goodness: specifically the facility to 
incorporate imported modules as part of the codegen/link step.

DMD has always opened and parsed all import modules, but right now it 
appears to discard them before codegen. Seems to me that should change 
(via a switch, or something); assuming Derek were given some credit for it
Aug 07 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


I share this opinion. Everyone has GNU Make.


 
 I don't.


At this point you can probably just run Build
on the sample application for the same effect ?

(that would be "d-fltk-1.1.x/D/test/hello.d")

Matthias needs some volunteers to port to, and
test on, the Windows and X11 platforms anyway

--anders
Aug 08 2006
prev sibling next sibling parent Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 
 Hello everyone,
 
 as promised, I have put a first attempt at D-FLTK onto our Subversion 
 system. The test application "hello" runs already on OS X.
 
 Everyone interested, please feel free to download, play, improve and 
 comment! You can send patches to me directly. You can also join the 
 general fltk newsgroup and discuss D-FLTK there (until the C++ folks 
 complain about too much traffic ;-)
 
 Anyway, I hop ya'll enjoy and don't get scared by my "D" style.
 
 
 Here's how you get the source:
 
 
 svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-D-1.1 
 d-fltk-1.1.x
 
 
 All "D" sources are in - um - "D". The rest of the FLTK archive is 
 intact to make it easy to compare "D" and "C++" code.
 
 Matthias


I gave it a try, and it worked, although I had to add "-fdeprecated" to the 
Makefile compile rule (are you using gdc 0.19?)

You should add "module" lines to the std/c/osx/* files. Also, when they're 
complete (if they're not already), you could ask Walter or David for inclusion 
in Phobos/GPhobos.

Finally, you have code like this:

version (Apple) {
   public import fl.mac;
}

version (X11) {
   public import fl.x11;
}

version (Win32) {
   public import fl.win32;
}

(I intentionally uncommented a couple of lines). I think it would be better if 
you added "else" clauses:

version (Apple) {
   public import fl.mac;
}
else version (X11) {
   public import fl.x11;
}
else version (Win32) {
   public import fl.win32;
}

Just in case.

Keep up this work because it's looking good.

-- 
Carlos Santander Bernal
Aug 07 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 
 Hello everyone,
 
 as promised, I have put a first attempt at D-FLTK onto our Subversion 
 system. The test application "hello" runs already on OS X.
 
 Everyone interested, please feel free to download, play, improve and 
 comment! You can send patches to me directly. You can also join the 
 general fltk newsgroup and discuss D-FLTK there (until the C++ folks 
 complain about too much traffic ;-)
 
 Anyway, I hop ya'll enjoy and don't get scared by my "D" style.
 
 
 Here's how you get the source:
 
 
 svn co http://svn.easysw.com/public/fltk/fltk/branches/branch-D-1.1 
 d-fltk-1.1.x
 
 
 All "D" sources are in - um - "D". The rest of the FLTK archive is 
 intact to make it easy to compare "D" and "C++" code.
 
 Matthias


You forgot to add std/c/osx/qd/quickdraw.d to rev 5287. Also, the previous two 
revs didn't work (I got "bus error" with both of them)

-- 
Carlos Santander Bernal
Aug 08 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Carlos Santander wrote:

 You forgot to add std/c/osx/qd/quickdraw.d to rev 5287. Also, the 
 previous two revs didn't work (I got "bus error" with both of them)


Thanks. I added the quickdraw.d header file.

If you get a bus error (which is very likely in this early state), it 
would be helpful if you could run 'gdb' on the executable and post the 
first eight or so lines of the traceback. Just enter:

   gdb button
   run
   bt

like so:


 gdb button


(gdb) run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000a
0x00003ec0 in _Dmain (args={length = 1, ptr = 0x303710}) at test/button.d:53
53        (cast(ubyte*)null)[10] = 3;
(gdb) bt

test/button.d:53



/SourceCache/Csu/Csu-58.1.1/crt.c:272

(gdb)

Thanks!

Matthias
Aug 08 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 
 Thanks. I added the quickdraw.d header file.


Ok. Now I get "make: *** No rule to make target `test/button.o', needed by
`button'.  Stop." I guess test/button.d is missing.


 
 If you get a bus error (which is very likely in this early state), it 
 would be helpful if you could run 'gdb' on the executable and post the 
 first eight or so lines of the traceback. Just enter:
 


Ok, here it is (rev 5288):

(gdb) bt

/System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:189

../../../gcc-4.0.3/libphobos/internal/adi.d:576

a={length = 2, ptr = 0x0}) at fl/widget.d:356


../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83

../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93

/SourceCache/Csu/Csu-58/crt.c:272



-- 
Carlos Santander Bernal
Aug 09 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Carlos Santander wrote:

 Thanks. I added the quickdraw.d header file.


 
 Ok. Now I get "make: *** No rule to make target `test/button.o', needed by
 `button'.  Stop." I guess test/button.d is missing.


Gee, where did I leave my brain yesterday? OK, it is added.


 Ok, here it is (rev 5288):
 
 (gdb) bt


Cool. Thanks! That shows that I did not understand slicing, duplicating 
and flexible arrays yet ;-)
Aug 09 2006
parent Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 Carlos Santander wrote:

 Thanks. I added the quickdraw.d header file.


 Ok. Now I get "make: *** No rule to make target `test/button.o', 
 needed by
 `button'.  Stop." I guess test/button.d is missing.


 
 Gee, where did I leave my brain yesterday? OK, it is added.
 

 Ok, here it is (rev 5288):

 (gdb) bt


 
 Cool. Thanks! That shows that I did not understand slicing, duplicating 
 and flexible arrays yet ;-)
 


rev 5291 works except when exiting the programs with Command-Q: bus error
again. 
Here's what I get:

(gdb) bt

(appleEvt=0xbfffead0, 
reply=0xbfffeae0, refcon=0) at fl/mac.d:1309












(nextHandler=0xbffff010, event=0x309730, userData=0x0) at fl/mac.d:1113















(nextHandler=0xbffff7e0, event=0x30a660, userData=0x0) at fl/mac.d:1113









../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83

../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93

/SourceCache/Csu/Csu-58/crt.c:272



-- 
Carlos Santander Bernal
Aug 09 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
HideSheetWindow is declared twice in windowmanager.

Also, maybe you should change your function pointer types from typedefs to 
aliases so no casting is required to use them.

-- 
Carlos Santander Bernal
Aug 09 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Carlos Santander wrote:

 HideSheetWindow is declared twice in windowmanager.


Thanks. Removed.


 Also, maybe you should change your function pointer types from typedefs 
 to aliases so no casting is required to use them.


Which ones? In the Carbon headers? Or in FLTK?

Matthias
Aug 14 2006
parent Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 Carlos Santander wrote:

 Also, maybe you should change your function pointer types from 
 typedefs to aliases so no casting is required to use them.


 
 Which ones? In the Carbon headers? Or in FLTK?
 


Carbon. I haven't seen the FLTK code yet, but I suppose you're doing the same, 
so the same suggestion applies.

-- 
Carlos Santander Bernal
Aug 14 2006
prev sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Another suggestion: you have code like this:

typedef UInt32 WindowPositionMethod;
enum {
    kWindowCenterOnMainScreen = 1,
    ...
}

I think you should make one of these two changes: change the typedef to alias 
(why, because C's typedef isn't D's typedef but alias), or make the enum derive 
(is that the right term?) from the typedef:

enum : WindowPositionMethod {
    kWindowCenterOnMainScreen = 1,
    ...
}

OT:
to anyone, what's the svn command to get a diff between two revisions of a file?

-- 
Carlos Santander Bernal
Aug 17 2006
parent reply Marcin Kuszczak <aarti interia.pl> writes:
 OT:
 to anyone, what's the svn command to get a diff between two revisions of a
 file?
 


This one is simple :-)

svn diff -r 100:HEAD or
svn diff -r 100:101

-- 
Regards
Marcin Kuszczak
(Aarti_pl)
Aug 17 2006
parent Carlos Santander <csantander619 gmail.com> writes:
Marcin Kuszczak escribió:

 OT:
 to anyone, what's the svn command to get a diff between two revisions of a
 file?


 
 This one is simple :-)
 
 svn diff -r 100:HEAD or
 svn diff -r 100:101
 


Thanks.

-- 
Carlos Santander Bernal
Aug 17 2006
prev sibling next sibling parent reply MatthiasM <dm matthiasm.com> writes:
I had a little more time and managed to port pushhbuttons and keyboard 
handling. The "button" demo works pretty well now.

I also ported the standard dialogs (messages, alerts, simple choices), 
and apart from the Fl_Input widget, the seem to work.

Group resizing is now implemented as well.

So, just in case you are writing a GUI app on Mac that only needs 
pushbuttons in a window, D-FLTK is usable for you ;-)


Matthias


PS: since I don't have the terminating 0 in "D" strings, you will 
sometimes see additional letters popping up in labels. This still 
requires fixing. The code is in "D/fl/draw.d", called fl_measure and 
fl_draw... .

PPS: download is still only via svn from:
   http://svn.easysw.com/public/fltk/fltk/branches/branch-D-1.1
Aug 13 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
MatthiasM escribió:

 
 I had a little more time and managed to port pushhbuttons and keyboard 
 handling. The "button" demo works pretty well now.
 
 I also ported the standard dialogs (messages, alerts, simple choices), 
 and apart from the Fl_Input widget, the seem to work.
 
 Group resizing is now implemented as well.
 
 So, just in case you are writing a GUI app on Mac that only needs 
 pushbuttons in a window, D-FLTK is usable for you ;-)
 
 
 Matthias
 
 
 PS: since I don't have the terminating 0 in "D" strings, you will 
 sometimes see additional letters popping up in labels. This still 
 requires fixing. The code is in "D/fl/draw.d", called fl_measure and 
 fl_draw... .
 
 PPS: download is still only via svn from:
   http://svn.easysw.com/public/fltk/fltk/branches/branch-D-1.1


I still get a bus error when pressing Command-Q with rev 5297 (both hello and 
button):

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00023e1c in _D2fl3mac21QuitAppleEventHandlerFPvPviZi (appleEvt=0xbfffead0, 
reply=0xbfffeae0, refcon=0) at fl/mac.d:1295
1295        if ( Fl_X.first == x ) {
(gdb) bt

(appleEvt=0xbfffead0, 
reply=0xbfffeae0, refcon=0) at fl/mac.d:1295












(nextHandler=0xbffff010, event=0x409490, userData=0x0) at fl/mac.d:1100















(nextHandler=0xbffff7e0, event=0x425ff0, userData=0x0) at fl/mac.d:1100









../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83

../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93

/SourceCache/Csu/Csu-58/crt.c:272



-- 
Carlos Santander Bernal
Aug 13 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Carlos Santander wrote:

 I still get a bus error when pressing Command-Q with rev 5297 (both 
 hello and button):


Thanks. This should be fixed now.

I can't get used to the fact that in "D", you can't compare pointers if 
one of them may be null:

class Fl_Window {
   ...
};
Fl_Window first_window, this_window;
if (first_window==this_window) ...

Now if first_window is null, I get a crash that I would not get in C++. 
Ah well ;-)
Aug 13 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
MatthiasM wrote:


 Carlos Santander wrote:

 I still get a bus error when pressing Command-Q with rev 5297 (both
 hello and button):


 
 Thanks. This should be fixed now.
 
 I can't get used to the fact that in "D", you can't compare pointers if
 one of them may be null:
 
 class Fl_Window {
    ...
 };
 Fl_Window first_window, this_window;
 if (first_window==this_window) ...
 
 Now if first_window is null, I get a crash that I would not get in C++.
 Ah well ;-)


Heh, well, == is for value comparison (and is implemented (for objects) like
foo.equals(bar)), is for pointers :)

if (foo is null)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Aug 13 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Lars Ivar Igesund wrote:

 
 if (foo is null)
 


Doh! Of course! Stuff like that is the reason to learn "D", but the 
transition time is always painful, I guess.

BTW: I added drawing of all boxtypes and a mostly working single line 
text input widget.

Please folks, keep on testing - and maybe even contribute fixes... .


Thanks,

   Matthias
Aug 14 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
MatthiasM wrote:


 BTW: I added drawing of all boxtypes and a mostly working single line text
input widget.



"boxtype" seems to be working for drawing at least
http://www.algonet.se/~afb/d/boxtype-fltk-mac.png


 Please folks, keep on testing - and maybe even contribute fixes... .


Did you have some kind of bug tracker for d-fltk ?

revision 5313 says:

button Program received signal EXC_BAD_ACCESS, Could not access memory.
======


fl/window.d:378

test/button.d:54

hello Program received signal EXC_BAD_ACCESS, Could not access memory.
=====

Cannot access memory at address 0x0
Cannot access memory at address 0x0

(this= 0x406c00, o= 0x407f80, index=0) at fl/group.d:484

(this= 0x406c00, o= 0x407f80) at fl/group.d:478

_D2fl6widget9Fl_Widget5_ctorFiiiiAaZC2fl6widget9Fl_Widget 
(this= 0x407f80, X=20, Y=40, W=260, H=100, L={length = 13, ptr = 0x3ec34 
"Hello, World!"}) at fl/widget.d:119

_D2fl3box6Fl_Box5_ctorFT2fl12enumerations10Fl_BoxtypeiiiiAaZC2fl3box6Fl_Box 
(this= 0x407f80, b=2 '\002', X=20, Y=40, W=260, H=100, l={length = 13, 
ptr = 0x3ec34 "Hello, World!"}) at fl/box.d:49

test/hello.d:34

Under Mac OS X 10.3

--anders
Aug 15 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
Anders F Björklund escribió:

 MatthiasM wrote:
 

 BTW: I added drawing of all boxtypes and a mostly working single line 
 text input widget.


 
 
 "boxtype" seems to be working for drawing at least
 http://www.algonet.se/~afb/d/boxtype-fltk-mac.png
 

 Please folks, keep on testing - and maybe even contribute fixes... .


 
 Did you have some kind of bug tracker for d-fltk ?
 
 revision 5313 says:
 
 button Program received signal EXC_BAD_ACCESS, Could not access memory.


Try "make clean" before each new "make".

-- 
Carlos Santander Bernal
Aug 15 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Carlos Santander wrote:


 revision 5313 says:

 button Program received signal EXC_BAD_ACCESS, Could not access memory.


 
 Try "make clean" before each new "make".


I did. But "button" still crashes, rev. 5316



fl/window.d:378

test/button.d:54

--anders
Aug 15 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Anders F Björklund wrote:

 Carlos Santander wrote:
 

 revision 5313 says:

 button Program received signal EXC_BAD_ACCESS, Could not access memory.


 Try "make clean" before each new "make".


 
 I did. But "button" still crashes, rev. 5316
 


 fl/window.d:378

 test/button.d:54


Oh, yes, I had that one before. "make clean" did not clean every file. I 
just checked in a better attempt at the Makefile.

make clean; make

should now fix this problem.

Is there something like a "makedepend" for "D"?

   Matthias
Aug 15 2006
next sibling parent reply kris <foo bar.com> writes:
MatthiasM wrote:

 Anders F Björklund wrote:
 

 Carlos Santander wrote:


 revision 5313 says:

 button Program received signal EXC_BAD_ACCESS, Could not access memory.



 Try "make clean" before each new "make".



 I did. But "button" still crashes, rev. 5316



 fl/window.d:378

 test/button.d:54


 
 
 Oh, yes, I had that one before. "make clean" did not clean every file. I 
 just checked in a better attempt at the Makefile.
 
 make clean; make
 
 should now fix this problem.
 
 Is there something like a "makedepend" for "D"?




Yes, Matthias ~ it's called Build, and it effectively adds each import 
to the compilation list. You can find Build on dsource.org
Aug 15 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
kris wrote:


 Is there something like a "makedepend" for "D"?


 
 Yes, Matthias ~ it's called Build, and it effectively adds each import 
 to the compilation list. You can find Build on dsource.org


I can't really get Build to work on the Macintosh.

But maybe that is just me... (and it did compile OK)

--anders
Aug 15 2006
prev sibling parent MatthiasM <dm matthiasm.com> writes:
kris wrote:

 MatthiasM wrote:

 Is there something like a "makedepend" for "D"?


 
 Yes, Matthias ~ it's called Build, and it effectively adds each import 
 to the compilation list. You can find Build on dsource.org


Thanks, Kris. I will try "build" when my code somewhat stabilizes and I 
can better judge what it'll do for me. For now, I stick with "make" 
simply because it is installed on every developer Mac anyways.

Matthias
Aug 15 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
MatthiasM wrote:


 I did. But "button" still crashes, rev. 5316


 
 Oh, yes, I had that one before. "make clean" did not clean every file. I 
 just checked in a better attempt at the Makefile.


I just removed all objects and binaries manually...


 make clean; make
 
 should now fix this problem.


The new Makefile works too, but "rm -rf fl/*.o"
looks strange. What is the -r flag doing there ?

--anders
Aug 15 2006
parent reply MatthiasM <dm matthiasm.com> writes:
Anders F Björklund wrote:


 The new Makefile works too, but "rm -rf fl/*.o"
 looks strange. What is the -r flag doing there ?


Nothing really. It doesn't harm either. It'll be removed in the next commit.
Aug 15 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
MatthiasM wrote:


 Nothing really. It doesn't harm either. It'll be removed in the next 
 commit.


Just paranoia from having a coworker run such a command with spaces. :-)

--anders
Aug 15 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
MatthiasM wrote:


 BTW: I added drawing of all boxtypes and a mostly working single line 
 text input widget.
 
 Please folks, keep on testing - and maybe even contribute fixes... .


This is probably a known problem / FLTK 1.1 shortcoming, but the
dialog boxes don't work with any non-ASCII characters for input.

The fatal exception thrown is a "Error: 4invalid UTF-8 sequence"
(looks like it is stuff the native platform codeset into a char[])

--anders
Aug 16 2006
parent MatthiasM <dm matthiasm.com> writes:
Anders F Björklund wrote:

 MatthiasM wrote:
 

 BTW: I added drawing of all boxtypes and a mostly working single line 
 text input widget.

 Please folks, keep on testing - and maybe even contribute fixes... .


 
 This is probably a known problem / FLTK 1.1 shortcoming, but the
 dialog boxes don't work with any non-ASCII characters for input.
 
 The fatal exception thrown is a "Error: 4invalid UTF-8 sequence"
 (looks like it is stuff the native platform codeset into a char[])


FLTK 1.1 does not speak UTF-8, but uses the machine default code page.

As soon as 1.1 is ported, I will converge 1.1 and 1.2, which has full 
UTF-8 support (and a few other very beautiful additions).

Matthias
Aug 16 2006
prev sibling parent reply MatthiasM <dm matthiasm.com> writes:
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
Aug 24 2006
next sibling parent Marcin Kuszczak <aarti interia.pl> writes:
MatthiasM wrote:


 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)
 


This point is very interesting :-) I am trying to convert some other C++
programs and found myself doing simple translations (e.g. std::string -->
char[], #include -> import, vector<object> -> object[]) very often when in
fact it is automatic, simple work. Also merging .cpp and .h to .d file is
rather boring work, which could be automated.

AFAIK there are few tools (e.g. Language Machine) which are created with
automatic translation of one language to another one, but I found them too
complicated to be effectively used (maybe am I wrong?). 

I would propose here to start writing simple macros in D itself (D has very
good regular expression support) which will do simple translations.
Probably the best way would be to create one program to do one simple
translation, and then start these programs one by one to get final

and you get similar experience as in case of bash scripts - you can just
write on command line ./translate.d and it will start "script". See docs
about scripting on D site.

Of course additional programmer intervention will be necessary anyway after
such a simple conversion ....

-- 
Regards
Marcin Kuszczak
(Aarti_pl)
Aug 25 2006
prev sibling parent reply MatthiasM <dm matthiasm.com> writes:
New commit to the svn.

As somewhat implied in my previous mail, I restarted the port from 
scratch, this time using some scripts to make life easier. It was also a 
great opportunity to put some recommendations from you guys in.

So, within two days I was able to port as much as I did in a week the 
first time around. Good. Windows are displayed, fonts can be loaded, 
rectangles can be drawn, and some mouse clicks are handled. Good enough 
to get a minimal UI up.

There is one other major change now which helps me tremendously: I am 
porting more literally, meaning, I am currently using C style strings. 
No support for D style strings yet. First the port, then the refinements.

Thanks for listening.

  Matthias

PS: I got some nice reactions from the FLTK community as well over the 
weeks. I also managed to clean the entire FLTK1.1.8 bug list. With that 
solid base, there may be some help coming up... .
Sep 01 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
MatthiasM wrote:

 
 New commit to the svn.
 
 As somewhat implied in my previous mail, I restarted the port from 
 scratch, this time using some scripts to make life easier. It was also a 
 great opportunity to put some recommendations from you guys in.
 
 So, within two days I was able to port as much as I did in a week the 
 first time around. Good. Windows are displayed, fonts can be loaded, 
 rectangles can be drawn, and some mouse clicks are handled. Good enough 
 to get a minimal UI up.
 
 There is one other major change now which helps me tremendously: I am 
 porting more literally, meaning, I am currently using C style strings. 
 No support for D style strings yet. First the port, then the refinements.
 
 Thanks for listening.
 
  Matthias
 
 PS: I got some nice reactions from the FLTK community as well over the 
 weeks. I also managed to clean the entire FLTK1.1.8 bug list. With that 
 solid base, there may be some help coming up... .


That's cool! It's good to see developers not enamored with D (yet <g>) provide
some positive 
feedback. I think D and FLTK were in many ways made for each other.
Sep 01 2006
prev sibling parent ns <demo demo.com> writes:
Hello Guys,

Any update on FLTK D port ?

Thanks
ns
Oct 02 2006