In article <bubp32$2h2q$1@digitaldaemon.com>, C says...
>
> So without the ability to  interface
>with C++ , it looks like you'll have to re-write it entirely , twice ( once for win32 , once for GTK).

and once for mac, and once for BeOS, and once....

I thought that was the idea.
I thought that is what Walter suggested.

We are using wxWindows for 2 reasons (as I see it - mainly):
- C++ code can be converted to D (with more or less difficulty)
- it's a proven GUI so we don't get cought in common traps
  if we create a new one.

If we establish a sound API (copied and improved from wxWindows)
Different teams would be reponsable for different system
(probably I wont help on windows for instance).
So each team will have to code for one system only.

Ant

Thats alot of writing :).  Personally I don't like how everything is prefixed with wx , but to each his own.

It would be good if we could take advantage of some existing code.  I tried to look at SWIG but it looks pretty complex.  Has anyone  succfesully used it to convert C++ -> D ?  I think we should see if this is doable , then if it isnt re-write in D , what do you guys think ?

C


"Ant" <Ant_member@pathlink.com> wrote in message news:bubr5o$2kkc$1@digitaldaemon.com...
> In article <bubp32$2h2q$1@digitaldaemon.com>, C says...
> >
> > So without the ability to  interface
> >with C++ , it looks like you'll have to re-write it entirely , twice
 once
> >for win32 , once for GTK).
>
> and once for mac, and once for BeOS, and once....
>
> I thought that was the idea.
> I thought that is what Walter suggested.
>
> We are using wxWindows for 2 reasons (as I see it - mainly):
> - C++ code can be converted to D (with more or less difficulty)
> - it's a proven GUI so we don't get cought in common traps
>   if we create a new one.
>
> If we establish a sound API (copied and improved from wxWindows)
> Different teams would be reponsable for different system
> (probably I wont help on windows for instance).
> So each team will have to code for one system only.
>
> Ant
>
>

In article <bubp32$2h2q$1@digitaldaemon.com>, C says...
..
>I was hoping that wxUniversal which implements all its own widgets ( and looks real good ) was C but no luck.  So without the ability to  interface with C++ , it looks like you'll have to re-write it entirely , twice ( once for win32 , once for GTK).

Appologies for an entirely off-hand, not thought-out question:

With the number of C++ things that we, and D users in the future,
are facing, is there (or will there ever be) any way (even in theory)
to make the interfacing easier?

Ant wrote:

>In article <bubkbb$29oj$1@digitaldaemon.com>, John Reimer says...
>  
>
>>In article <bubh0q$24jo$1@digitaldaemon.com>, Georg Wrede says...
>>    
>>
>>>I wonder if we could port only parts of wxWindows? Or is
>>>the code such that the difference in effort is negligible?
>>>      
>>>
>>Definitely only parts to start with. There's just too many things there to try
>>to integrate completely.  The basic structure should be implementable with
>>wxObject, wxApp, wxFrames,
>>    
>>
>
>can we drop the "wx"? please.
>
>Ant
>
>  
>
Why not do what Burton did with dig/opengl and make it a namespace. Actually, dig supported both forms more-or-less.

Anderson

Ant

>Can we go with an OpenGL toolkit?


I should add that before you brought this up I was seriously considering doing an openGL toolkit for Windy, basing it of dig's openGL but taking it further.  Parhaps forming a group (Yeah right you say! Are there any D groups at all?) to do small parts of the openGL toolkit such as texture loading, scenegraphs, gltext and an openGL gui toolbox -> some of which would simply be converted C libraries. The openGL part of Windy could be separted, to reduce size if it got to large.

However, that was one of the many spare-time-projects I may consider 4 or 5 months from now when I get free time.  And I'm not commiting to anything at the moment ;)

-Anderson

On Sun, 18 Jan 2004 02:52:16 +0800, J Anderson wrote:

> Ant
> 
>>Can we go with an OpenGL toolkit?
> 
> 
> I should add that before you brought this up I was seriously considering doing an openGL toolkit for Windy, basing it of dig's openGL but taking it further.  Parhaps forming a group (Yeah right you say! Are there any D groups at all?)

there are lots of D groups (one element each)

I still didn't give up.
I'll post here 'significative' milestones on this idea.
please do the same.

> to do small parts of the openGL toolkit such as texture loading, scenegraphs, gltext and an openGL gui toolbox -> some of which would simply be converted C libraries. The openGL part of Windy could be separted, to reduce size if it got to large.
> 
> However, that was one of the many spare-time-projects I may consider 4 or 5 months from now when I get free time.  And I'm not commiting to anything at the moment ;)

In 4/5 months we should have the API for the main D GUI toolkit (positive thinking - in reality this all project will be forgotten in 1 week :( ) so maybe it's a better idea to use the API from that. That will mean we will have another implementations of the D GUI that is good for "new systems" not dependent on a "battery charge"...

Ant

>
>can we drop the "wx"? please.
>
>Ant
>

I suppose, if no body wants them... That kind of loses the feel of wxWindows, though.  It looks then that people want a library "based" on wxWindows and not one that is a near duplicate.  That's fine.

In article <bubr5o$2kkc$1@digitaldaemon.com>, Ant says...
>
>In article <bubp32$2h2q$1@digitaldaemon.com>, C says...
>>
>> So without the ability to  interface
>>with C++ , it looks like you'll have to re-write it entirely , twice ( once for win32 , once for GTK).
>
>and once for mac, and once for BeOS, and once....
>
>I thought that was the idea.
>I thought that is what Walter suggested.

Yes, I thought I implied the need for rewrites.

>We are using wxWindows for 2 reasons (as I see it - mainly):
>- C++ code can be converted to D (with more or less difficulty)
>- it's a proven GUI so we don't get cought in common traps
>  if we create a new one.

We are basically taking advantage of the fact that the design is all thought out and that the appropriate win32 or gtk+ code, which lies within the wxWindows classes, can be used directly.  Conversion is a matter of converting C++ classes layer and layer to D.  This is a big enough task as it is.

>If we establish a sound API (copied and improved from wxWindows)
>Different teams would be reponsable for different system
>(probably I wont help on windows for instance).
>So each team will have to code for one system only.
>
>Ant
>

Your experience would be prime for the gtk+ version, I think :).

>Its only truly cross-platform if you stay with in the wx framework , which
>explains why its so huge , and even then there is some problems with spacing
>correctly on each platform ( wxSizer is just an abstraction  layer for
>some ) , resource scripts , icons and so on ( although in my experience it
>didnt take much to fix it ).

I understand this.  Code can be kept cross-platform, I am sure, by maintaining a careful style and isolating platform specific code.  Parinya, one of the fellows that visits this group, seems to have been successful in a fairly painless port of his MingW Studio from Windows to Linux (using wxWindows).  His project appears to be a fairly non-trivial one.  It seems wxWindows hugely eases the pain for such porting.

Concerning the sizer problems, I read about them.  But there seem to be well-documented ways of dealing with that problem.  So all seems surmountable.

>Somebody mention this a while back  , but wxHaskell
> http://wxhaskell.sourceforge.net/ ) has a wxC interface , but after looking
>it over it seems to only be C prototypes , and the definition of the functions in haskell ( I really dont know though I dont use Haskell , it would  be good if someone with knowledge of C/Haskell integration could confirm ) ?  It also looks like C++ , not C.

I haven't looked at this. Anything that could ease the task are of interest to me.

>I was hoping that wxUniversal which implements all its own widgets ( and looks real good ) was C but no luck.  So without the ability to  interface with C++ , it looks like you'll have to re-write it entirely , twice ( once for win32 , once for GTK).

Yes. Entirely is a ill-defined term. Once success is made on one platform, it may be easier to port to another.  The Gtk+ and win32 layers should be pretty much the same in D as C++.

>Keep us updated on progress ?
>
>C

Sure, once in awhile maybe. But it may be awhile until I have anything that works. Or it may not... :)

Got another idea.

If we have an established, proven interface for an interpreted language where wxWindows works excellently, then:

All we have to do is to have our D-GUI thin layer send commands to the interpreted language!

So, for example, if there's a Python interface to wxWindows, we just attach D to the Python interpreter. Then we can have a D API that receives window wishes, and then sends them to the Python interpreter, so it can then use the windowing thing.

This, of course would not be a quick-and-dirty solution.
It would more likely be called a now-and-filty solution.
But I think it gets the thing done!

Since, for the time being, D is an Intel-only language,
it follows that we probably do have the horse power available
for this kind of "multiply indirect" solution.

This would buy us time to slowly, and in peace, develop the Proper Solution? It also would let us take the necessary time to carefully study the D GUI spec for the standard.