View mode: basic / threaded / horizontal-split · Log in · Help
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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
>
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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;
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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 ;)
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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.
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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?
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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.
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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 ;).
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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
July 27, 2006
Re: FLTK native in 'D'. Would that be useful?
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?
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home