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
> 

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;

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

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.

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?

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.

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

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

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

MatthiasM wrote:
> Dave wrote:
>> I just happened to notice that there are no private class members in window.d (for example) and looking at the original window.h there probably should be.
>
> Ouch, I did not know that. Evil little details. Yes, we assume that the first members without a modifier are private.
>
> I did find two or three "friend" declarations in the source. Is there some equivalent in "D" or a good way to replace it?

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

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

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

For example:

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

import gui.fl.widget;

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

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

import gui.fl.window;

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

Make sense?