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

Dave wrote:
> 
> Make sense?

Yes, absolutely! Another issue solved ;-)

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

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


Sounds great, Matthias. I understand. :)

-JJR

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

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.

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

"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

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?

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