"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

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

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

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!

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

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

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

On Sun, 30 Jul 2006 08:57:51 -0700, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:


>>>    import gui.fl.window;
>>   Using dmd 0.163, try this:
>>  # // 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.
>


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

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

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