DBloke wrote:
> SDL and OpenGL could be a useful starting platform...

#1) SDL can not support multiple windows

#2) Every time you resize an SDL window the OpenGL context is destroyed on Windows (but not on linux), which means that for each window resize you need to reload opengl and all its textures.

clayasaurus wrote:

> #1) SDL can not support multiple windows
> 
> #2) Every time you resize an SDL window the OpenGL context is destroyed on Windows (but not on linux), which means that for each window resize you need to reload opengl and all its textures.

Ouch, to both of them!

Maybe it's just suitable for fullscreen game-like interfaces then.
Which, accidently, was where I was using it (without problems) :-)


Anyway, it would still mean lots of work to implement say a "tree
control" or an "open file dialog" etc. etc. with such a UI system ?

And that's not even going into things like Grids or HTML panes.
Or all the other widgets that you need when doing applications...

And then there is the lack of editors and documentation, and so on.

--anders

Anders F Björklund wrote:
<snip>

> I think there was Shawn working on DWT/Windows, JJR working on DWT/GTK
> (Linux) and Carlos working on DWT/Carbon (Mac OS X) in the beginning...
> 
> But I think the start of this thread was because the DWT/Win development
> is not making progress and I think the other platforms are stopped too ?
> 
> At least that's how the DWT forum posting sounds:
> http://www.dsource.org/forums/viewtopic.php?t=1169
> 

It's accurate to say that I've done little with the DWT linux port. There's been a lot of debate this way and that, and I've just lost the will to progress on it alone.

If the community can come up with a decision on this, where more people are willing to support and contribute to a GUI project, whatever it may be, I will be very willing to lend a hand to the best of my ability.

That said, I've been guilty of helping out more with DUIT than with DWT, probably mostly because Ant's been so active with it and a couple others were lending him a hand.

<snip>

> 
> I will await what the community comes up with for a new official project
> and/or restart of the DWT project, and just continue with wxD meanwhile.
> 
> GDC and wxD are the ones closest matching to what *I* want out of D, but
> for others then the official two: DMD and DWT, might be a better match ?
> 
> --anders


I'm interested to see where people want to go as well. Meanwhile, lightweight projects like Harmonia, that have active development and interest, probably wouldn't be exceedinly hard to port to different platfroms.

Interestingly, despite having so many people say they are interested in DWT,  ports of the GUI Framework have garnered very little support.

-JJR

John Reimer wrote:
> Anders F Björklund wrote:
> <snip>
> 
>> I think there was Shawn working on DWT/Windows, JJR working on DWT/GTK
>> (Linux) and Carlos working on DWT/Carbon (Mac OS X) in the beginning...
>>
>> But I think the start of this thread was because the DWT/Win development
>> is not making progress and I think the other platforms are stopped too ?
>>
>> At least that's how the DWT forum posting sounds:
>> http://www.dsource.org/forums/viewtopic.php?t=1169
>>
> 
> It's accurate to say that I've done little with the DWT linux port. There's been a lot of debate this way and that, and I've just lost the will to progress on it alone.
> 
> If the community can come up with a decision on this, where more people are willing to support and contribute to a GUI project, whatever it may be, I will be very willing to lend a hand to the best of my ability.
> 
> That said, I've been guilty of helping out more with DUIT than with DWT, probably mostly because Ant's been so active with it and a couple others were lending him a hand.
> 
> <snip>
> 
>>
>> I will await what the community comes up with for a new official project
>> and/or restart of the DWT project, and just continue with wxD meanwhile.
>>
>> GDC and wxD are the ones closest matching to what *I* want out of D, but
>> for others then the official two: DMD and DWT, might be a better match ?
>>
>> --anders
> 
> 
> I'm interested to see where people want to go as well. Meanwhile, lightweight projects like Harmonia, that have active development and interest, probably wouldn't be exceedinly hard to port to different platfroms.
> 
> Interestingly, despite having so many people say they are interested in DWT,  ports of the GUI Framework have garnered very little support.
> 
> -JJR

Who is interested in DWT? I know I am not one.

pragma wrote:
> In article <e257hp$bsn$1@digitaldaemon.com>, DBloke says...
>>> Another possibility is basing a framework on some portable ground, like for instance SDL or OpenGL. But it wouldn't feel very "native", then ?
>>>
>>> --anders
>> This is something that would need to be agreed, do we want Native or X Platform?
>>
>> Either choice would require significant effort IMHO, and require that all different platforms be synced to maintain consistency if D goes the X Platform route.
>>
>> D is X Platform so perhaps D's GUI should be also?
>>
>> SDL and OpenGL could be a useful starting platform, and D's GUI Framework could leverage a lot of low level code from the two platforms, and a bonus that it is written in C so will be easier to interface to in theory and X Platform.
>>
> 
> $0.02:
> As much as I like the idea of using something that is guaranteed to exist on all
> platforms (GL), there comes a rather stiff price for backing a raw graphics
> library.  Most notably is the fact that any such development effort would have
> to build its own rendering and event model from the ground up.  Also, meshing
> with the OS's native capabilities, like cut-and-paste, would prove troublesome.
> 
> Beyond that, it's the one approach that yields the most advantages.
> Applications would be guaranteed to behave *and* look the same on all platforms;
> kind of like Swing.  Rendering and compositing would take advantage of hardware
> where possible, so it'll likely be very fast if not efficent.  You get 3D
> rendering for free, so it could double as a multimedia/gaming lib as well.
> Skinnable interfaces, and paradigm bending concepts also become very possible -
> the kind of stuff that makes X11 look like a tasteless joke.
> 
> So all in all, backing GL is the most ambitious path, but probably the one that
> would yield the most promise.
> 
> I'll add that there seems to be an industry-wide paradigm shift that points
> squarely at using GL for rendering the humble GUI.  From what I understand, OSX
> already does this, and Linux is well on its way.  Windows GDI is a bloated
> dinosaur, and I would not be suprised if MS did away with it in Vista (or at
> least promoted a new model that is closer to the hardware while keeping GDI for
> compatibility's sake). So for once, we'd be planning ahead.  
> 
> In light of all that, I reckon that a GL based D windowing lib would prove
> easier to back-port to a native toolkit once this paradigm shift is in full
> swing - provided that's even necessary.  After all, all three major operating
> systems come with some kind of 3D or GL support out of the box already, right?
> 
> - EricAnderton at yahoo
> 
> PS, you could back DWT, Minwin, DUIT, etc on such a lib if you wanted to.

Terra is well on the way in this vein, you should check it out.

DBloke wrote:

> Hi,
> 
> The D community seems to be divided regarding a GUI/Framework for D.
> I guess the community needs to decide exactly what it would like from a
> GUI/Framework.
> 
> Are we looking for
> Portability to multiple platforms?
> 
...
> 
> DBloke

-- 
Work in progress

From my personal perspective, it needs to work well on my personal system, which runs Linux.  It also needs to be easy to set up (or come with the compiler), because I'm not *committed* to D.  I just want to get my project done, and D would be a nice tool.

In the longer term, I would also want the GUI to work on the Mac.  I'm indifferent to MSWind, but I'm fairly certain that it would happen if it were at all feasible, so that doesn't need much thought.

Better to start with a simple framework that can later be expanded, and get it working WELL.  (Simple means being able to do dialog boxes.  Ability to use input from a GUI builder, like glade, or SpecTCL would be a real plus, no question, but is LESS necessary that having a solid system.)

For my personal interest, I would like an enhanced version to be able to draw on canvases, display pictures from multiple file formats (including animated gifs), do sound, etc.  I don't think of these as features that should be present in the original version...even though without them I would need to find a different language.

KISS is a really good motto.

Another good feature would be documentation that says exactly which features
are supposed to be working.  I looked over wxD, and found it interesting,
but the only way to find out what was expected to be working would appear
to be to install it and try.  In this respect a well annotated stress test
setup would be very useful.  (Think of DStress as a checklist of what is
working in D.  It's not good user documentation, but it would be a good
basis for automatic creation of a status page of user documentation.
[Maybe it does that...I've been looking at so many options I've rather lost
track.])

Also needed is a good way to report bugs.  I think the capability for this is built into dsource, though I haven't tried to use it, since mainly I've been studying and evaluating rather than developing.

I would have liked it a lot if I had been able to choose D, but it looks to be too green yet, and this is mainly the libraries, but not entirely. E.g., when I tried dmd -o test test.d `gtk-config --libs` the compiler complained about the -l files.  Not good.  I might have checked out gcd, but there were other problems that ruled D out of the running, so I didn't bother.

Currently, you need to have a project that is adapted to the existing compiler and libraries, rather than adapting the compiler and libraries to the project.  (That's awkward, and doesn't sound like what I mean, but I can't think how to be clearer.  Lets try again...)  A language needs to be a general purpose tool, able to be adapted with minimal effort to a wide variety of problems.  One of the big tools to allow this is pre-existing libraries.  This means either the libraries are built for that language, or, alternatively, it is *VERY* easy to import them from and alternative language.  Otherwise the problems that the language can be used for with reasonable efficiency is quite limited.  One language that is often used as a base for libraries is C, but unfortunately the use of macros in C header files tends to make importing C libraries quite problematical.  Very few languages have a decent way to do this.  Most of those that do generate C as an intermediate code.  Languages with a long history and large user base tend to acquire a number of useful libraries in a form native to the language.  There is such a strong correlation (isomorphism?) between having a large set of libraries and being a well established language that it's probably impossible to say which caused the other, but it's reasonable to suspect a feedback relationship.

The first step, always (AFAIK), is to start with a few specialized libraries and a broad class of rudimentary but sturdy libraries.

In article <e25vmb$1frn$2@digitaldaemon.com>, Kyle Furlong says...
>
>pragma wrote:
>> [snip = "We could use GL for a portable base to build a GUI on"]
>> 
>> PS, you could back DWT, Minwin, DUIT, etc on such a lib if you wanted to.
>
>Terra is well on the way in this vein, you should check it out.

Thanks.

[sifts through SVN tree for Terra]

Wow.  Okay, I like where this is going.  My only regret is not enough time to put my back into it, but maybe I can see what I can contribute.  It certainly looks like a nice recipe for stone soup anyway.

http://www.dsource.org/projects/terra/browser/trunk/Terra/Source/Terra/Readme.txt

I also sincerely mean what I stated in that PS.  I think the major thing that is scaring people away from DWT is the sheer size of the thing, and what that means for porting the native layer of the library.  If D simply built the GUI toolchain in much the same way it has everything else (bottom up) we'd already have a whole crop portable GUI toolkits. :)

- Eric Anderton at yahoo

Charles Hixson wrote:

>> I guess the community needs to decide exactly what it would like from a
>> GUI/Framework.
>> 
>> Are we looking for
>> Portability to multiple platforms?

> -- 
> Work in progress
> [...]

BTW; Thunderbird hated this start, it thought your post was one big sig?

> From my personal perspective, it needs to work well on my personal system,
> which runs Linux.  It also needs to be easy to set up (or come with the
> compiler), because I'm not *committed* to D.  I just want to get my project
> done, and D would be a nice tool.
> 
> In the longer term, I would also want the GUI to work on the Mac.  I'm
> indifferent to MSWind, but I'm fairly certain that it would happen if it
> were at all feasible, so that doesn't need much thought.

wxD is intended for Linux (GTK+), Mac OS X (Carbon), as well as Windows.

> Better to start with a simple framework that can later be expanded, and get
> it working WELL.  (Simple means being able to do dialog boxes.  Ability to
> use input from a GUI builder, like glade, or SpecTCL would be a real plus,
> no question, but is LESS necessary that having a solid system.)

For wxWidgets, there are several editors for the XML-based "XRC" format.
One (from the wx author) is: http://www.anthemion.co.uk/dialogblocks/

> For my personal interest, I would like an enhanced version to be able to
> draw on canvases, display pictures from multiple file formats (including
> animated gifs), do sound, etc.  I don't think of these as features that
> should be present in the original version...even though without them I
> would need to find a different language.

wxD comes with both several image formats, and support for sound (0.05)
And drawing on canvases is supported, as well as using OpenGL canvases.

> KISS is a really good motto.

wxD is somewhat huge, but most of the code is rather straight-forward.
(not counting some of the voodoo going on with events and such tricks)

Some complexity comes from the mish-mash of languages used, though...

> Another good feature would be documentation that says exactly which features
> are supposed to be working.  I looked over wxD, and found it interesting,
> but the only way to find out what was expected to be working would appear
> to be to install it and try.  In this respect a well annotated stress test
> setup would be very useful.  (Think of DStress as a checklist of what is
> working in D.  It's not good user documentation, but it would be a good
> basis for automatic creation of a status page of user documentation. [Maybe it does that...I've been looking at so many options I've rather lost
> track.])

I've been working on such a list for wxD 0.05, but it's a lot of demos and I'm testing them on three platforms - so it amounts to some work...

I've also started on some minor docs, like http://wxd.sf.net/Hello.html
and with adding some API docs with Doxygen, like http://wxd.sf.net/docs/
In the long run there needs to be a tutorial or longer documentation,
explaining how to get started - with more words than just a Readme...

Also interesting would be a list of all available widgets, like SWT has:
http://www.eclipse.org/swt/widgets/, even if it's the same as wxWidgets.
There are a lot, especially when including all of http://wxcode.sf.net/,
since most of the C++ wxWidgets can be ported over to D if needed to be.

> Also needed is a good way to report bugs.  I think the capability for this
> is built into dsource, though I haven't tried to use it, since mainly I've
> been studying and evaluating rather than developing.

If you mean reporting wxD bugs, there should be a link on the home page:

http://sourceforge.net/tracker/?group_id=133831

> I would have liked it a lot if I had been able to choose D, but it looks to
> be too green yet, and this is mainly the libraries, but not entirely. E.g., when I tried dmd -o test test.d `gtk-config --libs` the compiler
> complained about the -l files.  Not good.  I might have checked out gcd,
> but there were other problems that ruled D out of the running, so I didn't
> bother.

The *-config scripts output stuff in GCC format, so you need to use GDC
- or feed it through some kind of preprocessing filter for DMD syntax...
I ended up hardcoding DMs Makefile, and using wx-config for GNUmakefile.
But I had to use "gcc" for the actual linking, not the "dmd" command ?

AFAIK: DMC/DMD doesn't do shared libraries, but for the GNU platforms
at least wxWidgets is possible to link as shared (if wanted), for wxD.

    ****

I think that wxD could serve as a GUI for D.
At least until something better is ready...

It's just an "alpha" in terms of stability,
but then again so is the D language itself ?

--anders

> wxD is intended for Linux (GTK+), Mac OS X (Carbon), as well as Windows.

I thought wxWidgets was a C++ library, and that it was next to impossible to interface to C++ in D ???

So does wxD build a lib for D or does wxD provide a layer on top of wxWidgets to access wxWidgets library?

Also how easy is it going to be to keep wxD synced with the main wxWidgets branches?

above comments not meant to be a critique just curiosity


> For wxWidgets, there are several editors for the XML-based "XRC" format.
> One (from the wx author) is: http://www.anthemion.co.uk/dialogblocks/
> 

The above is even better when it generates the C++ code ;) not much use in D though, but XRC is probably more portable than C++ code especially when used with wxPython or wxLua


> wxD comes with both several image formats, and support for sound (0.05)
> And drawing on canvases is supported, as well as using OpenGL canvases.
> 

So out of interest just how much is possible with wxD compared with wxWidgets, i.e TreeViews RichText Events etc?

Again above not a critique more curiosity ;)


> wxD is somewhat huge, but most of the code is rather straight-forward.
> (not counting some of the voodoo going on with events and such tricks)
> 
> Some complexity comes from the mish-mash of languages used, though...

I thought wxWidgets was developed in C++ ??

> I've been working on such a list for wxD 0.05, but it's a lot of demos and I'm testing them on three platforms - so it amounts to some work...

Well I have a Mac and x64 PC so I may be able to lend a hand testing if you like?

> 
> I've also started on some minor docs, like http://wxd.sf.net/Hello.html
> and with adding some API docs with Doxygen, like http://wxd.sf.net/docs/
> In the long run there needs to be a tutorial or longer documentation,
> explaining how to get started - with more words than just a Readme...

Could it be possible to use wxWidgets docs for wxD?

> 
> Also interesting would be a list of all available widgets, like SWT has:
> http://www.eclipse.org/swt/widgets/, even if it's the same as wxWidgets.
> There are a lot, especially when including all of http://wxcode.sf.net/,
> since most of the C++ wxWidgets can be ported over to D if needed to be.

I must have missed something somewhere I thought it was not possible to port C++ to D I am sure I read a post somewhere or on the D site saying that it is almost impossible to port C++ to D ??


> I think that wxD could serve as a GUI for D.
> At least until something better is ready...

if it is on par with wxWidgets then this could definately be the case wxWidgets is a pretty complete framework afaik.

Been readin up on SDL this could be a good base with wxD for multimedia framework ??

> 
> It's just an "alpha" in terms of stability,
> but then again so is the D language itself ?
> 

How far is D off from going Beta?

DBloke

DBloke wrote:

>> wxD is intended for Linux (GTK+), Mac OS X (Carbon), as well as Windows.
> 
> I thought wxWidgets was a C++ library, and that it was next to impossible to interface to C++ in D ???
> 
> So does wxD build a lib for D or does wxD provide a layer on top of wxWidgets to access wxWidgets library?

There is a wrapping layer (called "wxc"), written in C++, that
exports all the methods as "C" functions. The wxD class library
(called "wxd"), written in D, then calls to these C functions.
It's much easier to explain if you look at the wxD source code...

> Also how easy is it going to be to keep wxD synced with the main wxWidgets branches?

We're currently at 2.6.1, but there are not that many API changes
for 2.6.3 - so we can just "diff" those in to the wxD bindings...

It's on the roadmap, but for now we're using 2.6.1 as static libs.
In the future we probably want to be using the latest wx as shared.

> The above is even better when it generates the C++ code ;) not much use in D though, but XRC is probably more portable than C++ code especially when used with wxPython or wxLua

XRC can be used from wxD, and there is a demo with the main download.

>> wxD comes with both several image formats, and support for sound (0.05)
>> And drawing on canvases is supported, as well as using OpenGL canvases.
> 
> So out of interest just how much is possible with wxD compared with wxWidgets, i.e TreeViews RichText Events etc?

Most of it... See the demos, but at least Trees and HTML with Events.

>> Some complexity comes from the mish-mash of languages used, though...
> 
> I thought wxWidgets was developed in C++ ??

wxWidgets is done in C++. wxD is written in both C++ and D, but the
D classes are in turn based on the wx.NET project - written in C#...

So you end up with something reminding a little of C# (like: "IntPtr")
calling C++ methods exported as C functions, and your app written in D.

:-D

>> I've been working on such a list for wxD 0.05, but it's a lot of demos and I'm testing them on three platforms - so it amounts to some work...
> 
> Well I have a Mac and x64 PC so I may be able to lend a hand testing if you like?

Sure! There's "only" wxD 0.04 at the site at the moment, but I might as
well upload wxD 0.05 too as a "Release Candidate" or something similar ?

D doesn't do 64-bit yet, but I guess you could run regular X86 too ?
Start with the instructions at http://wxd.sourceforge.net/#installation

>> In the long run there needs to be a tutorial or longer documentation,
>> explaining how to get started - with more words than just a Readme...
> 
> Could it be possible to use wxWidgets docs for wxD?

Definitely! Especially the excellent whole book on wxWidgets:
http://www.wxwidgets.org/book/, we just need to highlight the
syntax differences - but the classes and the API are the same...

For a simple C++ vs D comparison, see http://wxd.sf.net/Hello.html
The biggest difference is all the missing macros and header files ?
One can also follow the wx.NET docs at http://wxnet.sf.net/docs.html

> I must have missed something somewhere I thought it was not possible to port C++ to D I am sure I read a post somewhere or on the D site saying that it is almost impossible to port C++ to D ??

You shouldn't believe all those people telling you what you can't do ;-)

> Been readin up on SDL this could be a good base with wxD for multimedia framework ??

Yes, at least when you bundle it with GL (and AL) for hardware features.

--anders