View mode: basic / threaded / horizontal-split · Log in · Help
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
"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
July 29, 2006
Andrew -- please start a different thread
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
July 29, 2006
Re: Andrew -- please start a different thread
"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?
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
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!
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
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
July 29, 2006
Re: FLTK native in 'D'. Would that be useful?
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
July 30, 2006
Re: FLTK native in 'D'. Would that be useful?
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
July 30, 2006
Re: FLTK native in 'D'. Would that be useful?
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
August 06, 2006
Re: FLTK native in 'D'. Would that be useful?
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
August 06, 2006
Re: FLTK native in 'D'. Would that be useful?
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
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home