Georg Wrede wrote:
> If I had my way, we'd create the minimum library with which
> you can make GUI programs. This library would be just a thin
> layer on top of the native (or in Linux, some of the most
> used GUI alternatives, such as KDE, Gnome) windowing system,
> giving us the native look and feel.
> 

I may be getting a bit carried away here, but I think that a definitive GUI toolkit for D, implemented in D would be a nice sort of litmus test for the same reason that it's neat that D's garbage collector is implemented in D. (let's see Java do that!)

The fact that the current attempts work as well as they do suggests that this isn't at all unreasonable.  It's just a matter of us getting our respective egos in line and working on one toolkit instead of three/six/eight/four hundred. :)

All this really requires is that a single interface be chosen.  Once we can decide on that (*if* we can decide on that), it's pretty much a matter of hacking up dig/windy/whatever and DUI so that they both match that interface.

 -- andy

I need to correct myself here: wxWindows does not support multiple langauges.  I jumped the gun.  It's a GUI that is C++ with hacks for Python and a version of BASIC.

>
>I may be getting a bit carried away here, but I think that a definitive GUI toolkit for D, implemented in D would be a nice sort of litmus test for the same reason that it's neat that D's garbage collector is implemented in D. (let's see Java do that!)

True, that would be nice.

>The fact that the current attempts work as well as they do suggests that this isn't at all unreasonable.  It's just a matter of us getting our respective egos in line and working on one toolkit instead of three/six/eight/four hundred. :)

True.

>All this really requires is that a single interface be chosen.  Once we can decide on that (*if* we can decide on that), it's pretty much a matter of hacking up dig/windy/whatever and DUI so that they both match that interface.

It would be nice to at least model a D GUI library after wxWindows.  It's just so prevalent and familiar to C++ users.  Much of it's popularity is because of an apparent good design and ease of use.  It would be interesting to see what one could do using D features in the making of such a windowing kit.  It would be good practice converting C++ code to D.  On the other hand, I may not have a clue about what I'm talking about.  But I'm very interested to see what's involved in a wxWindows system for D.  The more I read through the wxWindows web site, the more interested I get in it.

Later,

John

In article <bua7ei$2srf$1@digitaldaemon.com>, John Reimer says...
>
>I need to correct myself here: wxWindows does not support multiple langauges.  I jumped the gun.  It's a GUI that is C++ with hacks for Python and a version of BASIC.
>

OK, scratch that.  Now I see there are Lua, Perl, and Javascript versions.  It seems mostly interpreted languages can interface with wxWindows.

>It would be nice to at least model a D GUI library after wxWindows.  It's just so prevalent and familiar to C++ users.  Much of it's popularity is because of an apparent good design and ease of use.  It would be interesting to see what one could do using D features in the making of such a windowing kit.  It would be good practice converting C++ code to D.  On the other hand, I may not have a clue about what I'm talking about.  But I'm very interested to see what's involved in a wxWindows system for D.  The more I read through the wxWindows web site, the more interested I get in it.

I'm going to look into wxWindows and D.  I've been looking over wxWindows a bit and the more I see the more I think it can be done.  When I get a chance I'll download the source and see what kind of hunt/convert things are necessary (automation would be easier, but my knowledge level is inadequate ATM).  Since I'm working literally all weekend, that'll have to be sometime next week to even get a glance.  For now I'll content myself with studying the design/structure to get familiar with it.  Since I'll have to mix it with some real studies, this may be a very slow process (now isn't that an original excuse?). But man it's tempting to see a D version of wxWindows...

At first I was horrified to see major use of C++ macros in the wxWindows design, but I noticed that there are ways around it: specifically using the dynamic event routing feature over the macros-based static event table.  The other nice thing about wxWindows which will ease porting is the use of fairly basic C++ features.  It has avoided the use of templates, C++ exceptions, and C++ RTTI (The templates were avoided because of variances in C compilers)  It should be interesting to see how D can improve it with some features.  Oop, I'm getting carried away with this...I may be over-extending myself...but

Later,

John

PS. There's also a wxGTK+ that encapsulates the GTK+ libraries with wxWindows on Linux. If DUI could do this, an equivalent should be quite possible with D and wxWindows here also.  Once the conversion is done on the windows side, it should be easy to do equivalent changes on the to wxGTK+ following the windows versions D structure.

> It has avoided the use of templates, C++ exceptions, and C++ RTTI
>(The templates were avoided because of variances in C compilers)  It should be interesting to see how D can improve it with some features.  Oop, I'm getting carried away with this...I may be over-extending myself...but
>

I'll be forever correcting myself :-(.  Templates are supported in wxWindows. It's STL that isn't used because of variances across compilers. My apologies!

I wonder if we could port only parts of wxWindows? Or is the code such that the difference in effort is negligible?

Like some parts of everything vs. every part of something?

Or, could we use wxWindows as a binary library? And then make a thin layer on top of it in D?

I checked their screen shots, and it all was very impressive. But I'm no pro at evaluating the needed effort.

Should we decide on a specific version of DMD for the job? I think we should. Even so, the GUI library could be used from newer DMD versions, shouldn't this just be about linking, which I assume will not change?

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, a few controls and some wxEvents/handlers. The rest can be added gradually, I think.  In the wee hours of this morning, I played with a mock-up of a D style wxWindows program to get the feel for it.  I just converted the wxWindows hello world app to D to see what it looked like.  If I can actually implement a small app, it would be a start, and then slow improvement additions from there.

>Like some parts of everything vs. every part of something?

Some parts for now would be better.  Like I said, too much there to cover at once and most of it isn't that critical to a basic funtioning app.

>Or, could we use wxWindows as a binary library? And then make a thin layer on top of it in D?

Binary library? I don't understand. It's a C++ library. D can't interface it unless someone knows some magic for D to C++ interfacing (SWIG anyone?). Fixing the source, I think, will require going through the wxWindows files and trying to convert structures to D style stuff.  What I can gather after looking at some of the source in the cvs tree: removal of lots of C++ macros, use of D version{}, reimplementation of bits and pieces, conversion of events to delegates, etc. (and some snooping in the DUI source to see how some of it is done ;-) Unless there's an easier way I didn't think about...which is quite possible.

>I checked their screen shots, and it all was very impressive. But I'm no pro at evaluating the needed effort.

Heh, I know what you mean... After looking things over, I'm pretty sure this one will be a big effort...

>Should we decide on a specific version of DMD for the job? I think we should. Even so, the GUI library could be used from newer DMD versions, shouldn't this just be about linking, which I assume will not change?
>

Why wait? I'm just going to see what can be done in a basic way for now. D is easily ready for it, I think. I'm just wondering if I am.  Future D versions just have to recompile the library if necessary.  If deprecated language features eventually must be removed/replaced from the library, well that's been done before. No promises.  This will be a little, quiet experiment from my end. I'm just really interested in the possibilites.  It has strong potential for beautiful interfacing on both Windows and Linux (and Mac OS if we ever get a D backend for it).  Did I mention that there's an

Later,

John

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

I used to use wxWindows alot , there are a couple of issues with it I found.

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

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

Keep us updated on progress ?

C


"John Reimer" <John_member@pathlink.com> wrote in message news:bubkbb$29oj$1@digitaldaemon.com...
> 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, a few controls and some wxEvents/handlers. The
rest
> can be added gradually, I think.  In the wee hours of this morning, I
played
> with a mock-up of a D style wxWindows program to get the feel for it.  I
just
> converted the wxWindows hello world app to D to see what it looked like.
If I
> can actually implement a small app, it would be a start, and then slow improvement additions from there.
>
> >Like some parts of everything vs. every part of something?
>
> Some parts for now would be better.  Like I said, too much there to cover
at
> once and most of it isn't that critical to a basic funtioning app.
>
> >Or, could we use wxWindows as a binary library? And then make a thin layer on top of it in D?
>
> Binary library? I don't understand. It's a C++ library. D can't interface
it
> unless someone knows some magic for D to C++ interfacing (SWIG anyone?).
Fixing
> the source, I think, will require going through the wxWindows files and
trying
> to convert structures to D style stuff.  What I can gather after looking
at some
> of the source in the cvs tree: removal of lots of C++ macros, use of D version{}, reimplementation of bits and pieces, conversion of events to delegates, etc. (and some snooping in the DUI source to see how some of it
is
> done ;-) Unless there's an easier way I didn't think about...which is
quite
> possible.
>
> >I checked their screen shots, and it all was very impressive. But I'm no pro at evaluating the needed effort.
>
> Heh, I know what you mean... After looking things over, I'm pretty sure
this one
> will be a big effort...
>
> >Should we decide on a specific version of DMD for the job? I think we should. Even so, the GUI library could be used from newer DMD versions, shouldn't this just be about linking, which I assume will not change?
> >
>
> Why wait? I'm just going to see what can be done in a basic way for now. D
is
> easily ready for it, I think. I'm just wondering if I am.  Future D
versions
> just have to recompile the library if necessary.  If deprecated language features eventually must be removed/replaced from the library, well that's
been
> done before. No promises.  This will be a little, quiet experiment from my
end.
> I'm just really interested in the possibilites.  It has strong potential
for
> beautiful interfacing on both Windows and Linux (and Mac OS if we ever get
a D
> backend for it).  Did I mention that there's an
>
> Later,
>
> John
>
>