www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - moving wxd to github

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
As part of a necessary rewrite to better support wxWidgets 3.0 and D2,
the wxD development is moving from SourceForge (cvs) to GitHub (git).
As an interim step the existing source repository has been converted,
the details at: http://sourceforge.net/scm/?type=git&group_id=133831

Besides updating the API, that currently follows wxWidgets 2.6 (ouch)
even if you can link it with 2.8 and 2.9 as well if needed by system,
if will change the current "struct" method of passing arrays to C++
into some kind of dual "size_t" and "void*" method as required by DMD.


I am also stepping down as a maintainer, including the pre-built GDC
distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D.

Hopefully the new wxD project will have better luck of accomplishing a
open-source cross-platform GUI and IDE for the D programming language ?

--anders

http://wxd.sourceforge.net/
http://www.codeblocks.org/

http://www.digitalmars.com/d/archives/digitalmars/D/wxD_GUI_and_Code_Blocks_IDE_46121.html
Aug 26 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 26.08.2011, 10:10 Uhr, schrieb Anders F Bj=C3=B6rklund <afb algonet.s=
e>:


 I am also stepping down as a maintainer, including the pre-built GDC
 distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D=


.

 Hopefully the new wxD project will have better luck of accomplishing a=



 open-source cross-platform GUI and IDE for the D programming language =


?

 --anders


That are some good projects you were working on. We've got the precompil=
ed  =

DMD, Eclipse DDT and GtkD, but I would have tried wxWidgets in  =

Code::Blocks with D. And while building GDC from source is possible, the=
  =

Windows folks probably preferred a binary (and some Mac and Linux users,=
  =

too). I hope someone steps in and this is not another wave of dying  =

projects.

- Marco
Aug 26 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Marco Leise wrote:

 I am also stepping down as a maintainer, including the pre-built GDC
 distribution (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D.

 Hopefully the new wxD project will have better luck of accomplishing a
 open-source cross-platform GUI and IDE for the D programming language ?





 That are some good projects you were working on. We've got the
 precompiled DMD, Eclipse DDT and GtkD, but I would have tried wxWidgets
 in Code::Blocks with D. And while building GDC from source is possible,
 the Windows folks probably preferred a binary (and some Mac and Linux
 users, too). I hope someone steps in and this is not another wave of
 dying projects.


Would have ? Well, you can still use the existing stuff* for D(1).
It was mostly that focus has shifted to D2, since four years ago...
I updated most of it for better 64-bit support last year, and there
was a new Code::Blocks 10.05 but that was about it for development.

* http://www.codeblocks.org/downloads/26
   http://sourceforge.net/projects/gdcwin/files/gdc/r229/
   http://sourceforge.net/projects/gdcgnu/files/gdc/r229/
   http://sourceforge.net/projects/gdcmac/files/gdc/r229/

I guess you can also use QtD and Qt Creator, if you want something D2 ?

--anders
Aug 26 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 26.08.2011, 13:47 Uhr, schrieb Anders F Bj=C3=B6rklund <afb algonet.s=
e>:


 Marco Leise wrote:


 That are some good projects you were working on. We've got the
 precompiled DMD, Eclipse DDT and GtkD, but I would have tried wxWidge=




ts

 in Code::Blocks with D. And while building GDC from source is possibl=




e,

 the Windows folks probably preferred a binary (and some Mac and Linux=





 users, too). I hope someone steps in and this is not another wave of
 dying projects.


 Would have ? Well, you can still use the existing stuff* for D(1).
 It was mostly that focus has shifted to D2, since four years ago...
 I updated most of it for better 64-bit support last year, and there
 was a new Code::Blocks 10.05 but that was about it for development.

 * http://www.codeblocks.org/downloads/26
    http://sourceforge.net/projects/gdcwin/files/gdc/r229/
    http://sourceforge.net/projects/gdcgnu/files/gdc/r229/
    http://sourceforge.net/projects/gdcmac/files/gdc/r229/

 I guess you can also use QtD and Qt Creator, if you want something D2 =


?

 --anders


When I started D2 was already advertised as the way to go so I restricte=
d  =

myself to projects that work with D2.
(Btw. I do have that Code::Blocks version and wrote a little c++ editor =
 =

plug-in for private use.)
Aug 26 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Marco Leise wrote:

 Would have ? Well, you can still use the existing stuff* for D(1).
 It was mostly that focus has shifted to D2, since four years ago...
 I updated most of it for better 64-bit support last year, and there
 was a new Code::Blocks 10.05 but that was about it for development.





 When I started D2 was already advertised as the way to go so I
 restricted myself to projects that work with D2.


It does work with D2 (well, except for DMD 64-bit that is).

I think the restriction was "the GUI must be written in",
and it isn't - but in C++ and in D. And of course the IDE
doesn't have real D support, only when it looks like C++ ?


Anyway, the whole idea of moving it to github.com was so
that development could continue. We'll see how that goes.

The upstream project, wx.NET, has also been going through
some changes. And wxWidgets 3.0 hasn't been released yet.

--anders
Aug 26 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Do you mean you're stepping down as the maintainer of wxd, or just the
GDC/CodeBlocks stuff?

wxWidgets look very interesting to me, lots of documentation available
from what I can tell. Plus it seems it's easy to grab a device context
out of a wxWidget frame, so I could use Cairo with that (e.g.
http://code.google.com/p/wxcairo/wiki/IntegratingWithCairo).

I think I'll give wxd a try these days.

Btw, what is up with the excessive blank lines in the example source
files? After every statement there is a blank line, it almost seems
like a result of some indenter script that screwed things up. This is
easily fixable for my own needs, of course. :)
Aug 26 2011
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrej Mitrovic wrote:

 Do you mean you're stepping down as the maintainer of wxd, or just the
 GDC/CodeBlocks stuff?


All three. Mostly wxD, but also the others - not using.
I'll leave it up as-is, but won't be adding D2 features.

--anders
Aug 26 2011
parent reply Gour <gour atmarama.net> writes:
On Fri, 26 Aug 2011 19:30:57 +0200
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:

Hello Anders,


 All three. Mostly wxD, but also the others - not using.
 I'll leave it up as-is, but won't be adding D2 features.


Sorry to found out (when we're reconsidering D) that you go/went away.
:-(


It looks that gtkD is in the best shape from all D-related projects with
GUI bindings, but, otoh, it could be that wx-2.9/3.0 is providing the
best native experience on non-Linux OS-es. (We would develop on Linux,
but need good appearance of our desktop app both on Mac OS X & Windows.)

Have you lost interest in working on wxD due to using some other GUI
toolkit or no interest in GUI bindings in general?


Sincerely,
Gour


--=20
The embodied soul may be restricted from sense enjoyment,=20
though the taste for sense objects remains. But, ceasing=20
such engagements by experiencing a higher taste,=20
he is fixed in consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 21 2011
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 All three. Mostly wxD, but also the others - not using.
 I'll leave it up as-is, but won't be adding D2 features.


 Sorry to found out (when we're reconsidering D) that you go/went away.
 :-(


Not sure if I was ever "on" D2, but left all the D1 stuff up.
Including the GDC binaries, wxWidgets and Code::Blocks with D.


 Have you lost interest in working on wxD due to using some other GUI
 toolkit or no interest in GUI bindings in general?


No interest in general, the project is looking for a maintainer.
Last time I heard, the QtD binding was the most popular one ?

--anders
Nov 21 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
*correction: It's not just the samples, it's the library code too. I
don't understand, why the blank lines?
Aug 26 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I can see the problem now. The code uses CR followed by CRLF on every
line. This was probably some kind of unix -> windows EOL conversion
bug. Either CRLF or CR's should be killed (personally I'm ok with unix
endlines).
Aug 26 2011
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrej Mitrovic wrote:

 I can see the problem now. The code uses CR followed by CRLF on every
 line. This was probably some kind of unix ->  windows EOL conversion
 bug. Either CRLF or CR's should be killed (personally I'm ok with unix
 endlines).


The code uses CRLF, must be some kind of bug with your
git setup - looks "OK" from here (with the ^M that is).

--anders
Aug 26 2011
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 I can see the problem now. The code uses CR followed by CRLF on every
 line. This was probably some kind of unix -> windows EOL conversion
 bug. Either CRLF or CR's should be killed (personally I'm ok with unix
 endlines).


 The code uses CRLF, must be some kind of bug with your
 git setup - looks "OK" from here (with the ^M that is).


Apparently you set core.autocrlf=false in your git config,
(instead of "auto") to avoid it trying to convert things ?

--anders
Aug 26 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/26/11, Anders F Bj=F6rklund <afb algonet.se> wrote:

 The code uses CRLF, must be some kind of bug with your
 git setup - looks "OK" from here (with the ^M that is).


Sorry I've downloaded the tarball, not the git repo. The git repo
doesn't have these problems, thanks.
Aug 26 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
s/tarball/zip file

The zipped source has the duplicate newlines, but that probably
doesn't show up based on what editor you use. But anyway, the git
version works fine.
Aug 26 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
When I try to build via DMC's make I get:

D:\dev\projects\wxd>make
cd wxc
make
Error on line 181: can't read makefile '/build/msw/config.dmc'

I don't see a build folder anywhere. Are these build instructions
outdated on http://wxd.sourceforge.net/#installation ?
Aug 26 2011
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrej Mitrovic wrote:

 When I try to build via DMC's make I get:

 D:\dev\projects\wxd>make
 cd wxc
 make
 Error on line 181: can't read makefile '/build/msw/config.dmc'

 I don't see a build folder anywhere. Are these build instructions
 outdated on http://wxd.sourceforge.net/#installation ?


If you build with DM make, you need to set $WXDIR env variable.
It should say so, on that page. "set WXDIR=C:\wxWidgets-2.8.10"

Normally tested with GNU make though, and should be 2.8.12 now.

--anders
Aug 26 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well that kinda works now, thanks.

I've tried building the Controls sample. I've had to make some
modifications due to missing toString symbols and missing default
switches. After that I've unfortunately hit this:

http://www.digitalmars.com/ctg/optlink.html
C:\wxMSW-2.8.12\lib\dmc_lib\wxexpatd.lib(xmlparse)
 Error 168: >64K Global Types

Damn optlink..

I've re-built wxWidgets via GNU Make, then tried to build wxd with GNU
Make but failed:

D:\dev\projects\wxd>mingw32-make -f makefile.gcc
mingw32-make -C wxc -f makefile.gcc WX_RELEASE
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
process_begin: CreateProcess(NULL, wx-config --cxxflags, ...) failed.
mingw32-make[1]: Entering directory `D:/dev/projects/wxd/wxc'
g++ -D__GDC__   -O2 -Wall -c -o wx-release.o wx-release.cpp
wx-release.cpp:6:21: fatal error: wx/defs.h: No such file or directory
compilation terminated.
mingw32-make[1]: *** [wx-release.o] Error 1
mingw32-make[1]: Leaving directory `D:/dev/projects/wxd/wxc'
mingw32-make: *** [wxc/WX_RELEASE] Error 2

My WXDIR is set up properly:
D:\dev\projects\wxd>echo %WXDIR%
C:\wxMSW-2.8.12
Aug 30 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
FWIW the samples compile fine with the latest changesets, using dmd
make. Thanks for your work, Anders!
Nov 09 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Btw, it would be great if you could move the repo to Github when you
have the free time to do it. The samples need a few updates to work
with D2, and I'd like to make a pull for that. I don't really know my
way around sforge. :)
Nov 10 2011
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
On 2011-11-10 18.27, Andrej Mitrovic wrote:

 Btw, it would be great if you could move the repo to Github when you
 have the free time to do it. The samples need a few updates to work
 with D2, and I'd like to make a pull for that. I don't really know my
 way around sforge. :)


Missed a button, it's now at https://github.com/afb/wxd
in addition to the usual http://wxd.git.sourceforge.net/

--anders
Nov 21 2011
next sibling parent Gour <gour atmarama.net> writes:
On Mon, 21 Nov 2011 23:13:21 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 Missed a button, it's now at https://github.com/afb/wxd


Thanks a lot. Hopefully it will get some followers since we hope D
community is not like in Haskell: there are hundreds of Monad tutorials,
plenty of libraries on Hackage, but hardly one nicely maintained GUI
bindings project.


Sincerely,
Gour


--=20
As the embodied soul continuously passes, in this body,=20
from boyhood to youth to old age, the soul similarly passes=20
into another body at death. A sober person is not bewildered=20
by such a change.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 22 2011
prev sibling parent reply dolive <dolive89 sina.com> writes:
Anders F Björklund Wrote:


 On 2011-11-10 18.27, Andrej Mitrovic wrote:

 Btw, it would be great if you could move the repo to Github when you
 have the free time to do it. The samples need a few updates to work
 with D2, and I'd like to make a pull for that. I don't really know my
 way around sforge. :)


 
 Missed a button, it's now at https://github.com/afb/wxd
 in addition to the usual http://wxd.git.sourceforge.net/
 
 --anders



please let wxd can be able to  compile at the latest dmd2 for windows, but
currently only compiled on dmd1.064 for windows . please !

thank you very much !!!
Nov 22 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It compiles fine on DMD 2.056, but you need to compile wxWidgets via
DMD make first. It's described on wxd's website.

On 11/22/11, dolive <dolive89 sina.com> wrote:

 Anders F Bj=F6rklund Wrote:


 On 2011-11-10 18.27, Andrej Mitrovic wrote:

 Btw, it would be great if you could move the repo to Github when you
 have the free time to do it. The samples need a few updates to work
 with D2, and I'd like to make a pull for that. I don't really know my
 way around sforge. :)


 Missed a button, it's now at https://github.com/afb/wxd
 in addition to the usual http://wxd.git.sourceforge.net/

 --anders



 please let wxd can be able to  compile at the latest dmd2 for windows, bu=


t

 currently only compiled on dmd1.064 for windows . please !

 thank you very much !!!
Nov 22 2011
parent reply Sam Hu <samhudotsamhu gmail.com> writes:
Andrej Mitrovic Wrote:


 It compiles fine on DMD 2.056, but you need to compile wxWidgets via
 DMD make first. It's described on wxd's website.
 
 On 11/22/11, dolive <dolive89 sina.com> wrote:

 Anders F Björklund Wrote:


 On 2011-11-10 18.27, Andrej Mitrovic wrote:

 Btw, it would be great if you could move the repo to Github when you
 have the free time to do it. The samples need a few updates to work
 with D2, and I'd like to make a pull for that. I don't really know my
 way around sforge. :)


 Missed a button, it's now at https://github.com/afb/wxd
 in addition to the usual http://wxd.git.sourceforge.net/

 --anders



 please let wxd can be able to  compile at the latest dmd2 for windows, but
 currently only compiled on dmd1.064 for windows . please !

 thank you very much !!!




May I ask which version of wxWidget,2.8.12 or 2.9.?  ?Thanks.
Nov 22 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/23/11, Sam Hu <samhudotsamhu gmail.com> wrote:

 May I ask which version of wxWidget,2.8.12 or 2.9.?  ?Thanks.


For windows, it's:
http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.6.4.zip

Find this string: "1. wxWidgets" here: http://wxd.sourceforge.net/
and follow the instructions for step 1 (DM), or if you're on Linux
then I guess GCC. Compiling takes a while..

Then get the repo from github and run 'make' in the wxd directory.
After a while, you can browse to 'samples' and run 'make'.

The samples were recently updated to work with both D1 and D2.
Nov 22 2011
parent reply Sam Hu <samhudotsamhu gmail.com> writes:
Andrej Mitrovic Wrote:


 On 11/23/11, Sam Hu <samhudotsamhu gmail.com> wrote:

 May I ask which version of wxWidget,2.8.12 or 2.9.?  ?Thanks.


 
 For windows, it's:
 http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.6.4.zip
 
 Find this string: "1. wxWidgets" here: http://wxd.sourceforge.net/
 and follow the instructions for step 1 (DM), or if you're on Linux
 then I guess GCC. Compiling takes a while..
 
 Then get the repo from github and run 'make' in the wxd directory.
 After a while, you can browse to 'samples' and run 'make'.
 
 The samples were recently updated to work with both D1 and D2.


Thank you so much for the prompt response!Just wondering is there any special
reason that wx2.8.* or wx2.9.* could not be supported?
Nov 22 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
You'll have to ask Anders that.

I'm guessing what needs to be done is to update the wxc wrapper, and


I've heard something about wx3.0 being in plans, if it's a significant
change from the 2.x series then maybe it would be a good idea to wait
for that release before attempting to update the wrappers.
Nov 23 2011
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrej Mitrovic wrote:

 I'm guessing what needs to be done is to update the wxc wrapper, and



There were two main tracks to generating the wrappers, one was
using a patched SWIG and the other was a custom Perl script...

http://wxnet.cvs.sourceforge.net/viewvc/wxnet/wx.NET/Src/SWIG/
http://wxnet.cvs.sourceforge.net/viewvc/wxnet/wx.NET/Src/wx-c-gen/


the generated C libraries are _not_ identical between the two
(even if they then use the same wx C++ libraries to link with)
There's also some language differences for the native libs API.

Now that DMD has broken the ABI on x86_64, the string handling
needs to be redone (to use wxStringCharType* and size_t pairs?)
The Unicode handling is also done differently in wxWidgets 3.0:
http://docs.wxwidgets.org/trunk/overview_string.html (wxString)


 I've heard something about wx3.0 being in plans, if it's a significant
 change from the 2.x series then maybe it would be a good idea to wait
 for that release before attempting to update the wrappers.


One might also drop the D and Tango support, and go D2 only ?

--anders
Nov 24 2011
next sibling parent Gour <gour atmarama.net> writes:
On Thu, 24 Nov 2011 13:15:49 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 One might also drop the D and Tango support, and go D2 only ?


+1

and do wx-3.0 only.


Sincerely,
Gour


--=20
Those who are on this path are resolute in purpose,=20
and their aim is one. O beloved child of the Kurus,=20
the intelligence of those who are irresolute is many-branched.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 24 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/24/2011 4:15 AM, Anders F Björklund wrote:

 Now that DMD has broken the ABI on x86_64,


??
Nov 24 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well the cool thing is I can use wxGlide to generate C++ code, and
convert that to D. I tried it just now and it seems to work, but
converting everything by hand is a bit of a chore.

The biggest problem by far are the enums, since wxWidgets enums don't
have a "tag" while the wxd enums do. This might be fixable via some
quick shell scripts.

However even though D is C++ inspired, I just have a much easier time
converting python code instead. I think this is because wxGlide puts
everything into header+implementation files, and this is a chore to
convert to D, whereas the equivalent python code is in one file and
much shorter.

I definitely think I'll start using wxd from now on. :)
Nov 24 2011
next sibling parent reply Gour <gour atmarama.net> writes:
On Fri, 25 Nov 2011 05:35:52 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 Well the cool thing is I can use wxGlide to generate C++ code, and
 convert that to D. I tried it just now and it seems to work, but
 converting everything by hand is a bit of a chore.


Huh, does it fall in the category of 'language bindings' ? :-)


 I definitely think I'll start using wxd from now on. :)


Great!


Sincerely,
Gour


--=20
The senses are so strong and impetuous, O Arjuna,=20
that they forcibly carry away the mind even of a man=20
of discrimination who is endeavoring to control them.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 24 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/25/11, Gour <gour atmarama.net> wrote:

 Huh, does it fall in the category of 'language bindings' ? :-)


It's a GUI builder with code generation: http://wxglade.sourceforge.net/

Or maybe I didn't get the joke? Hehe
Nov 24 2011
parent Gour <gour atmarama.net> writes:
On Fri, 25 Nov 2011 08:51:19 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 On 11/25/11, Gour <gour atmarama.net> wrote:

 Huh, does it fall in the category of 'language bindings' ? :-)


=20



 Or maybe I didn't get the joke? Hehe


;)


Sincerely,
Gour

--=20
As the embodied soul continuously passes, in this body,=20
from boyhood to youth to old age, the soul similarly passes=20
into another body at death. A sober person is not bewildered=20
by such a change.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 25 2011
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrej Mitrovic wrote:

 Well the cool thing is I can use wxGlide to generate C++ code, and
 convert that to D. I tried it just now and it seems to work, but
 converting everything by hand is a bit of a chore.


So don't generate code, use XRC resources instead ?


 However even though D is C++ inspired, I just have a much easier time
 converting python code instead. I think this is because wxGlide puts
 everything into header+implementation files, and this is a chore to
 convert to D, whereas the equivalent python code is in one file and
 much shorter.


Supposedly you could patch it to generate D code...

https://bitbucket.org/agriggio/wxglade/src/default/codegen/

Then you wouldn't have to convert it later at all.

--anders
Nov 25 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/25/11, Anders F Bj=F6rklund <afb algonet.se> wrote:

 Andrej Mitrovic wrote:

 Well the cool thing is I can use wxGlide to generate C++ code, and
 convert that to D. I tried it just now and it seems to work, but
 converting everything by hand is a bit of a chore.


 So don't generate code, use XRC resources instead ?


I haven't thought of that! I'm very new to wxWidgets, thanks for the tip.
Nov 25 2011
prev sibling parent reply Gour <gour atmarama.net> writes:
On Fri, 25 Nov 2011 11:07:45 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 So don't generate code, use XRC resources instead ?


wxD can use XRC files?

It would be great, then we can use some of the builders like
DialogBlocks/wxForms...


Sincerely,
Gour


--=20
One who restrains his senses, keeping them under full control,=20
and fixes his consciousness upon Me, is known as a man of=20
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 25 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 So don't generate code, use XRC resources instead ?


 wxD can use XRC files?

 It would be great, then we can use some of the builders like
 DialogBlocks/wxForms...


See the "Xrc" demo in Samples, for some example code.

http://docs.wxwidgets.org/stable/wx_xrcoverview.html

--anders
Nov 25 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I've managed to get StyledTextCtrl compiled and working. I had to add
a few missing .obj/.cpp file entries in the DMC makefile for the
StyledTextCtrl contrib tree (just a couple of lexer files), but there
was also a cyclic import problem in wxd between wx.StyledTextCtrl's
and wx.TaskBarIcon's module ctors.

So as a temporary workaround I've merged STC's ctor into TaskBarIcon.d.

Btw, how can I figure out what "int style" means for STC? The docs
I've found only don't say anything about what that option is in the
ctor. I'm trying to make STC autoexpand in a  tab widget. But STC
stays the same size when I resize the window:
http://paste.pocoo.org/show/513430/

Maybe I need to use events on size changes?
Nov 26 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
On Sat, Nov 26, 2011 at 11:27 PM, Andrej Mitrovic <
andrej.mitrovich gmail.com> wrote:


 I've managed to get StyledTextCtrl compiled and working. I had to add
 a few missing .obj/.cpp file entries in the DMC makefile for the
 StyledTextCtrl contrib tree (just a couple of lexer files), but there
 was also a cyclic import problem in wxd between wx.StyledTextCtrl's
 and wx.TaskBarIcon's module ctors.

 So as a temporary workaround I've merged STC's ctor into TaskBarIcon.d.

 Btw, how can I figure out what "int style" means for STC? The docs
 I've found only don't say anything about what that option is in the
 ctor. I'm trying to make STC autoexpand in a  tab widget. But STC
 stays the same size when I resize the window:
 http://paste.pocoo.org/show/513430/

 Maybe I need to use events on size changes?


The style int is a bitfield with stuff like border options and sometimes
control specific settings.  Check wxWindow's documentation for the basic
styles.

You use sizers for pretty much all layout work in wxWidgets.  To do what
you want you could make a vertical box sizer, add the STC with a proportion
of 1 (expand vertically) and wxEXPAND flag (expand horizontally), and set
it as the sizer of the parent window.

This short tutorial is helpful for learning to use sizers:
http://neume.sourceforge.net/sizerdemo/

Regards,
Brad Anderson
Nov 27 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ah right, sizers. I forgot to set a sizer for the tab. Now it works:
http://codepad.org/Kc5TxXjU

Thanks!
Nov 27 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
FWIW I've got the StyledText sample fixed for D2 (it wasn't compiling
for D1 either).

It has a dependency on the Display class, and it seems wxd is compiled
with this class but you can't use it because it depends on
wxc\display.cpp, which has a whole section idfef'd out (via #if
wxUSE_DISPLAY). So naturally there's linker errors.

I tried but I couldn't compile the wxc\display.cpp file when I defined
wxUSE_DISPLAY, I kept getting weird DMC errors.

Anywho the sample only used it for priting so I just disabled that
functionality.
Nov 27 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 28 Nov 2011 02:11:24 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 It has a dependency on the Display class, and it seems wxd is compiled
 with this class but you can't use it because it depends on
 wxc\display.cpp, which has a whole section idfef'd out (via #if
 wxUSE_DISPLAY). So naturally there's linker errors.


I haven't build wxD yet, but just curious...you say that the sample
depends on wxc\display.cpp, but I thought that wxc stuff belonged to
wx.NET port, while the wxD site says: "Newer wxD version (0.10) has been
updated to wxWidgets 2.6.4 and linkable with wxWidgets 2.8.4 as well,
and is now based directly on the original wx classes since the
previously used wx.NET was not being maintained anymore."

Please advise?

Edit: Now I see that wxC is/was project meant to provide basis for
wxEiffel (& wxHaskell) bindings...but seeing it's not really maintained
it seems to be dead end. My proposition is research about the
possibility to do wxD straight from the SWIG and its D support since
present approaches does not, I'm afraid, promise bright future.

Morever, I believe there are not so many wxD-2.8.x applications written
and it's reasonable to start working on 2.9/3.0 not caring much about
older releases.

Sincerely,
Gour

--=20
A person who is not disturbed by the incessant flow of=20
desires =E2=80=94 that enter like rivers into the ocean, which is=20
ever being filled but is always still =E2=80=94 can alone achieve=20
peace, and not the man who strives to satisfy such desires.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 27 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 I haven't build wxD yet, but just curious...you say that the sample
 depends on wxc\display.cpp, but I thought that wxc stuff belonged to
 wx.NET port, while the wxD site says: "Newer wxD version (0.10) has been
 updated to wxWidgets 2.6.4 and linkable with wxWidgets 2.8.4 as well,
 and is now based directly on the original wx classes since the
 previously used wx.NET was not being maintained anymore."

 Please advise?


You'll need to read the entire thing.
http://wxd.sourceforge.net/#libraries

"wxD is not a D port of wxWidgets, so it uses the C++ libraries. It is 
composed of two parts: (2 static libraries)

     * wxc is a C++ library which exposes the wxWidgets API as a 
collection of D-friendly functions (extern "C").
     * wxd is a library written in D which parallels the wxWidgets (C++) 


It's then linked to the regular wx libraries from wxWidgets, [...]"

So wxD (the project) consists of two sub-libraries: wxc and wxd.
Whether it's libwxc.a or wxc.lib depends on the platform/compiler.


wx.NET is sorta/kinda maintained again now, much like wxD itself...
It changed name to "WX.Net", in some attempt to make it more .NET
(probably a really bad idea, as it hinders porting from wxWidgets)
Fortunately D has the "alias" keyword, instead of such renamings.

http://wxnet.sourceforge.net/



 Edit: Now I see that wxC is/was project meant to provide basis for
 wxEiffel (& wxHaskell) bindings...but seeing it's not really maintained
 it seems to be dead end. My proposition is research about the
 possibility to do wxD straight from the SWIG and its D support since
 present approaches does not, I'm afraid, promise bright future.


If you were to use SWIG, you would still have the same two libraries ?
Just that files would be: example.d + example_im.d, example_wrap.cxx
(as generated by SWIG from your example.i source file and the headers)
whereas they are currently called: wx/Example.d and wxc/example.cpp

http://www.swig.org/Doc2.0/SWIGPlus.html

You would also get all the function-pointer fun (like in Derelict),
why there is the extra intermediary module to hide the dlopen junk.
The wxD code uses regular bindings, so it would just link directly.
But one could probably move the extern(C) declarations, if desired.

http://svn.dsource.org/projects/derelict/trunk/docs/derelictify.html


 Morever, I believe there are not so many wxD-2.8.x applications written
 and it's reasonable to start working on 2.9/3.0 not caring much about
 older releases.


You could always put it in some namespace, like Derelict/Deimos does ?

The classes already grow an annoying filename addition to their name
anyway, unless you add all the classes to the main wx.d file directly.
So it probably doesn't matter if wxApp is called "deity.wx_.app.App",
as long as you have a top module to import and some reasonable aliases.


When you do the SWIG interface files, you should not use the includes
directly since those have a *lot* of platform/implementation details:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/include/wx/   (1561)

Instead it's better to use the Doxygen interfaces as the basis for .i
Those should focus more on the actual wx API you want to export to D:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/interface/wx/  (350)

--anders
Nov 28 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 28 Nov 2011 12:20:27 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 You'll need to read the entire thing.
 http://wxd.sourceforge.net/#libraries


Ahh, thank you. Somehow I did miss it. :-(


 So wxD (the project) consists of two sub-libraries: wxc and wxd.
 Whether it's libwxc.a or wxc.lib depends on the platform/compiler.


OK.


 If you were to use SWIG, you would still have the same two libraries ?
 Just that files would be: example.d + example_im.d, example_wrap.cxx
 (as generated by SWIG from your example.i source file and the headers)
 whereas they are currently called: wx/Example.d and wxc/example.cpp


OK; but do you consider it would be better not to depend on wx.NET?



 The classes already grow an annoying filename addition to their name
 anyway, unless you add all the classes to the main wx.d file directly.
 So it probably doesn't matter if wxApp is called "deity.wx_.app.App",
 as long as you have a top module to import and some reasonable
 aliases.


Right. My main concern is just whether it is more feasible to provide
wxD directly using SWIG'S D capability.


 When you do the SWIG interface files, you should not use the includes
 directly since those have a *lot* of platform/implementation details:


I believe that those things should be taken care of by e.g. cmake.


 Instead it's better to use the Doxygen interfaces as the basis for .i
 Those should focus more on the actual wx API you want to export to D:


Yes. WxPython will also use info from Doxygen.

So, is wxD going to continue like now, or do you envision some change
how to proceed for wx-2.9/3.=3D?


Sincerely,
Gour


--=20
A person who is not disturbed by the incessant flow of=20
desires =E2=80=94 that enter like rivers into the ocean, which is=20
ever being filled but is always still =E2=80=94 can alone achieve=20
peace, and not the man who strives to satisfy such desires.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 28 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 If you were to use SWIG, you would still have the same two libraries ?
 Just that files would be: example.d + example_im.d, example_wrap.cxx
 (as generated by SWIG from your example.i source file and the headers)
 whereas they are currently called: wx/Example.d and wxc/example.cpp


 OK; but do you consider it would be better not to depend on wx.NET?


At this point in time it doesn't matter, the generated files are
different even if the scripts to generate them are somewhat similar.
The API is also different, from the different languages used and
from this recent push to rename things to be more like rest of .NET.

So it's not really dependent on wx.NET now, even if the wx-c-gen.pl
script and a few other translation details were reused and adapted ?
Other bindings, for instance for SDL and for OpenGL, were generated
by similar perl scripts operating on the original C/C++ header files.


 The classes already grow an annoying filename addition to their name
 anyway, unless you add all the classes to the main wx.d file directly.
 So it probably doesn't matter if wxApp is called "deity.wx_.app.App",
 as long as you have a top module to import and some reasonable
 aliases.


 Right. My main concern is just whether it is more feasible to provide
 wxD directly using SWIG'S D capability.


Easiest way to tell is to start wrapping a couple of classes, to see ?

%module object

%{
#include "include/wx/object.h"
%}

%include "interface/wx/object.h"

And then use `swig -d -d2 -c++ -outcurrentdir wx/object.i` to generate.

Probably need some kind of namespace workaround to create the modules
as "wx.object" rather than just "object" or to convert the "wxObject".

Eventually it should use <wx/object.h> and copy/fix the interface, but.


Here's a more complete example of what it would look like in the end:

http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/
http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/

Even using SWIG, there's a whole lot of code that needs to be written.



 When you do the SWIG interface files, you should not use the includes
 directly since those have a *lot* of platform/implementation details:


 I believe that those things should be taken care of by e.g. cmake.


Linking is a whole other issue, this was "just" for determining the
interface files for SWIG (the .i). Probably by combining both wx/*.h ?


 Instead it's better to use the Doxygen interfaces as the basis for .i
 Those should focus more on the actual wx API you want to export to D:


 Yes. WxPython will also use info from Doxygen.


I think it would be needed to translate it to DDoc for it to be allowed,
but wxD also makes use of Doxygen as can be seen from the API reference.



 So, is wxD going to continue like now, or do you envision some change
 how to proceed for wx-2.9/3.=?


I don't plan to do anything with it, I put it up on github so that it
could be forked and maintained if there are any bugfixes etc needed...

Both wxWidgets and Code::Blocks are Open Source, so if you want to
continue to base the GUI and IDE for the D programming language on
those there's plenty of things that could be improved for either...
The same goes for GCC (and LDC), of course. Maybe even for DMD too.

The wxWidgets roadmap says "We hope to make 3.0 in the spring of 2012."
But as mentioned earlier, using 2.9 should be just fine before that ?

It's perfectly doable to continue to use the current wxd.sourceforge.net
even with wx 3.0 and D 2.0, so I think I will just leave that up as-is.
Ditto for the GDC binaries there, that probably need updating both for
64-bit and for D 2 as well as for newer versions of GCC and of the OS.

When starting up the "wxD2" or "$deity" - or whatever the new project
would be named, it could probably do more changes than just use SWIG ?

--anders
Nov 28 2011
next sibling parent reply Gour <gour atmarama.net> writes:
On Mon, 28 Nov 2011 16:18:33 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 At this point in time it doesn't matter, the generated files are
 different even if the scripts to generate them are somewhat similar.
 The API is also different, from the different languages used and
 from this recent push to rename things to be more like rest of .NET.


OK.


 Easiest way to tell is to start wrapping a couple of classes, to see ?


[...]


 Here's a more complete example of what it would look like in the end:
=20
 http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/
 http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/


Thank you.


 Even using SWIG, there's a whole lot of code that needs to be written.


Sure. We just wonder if using route will be more effective in the long
run?


 I don't plan to do anything with it, I put it up on github so that it
 could be forked and maintained if there are any bugfixes etc needed...


OK.


 Both wxWidgets and Code::Blocks are Open Source, so if you want to
 continue to base the GUI and IDE for the D programming language on
 those there's plenty of things that could be improved for either...


Well, for IDE, I'll probably use Geany. As far as GUI-part is concerned,
depending on the toolkit we choose. we'd just use some GUI builder (each
toolkit has some.)


 The wxWidgets roadmap says "We hope to make 3.0 in the spring of
 2012." But as mentioned earlier, using 2.9 should be just fine before
 that ?


Yes. Afaik, the major part of new wx-3.0 stuff is already in 2.9.


 It's perfectly doable to continue to use the current
 wxd.sourceforge.net even with wx 3.0 and D 2.0, so I think I will
 just leave that up as-is.=20


OK.


 When starting up the "wxD2" or "$deity" - or whatever the new project
 would be named, it could probably do more changes than just use SWIG ?


Thank you for making it clear. ;)


Sincerely,
Gour


--=20
When your intelligence has passed out of the dense forest=20
of delusion, you shall become indifferent to all that has=20
been heard and all that is to be heard.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 28 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 Here's a more complete example of what it would look like in the end:

 http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/
 http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/


 Thank you.


Of course, you don't *have* to wrap all the classes or methods ?
One could start with the ones that are likely to be used from D.


 Even using SWIG, there's a whole lot of code that needs to be written.


 Sure. We just wonder if using route will be more effective in the long
 run?


Automation is surely the way to go, the only question is whether it
should be a custom script or if a (patched?) SWIG would be better.

BTW:
If it helps, there's a Doxygen parser (for the XML output) in the
docs/doxygen/scripts directory that could be used to start it off:

cd docs/doxygen
./regen.sh xml
python scripts/make_bindings.py --swig --output_dir=bindings \
                                 out/xml/classwx_app.xml

The generated SWIG bindings are for wxPython, but I suppose you
could adopt the swig_tools.SWIGBuilder to generate some D SWIG ?

python scripts/doxymlparser.py --report out/xml/classwx_app.xml


 I don't plan to do anything with it, I put it up on github so that it
 could be forked and maintained if there are any bugfixes etc needed...


 OK.


 It's perfectly doable to continue to use the current
 wxd.sourceforge.net even with wx 3.0 and D 2.0, so I think I will
 just leave that up as-is.


 OK.


Just that I won't have much time to actually maintain it, myself.


 When starting up the "wxD2" or "$deity" - or whatever the new project
 would be named, it could probably do more changes than just use SWIG ?


 Thank you for making it clear. ;)


Whether it's about hosting or organization, or something different.

--anders
Nov 28 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 28 Nov 2011 21:01:38 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 Of course, you don't *have* to wrap all the classes or methods ?
 One could start with the ones that are likely to be used from D.


Well, it is still big project and not so easy to say what needed.

In any case, substantial part has to be bound in order to get into
writing multi-platform desktop app.


 Automation is surely the way to go, the only question is whether it
 should be a custom script or if a (patched?) SWIG would be better.


That's hard for me to say.


 If it helps, there's a Doxygen parser (for the XML output) in the
 docs/doxygen/scripts directory that could be used to start it off:
=20
 cd docs/doxygen
 ./regen.sh xml
 python scripts/make_bindings.py --swig --output_dir=3Dbindings \
                                  out/xml/classwx_app.xml
=20
 The generated SWIG bindings are for wxPython, but I suppose you
 could adopt the swig_tools.SWIGBuilder to generate some D SWIG ?


I'll take a look to see if it makes sense to me. :)


 Just that I won't have much time to actually maintain it, myself.


I'm also not capable to lead such project and would have to take that
into consideration when deciding which GUI toolkit to use with D.

In any case, for now, I plan to learn more D, master some CMake and
start playing with SWIG in order to provide bindings for 3rd party C
library which we'll use.

Then, in the meantime, maybe there will be more clear which toolkit is
optimal to use when writing desktop app in D *today*.


Sincerely,
Gour


--=20
One who restrains his senses, keeping them under full control,=20
and fixes his consciousness upon Me, is known as a man of=20
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 28 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Gour wrote:

 Just that I won't have much time to actually maintain it, myself.


 I'm also not capable to lead such project and would have to take that
 into consideration when deciding which GUI toolkit to use with D.

 In any case, for now, I plan to learn more D, master some CMake and
 start playing with SWIG in order to provide bindings for 3rd party C
 library which we'll use.


I'm no fan of either, and prefer plain import modules and libs over
function pointers and complex tools. But I guess that was obvious.


 Then, in the meantime, maybe there will be more clear which toolkit is
 optimal to use when writing desktop app in D *today*.


Well, I believe you had the officially supported DWT and QtD plus
the also available GtkD and wxD. Didn't seem like a bad selection ?

All four of those are well supported toolkits, _upstream_ that is.
Either GUI should do the trick for writing a desktop application.


But even if Phobos/Deimos would have something like Tk (or FLTK)
integrated, it probably wouldn't be accepted as a real solution.

That is, just for being too ugly or too grey or something similar.

Something like "MinWin" or Lucid seemed like a good idea to have
in the standard D library, just a small native wrapper for GUI...

But before that happens, you're stuck with the third party efforts.


Now, why would you want to use D as your language(s) rather than
C, Python, Java ? Or even C++. That was the real question for me.

There has to be enough advantages to overcome the shortcomings,
which in the end wasn't true when making desktop apps (or games).

--anders
Nov 28 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 28 Nov 2011 22:55:10 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 I'm no fan of either, and prefer plain import modules and libs over
 function pointers and complex tools.=20


Well, my belief is that tools can help when maintaining bindings, iow.
when one has to keep the API up-to-date.

Of course, my experience was with c2hs (Haskell) where it was easy to
notice change in the upstream's API.

However, we'll try with SWIG.


 But I guess that was obvious.


It is.


 Well, I believe you had the officially supported DWT=20


I'm not so sure DWT is either officially supported or in the same league
as other toolkits. World of SWT is not thrilling...


 and QtD plus the also available GtkD and wxD. Didn't seem like a bad
 selection ?


I already wrote about that in another thread...nice selection, but not
so great support.


 All four of those are well supported toolkits, _upstream_ that is.
 Either GUI should do the trick for writing a desktop application.


Upstream was never meant as part of the problem which is on the D-side.
:-)


 But even if Phobos/Deimos would have something like Tk (or FLTK)
 integrated, it probably wouldn't be accepted as a real solution.


Right.


 That is, just for being too ugly or too grey or something similar.


Or too light perhaps. ;)


 Now, why would you want to use D as your language(s) rather than
 C, Python, Java ? Or even C++. That was the real question for me.


Because I want to work on open-source project in my spare time and that
should have some component of 'fun'...C & C++ are not falling into that
category, I don't know nor like Java, not inspired about Lisp-languages,
Haskell is too-theoretical...which leaves me with the Python, but I find
D as sweet spot between scripting languages & C(++). Moreover, it will
be bigger project which would need longer maintainance and we believe
that although D is not maybe completely ready today, it will be soon
enough, so we can start working by writing non-GUI libs for the project.


 There has to be enough advantages to overcome the shortcomings,
 which in the end wasn't true when making desktop apps (or games).


"De gustibus non est disputandum..."



Sincerely,
Gour


--=20
One who is able to withdraw his senses from sense objects,=20
as the tortoise draws its limbs within the shell,=20
is firmly fixed in perfect consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 28 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-29 07:37, Gour wrote:

 On Mon, 28 Nov 2011 22:55:10 +0100
 Anders F Björklund<afb algonet.se>  wrote:


 I'm no fan of either, and prefer plain import modules and libs over
 function pointers and complex tools.


 Well, my belief is that tools can help when maintaining bindings, iow.
 when one has to keep the API up-to-date.

 Of course, my experience was with c2hs (Haskell) where it was easy to
 notice change in the upstream's API.

 However, we'll try with SWIG.


 But I guess that was obvious.


 It is.


 Well, I believe you had the officially supported DWT


 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


DWT is not officially supported. A couple of years ago Walter announced 
that DWT was going to be the official GUI library for D but that was one 
of the previous attempts to port SWT to D. When that happened the 
development of DWT stopped. I guess it was just bad timing but since 
that Walter has been very reluctant in doing something similar again.

-- 
/Jacob Carlborg
Nov 28 2011
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Jacob Carlborg wrote:

 Well, I believe you had the officially supported DWT


 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


 DWT is not officially supported. A couple of years ago Walter announced
 that DWT was going to be the official GUI library for D but that was one
 of the previous attempts to port SWT to D. When that happened the
 development of DWT stopped. I guess it was just bad timing but since
 that Walter has been very reluctant in doing something similar again.


Right, that was the DWT version I meant (the non-Tango variant)

Guess it happened again with QtD, after recommended by Andrei ?

--anders

* In "The Case for D":
   http://drdobbs.com/high-performance-computing/217801225
Nov 28 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-29 08:57, Anders F Björklund wrote:

 Jacob Carlborg wrote:

 Well, I believe you had the officially supported DWT


 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


 DWT is not officially supported. A couple of years ago Walter announced
 that DWT was going to be the official GUI library for D but that was one
 of the previous attempts to port SWT to D. When that happened the
 development of DWT stopped. I guess it was just bad timing but since
 that Walter has been very reluctant in doing something similar again.


 Right, that was the DWT version I meant (the non-Tango variant)

 Guess it happened again with QtD, after recommended by Andrei ?

 --anders

 * In "The Case for D":
 http://drdobbs.com/high-performance-computing/217801225


Hehe, D and GUI libraries don't seem to agree.

-- 
/Jacob Carlborg
Nov 29 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-29 07:37, Gour wrote:

 On Mon, 28 Nov 2011 22:55:10 +0100
 Anders F Björklund<afb algonet.se>  wrote:


 I'm no fan of either, and prefer plain import modules and libs over
 function pointers and complex tools.


 Well, my belief is that tools can help when maintaining bindings, iow.
 when one has to keep the API up-to-date.

 Of course, my experience was with c2hs (Haskell) where it was easy to
 notice change in the upstream's API.

 However, we'll try with SWIG.


 But I guess that was obvious.


 It is.


 Well, I believe you had the officially supported DWT


 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


BTW, I don't understand what people has against DWT/SWT. In my 
experience it's the toolkit that offers best native look and feeling. 
Note that I have no experience with wx but the screenshots on the site 
looks really bad.

-- 
/Jacob Carlborg
Nov 28 2011
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Jacob Carlborg wrote:

 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


 BTW, I don't understand what people has against DWT/SWT. In my
 experience it's the toolkit that offers best native look and feeling.


One advantage of DWT is/was that it linked directly with the system.
With wxWidgets (in wxD), there is the C++ framework layer inbetween.

But other than that, the two should be rather similar in look/feel ?
At least when compared to GTK+ or Qt, using their own custom widgets.


 Note that I have no experience with wx but the screenshots on the site
 looks really bad.


What site is that ? Is it one of these:

http://www.wxwidgets.org/about/screensh.htm

http://wxd.sourceforge.net/screenshot.html

http://wxd.sourceforge.net/#screenshots

It's not supposed to look much different, from other native apps.
The easiest way to see is trying the wxWidgets binaries yourself:

http://wxd.sourceforge.net/#demo

--anders
Nov 29 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-29 09:09, Anders F Björklund wrote:

 Jacob Carlborg wrote:

 I'm not so sure DWT is either officially supported or in the same league
 as other toolkits. World of SWT is not thrilling...


 BTW, I don't understand what people has against DWT/SWT. In my
 experience it's the toolkit that offers best native look and feeling.


 One advantage of DWT is/was that it linked directly with the system.
 With wxWidgets (in wxD), there is the C++ framework layer inbetween.

 But other than that, the two should be rather similar in look/feel ?
 At least when compared to GTK+ or Qt, using their own custom widgets.


 Note that I have no experience with wx but the screenshots on the site
 looks really bad.


 What site is that ? Is it one of these:

 http://www.wxwidgets.org/about/screensh.htm

 http://wxd.sourceforge.net/screenshot.html

 http://wxd.sourceforge.net/#screenshots

 It's not supposed to look much different, from other native apps.
 The easiest way to see is trying the wxWidgets binaries yourself:

 http://wxd.sourceforge.net/#demo

 --anders


All the Mac OS X images on this site look horrible: 
http://www.wxwidgets.org/about/screensh.htm

But that might be a problem with the applications and not the toolkit. 
And the images are so horrible outdated. What version of Mac OS X is 
that, 10.3?

BTW, how is the support for Mac OS X specific "widgets" that are usually 
not available on other platforms, like:

* Dialog sheets
* Unified toolbar
* Adding menu items to the dock icon
* Adding menu items to the application menu (or what it's called)

I tried to run the demo, it requires Rosetta, that was a couple of 
versions ago of Mac OS X.


-- 
/Jacob Carlborg
Nov 29 2011
next sibling parent reply Gour <gour atmarama.net> writes:
On Tue, 29 Nov 2011 13:39:42 +0100
Jacob Carlborg <doob me.com> wrote:


 BTW, how is the support for Mac OS X specific "widgets" that are
 usually not available on other platforms, like:


No idea. I know only that wxOSX port supporting Cocoa is a new one.


Sincerely,
Gour


--=20
One who restrains his senses, keeping them under full control,=20
and fixes his consciousness upon Me, is known as a man of=20
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Nov 29 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-29 14:35, Gour wrote:

 On Tue, 29 Nov 2011 13:39:42 +0100
 Jacob Carlborg<doob me.com>  wrote:


 BTW, how is the support for Mac OS X specific "widgets" that are
 usually not available on other platforms, like:


 No idea. I know only that wxOSX port supporting Cocoa is a new one.


Then I would guess no. It's the same thing with SWT/DWT. When SWT 3.4 
was developed the Cocoa port was started and it didn't get all these 
widgets until 3.7. Eclipse still doesn't use the native toolbar for example.

-- 
/Jacob Carlborg
Nov 29 2011
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Jacob Carlborg wrote:

 All the Mac OS X images on this site look horrible:
 http://www.wxwidgets.org/about/screensh.htm

 But that might be a problem with the applications and not the toolkit.
 And the images are so horrible outdated. What version of Mac OS X is
 that, 10.3?


Okay, so "horrible" was more about outdated than broken or anything.

Most of the wxD screenshots are from Mac OS X 10.4 "Tiger" (2006).


 BTW, how is the support for Mac OS X specific "widgets" that are usually
 not available on other platforms, like:

 * Dialog sheets
 * Unified toolbar
 * Adding menu items to the dock icon
 * Adding menu items to the application menu (or what it's called)


It's in the nature of cross-platform toolkits to poorly support such.

The sheets and toolbars should work in wxOSX/Cocoa (but not in wxMac)


 I tried to run the demo, it requires Rosetta, that was a couple of
 versions ago of Mac OS X.


All but the latest should run it OK, but I guess you need to compile.

It looks like: http://www.algonet.se/~afb/wx/WidgetsDemo-MacOSX.png






--anders
Nov 29 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-29 18:06, Anders F Björklund wrote:

 Jacob Carlborg wrote:

 All the Mac OS X images on this site look horrible:
 http://www.wxwidgets.org/about/screensh.htm

 But that might be a problem with the applications and not the toolkit.
 And the images are so horrible outdated. What version of Mac OS X is
 that, 10.3?


 Okay, so "horrible" was more about outdated than broken or anything.


Well, yes. But that's the whole point, otherwise GTK+ would be an option.


 Most of the wxD screenshots are from Mac OS X 10.4 "Tiger" (2006).


Yeah, they look a bit better.


 BTW, how is the support for Mac OS X specific "widgets" that are usually
 not available on other platforms, like:

 * Dialog sheets
 * Unified toolbar
 * Adding menu items to the dock icon
 * Adding menu items to the application menu (or what it's called)


 It's in the nature of cross-platform toolkits to poorly support such.


Unfortunately yes. But I see know reason why there can't be a 
corss-platform toolkit with additional platform specific widgets or similar.

This is something I would like to see in a cross-platform toolkit.

http://mschrag.blogspot.com/2008/06/maclipse.html

When a widget is emulated, provide look and feel that would fit for the 
specific platform.


 The sheets and toolbars should work in wxOSX/Cocoa (but not in wxMac)


Ok, I see.


 I tried to run the demo, it requires Rosetta, that was a couple of
 versions ago of Mac OS X.


 All but the latest should run it OK, but I guess you need to compile.

 It looks like: http://www.algonet.se/~afb/wx/WidgetsDemo-MacOSX.png






 --anders


Yeah, I've tried it out now, looks pretty Ok. But comparing that widget 
demo to SWT is basically no difference. SWT looks a bit more polished, 
but that might be the widget demo and not the toolkit.

Does wxWdiget support:

* Internationalization
* Accessibility
* Date widget
* Validation of input fields

-- 
/Jacob Carlborg
Nov 29 2011
parent reply Brad Anderson <eco gnuk.net> writes:
On Tue, Nov 29, 2011 at 1:58 PM, Jacob Carlborg <doob me.com> wrote:


 On 2011-11-29 18:06, Anders F Bj=F6rklund wrote:


 Jacob Carlborg wrote:


 All the Mac OS X images on this site look horrible:
 http://www.wxwidgets.org/**about/screensh.htm<http://www.wxwidgets.org/=






about/screensh.htm>

 But that might be a problem with the applications and not the toolkit.
 And the images are so horrible outdated. What version of Mac OS X is
 that, 10.3?


 Okay, so "horrible" was more about outdated than broken or anything.


 Well, yes. But that's the whole point, otherwise GTK+ would be an option.


  Most of the wxD screenshots are from Mac OS X 10.4 "Tiger" (2006).


 Yeah, they look a bit better.


  BTW, how is the support for Mac OS X specific "widgets" that are usually

 not available on other platforms, like:

 * Dialog sheets
 * Unified toolbar
 * Adding menu items to the dock icon
 * Adding menu items to the application menu (or what it's called)


 It's in the nature of cross-platform toolkits to poorly support such.


 Unfortunately yes. But I see know reason why there can't be a
 corss-platform toolkit with additional platform specific widgets or simil=


ar.

 This is something I would like to see in a cross-platform toolkit.

 http://mschrag.blogspot.com/**2008/06/maclipse.html<http://mschrag.blogsp=


ot.com/2008/06/maclipse.html>

 When a widget is emulated, provide look and feel that would fit for the
 specific platform.


wxWidgets tries to do just that.  It is done by programmers though so
sometimes they don't quite capture the look.



  The sheets and toolbars should work in wxOSX/Cocoa (but not in wxMac)


 Ok, I see.


  I tried to run the demo, it requires Rosetta, that was a couple of

 versions ago of Mac OS X.


 All but the latest should run it OK, but I guess you need to compile.

 It looks like: http://www.algonet.se/~afb/wx/**WidgetsDemo-MacOSX.png<ht=




tp://www.algonet.se/~afb/wx/WidgetsDemo-MacOSX.png>






 --anders


 Yeah, I've tried it out now, looks pretty Ok. But comparing that widget
 demo to SWT is basically no difference. SWT looks a bit more polished, bu=


t

 that might be the widget demo and not the toolkit.

 Does wxWdiget support:

 * Internationalization


Yes.



 * Accessibility


I would imagine this is more of an OS level function so...probably?



 * Date widget


Yes.



 * Validation of input fields



Yes.



 --
 /Jacob Carlborg





 Nov 29 2011



  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 22:24, Brad Anderson wrote:

 On Tue, Nov 29, 2011 at 1:58 PM, Jacob Carlborg <doob me.com
 <mailto:doob me.com>> wrote:

     On 2011-11-29 18:06, Anders F Björklund wrote:

         Jacob Carlborg wrote:

             All the Mac OS X images on this site look horrible:
             http://www.wxwidgets.org/__about/screensh.htm
             <http://www.wxwidgets.org/about/screensh.htm>

             But that might be a problem with the applications and not
             the toolkit.
             And the images are so horrible outdated. What version of Mac
             OS X is
             that, 10.3?


         Okay, so "horrible" was more about outdated than broken or anything.


     Well, yes. But that's the whole point, otherwise GTK+ would be an
     option.


         Most of the wxD screenshots are from Mac OS X 10.4 "Tiger" (2006).


     Yeah, they look a bit better.


             BTW, how is the support for Mac OS X specific "widgets" that
             are usually
             not available on other platforms, like:

             * Dialog sheets
             * Unified toolbar
             * Adding menu items to the dock icon
             * Adding menu items to the application menu (or what it's
             called)


         It's in the nature of cross-platform toolkits to poorly support
         such.


     Unfortunately yes. But I see know reason why there can't be a
     corss-platform toolkit with additional platform specific widgets or
     similar.

     This is something I would like to see in a cross-platform toolkit.

     http://mschrag.blogspot.com/__2008/06/maclipse.html
     <http://mschrag.blogspot.com/2008/06/maclipse.html>

     When a widget is emulated, provide look and feel that would fit for
     the specific platform.


 wxWidgets tries to do just that.  It is done by programmers though so
 sometimes they don't quite capture the look.


         The sheets and toolbars should work in wxOSX/Cocoa (but not in
         wxMac)


     Ok, I see.


             I tried to run the demo, it requires Rosetta, that was a
             couple of
             versions ago of Mac OS X.


         All but the latest should run it OK, but I guess you need to
         compile.

         It looks like:
         http://www.algonet.se/~afb/wx/__WidgetsDemo-MacOSX.png
         <http://www.algonet.se/~afb/wx/WidgetsDemo-MacOSX.png>






         --anders


     Yeah, I've tried it out now, looks pretty Ok. But comparing that
     widget demo to SWT is basically no difference. SWT looks a bit more
     polished, but that might be the widget demo and not the toolkit.

     Does wxWdiget support:

     * Internationalization


 Yes.

     * Accessibility


 I would imagine this is more of an OS level function so...probably?

     * Date widget


 Yes.

     * Validation of input fields


 Yes.



     --
     /Jacob Carlborg


That's good to hear.

-- 
/Jacob Carlborg



 Nov 29 2011



prev sibling next sibling parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 29.11.2011, 08:47 Uhr, schrieb Jacob Carlborg <doob me.com>:


 Note that I have no experience with wx but the screenshots on the site  
 looks really bad.


Take a look at Code::Blocks for an example. I think it is one of the most  
sophisticated applications written with wxWidgets. I used to have trouble  
with the XML GUI definitions though. Somehow they took ages for me to load  
and generate the UI on Linux, but not on Windows. So I am biased slightly  
against wx with XML or XRC or what they are called.

The images to the right http://eclipse.org/swt/ remind me of some  
discussion we had here. Anyway I'm fine with SWT, too and used gtkD  
previously. I think it looks good and is small by itself, relying mostly  
on functionality from the Java library where C++ libraries like QT tend to  
build up a large general purpose code base.



 Nov 29 2011



 next sibling parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 09:16:09 +0100
"Marco Leise" <Marco.Leise gmx.de> wrote:


 Take a look at Code::Blocks for an example. I think it is one of the
 most sophisticated applications written with wxWidgets. I used to
 have trouble with the XML GUI definitions though. Somehow they took
 ages for me to load and generate the UI on Linux, but not on Windows.


That's strange and it is the first time I heard something like that.

Two days ago I also asked on wxWidgets list if using XRC is kind of
idiomatic within wxWidgets community and Vadim Zeitlin (one of the core
devs) replied:=20

"Personally I've never really understood the appeal of compiling into code
and whenever I use XRC I load it during run-time. Perhaps you can gain some
minor performance advantage from compiling it into code (although I don't
know if anybody has ever really measured this) but using XRC is much more
flexible as you can tweak it without recompiling/rebuilding and often even
without restarting the program so I'd definitely recommend using it as is,
at least in the beginning."


 So I am biased slightly against wx with XML or XRC or what they are
 called.


I'd say your experience is probably not the accurate representation. Was
your problem with slow loading when using C++ or wxD?


Sincerely,
Gour


--=20
In the material world, one who is unaffected by whatever good=20
or evil he may obtain, neither praising it nor despising it,=20
is firmly fixed in perfect knowledge.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 29.11.2011, 09:26 Uhr, schrieb Gour <gour atmarama.net>:


 On Tue, 29 Nov 2011 09:16:09 +0100
 "Marco Leise" <Marco.Leise gmx.de> wrote:


 Take a look at Code::Blocks for an example. I think it is one of the
 most sophisticated applications written with wxWidgets. I used to
 have trouble with the XML GUI definitions though. Somehow they took
 ages for me to load and generate the UI on Linux, but not on Windows.


 That's strange and it is the first time I heard something like that.

 Two days ago I also asked on wxWidgets list if using XRC is kind of
 idiomatic within wxWidgets community and Vadim Zeitlin (one of the core
 devs) replied:

 "Personally I've never really understood the appeal of compiling into  
 code
 and whenever I use XRC I load it during run-time. Perhaps you can gain  
 some
 minor performance advantage from compiling it into code (although I don't
 know if anybody has ever really measured this) but using XRC is much more
 flexible as you can tweak it without recompiling/rebuilding and often  
 even
 without restarting the program so I'd definitely recommend using it as  
 is,
 at least in the beginning."


 So I am biased slightly against wx with XML or XRC or what they are
 called.


 I'd say your experience is probably not the accurate representation. Was
 your problem with slow loading when using C++ or wxD?


 Sincerely,
 Gour


Precisely this: http://forums.codeblocks.org/index.php/topic,13660.0.html
And debugging this lead me to the line where the XRC is parsed. It may  
after all have been an issue with my system / the xml library / gtk /  
compiz / etc... The experience just left a bad taste for me.



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 09:58:36 +0100
"Marco Leise" <Marco.Leise gmx.de> wrote:


 Precisely this:
 http://forums.codeblocks.org/index.php/topic,13660.0.html And
 debugging this lead me to the line where the XRC is parsed. It may
 after all have been an issue with my system / the xml library / gtk /
 compiz / etc... The experience just left a bad taste for me.


I can understand there is bad taste, but isn't it the problem of
Code:Blocks?

Have you tried using e.g. DialogBlocks and see how it behaves?


Sincerely,
Gour

--=20
While contemplating the objects of the senses, a person=20
develops attachment for them, and from such attachment lust=20
develops, and from lust anger arises.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 29.11.2011, 10:19 Uhr, schrieb Gour <gour atmarama.net>:


 On Tue, 29 Nov 2011 09:58:36 +0100
 "Marco Leise" <Marco.Leise gmx.de> wrote:


 Precisely this:
 http://forums.codeblocks.org/index.php/topic,13660.0.html And
 debugging this lead me to the line where the XRC is parsed. It may
 after all have been an issue with my system / the xml library / gtk /
 compiz / etc... The experience just left a bad taste for me.


 I can understand there is bad taste, but isn't it the problem of
 Code:Blocks?

 Have you tried using e.g. DialogBlocks and see how it behaves?


 Sincerely,
 Gour


Since the time was spent in the call to the XRC parser and it works fast  
on Windows and other people's Linux boxes, I think it is a problem outside  
of Code::Blocks. I haven't looked into any other wxWidgets applications,  
no. I think it is a good library in general though from what I've heard,  
so keep the arguments coming :)



 Nov 29 2011



  parent  Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 11:05:15 +0100
"Marco Leise" <Marco.Leise gmx.de> wrote:


 I think it is a good library in general though from what I've heard,
 so keep the arguments coming :)


It's definitely nice library, mature, owned by open-source community,
with license suitable for commercial projects, supporting native
widgets...but that's not the problem - wxD is too big for me to work on
it and therefore no need for further arguments. ;)


Sincerely,
Gour

--=20
One who is able to withdraw his senses from sense objects,=20
as the tortoise draws its limbs within the shell,=20
is firmly fixed in perfect consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 09:16, Marco Leise wrote:

 Am 29.11.2011, 08:47 Uhr, schrieb Jacob Carlborg <doob me.com>:


 Note that I have no experience with wx but the screenshots on the site
 looks really bad.


 Take a look at Code::Blocks for an example. I think it is one of the
 most sophisticated applications written with wxWidgets. I used to have
 trouble with the XML GUI definitions though. Somehow they took ages for
 me to load and generate the UI on Linux, but not on Windows. So I am
 biased slightly against wx with XML or XRC or what they are called.


I'll have a look at Code::Blocks.


 The images to the right http://eclipse.org/swt/ remind me of some
 discussion we had here. Anyway I'm fine with SWT, too and used gtkD
 previously. I think it looks good and is small by itself, relying mostly
 on functionality from the Java library where C++ libraries like QT tend
 to build up a large general purpose code base.


I know these images are not the best but at least they look better than 
wxWidget's.

-- 
/Jacob Carlborg



 Nov 29 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 09:16, Marco Leise wrote:

 Am 29.11.2011, 08:47 Uhr, schrieb Jacob Carlborg <doob me.com>:


 Note that I have no experience with wx but the screenshots on the site
 looks really bad.


 Take a look at Code::Blocks for an example. I think it is one of the
 most sophisticated applications written with wxWidgets. I used to have
 trouble with the XML GUI definitions though. Somehow they took ages for
 me to load and generate the UI on Linux, but not on Windows. So I am
 biased slightly against wx with XML or XRC or what they are called.


I took a quick look at Code::Blocks and it doesn't look very good (on 
Mac OS X), but again, it might be the application and not the toolkit. 
But what I can see is that it doesn't have a unified toolbar. On the 
other hand neither does Eclipse, but at least SWT supports unified toolbars.

-- 
/Jacob Carlborg



 Nov 29 2011



prev sibling  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 08:47:01 +0100
Jacob Carlborg <doob me.com> wrote:


 BTW, I don't understand what people has against DWT/SWT.=20


First of all, I don't have any experience and as I wrote in another
thread, looking at http://www.eclipse.org/swt/community.php - Ports
section does not boost enthusiasm:

- Fox port last news dated Sep 16, 2005
- Swing port - 2007-08-20=20
- D port based on 3.4 while 3.8 is in active development.

Moreover, list of SWT-based apps tends to be quite short.


 In my experience it's the toolkit that offers best native look and
 feeling.=20


It could be, but it is, somehow, not very well accepted.


 Note that I have no experience with wx but the screenshots on the
 site looks really bad.


I don't understand - if wxWidgets use native widgets on Windows, Linux
and Mac OS X what can be bad then?

SWT does support, afaik, same toolkits on every platform as wxWidgets?



Sincerely,
Gour

--=20
Never was there a time when I did not exist,=20
nor you, nor all these kings; nor in the future=20
shall any of us cease to be.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



 next sibling parent reply "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 29.11.2011, 09:19 Uhr, schrieb Gour <gour atmarama.net>:


 On Tue, 29 Nov 2011 08:47:01 +0100
 Jacob Carlborg <doob me.com> wrote:


 BTW, I don't understand what people has against DWT/SWT.


 First of all, I don't have any experience and as I wrote in another
 thread, looking at http://www.eclipse.org/swt/community.php - Ports
 section does not boost enthusiasm:

 - Fox port last news dated Sep 16, 2005
 - Swing port - 2007-08-20
 - D port based on 3.4 while 3.8 is in active development.

 Moreover, list of SWT-based apps tends to be quite short.


 In my experience it's the toolkit that offers best native look and
 feeling.


 It could be, but it is, somehow, not very well accepted.


I have two ideas why:
1. It is written in Java instead of C, which makes it impossible to write  
bindings for Python or C++.
2. Java started with AWT. Later Swing was introduced as an alternative,  
which satisfied those who found AWT lacking in some aspects. So today  
you'd really have to read something like this  
http://www.ibm.com/developerworks/grid/library/os-swingswt/ to learn about  
the key differences between the three and eventually decide to move on to  
SWT.

Your are practically merging two isolated worlds in your comparison: Java  
platform vs. the rest; [AWT, Swing, SWT] vs. [GTK+, QT, wxWidgets, ...]
It's probably comparable to the acceptance of D in a forum for embedded  
developers.

I'm just thinking, that whatever toolkit has the fewest dependencies while  
offering the most used widgets has the best chances to make it into Phobos  
one day - if that is still desired.



 Nov 29 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 10:25, Marco Leise wrote:

 Your are practically merging two isolated worlds in your comparison:
 Java platform vs. the rest; [AWT, Swing, SWT] vs. [GTK+, QT, wxWidgets,
 ...]


But since DWT is a port of SWT (completely written in D) I think it's 
fair to compare SWT/DWT to gtk, qt and wxwidgets.


 It's probably comparable to the acceptance of D in a forum for embedded
 developers.

 I'm just thinking, that whatever toolkit has the fewest dependencies
 while offering the most used widgets has the best chances to make it
 into Phobos one day - if that is still desired.


As far as I know DWT is the only toolkit that does not require any 
external dependencies (except the functions provided by the OS).

-- 
/Jacob Carlborg



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 15:28:56 +0100
Jacob Carlborg <doob me.com> wrote:


 But since DWT is a port of SWT (completely written in D) I think it's=20
 fair to compare SWT/DWT to gtk, qt and wxwidgets.


I tend to agreei, but wonder how much of the binding process can be
automated or it could be done by hand only?


 As far as I know DWT is the only toolkit that does not require any=20
 external dependencies (except the functions provided by the OS).


That's strong point...Maybe I should, at least, try to compile it and
check how it looks...


Sincerely,
Gour


--=20
In this endeavor there is no loss or diminution,=20
and a little advancement on this path can protect=20
one from the most dangerous type of fear.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 16:50, Gour wrote:

 On Tue, 29 Nov 2011 15:28:56 +0100
 Jacob Carlborg<doob me.com>  wrote:


 But since DWT is a port of SWT (completely written in D) I think it's
 fair to compare SWT/DWT to gtk, qt and wxwidgets.


 I tend to agreei, but wonder how much of the binding process can be
 automated or it could be done by hand only?


There's a project at dsource.org called Tioport, that tried to automated 
the process of port SWT to D. But the author gave up that project and 
started to manually port SWT instead. It turned out that you would need 
to port a large part of the Java standard library.

There's also a C++ port of SWT available. It uses NewJ which implements 
the core Java API in C++.

http://www.pure-native.com/swtcpp/index.html

If you have basically the whole Java standard library (or the core APIs) 
ported to D it would be a lot easier to automate the port.


 As far as I know DWT is the only toolkit that does not require any
 external dependencies (except the functions provided by the OS).


 That's strong point...Maybe I should, at least, try to compile it and
 check how it looks...


I recommend you give it a try.

-- 
/Jacob Carlborg



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 17:04:16 +0100
Jacob Carlborg <doob me.com> wrote:


 There's a project at dsource.org called Tioport, that tried to
 automated the process of port SWT to D. But the author gave up that
 project and started to manually port SWT instead. It turned out that
 you would need to port a large part of the Java standard library.


Ahh, that's not awesome.


 That's strong point...Maybe I should, at least, try to compile it
 and check how it looks...


=20
 I recommend you give it a try.


It seems it needs dsss?


Sincerely,
Gour

--=20
=46rom anger, complete delusion arises, and from delusion=20
bewilderment of memory. When memory is bewildered,=20
intelligence is lost, and when intelligence is lost=20
one falls down again into the material pool.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 17:07, Gour wrote:

 On Tue, 29 Nov 2011 17:04:16 +0100
 Jacob Carlborg<doob me.com>  wrote:


 There's a project at dsource.org called Tioport, that tried to
 automated the process of port SWT to D. But the author gave up that
 project and started to manually port SWT instead. It turned out that
 you would need to port a large part of the Java standard library.


 Ahh, that's not awesome.


 That's strong point...Maybe I should, at least, try to compile it
 and check how it looks...


 I recommend you give it a try.


 It seems it needs dsss?


No, it currently uses rake to build the project. Which means you need 
both ruby and rake to build DWT.


-- 
/Jacob Carlborg



 Nov 29 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 18:25, Jacob Carlborg wrote:

 On 2011-11-29 17:07, Gour wrote:

 On Tue, 29 Nov 2011 17:04:16 +0100
 Jacob Carlborg<doob me.com> wrote:


 There's a project at dsource.org called Tioport, that tried to
 automated the process of port SWT to D. But the author gave up that
 project and started to manually port SWT instead. It turned out that
 you would need to port a large part of the Java standard library.


 Ahh, that's not awesome.


 That's strong point...Maybe I should, at least, try to compile it
 and check how it looks...


 I recommend you give it a try.


 It seems it needs dsss?


 No, it currently uses rake to build the project. Which means you need
 both ruby and rake to build DWT.


For various reason, it's actually easier to build DWT by just compiling 
the an application that uses DWT using rdmd or similar.

-- 
/Jacob Carlborg



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 18:27:01 +0100
Jacob Carlborg <doob me.com> wrote:


 For various reason, it's actually easier to build DWT by just
 compiling the an application that uses DWT using rdmd or similar.


Heh, but I don't have any. ;)


Sincerely,
Gour


--=20
One who restrains his senses, keeping them under full control,=20
and fixes his consciousness upon Me, is known as a man of=20
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 19:47, Gour wrote:

 On Tue, 29 Nov 2011 18:27:01 +0100
 Jacob Carlborg<doob me.com>  wrote:


 For various reason, it's actually easier to build DWT by just
 compiling the an application that uses DWT using rdmd or similar.


 Heh, but I don't have any. ;)


You can compile the snippets with this command:

"rake base swt snippets"

If I recall correctly. You can run "rake -T" to see what build targets 
are available. To build DWT you need these system libraries:

http://dsource.org/projects/dwt/wiki/ImportLibraries

-- 
/Jacob Carlborg



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 22:03:27 +0100
Jacob Carlborg <doob me.com> wrote:


 "rake base swt snippets"
=20
 If I recall correctly. You can run "rake -T" to see what build
 targets are available. To build DWT you need these system libraries:


No experience at all with Java/SWT...downloaded hg repo and tried:

[gour atmarama dwt2-c43718956f21] rake swt=20
/home/gour/tmp/dwt/dwt2-c43718956f21/rakefile:19: Use RbConfig instead of o=
bsolete and deprecated Config.
Building org.eclipse.swt.gtk.linux.x86
workdir=3D>/home/gour/tmp/dwt/dwt2-c43718956f21/org.eclipse.swt.gtk.linux.x=
86/src
org/eclipse/swt/internal/Compatibility.d(15): Error: module all is in file =
'java/lang/all.d' which cannot be read
import path[0] =3D /home/gour/tmp/dwt/dwt2-c43718956f21/org.eclipse.swt.gtk=
.linux.x86/src
import path[1] =3D /home/gour/tmp/dwt/dwt2-c43718956f21/imp
import path[2] =3D /usr/include/d
import path[3] =3D /usr/include/d/druntime/import
rake aborted!
compile error

Tasks: TOP =3D> swt
(See full trace by running task with --trace)


Any idea?


Sincerely,
Gour

--=20
The senses are so strong and impetuous, O Arjuna,=20
that they forcibly carry away the mind even of a man=20
of discrimination who is endeavoring to control them.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Dec 01 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-12-01 11:05, Gour wrote:

 On Tue, 29 Nov 2011 22:03:27 +0100
 Jacob Carlborg<doob me.com>  wrote:


 "rake base swt snippets"

 If I recall correctly. You can run "rake -T" to see what build
 targets are available. To build DWT you need these system libraries:


 No experience at all with Java/SWT...downloaded hg repo and tried:

 [gour atmarama dwt2-c43718956f21] rake swt
 /home/gour/tmp/dwt/dwt2-c43718956f21/rakefile:19: Use RbConfig instead of
obsolete and deprecated Config.
 Building org.eclipse.swt.gtk.linux.x86
 workdir=>/home/gour/tmp/dwt/dwt2-c43718956f21/org.eclipse.swt.gtk.linux.x86/src
 org/eclipse/swt/internal/Compatibility.d(15): Error: module all is in file
'java/lang/all.d' which cannot be read
 import path[0] = /home/gour/tmp/dwt/dwt2-c43718956f21/org.eclipse.swt.gtk.linux.x86/src
 import path[1] = /home/gour/tmp/dwt/dwt2-c43718956f21/imp
 import path[2] = /usr/include/d
 import path[3] = /usr/include/d/druntime/import
 rake aborted!
 compile error

 Tasks: TOP =>  swt
 (See full trace by running task with --trace)


 Any idea?


You need to build the "base" library as well, run "rake base swt". The 
"base" library contains a port of a small part of the Java core API's, 
this makes it easier to port SWT.

You can build the and try snippets as well.

-- 
/Jacob Carlborg



 Dec 01 2011



  parent reply Gour <gour atmarama.net>  writes:


On Thu, 01 Dec 2011 13:29:41 +0100
Jacob Carlborg <doob me.com> wrote:


 You need to build the "base" library as well, run "rake base swt".
 The "base" library contains a port of a small part of the Java core
 API's, this makes it easier to port SWT.


[gour atmarama dwt2-c43718956f21] rake base swt
/home/gour/tmp/dwt/dwt2-c43718956f21/rakefile:19: Use RbConfig instead of o=
bsolete and deprecated Config.
Building dwt-base
workdir=3D>/home/gour/tmp/dwt/dwt2-c43718956f21/base/src
java/nonstandard/RuntimeTraits.d(86): do-while statement requires terminati=
ng ;
rake aborted!
compile error

Tasks: TOP =3D> base
(See full trace by running task with --trace)


Sincerely,
Gour


--=20
Never was there a time when I did not exist,=20
nor you, nor all these kings; nor in the future=20
shall any of us cease to be.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Dec 01 2011



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2011-12-01 15:09, Gour wrote:

 On Thu, 01 Dec 2011 13:29:41 +0100
 Jacob Carlborg<doob me.com>  wrote:


 You need to build the "base" library as well, run "rake base swt".
 The "base" library contains a port of a small part of the Java core
 API's, this makes it easier to port SWT.


 [gour atmarama dwt2-c43718956f21] rake base swt
 /home/gour/tmp/dwt/dwt2-c43718956f21/rakefile:19: Use RbConfig instead of
obsolete and deprecated Config.
 Building dwt-base
 workdir=>/home/gour/tmp/dwt/dwt2-c43718956f21/base/src
 java/nonstandard/RuntimeTraits.d(86): do-while statement requires terminating ;
 rake aborted!
 compile error


Ok, apparently later versions of the compiler have become better and 
catches this miss.

-- 
/Jacob Carlborg



 Dec 01 2011



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 12/01/2011 04:45 PM, Jacob Carlborg wrote:

 On 2011-12-01 15:09, Gour wrote:

 On Thu, 01 Dec 2011 13:29:41 +0100
 Jacob Carlborg<doob me.com> wrote:


 You need to build the "base" library as well, run "rake base swt".
 The "base" library contains a port of a small part of the Java core
 API's, this makes it easier to port SWT.


 [gour atmarama dwt2-c43718956f21] rake base swt
 /home/gour/tmp/dwt/dwt2-c43718956f21/rakefile:19: Use RbConfig instead
 of obsolete and deprecated Config.
 Building dwt-base
 workdir=>/home/gour/tmp/dwt/dwt2-c43718956f21/base/src
 java/nonstandard/RuntimeTraits.d(86): do-while statement requires
 terminating ;
 rake aborted!
 compile error


 Ok, apparently later versions of the compiler have become better and
 catches this miss.


Blame me. :o)

https://github.com/D-Programming-Language/dmd/pull/372

It actually still will compile with the -d flag enabled. Or you could 
add the ';'.



 Dec 01 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-29 09:19, Gour wrote:

 I don't understand - if wxWidgets use native widgets on Windows, Linux
 and Mac OS X what can be bad then?


These multi-platform toolkits seems to be usually targeted to Windows or 
Linux and are often missing "widgets" that are only available on Mac OS 
X, like unified toolbars and dialog sheets.

-- 
/Jacob Carlborg



 Nov 29 2011



prev sibling  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 All four of those are well supported toolkits, _upstream_ that is.
 Either GUI should do the trick for writing a desktop application.


 Upstream was never meant as part of the problem which is on the D-side.
 :-)


True that. I suppose that part of the problem is that C++ doesn't link
with anything else, unless you bother to do an extern "C" interface ?


 But even if Phobos/Deimos would have something like Tk (or FLTK)
 integrated, it probably wouldn't be accepted as a real solution.


 Right.


 That is, just for being too ugly or too grey or something similar.


 Or too light perhaps. ;)


That part I'm not so sure about, both toolkits have tons of widgets.
At least when compared to something homegrown and language-specific ?


 Now, why would you want to use D as your language(s) rather than
 C, Python, Java ? Or even C++. That was the real question for me.


 Because I want to work on open-source project in my spare time and that
 should have some component of 'fun'...C&  C++ are not falling into that
 category, I don't know nor like Java, not inspired about Lisp-languages,
 Haskell is too-theoretical...which leaves me with the Python, but I find
 D as sweet spot between scripting languages&  C(++). Moreover, it will
 be bigger project which would need longer maintainance and we believe
 that although D is not maybe completely ready today, it will be soon
 enough, so we can start working by writing non-GUI libs for the project.


Right. I guess some of that sweetness faded with moving to D1/Tango
and then to D2/Phobos. Or when the GDC project needed more maintenance.

Both problems were fixable (and fixed), just added to the resistance.
And if there's too much effort in practice, then it stops being fun...

But I think that the effort _was_ successful, there was an open source
DMD (GDC), GUI (wxWidgets) and IDE (Code::Blocks) released for D(1) ?

Something more is needed, but what it would be and what it will look
like I don't know. Probably something more close to the new language.


 There has to be enough advantages to overcome the shortcomings,
 which in the end wasn't true when making desktop apps (or games).


 "De gustibus non est disputandum..."


Or maybe it just doesn't have the same shine that it did, 5 years ago.

--anders



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 09:01:30 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 True that. I suppose that part of the problem is that C++ doesn't link
 with anything else, unless you bother to do an extern "C" interface ?


Whatever...


 Or too light perhaps. ;)


=20
 That part I'm not so sure about, both toolkits have tons of widgets.
 At least when compared to something homegrown and language-specific ?


Tk is, well, ugly. Otoh, FOX is C++ with, iirc, Windows-like non-native
look, so what is its advantage over e.g. GTK+?


 Right. I guess some of that sweetness faded with moving to D1/Tango
 and then to D2/Phobos. Or when the GDC project needed more
 maintenance.


Fortunately, I don't have experience with D1 --> D2 issue.


 Something more is needed, but what it would be and what it will look
 like I don't know. Probably something more close to the new language.


Some more organization and collective effort. DMD/Phobos looks OK now.


 Probably something more close to the new language.


I bet it's too early for that. D community cannot even properly
maintaint bindings, what to speak of native GUI lib.

However, having, at least, one bindings with higher-level D-ish API
would be very welcome.


 Or maybe it just doesn't have the same shine that it did, 5 years ago.


What?


Sincerely,
Gour


--=20
A person who has given up all desires for sense gratification,=20
who lives free from desires, who has given up all sense of=20
proprietorship and is devoid of false ego =E2=80=94 he alone can=20
attain real peace.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 Something more is needed, but what it would be and what it will look
 like I don't know. Probably something more close to the new language.


 Some more organization and collective effort. DMD/Phobos looks OK now.


I'm sticking with the original business plan:
1. Move to github.com
2. ?
3. Profit!


 Probably something more close to the new language.


 I bet it's too early for that. D community cannot even properly
 maintaint bindings, what to speak of native GUI lib.

 However, having, at least, one bindings with higher-level D-ish API
 would be very welcome.


I think the original plan was to build that on top of something.

So you have a straight porting of some general API, and then
another layer on top of that with a more highlevel approach ?

But using all those wrappers-on-wrappers do get a bit "oniony".


 Or maybe it just doesn't have the same shine that it did, 5 years ago.


 What?


Using a new shiny language, tends to naturally fade after a while.

--anders



 Nov 29 2011



  parent  Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 09:34:27 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 I'm sticking with the original business plan:
 1. Move to github.com
 2. ?
 3. Profit!


It's a bit puzzling, but I won't beat it further.=20


 I think the original plan was to build that on top of something.
=20
 So you have a straight porting of some general API, and then
 another layer on top of that with a more highlevel approach ?


Yes, that's logical approach if one approaches from higher-level
language, otherwise, just having a wrapper over C(++) is loss.

That's what I likes in gtk2hs & wxhaskell bindings.


 But using all those wrappers-on-wrappers do get a bit "oniony".


gtk2hs provides direct higher-level API.


 Using a new shiny language, tends to naturally fade after a while.


Ahh...That's probably the main problem then since "When there is a will,
there is a way."

I spent sufficient time with Haskell that I can appreciate D's blend of
functionality with its elegance and higher-level features, but we need
some spark of functionality as well in the form of GUI, databases etc.


Sincerely,
Gour


--=20
But a person free from all attachment and aversion and able=20
to control his senses through regulative principles of=20
freedom can obtain the complete mercy of the Lord.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



prev sibling next sibling parent reply Gerrit Wichert <gwichert yahoo.com>  writes:


 So, is wxD going to continue like now, or do you envision some change
 how to proceed for wx-2.9/3.=?


 I don't plan to do anything with it, I put it up on github so that it
 could be forked and maintained if there are any bugfixes etc needed...


So if i understand you right, the way to keep wxD alive ist to fork your 
repository
and continue it as an independent project ?



 Nov 28 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gerrit Wichert wrote:

 So, is wxD going to continue like now, or do you envision some change
 how to proceed for wx-2.9/3.=?


 I don't plan to do anything with it, I put it up on github so that it
 could be forked and maintained if there are any bugfixes etc needed...


 So if i understand you right, the way to keep wxD alive ist to fork your
 repository
 and continue it as an independent project ?


The way to keep the project alive was to contribute to SourceForge,
moving the repository to github is to connect with the D community.

Either way, to keep it alive you just need to use it. By using git,
it doesn't matter to which repository the commits are actually done.

--anders



 Nov 28 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 07:56:34 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 The way to keep the project alive was to contribute to SourceForge,
 moving the repository to github is to connect with the D community.


Have you read http://zbowling.github.com/blog/2011/11/25/github/ ?

Github & forks are not panacea if there are not people ready to work
together on the project.

Moreover, your announcement to step down set the tone for the project...


Sincerely,
Gour

--=20



 Nov 29 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 The way to keep the project alive was to contribute to SourceForge,
 moving the repository to github is to connect with the D community.


 Have you read http://zbowling.github.com/blog/2011/11/25/github/ ?

 Github&  forks are not panacea if there are not people ready to work
 together on the project.


Apparently CVS was getting in the way. I was fine with either myself.

Main repo is at http://sourceforge.net/scm/?type=git&group_id=133831


 Moreover, your announcement to step down set the tone for the project...


It's been drifting for a year, I don't think there's any announcement.

All I said was that I don't have the energy to start over with wx3/D2.
The project should be fine for wxWidgets 2.8.12, maybe I just didn't
emphasize that fact enough. It even "works" with 2.9.2 and DMD 2.054,
although not using any of the newer features. That's not too shabby ?

It's been 5 years. http://www.algonet.se/~afb/wx/wxWidgets-Minimal.html

--anders



 Nov 29 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 09:54:40 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 It's been drifting for a year, I don't think there's any announcement.


Well, on 26th of August you wrote: "I am also stepping down as a
maintainer, including the pre-built GDC distribution
(gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D." and after
being questioned by Andrej: "Do you mean you're stepping down as the
maintainer of wxd, or just the GDC/CodeBlocks stuff?" your answer was:
"All three. Mostly wxD, but also the others - not using." and your firt
message cited above when all this wxD-thingie has started for me. :-)


 All I said was that I don't have the energy to start over with wx3/D2.


I understand you.


 The project should be fine for wxWidgets 2.8.12, maybe I just didn't
 emphasize that fact enough. It even "works" with 2.9.2 and DMD 2.054,
 although not using any of the newer features. That's not too shabby ?


Not at all, but considering wx-3.0 is the future, the project is stalled
at the moment.


 It's been 5 years.
 http://www.algonet.se/~afb/wx/wxWidgets-Minimal.html


Congratulations!

I was not aware you took care so long for the project. Too bad I was not
around earlier since for me it does not make sense to start developing
wxD application now with 2.8.x.

So, I can only say: "Thank you" for pushing so long alone without proper
support of other members within D community.

Let's hope there will be more interest for GUI in D in the future if D
wants to sell itself on 'practicality' ("D is a multi-paradigm
programming language that combines a principled approach with a focus on
practi=C2=ADcality.")


Sincerely,
Gour


--=20
=46rom anger, complete delusion arises, and from delusion=20
bewilderment of memory. When memory is bewildered,=20
intelligence is lost, and when intelligence is lost=20
one falls down again into the material pool.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 It's been drifting for a year, I don't think there's any announcement.


 Well, on 26th of August you wrote: "I am also stepping down as a
 maintainer, including the pre-built GDC distribution
 (gdcwin/gdcgnu/gdcmac) and the Code::Blocks support for D." and after
 being questioned by Andrej: "Do you mean you're stepping down as the
 maintainer of wxd, or just the GDC/CodeBlocks stuff?" your answer was:
 "All three. Mostly wxD, but also the others - not using." and your firt
 message cited above when all this wxD-thingie has started for me. :-)


Ah, right :-)

I do think it would make more sense if it was maintained by someone
actually using the software on a daily basis, but if nobody steps up
I suppose it could also be left (in the current state) for a while ?
Either would be fine: starting over with SWIG, or keeping Status Quo.


 All I said was that I don't have the energy to start over with wx3/D2.


 I understand you.


 The project should be fine for wxWidgets 2.8.12, maybe I just didn't
 emphasize that fact enough. It even "works" with 2.9.2 and DMD 2.054,
 although not using any of the newer features. That's not too shabby ?


 Not at all, but considering wx-3.0 is the future, the project is stalled
 at the moment.


Right, I guess it's "in maintenance" (without ever leaving Alpha stage).

If the 3.0 release would include a C version, that would change things
since that would mean that some of the SWIG code could be shared with

Currently each extra language has their own set of SWIG interface files.

--anders



 Nov 29 2011



  parent  Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 12:09:02 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 I do think it would make more sense if it was maintained by someone
 actually using the software on a daily basis, but if nobody steps up
 I suppose it could also be left (in the current state) for a while ?


It can even stay eternally so. :-)


 Either would be fine: starting over with SWIG, or keeping Status Quo.


My vote is for former...klickverbot told me that SWIG cannot handle Qz
by itself since it is too complex beast, but wx is possible.


 If the 3.0 release would include a C version, that would change things
 since that would mean that some of the SWIG code could be shared with

 Ruby). Currently each extra language has their own set of SWIG
 interface files.


I'll ask in wxwidgets if there is plan for something like that.


Sincerely,
Gour


--=20
As a strong wind sweeps away a boat on the water,=20
even one of the roaming senses on which the mind=20
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 29 2011



prev sibling  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Honestly I can't even get a simple SWIG project working (the demo from
klickverbot's announcement on his blog). Apparently there's some
const-related issues.

Building the examples that come with swig windows binary doesn't work,
tried it via mingw32-make and via MSYS. Apparently there's a missing
"Makefile" in the root dir. Building SWIG from source doesn't work on
Windows anymore either. ("Swig/misc.c:1119:18: fatal error: pcre.h: No
such file or directory"). So you have a project that is only
maintained on some platforms. (this is the swig-2.0.4 release).

Funnily enough the SVN version from a year ago worked perfectly, but
now an official release doesn't work.

The question is, what if you end up finding a bug in the generated
code? Worst case scenario - you have to fix SWIG itself.

Btw, Johannes Pfau wrapped most of TagLib with SWIG and said the
wrapping process was frustrating.

I quite like the 'wxc' wrapper library, if you screw something up it
doesn't look like too much work to fix it. Obviously you have to write
everything by hand, so it's repetitive work. But at least you get a
readable codebase + you get to statically link with the library.



 Nov 28 2011



  parent reply Gour <gour atmarama.net>  writes:


On Tue, 29 Nov 2011 00:53:20 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:


 Honestly I can't even get a simple SWIG project working (the demo from
 klickverbot's announcement on his blog). Apparently there's some
 const-related issues.


Hmm...have you reported the issue to klickverbot?


 Building the examples that come with swig windows binary doesn't work,
 tried it via mingw32-make and via MSYS. Apparently there's a missing
 "Makefile" in the root dir. Building SWIG from source doesn't work on
 Windows anymore either. ("Swig/misc.c:1119:18: fatal error: pcre.h: No
 such file or directory").=20


Have you submitted report to SWIG devs?


 So you have a project that is only maintained on some platforms. (this
 is the swig-2.0.4 release).


I'll install dev env on my Windows under vbox to check it out.


 The question is, what if you end up finding a bug in the generated
 code? Worst case scenario - you have to fix SWIG itself.


What's the difference if you find bug in DMD?


 Btw, Johannes Pfau wrapped most of TagLib with SWIG and said the
 wrapping process was frustrating.


Well, I'd like to hear more about his experiences...Which version of
SWIG he used?

Otoh, is there better tool for providing bindings which can automate
(some of) the work?


 I quite like the 'wxc' wrapper library, if you screw something up it
 doesn't look like too much work to fix it. Obviously you have to write
 everything by hand, so it's repetitive work.=20


wxC also has to be maintained...As I wrote in another thread, it would
be nice to have stable wxC project so that all language bindings can
profit  from it.


 But at least you get a
 readable codebase + you get to statically link with the library.


Let's hope something will change in regard to the linking process.

At the end, the purpose of my posting was to find out what's the status
of current GUI-bindings-related projects in terms of current &
near-future support, so, this is something which one has to take into
consideration despite of upstream status which is OK for the main 3
toolkits (somehow, I do not count much on SWT/DWT.)

Moreover, although wxWidgets has some advantage over the other two related
to offering native look, seeing there is not much initiative to push wxD
forward in the short-term, this thread is closed for me (except if I
don't get signal that using wxWidgets is optimal toolkit for our use in
the *longer-term*.)

Thank you to all for your input.


Sincerely,
Gour


--=20
You have a right to perform your prescribed duty,=20
but you are not entitled to the fruits of action.=20
Never consider yourself the cause of the results=20
of your activities, and never be attached to not doing your duty.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 28 2011



  parent  Johannes Pfau <spam example.com>  writes:


Gour wrote:

 Btw, Johannes Pfau wrapped most of TagLib with SWIG and said the
 wrapping process was frustrating.


Well, I'd like to hear more about his experiences...Which version of
SWIG he used?


I think the last version I used was a svn snapshot after the 2.0.2
release. It's not that using swig was especially frustrating, but the
TagLib C++ API offers little over the much simpler C API. So I thought
wrapping the complete C++ API just wasn't worth it.

Some problems I had with swig:

As I was new to swig I had no idea how to organize a big project
consisting of multiple C++ headers. There are questions like include
vs. import; simply editing the C++ headers vs. including the headers and
placing rename directives etc. into own files; how to organize the
project, so that changes to the c++ library can be merged easily...

The swig manual is *huge* and works well as a reference, but a simple
introduction tutorial doesn't exist AFAIK.

It took me some time to get template instances working, somehow I
didn't understand the syntax or whatever.

And there are some 'cosmetic issues' that don't matter for
functionality, but I found these to be annoying:
* IIRC free functions or variables/properties always go into the main
  file and it's not possible to place those into a specific namespace
* I think it's the same for template instances and hand written code,
  but I'm not sure
* Namespace duplication: Namespaces look like this: "TagLib.APE.APE".
  This is needed to support some corner cases where C++
  namespaces wouldn't map well to D namespaces otherwise. But
  for simple namespaces I'd like to have proper namespaces
  ("TagLib.APE")
* swig always generates a main module, and IIRC it even has to be a
  toplevel module (TagLibBase, not TagLib.Base). And as D doesn't allow
  packages and modules to have the same name, it wasn't possible to
  simply name this main module "TagLib", so I named it "TagLibD"
  instead. But this still sucks, as your namespaces then look like this:

TagLibD
TagLib.TagLib
TagLib.APE.APE
TagLib.ID3v2.ID3v2

Having two different toplevel namespaces especially annoyed me.

However, I'd nevertheless say swig is the best solution to wrap a C++
project unless there's a manually written, well supported C API.

Also, in case you're interested, the source for that TagLib swig
wrapper is here:
https://github.com/jpf91/TagLibD/

-- 
Johannes Pfau



 Nov 29 2011



prev sibling next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


How do I build wx28 in release mode? I've tried BUILD=release but that
didn't help.

The issue I'm having is that Optlink can't link due to a >64k global
symbols error.



 Dec 02 2011



prev sibling next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


ulink works fine though. It's great that I have to rely on third-party
linkers like that. -_-

Anders, if I want to edit the wxc bindings to add wx28+ support do I
have to wrap new functions in #ifdef sections to preserve wx26
support? Or should I just disregard wx26 alltogether and leave that as
an old branch?



 Dec 02 2011



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


I just tried wrapping some new functions and they seem to work. I
think if wx28 isn't too different from wx26 I could do a diff of the
two include directories and implement wxc wrapper functions to get
wx28 support in wxd.



 Dec 02 2011



prev sibling next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


I'm just a little confused about that wxWindows license. So basically,
if I release my sources then they have to be GPL, but if I don't then
I can distribute only the binaries freely? IOW, I can't license my
sources with Boost or similar if I use wxd?



 Nov 24 2011



prev sibling next sibling parent  Brad Anderson <eco gnuk.net>  writes:


On Thu, Nov 24, 2011 at 9:52 PM, Andrej Mitrovic <andrej.mitrovich gmail.com

 wrote:



 I'm just a little confused about that wxWindows license. So basically,
 if I release my sources then they have to be GPL, but if I don't then
 I can distribute only the binaries freely? IOW, I can't license my
 sources with Boost or similar if I use wxd?


It's just LGPL unless you are writing something closed source, then you are
free to distribute on your own terms.  Kind of a weird license but not too
complicated if you already know how to work with LGPL libraries.



 Nov 24 2011



prev sibling  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Walter Bright wrote:

 Now that DMD has broken the ABI on x86_64,


 ??


... compared with GDC, that was.

Think we discussed this earlier, it's about the
passing of structs as parameters compared with C++.

The code is passing a D "string" to the C++ side,
and then interpreting this C argument as a struct:

/// length-prefixed string in UTF-8 format
struct dstr {
	size_t          length;
	const char*     data;
};

This only works in 32-bit code, and not in 64-bit.
Need to use two separate .length and .ptr pairs.


It should probably pass around wxString() objects
instead, even if that's slightly less convenient...

So instead of:

         static extern (C) void   wxApp_SetAppName(IntPtr self, string 
name);
         static extern (C) IntPtr wxApp_GetAppName(IntPtr self);

         public string AppName() { return cast(string) new 
wxString(wxApp_GetAppName(wxobj), true); }
         public void AppName(string name) { wxApp_SetAppName(wxobj, name); }

It should do:

         static extern (C) void   wxApp_SetAppName(IntPtr self, IntPtr 
name);
         static extern (C) IntPtr wxApp_GetAppName(IntPtr self);

         public wxString AppName() { return wxApp_GetAppName(wxobj); }
         public void AppName(wxString name) { wxApp_SetAppName(wxobj, 
name); }

Then it will be more explicit *when* strings are created,
especially if any UTF conversion needs to be done by it.

--anders



 Nov 25 2011



prev sibling next sibling parent reply Brad Anderson <eco gnuk.net>  writes:


On Wed, Nov 23, 2011 at 10:19 AM, Andrej Mitrovic <
andrej.mitrovich gmail.com> wrote:


 You'll have to ask Anders that.

 I'm guessing what needs to be done is to update the wxc wrapper, and


 I've heard something about wx3.0 being in plans, if it's a significant
 change from the 2.x series then maybe it would be a good idea to wait
 for that release before attempting to update the wrappers.


2.9 is very close to what 3.0 will be (it is the development version for
the 3.0 release).  All the major changes are done.  It'd be fine to work
against 2.9 in anticipation of 3.0 support.

Regards,
Brad Anderson



 Nov 23 2011



  parent  Gour <gour atmarama.net>  writes:


On Wed, 23 Nov 2011 11:14:46 -0700
Brad Anderson <eco gnuk.net> wrote:


 2.9 is very close to what 3.0 will be (it is the development version
 for the 3.0 release).  All the major changes are done.  It'd be fine
 to work against 2.9 in anticipation of 3.0 support.


+1

Btw, on wxwidgets list I've heard about "C target language
backend" and asked on swig list about its status...

See http://swig.svn.sourceforge.net/viewvc/swig/branches/gsoc2008-maciekd/D=
oc/Manual/C.html


Sincerely,
Gour


--=20
One who is able to withdraw his senses from sense objects,=20
as the tortoise draws its limbs within the shell,=20
is firmly fixed in perfect consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 23 2011



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Sam Hu wrote:

 May I ask which version of wxWidget,2.8.12 or 2.9.?  ?Thanks.


 For windows, it's:
 http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.6.4.zip

 Find this string: "1. wxWidgets" here: http://wxd.sourceforge.net/
 and follow the instructions for step 1 (DM), or if you're on Linux
 then I guess GCC. Compiling takes a while..

 Then get the repo from github and run 'make' in the wxd directory.
 After a while, you can browse to 'samples' and run 'make'.

 The samples were recently updated to work with both D1 and D2.


 Thank you so much for the prompt response!Just wondering is there any special
reason that wx2.8.* or wx2.9.* could not be supported?


Both wxWidgets 2.8 and 2.9 are supported, just that the API
was originally exported from wx 2.6.4 so that's the lowest
denominator and starting point, while 2.8.12 is the "stable".

In 2011 (with 0.16), the code was updated to work with wx 2.9
and dmd 2.054 - in addition to previous wx 2.8 and dmd 1.030
(it "should" still work with wx 2.6 and dmd 1.020 too, afaik)

If no other concerns, then pick 2.8.12 (the "Current Stable")
Supporting 2.6 was mostly for DMC, and 2.9 was mostly for Cocoa.


Maybe one would want to regenerate the D API for wxWidgets 3.0,
but should work fine without - similar to "WXWIN_COMPATIBILITY_*"

i.e. currently exported API:
http://wxd.sourceforge.net/wxWidgets-2.6.4/docs/html/wx/wx_classref.html

vs. the latest available API:
http://docs.wxwidgets.org/trunk/page_class_cat.html (from the svn trunk)

--anders



 Nov 24 2011



 next sibling parent reply Gour <gour atmarama.net>  writes:


On Thu, 24 Nov 2011 12:01:46 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 Maybe one would want to regenerate the D API for wxWidgets 3.0,
 but should work fine without - similar to "WXWIN_COMPATIBILITY_*"


I'm reading SWIG docs and there is says: "...SWIG is quite capable in
supporting most of C++. Some of the major features include:

* Full C99 preprocessing.
* All ANSI C and C++ datatypes.
* Functions, variables, and constants.
* Classes.
* Single and multiple inheritance.
* Overloaded functions and methods.
* Overloaded operators.
* C++ templates (including member templates, specialization, and partial sp=
ecialization).
* Namespaces.
* Variable length arguments.
* C++ smart pointers.=20

Currently, the only major C++ feature not supported is nested classes--a
limitation that should be removed in a future release, but has some
workarounds for the moment.

It is important to stress that SWIG is not a simplistic C++ lexing tool
like several apparently similar wrapper generation tools. SWIG not only
parses C++, it implements the full C++ type system and it is able to
understand C++ semantics. SWIG generates its wrappers with full
knowledge of this information. As a result, you will find SWIG to be
just as capable of dealing with nasty corner cases as it is in wrapping
simple C++ code. In fact, SWIG is able handle C++ code that stresses the
very limits of many C++ compilers."

What do you think about providing wxWidgets 3.0 API using SWIG?

I've asked for opinion Robin who is doing wxpython and has plenty of
experience with both wx & SWIG...waiting for his reply.


Sincerely,
Gour


--=20
As a strong wind sweeps away a boat on the water,=20
even one of the roaming senses on which the mind=20
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 24 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 What do you think about providing wxWidgets 3.0 API using SWIG?


http://xkcd.com/224/


 I've asked for opinion Robin who is doing wxpython and has plenty of
 experience with both wx&  SWIG...waiting for his reply.


Sounds like a good idea, though you probably want to use SWIG 2.0
for the improved D support - while wxPython uses SWIG 1.3 afaict ?

I would drop support for wxWidgets 2.x and DMD 1.x - and go for
wxWidgets 2.9.x and DMD 2.0xx directly. And pick one "make" (GNU).

Trying to support two languages, two libraries, two+ compilers,
two+ buildtools, and so on, was just no fun and not very workable ?

It's easier to just use configure+make, and MSYS/MinGW on Windows,
than trying to work with the DOS console (in C++) or DM's Make.exe.

--anders



 Nov 24 2011



  parent reply Gour <gour atmarama.net>  writes:


On Thu, 24 Nov 2011 13:55:23 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 http://xkcd.com/224/


LOL.


 Sounds like a good idea, though you probably want to use SWIG 2.0
 for the improved D support - while wxPython uses SWIG 1.3 afaict ?


I do not know about wxPython, but, yes, SWIG 2.0 which has support for
D.


 I would drop support for wxWidgets 2.x and DMD 1.x - and go for
 wxWidgets 2.9.x and DMD 2.0xx directly.=20


I fully agree,


 And pick one "make" (GNU).


That's not fully clear to me.


 Trying to support two languages, two libraries, two+ compilers,
 two+ buildtools, and so on, was just no fun and not very workable ?


Can you explain what do you think?


 It's easier to just use configure+make, and MSYS/MinGW on Windows,
 than trying to work with the DOS console (in C++) or DM's Make.exe.


I'm also thinking about cmake and will try to help Jens to prepare
cmaked2 to be included in the upstream.

Cmake is not the most elegant tool, but it works and I got confirmation
that it supports dmd & gdc.

What do you think?


Sincerely,
Gour


--=20
As a strong wind sweeps away a boat on the water,=20
even one of the roaming senses on which the mind=20
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Nov 24 2011



  parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Gour wrote:

 And pick one "make" (GNU).


 That's not fully clear to me.


Instead of doing separate GNUmakefile and Makefile, and synching those ?

There was even a build.brf and dsss.conf, while those were in fashion...


 Trying to support two languages, two libraries, two+ compilers,
 two+ buildtools, and so on, was just no fun and not very workable ?


 Can you explain what do you think?


Drop D1, drop Tango, and make DMD the default compiler syntax
(possibly using gdmd or ldmd behind the covers, where desired)

Then do a standard build system, the suggestion was GNU make
and GNU bash - rather than trying to cope with several systems.


 Cmake is not the most elegant tool, but it works and I got confirmation
 that it supports dmd&  gdc.

 What do you think?


It would just generate a Makefile anyway ? But if it could
generate the IDE projects, then maybe it's worth pursuing...

If one used standard make and shell, then one could use the
standard "wx-config" and friends and just be done with it:

http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html

--anders



 Nov 25 2011



  parent  Gour <gour atmarama.net>  writes:


On Fri, 25 Nov 2011 11:24:02 +0100
Anders F Bj=C3=B6rklund <afb algonet.se> wrote:


 Drop D1, drop Tango, and make DMD the default compiler syntax
 (possibly using gdmd or ldmd behind the covers, where desired)


+1


 It would just generate a Makefile anyway ? But if it could
 generate the IDE projects, then maybe it's worth pursuing...


Here is the list of gnerators available in cmake:

Borland Makefiles
MSYS Makefiles
MinGW Makefiles
NMake Makefiles
Unix Makefiles
Visual Studio 6
Visual Studio 7
Visual Studio 7 .NET 2003
Visual Studio 8 2005
Visual Studio 8 2005 Win64
Visual Studio 9 2008
Visual Studio 9 2008 Win64
Watcom WMake
CodeBlocks - MinGW Makefiles
CodeBlocks - Unix Makefiles
Eclipse CDT4 - MinGW Makefiles
Eclipse CDT4 - NMake Makefiles
Eclipse CDT4 - Unix Makefiles

check: http://www.cmake.org/cmake/help/cmake2.6docs.html#section_Generators


btw, I'm going to help Jens to push cmake2d upstream to be included in the
official release.


Sincerely,
Gour

--=20



 Nov 25 2011



prev sibling  parent  Sam Hu <samhudotsamhu gmail.com>  writes:


Anders F Björklund Wrote:


 Sam Hu wrote:

 May I ask which version of wxWidget,2.8.12 or 2.9.?  ?Thanks.


 For windows, it's:
 http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.6.4.zip

 Find this string: "1. wxWidgets" here: http://wxd.sourceforge.net/
 and follow the instructions for step 1 (DM), or if you're on Linux
 then I guess GCC. Compiling takes a while..

 Then get the repo from github and run 'make' in the wxd directory.
 After a while, you can browse to 'samples' and run 'make'.

 The samples were recently updated to work with both D1 and D2.


 Thank you so much for the prompt response!Just wondering is there any special
reason that wx2.8.* or wx2.9.* could not be supported?


 
 Both wxWidgets 2.8 and 2.9 are supported, just that the API
 was originally exported from wx 2.6.4 so that's the lowest
 denominator and starting point, while 2.8.12 is the "stable".
 
 In 2011 (with 0.16), the code was updated to work with wx 2.9
 and dmd 2.054 - in addition to previous wx 2.8 and dmd 1.030
 (it "should" still work with wx 2.6 and dmd 1.020 too, afaik)
 
 If no other concerns, then pick 2.8.12 (the "Current Stable")
 Supporting 2.6 was mostly for DMC, and 2.9 was mostly for Cocoa.
 
 
 Maybe one would want to regenerate the D API for wxWidgets 3.0,
 but should work fine without - similar to "WXWIN_COMPATIBILITY_*"
 
 i.e. currently exported API:
 http://wxd.sourceforge.net/wxWidgets-2.6.4/docs/html/wx/wx_classref.html
 
 vs. the latest available API:
 http://docs.wxwidgets.org/trunk/page_class_cat.html (from the svn trunk)
 
 --anders


Glad to hear that wx2.8 and wx2.9 are both supported.
GUI library in D(2) like DFL,DWT,gtkD and QtD all these I have tried to build
turns out it is not so difficult.However wxD is the one I never ever build
successfully under windows,yes,maybe this is not so difficult to others here.
It would be grateful for someone to write a step by step guideline for build
wxD under different platform,the one I would like see is dmd2.056/dmc/mingw
under windows with wx2.9.3 as it has wxWebView.It would be nice as well if
somebody would like to share his build package.With 7-zip I think it won't be
too big to transfer on the web.

Regards,
Sam



 Nov 24 2011