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/
 
 

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/


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 would be DWT (based on SWT / Java) and wxD (based on wxWidgets / C#). We also have MinWin and FOX, but neither is available for Macintosh... (unless you count running under X11, which is a bit of a cheat really) So if FLTK was available to D (native or wrapped), that would be great!
 FLTK is a Fast and Light user interface Tool Kit. It sets directly onto the low
 lever interfaces of the three 
 main supported platforms (MSWindows:WIN32, Unix including Linux: X11, Mac OS X:
 Carbon/Quartz). 

Does this port require that the Windows and Carbon headers are completed first ? If so, we could have a slight bit of a problem there already... FLTK itself (in C++) works good enough on Win/Mac, just wonder how easy it will be to port those sections over to D. Was that part of your test? There is some movement on translating the Win32 headers, but I don't think the CarbonHeaders project (on Dsource) is making much progress. I tried it earlier, but in the end just gave up and used C++ instead... --anders
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:
 ...

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=


 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=

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

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

 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=

    gui/fl/window.d

 and using

    import gui.fl.window;

Using dmd 0.163, try this: # // import all symbols in gui.fl.window module into the 'fl' namespace # # import fl =3D gui.fl.window; # # void main() # { # ... # auto win1 =3D new fl.Window( ); # ... # } 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): # import gui.fl.window; # // rename the module namespace # alias gui.fl.window fl; # # void main() # { # ... # auto win1 =3D new fl.Window(); # ... # } 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()

# // import all symbols in gui.fl.window module into the 'fl' namespace # # import fl = gui.fl.window;

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



 #
 # import fl =3D gui.fl.window;

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: # // import all symbols in gui.fl.window module into the 'fl' namespace # # import fl = gui.fl.window; # # void main() # { # ... # auto win1 = new fl.Window( ); # ... # } 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): # import gui.fl.window; # // rename the module namespace # alias gui.fl.window fl; # # void main() # { # ... # auto win1 = new fl.Window(); # ... # } 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 language with a namespace naming system like C++ (or C#) to D's 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;

# // import all symbols in gui.fl.window module into the 'fl' namesp=


 #
 # import fl =3D gui.fl.window;
 #
 # void main()
 # {
 #     ...
 #     auto win1 =3D new fl.Window( );
 #     ...
 # }
   Using GDC 0.19 (equivalent to 0.162), I think you can do this for n=


 (next version should support the new import features, though):
   # import gui.fl.window;
 # // rename the module namespace
 # alias gui.fl.window fl;
 #
 # void main()
 # {
 #     ...
 #     auto win1 =3D new fl.Window();
 #     ...
 # }
  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=

 language with a namespace naming system like C++ (or C#) to D's
 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=

 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 


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

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

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

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 #0 0x00003ec0 in _Dmain (args={length = 1, ptr = 0x303710}) at test/button.d:53 #1 0x0002c368 in _d_run_main2goFZv () #2 0x0002c42c in _d_run_main () #3 0x000024a4 in _start (argc=1, argv=0xbffff9a0, envp=0xbffff9a8) at /SourceCache/Csu/Csu-58.1.1/crt.c:272 #4 0x0000234c in start () (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 #0 0xffff8824 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:189 #1 0x00026bd8 in _adDup (a={length = 2, ptr = 0x0}, szelem=4218832) at ../../../gcc-4.0.3/libphobos/internal/adi.d:576 #2 0x000104a0 in _D2fl6widget9Fl_Widget10copy_labelFAaZv (this= 0x407f80, a={length = 2, ptr = 0x0}) at fl/widget.d:356 #3 0x00002600 in _Dmain (args={length = 1, ptr = 0x303610}) at test/hello.d:37 #4 0x00028a28 in _d_run_main2goFZv () at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83 #5 0x00028afc in _d_run_main (argc=4218832, argv=0x0, main_func=0x2) at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93 #6 0x00001e7c in _start (argc=1, argv=0xbffffb70, envp=0xbffffb78) at /SourceCache/Csu/Csu-58/crt.c:272 #7 0x00001d24 in start () -- 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 #0 0x0001b774 in _D2fl3mac21QuitAppleEventHandlerFPvPviZi (appleEvt=0xbfffead0, reply=0xbfffeae0, refcon=0) at fl/mac.d:1309 #1 0x914f9960 in aeDispatchAppleEvent () #2 0x91504fc0 in sendToSelf () #3 0x914fd8f8 in AESendMessage () #4 0x914fd3d4 in aeSend () #5 0x9329938c in AESend () #6 0x9334fcc4 in SendCoreAEToSelf () #7 0x932b5bf0 in HandleCommandEvent () #8 0x931e72b4 in HIApplication::EventHandler () #9 0x931ea554 in DispatchEventToHandlers () #10 0x931e9cac in SendEventToEventTargetInternal () #11 0x932298f8 in CallNextEventHandler () #12 0x0001b2a8 in _D2fl3mac21carbonDispatchHandlerFPvPvPvZi (nextHandler=0xbffff010, event=0x309730, userData=0x0) at fl/mac.d:1113 #13 0x931ea554 in DispatchEventToHandlers () #14 0x931e9cac in SendEventToEventTargetInternal () #15 0x931f0a60 in SendEventToEventTarget () #16 0x932692cc in SendHICommandEvent () #17 0x93299158 in SendMenuItemSelectedEvent () #18 0x932b49d0 in HandleKeyboardEvent () #19 0x931ea554 in DispatchEventToHandlers () #20 0x931e9cac in SendEventToEventTargetInternal () #21 0x931e9b28 in SendEventToEventTargetWithOptions () #22 0x932b3ce0 in HandleKeyboardEvent () #23 0x931f0ddc in ToolboxEventDispatcherHandler () #24 0x931ea7a4 in DispatchEventToHandlers () #25 0x931e9cac in SendEventToEventTargetInternal () #26 0x932298f8 in CallNextEventHandler () #27 0x0001b2a8 in _D2fl3mac21carbonDispatchHandlerFPvPvPvZi (nextHandler=0xbffff7e0, event=0x30a660, userData=0x0) at fl/mac.d:1113 #28 0x931ea554 in DispatchEventToHandlers () #29 0x931e9cac in SendEventToEventTargetInternal () #30 0x931f0a60 in SendEventToEventTarget () #31 0x0001b534 in _D2fl3mac16do_queued_eventsFdZd (time=1e+20) at fl/mac.d:1259 #32 0x0001b6b8 in _D2fl3mac7fl_waitFdZi (time=1e+20) at fl/mac.d:1294 #33 0x00002740 in _D2fl2fl2Fl4waitFdZd (time_to_wait=1e+20) at fl/fl.d:141 #34 0x000027dc in _D2fl2fl2Fl3runFZi () at fl/fl.d:197 #35 0x00002650 in _Dmain (args={length = 1, ptr = 0x303610}) at test/hello.d:40 #36 0x00028a28 in _d_run_main2goFZv () at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83 #37 0x00028afc in _d_run_main (argc=1, argv=0x0, main_func=0x1800000) at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93 #38 0x00001e7c in _start (argc=1, argv=0xbffffb68, envp=0xbffffb70) at /SourceCache/Csu/Csu-58/crt.c:272 #39 0x00001d24 in start () -- 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 #0 0x00023e1c in _D2fl3mac21QuitAppleEventHandlerFPvPviZi (appleEvt=0xbfffead0, reply=0xbfffeae0, refcon=0) at fl/mac.d:1295 #1 0x914f9960 in aeDispatchAppleEvent () #2 0x91504fc0 in sendToSelf () #3 0x914fd8f8 in AESendMessage () #4 0x914fd3d4 in aeSend () #5 0x9329938c in AESend () #6 0x9334fcc4 in SendCoreAEToSelf () #7 0x932b5bf0 in HandleCommandEvent () #8 0x931e72b4 in HIApplication::EventHandler () #9 0x931ea554 in DispatchEventToHandlers () #10 0x931e9cac in SendEventToEventTargetInternal () #11 0x932298f8 in CallNextEventHandler () #12 0x0002389c in _D2fl3mac21carbonDispatchHandlerFPvPvPvZi (nextHandler=0xbffff010, event=0x409490, userData=0x0) at fl/mac.d:1100 #13 0x931ea554 in DispatchEventToHandlers () #14 0x931e9cac in SendEventToEventTargetInternal () #15 0x931f0a60 in SendEventToEventTarget () #16 0x932692cc in SendHICommandEvent () #17 0x93299158 in SendMenuItemSelectedEvent () #18 0x932b49d0 in HandleKeyboardEvent () #19 0x931ea554 in DispatchEventToHandlers () #20 0x931e9cac in SendEventToEventTargetInternal () #21 0x931e9b28 in SendEventToEventTargetWithOptions () #22 0x932b3ce0 in HandleKeyboardEvent () #23 0x931f0ddc in ToolboxEventDispatcherHandler () #24 0x931ea7a4 in DispatchEventToHandlers () #25 0x931e9cac in SendEventToEventTargetInternal () #26 0x932298f8 in CallNextEventHandler () #27 0x0002389c in _D2fl3mac21carbonDispatchHandlerFPvPvPvZi (nextHandler=0xbffff7e0, event=0x425ff0, userData=0x0) at fl/mac.d:1100 #28 0x931ea554 in DispatchEventToHandlers () #29 0x931e9cac in SendEventToEventTargetInternal () #30 0x931f0a60 in SendEventToEventTarget () #31 0x00023bdc in _D2fl3mac16do_queued_eventsFdZd (time=1e+20) at fl/mac.d:1245 #32 0x00023d60 in _D2fl3mac7fl_waitFdZi (time=1e+20) at fl/mac.d:1280 #33 0x00002960 in _D2fl2fl2Fl4waitFdZd (time_to_wait=1e+20) at fl/fl.d:167 #34 0x000029fc in _D2fl2fl2Fl3runFZi () at fl/fl.d:223 #35 0x0000275c in _Dmain (args={length = 1, ptr = 0x403610}) at test/button.d:55 #36 0x00031fac in _d_run_main2goFZv () at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:83 #37 0x00032080 in _d_run_main (argc=1, argv=0x0, main_func=0x1800000) at ../../../gcc-4.0.3/libphobos/internal/dgccmain2.d:93 #38 0x00001e9c in _start (argc=1, argv=0xbffffb68, envp=0xbffffb70) at /SourceCache/Csu/Csu-58/crt.c:272 #39 0x00001d44 in start () -- 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. ====== #0 0x00028928 in _D9invariant12_d_invariantFC6ObjectZv () #1 0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this= 0x1) at fl/window.d:378 #2 0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at test/button.d:54 hello Program received signal EXC_BAD_ACCESS, Could not access memory. ===== #0 0x00000000 in ?? () Cannot access memory at address 0x0 Cannot access memory at address 0x0 #1 0x0001c09c in _D2fl5group8Fl_Group6insertFC2fl6widget9Fl_WidgetiZv (this= 0x406c00, o= 0x407f80, index=0) at fl/group.d:484 #2 0x0001bfec in _D2fl5group8Fl_Group3addFC2fl6widget9Fl_WidgetZv (this= 0x406c00, o= 0x407f80) at fl/group.d:478 #3 0x00011dcc in _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 #4 0x00007670 in _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 #5 0x00002920 in _Dmain (args={length = 1, ptr = 0x301160}) at 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 #0 0x00028928 in _D9invariant12_d_invariantFC6ObjectZv () #1 0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this= 0x1) at fl/window.d:378 #2 0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at 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 #0 0x00028928 in _D9invariant12_d_invariantFC6ObjectZv () #1 0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this= 0x1) at fl/window.d:378 #2 0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at 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 #0 0x00028928 in _D9invariant12_d_invariantFC6ObjectZv () #1 0x000177c4 in _D2fl6window9Fl_Window9iconlabelFZAa (this= 0x1) at fl/window.d:378 #2 0x0000297c in _Dmain (args={length = 1, ptr = 0x301160}) at 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 translation. Additionally you can use #!dmd -run in first line of programs 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