www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Whither DWT?

reply Kyle Furlong <kylefurlong gmail.com> writes:
Shawn has not responded to inquiries on dsource for quite a while. He is the
sole developer for the "official" GUI toolkit for 
our beloved :D.

This cannot continue. All I ask is that the official toolkit be in active
development, which leaves four options:

1. Renew Shawn's interest in DWT
2. Install a new lead for DWT or a branch of DWT
3. Choose another official toolkit
4. Develop a new official toolkit
Apr 14 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Kyle Furlong wrote:

 Shawn has not responded to inquiries on dsource for quite a while. He is 
 the sole developer for the "official" GUI toolkit for our beloved :D.
 
 This cannot continue. All I ask is that the official toolkit be in 
 active development, which leaves four options:
 
 1. Renew Shawn's interest in DWT
 2. Install a new lead for DWT or a branch of DWT
 3. Choose another official toolkit
 4. Develop a new official toolkit


If Shawn doesn't come back in a couple of months, I'd suggest option 3, 
namely, DUI http://www.dsource.org/projects/dui . My reasoning...




essentially rewrite DWT for each platform you target, this is a 
development and maintenance nightmare. Meanwhile, DUI being based upon 
GTK means it either already works or is an easy port to all platforms 
GTK targets.


ports? How familiar are people with SWT in the first place? Correct me 
if wrong, but I get the feeling people are more familiar with GTK.

DWT _may_ be a better product, but DUI is more practical.
Apr 14 2006
next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
I second that.
For me, DWT without Linux support is useless.
Apr 14 2006
parent reply Kramer <Kramer_member pathlink.com> writes:
In article <e1oevk$2kr7$2 digitaldaemon.com>, Frank Benoit says...

I second that.
For me, DWT without Linux support is useless.


What about wxD?  That seems promising as the underlying framework is supported
across multiple platforms.

-Kramer
Apr 14 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Kramer wrote:

 In article <e1oevk$2kr7$2 digitaldaemon.com>, Frank Benoit says...

 I second that.
 For me, DWT without Linux support is useless.


 
 What about wxD?  That seems promising as the underlying framework is supported
 across multiple platforms.


It is? I just looked at its website and it says it has ports for 
Windows, GTK, and Mac, which makes me think that they write a new 
backend for each platform they support. From what I can tell, wxd is 
farther along than DWT, but the site says that wxd is still an early alpha.


 
 -Kramer
Apr 14 2006
next sibling parent Kramer <Kramer_member pathlink.com> writes:
In article <e1p7tn$an8$1 digitaldaemon.com>, clayasaurus says...

Kramer wrote:

 In article <e1oevk$2kr7$2 digitaldaemon.com>, Frank Benoit says...

 I second that.
 For me, DWT without Linux support is useless.


 
 What about wxD?  That seems promising as the underlying framework is supported
 across multiple platforms.


It is? I just looked at its website and it says it has ports for 
Windows, GTK, and Mac, which makes me think that they write a new 
backend for each platform they support. From what I can tell, wxd is 
farther along than DWT, but the site says that wxd is still an early alpha.


 
 -Kramer
 
 





Well, I might have spoke hastily.  I just meant that wxWidgets is available on
multiple platforms and I think D code is fairly portable, so I guess I
extrapolated a bit.  I just get excited thinking about a stable D gui platform.
I'll cease here though before I spout more gibberish.

-Kramer
Apr 15 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 What about wxD?  That seems promising as the underlying framework is 
 supported across multiple platforms.


 
 It is? I just looked at its website and it says it has ports for 
 Windows, GTK, and Mac, which makes me think that they write a new 
 backend for each platform they support. From what I can tell, wxd is 
 farther along than DWT, but the site says that wxd is still an early alpha.


Half right, *wxWidgets* has a new port of each platform that it 
supports. (but it is written in C++, this cross-platform library)

Here is their list of the currently supported wxWidgets platforms:
     * wxMSW: Win32/Win64/WinCE.
     * wxGTK: GTK+ 1 or 2 on Unix.
     * wxX11: Xlib on Unix.
     * wxMac: Mac OS X/Carbon, Mac OS Classic.
     * wxMGL: MGL on DOS, Linux and other platforms supported by MGL.
     * wxBase: non-GUI builds of the library.
     * wxCocoa: Mac OS X/Cocoa (beta).
     * wxOS2: a Presentation Manager port (beta).
     * wxPalmOS: a Palm OS port (alpha).

wxD is "just" a D wrapping layer for wxWidgets, inspired by / based on 
wx.NET - but written in C++ for the wrappers and in D for the classes.

The wxD code should be portable to everything with wxWidgets and D,
but is being developed and actively tested on three major platforms:

     * Windows XP (wxMSW)
     * Linux/GTK (wxGTK)
     * Mac OS X (wxMac)

It's not being tested on any of Windows 95, GTK 1.x, X11 or Mac OS 9.
But it "could" still be made to work there, if anyone wanted to...(?)

The alpha status (same as D!) comes mostly from the facts that the
memory handling isn't exactly perfect, and that some wxD demos crash.

wxWidgets itself (C++) is stable, at least on these three platforms.
wx.NET, on which wxD is based, is also a bit more stable and tested.



means that it is both smaller and bigger than the other projects...
Smaller: less code is needed on the D side of the equation. (wxD)
Bigger: more code is needed on the C++ side (being done elsewhere)

But there should be *no* OS-specific code in wxD, outside of API
differences (versioned) or the differences in the Makefiles etc.
I will make the home page spell this out clearer, with wxD 0.05.
(since apparently you got the wrong impression, from wxD 0.04...)

--anders


PS.
You can also check out some of the other language wrappers for wx:

* C++     http://www.wxwidgets.org/

* Python  http://www.wxpython.org/
* Lua     http://wxlua.sourceforge.net/

These all share the same underlying interface implementation. (wx)
Apr 16 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Have you ever thought about putting your project on dsource? I have a 
feeling it would get a lot more exposure to D programmers that way :) I 
know I myself like to keep tabs on most of the projects on dsource, and 
the reason I didn't mention wxd was because I'm mostly clueless about it.
~ Clay

Anders F Björklund wrote:

 clayasaurus wrote:
 

 What about wxD?  That seems promising as the underlying framework is 
 supported across multiple platforms.


 It is? I just looked at its website and it says it has ports for 
 Windows, GTK, and Mac, which makes me think that they write a new 
 backend for each platform they support. From what I can tell, wxd is 
 farther along than DWT, but the site says that wxd is still an early 
 alpha.


 
 Half right, *wxWidgets* has a new port of each platform that it 
 supports. (but it is written in C++, this cross-platform library)
 
 Here is their list of the currently supported wxWidgets platforms:
     * wxMSW: Win32/Win64/WinCE.
     * wxGTK: GTK+ 1 or 2 on Unix.
     * wxX11: Xlib on Unix.
     * wxMac: Mac OS X/Carbon, Mac OS Classic.
     * wxMGL: MGL on DOS, Linux and other platforms supported by MGL.
     * wxBase: non-GUI builds of the library.
     * wxCocoa: Mac OS X/Cocoa (beta).
     * wxOS2: a Presentation Manager port (beta).
     * wxPalmOS: a Palm OS port (alpha).
 
 wxD is "just" a D wrapping layer for wxWidgets, inspired by / based on 
 wx.NET - but written in C++ for the wrappers and in D for the classes.
 
 The wxD code should be portable to everything with wxWidgets and D,
 but is being developed and actively tested on three major platforms:
 
     * Windows XP (wxMSW)
     * Linux/GTK (wxGTK)
     * Mac OS X (wxMac)
 
 It's not being tested on any of Windows 95, GTK 1.x, X11 or Mac OS 9.
 But it "could" still be made to work there, if anyone wanted to...(?)
 
 The alpha status (same as D!) comes mostly from the facts that the
 memory handling isn't exactly perfect, and that some wxD demos crash.
 
 wxWidgets itself (C++) is stable, at least on these three platforms.
 wx.NET, on which wxD is based, is also a bit more stable and tested.
 
 

 means that it is both smaller and bigger than the other projects...
 Smaller: less code is needed on the D side of the equation. (wxD)
 Bigger: more code is needed on the C++ side (being done elsewhere)
 
 But there should be *no* OS-specific code in wxD, outside of API
 differences (versioned) or the differences in the Makefiles etc.
 I will make the home page spell this out clearer, with wxD 0.05.
 (since apparently you got the wrong impression, from wxD 0.04...)
 
 --anders
 
 
 PS.
 You can also check out some of the other language wrappers for wx:
 
 * C++     http://www.wxwidgets.org/

 * Python  http://www.wxpython.org/
 * Lua     http://wxlua.sourceforge.net/
 
 These all share the same underlying interface implementation. (wx)
Apr 17 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:


 Have you ever thought about putting your project on dsource? I have a 
 feeling it would get a lot more exposure to D programmers that way :)


There are several D projects on SourceForge - as well as on dsource ?

This one (wxD) is not entirely my own, and has been OK on SourceForge...
I don't think moving it over to DS would help, but maybe you are right.

Now seems to be a bad time to be doing so, though ?
"FATAL: connection limit exceeded for non-superusers"


But I thought that one of the biggest reasons for the lack of interest 
was that Walter already picked another framework (DWT) as the official.
Or that most people are just using DMD and Windows anyway, and then it 
made more sense to pick one of the several existing D/Windows toolkits.
Or perhaps start something new in "pure D", like Harmonia or MinWin ?

I'm using wxWidgets elsewhere, so it made sense to use it for D too...
(the cross-language portability is an added bonus to the cross-platform)


Anyway, wxD 0.05 will soon be released with support for sound and with 
the cross-platform support cleaned up and expanded. Plus some bugfixes.

It'll be announced on digitalmars.D.announce and on http://wxd.sf.net/
(send us an email if you like to join the project or help beta testing)

--anders
Apr 18 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
clayasaurus wrote:

 Kyle Furlong wrote:

 Shawn has not responded to inquiries on dsource for quite a while. He 
 is the sole developer for the "official" GUI toolkit for our beloved :D.

 This cannot continue. All I ask is that the official toolkit be in 
 active development, which leaves four options:

 1. Renew Shawn's interest in DWT
 2. Install a new lead for DWT or a branch of DWT
 3. Choose another official toolkit
 4. Develop a new official toolkit


 
 If Shawn doesn't come back in a couple of months, I'd suggest option 3, 
 namely, DUI http://www.dsource.org/projects/dui . My reasoning...
 

 

 essentially rewrite DWT for each platform you target, this is a 
 development and maintenance nightmare. Meanwhile, DUI being based upon 
 GTK means it either already works or is an easy port to all platforms 
 GTK targets.
 

 ports? How familiar are people with SWT in the first place? Correct me 
 if wrong, but I get the feeling people are more familiar with GTK.
 
 DWT _may_ be a better product, but DUI is more practical.


Good points.

Maybe I'm mistaken, but isn't there a number of (large) dependencies you 
have to pre-install to use DUI on Windows. Like GTK + MinGW or CYGWIN 
and such?

To me, unless that is handled very nicely by an installer (which is also 
easy to duplicate for end-user installation routines), that would be a 
major strike against it being more practical.

IMHO, the choice needs to be 'seamless' on Windows because that will be 
the major platform for D in the foreseeable future.

Thanks,

- Dave
Apr 14 2006
parent Ant <duitoolkit yahoo.ca> writes:
Dave wrote:

 clayasaurus wrote:

 Kyle Furlong wrote:

 Shawn has not responded to inquiries on dsource for quite a while. He 
 is the sole developer for the "official" GUI toolkit for our beloved :D.

 This cannot continue. All I ask is that the official toolkit be in 
 active development, which leaves four options:

 1. Renew Shawn's interest in DWT
 2. Install a new lead for DWT or a branch of DWT
 3. Choose another official toolkit
 4. Develop a new official toolkit


 If Shawn doesn't come back in a couple of months, I'd suggest option 
 3, namely, DUI http://www.dsource.org/projects/dui . My reasoning...




 essentially rewrite DWT for each platform you target, this is a 
 development and maintenance nightmare. Meanwhile, DUI being based upon 
 GTK means it either already works or is an easy port to all platforms 
 GTK targets.


 DWT ports? How familiar are people with SWT in the first place? 
 Correct me if wrong, but I get the feeling people are more familiar 
 with GTK.

 DWT _may_ be a better product, but DUI is more practical.


 
 Good points.
 
 Maybe I'm mistaken, but isn't there a number of (large) dependencies you 
 have to pre-install to use DUI on Windows. Like GTK + MinGW or CYGWIN 
 and such?
 
 To me, unless that is handled very nicely by an installer (which is also 
 easy to duplicate for end-user installation routines), that would be a 
 major strike against it being more practical.
 
 IMHO, the choice needs to be 'seamless' on Windows because that will be 
 the major platform for D in the foreseeable future.
 
 Thanks,
 
 - Dave


no just install Gtk+ from http://gimp-win.sourceforge.net/stable.html
depending on your compilation procedures you don't even need a DUI lib, 
just the sources.

Ant
Apr 14 2006
prev sibling parent reply DBloke <DBloke NoSpam.org> writes:
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?

Something similar to the .NET Framework? i.e. not just a GUI but an 
entire Framework

Nice GUI RAD IDE similar to SharpDevelop or Visual Studio 2005?

Native API's converted to D for each platform?

A Consistent look and feel across all OS Platforms?

Obviously not all of the above can be achieved, as some are mutually 
exclusive to each other, i.e Native API's and consistent look across OS 
Platforms.

I am sure there are other ideas, but would it not be better to 
collaborate all efforts on a single project rather than several 
individual projects striving for the same goal.

It is still possible to divide and conquer but why not on a single 
project rather than several different ones.

I understand that there are those that have worked hard on their own 
projects and don't want to abandon them, so why not take the best from 
them all and put this into a single focused effort?

Just my humble opinion as a new comer to D, and not meant to offend 
anyone so apologies if it does, this is not my intention.

DBloke
Apr 19 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
DBloke wrote:

 
 I am sure there are other ideas, but would it not be better to
 collaborate all efforts on a single project rather than several
 individual projects striving for the same goal.


Well, you're not the first to propose this...

Anyway, even GUI-projects can have quite different goals, and not all are
actually necessary to have cross-platform as it increases the internal
complexity of the project. And many choose their GUI based on previous
experiences and since there are umpteen GUI's in other languages, these
experiences are very diverse. :)
Apr 19 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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?
 
 Something similar to the .NET Framework? i.e. not just a GUI but an 
 entire Framework
 
 Nice GUI RAD IDE similar to SharpDevelop or Visual Studio 2005?
 
 Native API's converted to D for each platform?
 
 A Consistent look and feel across all OS Platforms?
 
 Obviously not all of the above can be achieved, as some are mutually 
 exclusive to each other, i.e Native API's and consistent look across OS 
 Platforms.


I agree. I think that it's been unproductive to discuss the merits of 
various frameworks without discussing the philosophy behind them.

I think there's reasonable agreement of many of the underlying issues (I 
haven't heard anyone arguing for a monolithic .NET-style framework).
But there are (at least) two major groups -- cross-platform, and 
OS-native. IMHO, anyone who wants small Windows-only executables, is 
*never* going to be happy with a cross-platform solution.


 I am sure there are other ideas, but would it not be better to 
 collaborate all efforts on a single project rather than several 
 individual projects striving for the same goal.


Agreed, but I don't think there is one common goal. It does seem to me, 
though, to be feasible to reduce the plethora of projects significantly.

Personally, I've joined Stewart in the conversion of the Windows API, 
which seems to me to be necessary for all frameworks. I think this is a 
case where a bottom-up approach is the most promising.


 It is still possible to divide and conquer but why not on a single 
 project rather than several different ones.
 
 I understand that there are those that have worked hard on their own 
 projects and don't want to abandon them, so why not take the best from 
 them all and put this into a single focused effort?
 
 Just my humble opinion as a new comer to D, and not meant to offend 
 anyone so apologies if it does, this is not my intention.
 
 DBloke
Apr 19 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:


 Personally, I've joined Stewart in the conversion of the Windows API, 
 which seems to me to be necessary for all frameworks. I think this is a 
 case where a bottom-up approach is the most promising.


It is not needed if the interface to the system is written in C or C++,
instead of D ? (some GUI libraries use this approach, like DIUP or wxD)

But for a framework written all in D it is needed, and it's a problem...
For Mac OS X, one needs to convert all the Carbon API framework headers.


When doing a minimalist approach, like MinWin, one can probably get away 
with just declaring the used stuff on the fly and not the whole thing...

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
Apr 19 2006
parent reply DBloke <DBloke NoSpam.org> writes:
 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.
Apr 19 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
DBloke wrote:


 This is something that would need to be agreed, do we want Native or X 
 Platform?


Why would it need to be universally agreed on ? Couldn't we have both ?

If you mean for the "official" Digital Mars GUI for D, then Walter has
already chosen DWT which is a native interface ("heavyweight" widgets)


 D is X Platform so perhaps D's GUI should be also?


AFAIK, "D" (as in DMD) is Dual-platform ? But I prefer Cross-platform,
as available with the GDC back-end/compiler. Mostly because I use Mac.

And I prefer native D widgets, just as I prefer native D executables...


 SDL and OpenGL could be a useful starting platform, [...]
 and a bonus that it is written in C so will be easier to interface to


Yes, a definitive bonus of SDL and GL is that the D bindings are done
and that you can link directly to the system libraries (i.e. not C++)

Then again we don't have any "official" bindings for either of them ?

--anders


PS. You do know that there already are a few D frameworks, right ?
     heavyweight: MinWin, DIUP, DUI, DWT, wxD
     lightweight: Harmonia, Terra
     http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries
Apr 19 2006
parent reply DBloke <DBloke NoSpam.org> writes:
Bloke wrote:

 

 This is something that would need to be agreed, do we want Native or X 
 Platform?


 
 Why would it need to be universally agreed on ? Couldn't we have both ?


Yes D could have both but assuming that one half work on X Platform and 
one half on Native then you only have half as much effort for each 
rather than 100% on one.

 
 If you mean for the "official" Digital Mars GUI for D, then Walter has
 already chosen DWT which is a native interface ("heavyweight" widgets)


Yes I read the post, but is DWT not a Windows only implementation, and 
is it still actively updated and maintained?

If only Windows Only what possibilities are there to make it Dual/ X 
Platform ;)

It seems that DWT was supposed to mirror SWT but the version of DWT is 
over a year out of date compared to SWT Stable.

AFAICS there is only Shawn working on this if DWT is the chosen one 
would it not be better to concentrate all efforts on this adding and 
removing ideas from other GUI Framworks to DWT in a multi man effort?


 And I prefer native D widgets, just as I prefer native D executables...


Are you referring to DWT?


 Yes, a definitive bonus of SDL and GL is that the D bindings are done
 and that you can link directly to the system libraries (i.e. not C++)
 
 Then again we don't have any "official" bindings for either of them ?


What would make a binding official? was TUMIKI Fighters not written in 
SDL and OpenGL http://www.asahi-net.or.jp/~cs8k-cyu/windows/tf_e.html ?



 PS. You do know that there already are a few D frameworks, right ?


Yes :) but this is what I was referring to in original post there are 
lots of GUI Frameworks about but none finished afaics or at least out of 
alpha or early stages.

Why not have a community effort finishing one or using all the best 
ideas from each project and building a new one from ground up?
DBloke
Apr 19 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
DBloke wrote:


 Yes D could have both but assuming that one half work on X Platform
 and one half on Native then you only have half as much effort for each
 rather than 100% on one.


I think that both of these approaches have their uses, actually...

If there was a finite number of people working on it totally,
it would make sense to pick one. But I don't think there are ?
It's more like some people are interested in one and others
are interested in the other, and you can't make them "switch"

And even if I think the native toolkit should be the primary one,
I can't deny that for instance Harmonia or XUL gives good results ?


 If you mean for the "official" Digital Mars GUI for D, then Walter has
 already chosen DWT which is a native interface ("heavyweight" widgets)


 Yes I read the post, but is DWT not a Windows only implementation, and
 is it still actively updated and maintained?


[...]

 AFAICS there is only Shawn working on this if DWT is the chosen one
 would it not be better to concentrate all efforts on this adding and
 removing ideas from other GUI Framworks to DWT in a multi man effort?


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


 And I prefer native D widgets, just as I prefer native D executables...


 Are you referring to DWT?


I meant in general, as in heavyweight/widgets over lightweight/gadgets.
(I think you used the terms "native" and "crossplatform" for the two ?)

I just like using the frameworks using native widgets better myself;
even if it would be very cool to have something like Swing, in OpenGL ?

Have been writing Java apps with Swing earlier, that has worked well.
But there both the code and gui is portable, which it isn't in D exes.
So currently I'm doing either wxWidgets with C++, or Swing with Java.
(for the cross-platform projects, the rest use some old native stuff)

i.e. either both program/framework is native, or they're both virtual
SWT just isn't my "personal favorite", so I haven't been using it...


 Then again we don't have any "official" bindings for either of them ?


 What would make a binding official? [...]


Supported by Digital Mars ? Or available as a standard D download ?

But I know that there are two approaches here, "headers" (bindings)
and "Derelict" (loading shared library function pointers at runtime)
So maybe it's not doable to have just one official SDL/GL binding...
The SDL/GL bindings are both working well, that is not the problem.


 Why not have a community effort finishing one or using all the best
 ideas from each project and building a new one from ground up?


A new library on the same scope of SWT or wxWidgets takes years to do,
which is why it was much easier to port or wrap the original versions ?

If doing a brand new GUI library, then MinWin (heavyweight) or Harmonia
(lightweight) seems to be the two D libraries that are furthest along ?
Or perhaps the DUI library, if wrapping GTK+ is cross-platform enough ?
(it looks a bit weird on Windows, and is not finished yet for Mac OS X)

     ****

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
Apr 19 2006
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
Apr 19 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
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.
Apr 19 2006
prev sibling parent reply Jari-Matti Mäkelä <Jari-Matti_member pathlink.com> writes:
In article <e25lku$10bp$1 digitaldaemon.com>, 
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...


I just like using the frameworks using native widgets better myself;
even if it would be very cool to have something like Swing, in OpenGL ?


Harmonia + OpenGL backend would be really cool for games. Well, I might have 
some time on July to ponder this thing further.
Apr 22 2006
parent "Boris Wang" <nano.kago hotmail.com> writes:
"Jari-Matti Mäkel?" <Jari-Matti_member pathlink.com>
дÈëÏûÏ¢ÐÂÎÅ:e2diac$21jj$1 digitaldaemon.com...

 In article <e25lku$10bp$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...


I just like using the frameworks using native widgets better myself;
even if it would be very cool to have something like Swing, in OpenGL ?


 Harmonia + OpenGL backend would be really cool for games. Well, I might 
 have


Why only cool for games?  like vista, cool for desktop applications too.

the method, data abstraction + 3D api,  is the future of GUI development.

There are so many OS, but only two 3D api, OpenGL and DirectX
Apr 27 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
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.
Apr 19 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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.
Apr 19 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
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
Apr 19 2006
prev sibling next sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
"Kyle Furlong" <kylefurlong gmail.com> 
??????:e25vmb$1frn$2 digitaldaemon.com...

 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.


Yes, Terra is cool, but it only limit the refresh rate for save of cpu, we 
also need update on demand, and update on changed.
Apr 27 2006
prev sibling parent reply freeagle <freeagle inmail.sk> writes:
Hello,

Im quite new to D, but reading a lot of posts lately and checking some 
websites about D i can say that the demand for good GUI API is quite 
high in the community (including me).

And i must say i agree with the idea of using OpenGL for making a cross 
platform GUI. Having a modern GUI rendered using graphics hardware could 
    drag more attention to D. And problem of not native look of such API 
could be easily handled using different themes. When i checked Terra 
project source, the actual style of the widgets takes only few lines of 
code and a set of images. For me, OpenGL is the right way to go.

Freeagle
May 01 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
freeagle wrote:

 Hello,
 
 Im quite new to D, but reading a lot of posts lately and checking some 
 websites about D i can say that the demand for good GUI API is quite 
 high in the community (including me).
 
 And i must say i agree with the idea of using OpenGL for making a cross 
 platform GUI. Having a modern GUI rendered using graphics hardware could 
    drag more attention to D. And problem of not native look of such API 
 could be easily handled using different themes. When i checked Terra 
 project source, the actual style of the widgets takes only few lines of 
 code and a set of images. For me, OpenGL is the right way to go.
 
 Freeagle


All Terra needs is a complete widget set. Like you have specified, all 
this takes is the logic and skinning. I wrote a scrollbar widget and 
skinned it in less than a day.
May 01 2006
parent reply freeagle <freeagle inmail.sk> writes:
Kyle Furlong wrote:

 freeagle wrote:

 Hello,

 Im quite new to D, but reading a lot of posts lately and checking some 
 websites about D i can say that the demand for good GUI API is quite 
 high in the community (including me).

 And i must say i agree with the idea of using OpenGL for making a 
 cross platform GUI. Having a modern GUI rendered using graphics 
 hardware could    drag more attention to D. And problem of not native 
 look of such API could be easily handled using different themes. When 
 i checked Terra project source, the actual style of the widgets takes 
 only few lines of code and a set of images. For me, OpenGL is the 
 right way to go.

 Freeagle


 
 All Terra needs is a complete widget set. Like you have specified, all 
 this takes is the logic and skinning. I wrote a scrollbar widget and 
 skinned it in less than a day.


i wonder if its possible/reasonable to use it for more complex GUI apps, 
IDE for example, or any other bigger projects
May 01 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
freeagle wrote:

 Kyle Furlong wrote:

 freeagle wrote:

 Hello,

 Im quite new to D, but reading a lot of posts lately and checking 
 some websites about D i can say that the demand for good GUI API is 
 quite high in the community (including me).

 And i must say i agree with the idea of using OpenGL for making a 
 cross platform GUI. Having a modern GUI rendered using graphics 
 hardware could    drag more attention to D. And problem of not native 
 look of such API could be easily handled using different themes. When 
 i checked Terra project source, the actual style of the widgets takes 
 only few lines of code and a set of images. For me, OpenGL is the 
 right way to go.

 Freeagle


 All Terra needs is a complete widget set. Like you have specified, all 
 this takes is the logic and skinning. I wrote a scrollbar widget and 
 skinned it in less than a day.


 
 i wonder if its possible/reasonable to use it for more complex GUI apps, 
 IDE for example, or any other bigger projects


Why not? All you have to do is write the widgets you need and skin them. :-D
May 01 2006
parent reply freeagle <freeagle inmail.sk> writes:
Kyle Furlong wrote:

 freeagle wrote:

 Kyle Furlong wrote:

 freeagle wrote:

 Hello,

 Im quite new to D, but reading a lot of posts lately and checking 
 some websites about D i can say that the demand for good GUI API is 
 quite high in the community (including me).

 And i must say i agree with the idea of using OpenGL for making a 
 cross platform GUI. Having a modern GUI rendered using graphics 
 hardware could    drag more attention to D. And problem of not 
 native look of such API could be easily handled using different 
 themes. When i checked Terra project source, the actual style of the 
 widgets takes only few lines of code and a set of images. For me, 
 OpenGL is the right way to go.

 Freeagle


 All Terra needs is a complete widget set. Like you have specified, 
 all this takes is the logic and skinning. I wrote a scrollbar widget 
 and skinned it in less than a day.


 i wonder if its possible/reasonable to use it for more complex GUI 
 apps, IDE for example, or any other bigger projects


 
 Why not? All you have to do is write the widgets you need and skin them. 
 :-D


asking coz i havent found anything about how thorough is the design of 
terra, if the code of bigger apps will still remain maintainable, and if 
its able to introduce new features easily without some major code rewrites
May 02 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
freeagle wrote:

 Kyle Furlong wrote:

 freeagle wrote:

 Kyle Furlong wrote:

 freeagle wrote:

 Hello,

 Im quite new to D, but reading a lot of posts lately and checking 
 some websites about D i can say that the demand for good GUI API is 
 quite high in the community (including me).

 And i must say i agree with the idea of using OpenGL for making a 
 cross platform GUI. Having a modern GUI rendered using graphics 
 hardware could    drag more attention to D. And problem of not 
 native look of such API could be easily handled using different 
 themes. When i checked Terra project source, the actual style of 
 the widgets takes only few lines of code and a set of images. For 
 me, OpenGL is the right way to go.

 Freeagle


 All Terra needs is a complete widget set. Like you have specified, 
 all this takes is the logic and skinning. I wrote a scrollbar widget 
 and skinned it in less than a day.


 i wonder if its possible/reasonable to use it for more complex GUI 
 apps, IDE for example, or any other bigger projects


 Why not? All you have to do is write the widgets you need and skin 
 them. :-D


 asking coz i havent found anything about how thorough is the design of 
 terra, if the code of bigger apps will still remain maintainable, and if 
 its able to introduce new features easily without some major code rewrites


Like I said before, all you have to do is write the widget set. In terms 
of maintainability, I don't see how the GUI library has anything to do 
with the maintainability of your code. The design is solid as far as I 
can see. Trevor Parscal (the author) produces very high quality code.
-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
May 02 2006
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
freeagle wrote:

 Hello,
 
 Im quite new to D, but reading a lot of posts lately and checking some
 websites about D i can say that the demand for good GUI API is quite
 high in the community (including me).
 
 And i must say i agree with the idea of using OpenGL for making a cross
 platform GUI. Having a modern GUI rendered using graphics hardware could
    drag more attention to D. And problem of not native look of such API
 could be easily handled using different themes. When i checked Terra
 project source, the actual style of the widgets takes only few lines of
 code and a set of images. For me, OpenGL is the right way to go.
 
 Freeagle


Personally, I don't like these kinds of GUI toolkits.  Granted, they ARE
more portable, and easier to write, but:

A) Visuals.  Not one single self-rendered toolkit I've ever seen has
looked right.  GTK+, Swing... they all have small, subtle, but very
annoying quirks that allow you to say: "Hey, this isn't a native app!"
That should *never* happen.  Sun has had years to try to perfect this,
and yet they haven't.

What is worse, what are you going to do about Vista?  When that comes
out, all your work on the XP skin has to be re-done from scratch.  And
even then, given that Vista uses all those transparency effects, will it
even be possible without a major rewrite?

The problem is magnified if Vista has multiple themes.  Then you've got
to support each one separately... you get the idea.

And let's not forget the million and one themes of KDE and GNOME...

B) Operation.  Under Windows, I sometimes use IMEs (Input Method
Editors) to input text in Japanese.  Now, there's an option in Windows
to enable extra support for this in text boxes... the problem is that if
you're rendering the text boxes yourself, this support mysteriously
disappears.  You will never be able to cover the entire set of system
built-in functionality.  If you did manage to, you'd basically be
re-implementing the entire toolkit API on every native system... which
is much more work than just wrapping it in the first place.

That said, I still think projects like this are important.  For
applications that don't care one whit if they "fit" with the system or
not, they're a boon.  Such is true of things like media players, games,
and other applications that intend to have a distinctive look (or don't
need one at all :P)

But at the end of the day, I'd still prefer to have something like
wxWidgets or SWT for D (in addition to toolkits like Terra), so that my
programs will function properly :)

	-- Daniel "Foolish Swing!  Everyone knows that Windows tree views have
SQUARE swizzles, not round ones!  Your heinous deception is unmasked!" Keep

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 03 2006
parent reply freeagle <freeagle inmail.sk> writes:
Daniel Keep wrote:

 
 freeagle wrote:

 Hello,

 Im quite new to D, but reading a lot of posts lately and checking some
 websites about D i can say that the demand for good GUI API is quite
 high in the community (including me).

 And i must say i agree with the idea of using OpenGL for making a cross
 platform GUI. Having a modern GUI rendered using graphics hardware could
    drag more attention to D. And problem of not native look of such API
 could be easily handled using different themes. When i checked Terra
 project source, the actual style of the widgets takes only few lines of
 code and a set of images. For me, OpenGL is the right way to go.

 Freeagle


 
 Personally, I don't like these kinds of GUI toolkits.  Granted, they ARE
 more portable, and easier to write, but:
 
 A) Visuals.  Not one single self-rendered toolkit I've ever seen has
 looked right.  GTK+, Swing... they all have small, subtle, but very
 annoying quirks that allow you to say: "Hey, this isn't a native app!"
 That should *never* happen.  Sun has had years to try to perfect this,
 and yet they haven't.
 
 What is worse, what are you going to do about Vista?  When that comes
 out, all your work on the XP skin has to be re-done from scratch.  And
 even then, given that Vista uses all those transparency effects, will it
 even be possible without a major rewrite?


- actually, with a good design, it could be possible to add modify skins 
and themes with just a different set of images, maybe small code 
rewrite. Id never accept a toolkit that need to rewrite whole widget set 
for every available theme/skin it supports. About those transparency 
effects, OpenGL has alpha blending, so i dont see what major rewrites 
you are talking about. But i must say i havent tried vista yet, so im 
not even absolutely sure what transparency effects you are talking about.


 The problem is magnified if Vista has multiple themes.  Then you've got
 to support each one separately... you get the idea.
 
 And let's not forget the million and one themes of KDE and GNOME...
 
 B) Operation.  Under Windows, I sometimes use IMEs (Input Method
 Editors) to input text in Japanese.  Now, there's an option in Windows
 to enable extra support for this in text boxes... the problem is that if
 you're rendering the text boxes yourself, this support mysteriously
 disappears.  You will never be able to cover the entire set of system
 built-in functionality.  If you did manage to, you'd basically be
 re-implementing the entire toolkit API on every native system... which
 is much more work than just wrapping it in the first place.
 
 That said, I still think projects like this are important.  For
 applications that don't care one whit if they "fit" with the system or
 not, they're a boon.  Such is true of things like media players, games,
 and other applications that intend to have a distinctive look (or don't
 need one at all :P)
 
 But at the end of the day, I'd still prefer to have something like
 wxWidgets or SWT for D (in addition to toolkits like Terra), so that my
 programs will function properly :)
 
 	-- Daniel "Foolish Swing!  Everyone knows that Windows tree views have
 SQUARE swizzles, not round ones!  Your heinous deception is unmasked!" Keep
 


- many of the features you mentioned can be achieved if you thoroughly 
design the toolkit before you start to code. I havent seen any terras 
design document, so i cant say how good is terra with this. Anyway, no 
toolkit can do everything, thats why there are plethora toolkits on the 
market. Everything has pros and cons
May 04 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
freeagle wrote:

 Daniel Keep wrote:

 What is worse, what are you going to do about Vista?  When that comes
 out, all your work on the XP skin has to be re-done from scratch.  And
 even then, given that Vista uses all those transparency effects, will it
 even be possible without a major rewrite?


 
 - actually, with a good design, it could be possible to add modify skins
 and themes with just a different set of images, maybe small code
 rewrite. Id never accept a toolkit that need to rewrite whole widget set
 for every available theme/skin it supports. About those transparency
 effects, OpenGL has alpha blending, so i dont see what major rewrites
 you are talking about. But i must say i havent tried vista yet, so im
 not even absolutely sure what transparency effects you are talking about.


AFAIK application windows in Vista have a < 50% alpha value and a lame
distortion effect on the window title bars by default. It's easy to do
these things in OpenGL. You can even create animated, multitextured
backgrounds with bump mapping without any greater problems - even with a
terrible widget set design.

-- 
Jari-Matti
May 04 2006
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jari-Matti Mäkelä wrote:

 freeagle wrote:

 Daniel Keep wrote:

 What is worse, what are you going to do about Vista?  When that comes
 out, all your work on the XP skin has to be re-done from scratch.  And
 even then, given that Vista uses all those transparency effects, will it
 even be possible without a major rewrite?


 - actually, with a good design, it could be possible to add modify skins
 and themes with just a different set of images, maybe small code
 rewrite. Id never accept a toolkit that need to rewrite whole widget set
 for every available theme/skin it supports. About those transparency
 effects, OpenGL has alpha blending, so i dont see what major rewrites
 you are talking about. But i must say i havent tried vista yet, so im
 not even absolutely sure what transparency effects you are talking about.


 
 AFAIK application windows in Vista have a < 50% alpha value and a lame
 distortion effect on the window title bars by default. It's easy to do
 these things in OpenGL. You can even create animated, multitextured
 backgrounds with bump mapping without any greater problems - even with a
 terrible widget set design.
 


You most certainly can do those things in OpenGL.

Except Vista's desktop is composited using DirectX, so you can't simply
"render" the window using OpenGL and expect it to blend with everything
else.  Which means you would have to work out some way to grab all the
pixels underneath the current window, and I'm not entirely sure how you
would do that.

Of course, once you've done that, you can load the pixels into OpenGL,
then render, and then... oh wait, Vista turns off desktop compositing as
soon as you try to use OpenGL.  Which means as soon as you fire up your
windowed OpenGL app... all the desktop compositing and Vista theme
disappears.  Oops.  Now your program looks out of place anyway >_<

Unless of course Microsoft changes their mind about OpenGL... bloody
monopolists... stupid DirectX...

Anyway, my original motive was more directed to the "we should make a
self-rendered toolkit" vs "no!  we should make a native toolkit!"
comments.  I think we need at least once of each, since there are things
each toolkit can't really do.

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 04 2006
parent reply freeagle <freeagle inmail.sk> writes:
Daniel Keep wrote:

 
 Jari-Matti Mäkelä wrote:

 freeagle wrote:

 Daniel Keep wrote:

 What is worse, what are you going to do about Vista?  When that comes
 out, all your work on the XP skin has to be re-done from scratch.  And
 even then, given that Vista uses all those transparency effects, will it
 even be possible without a major rewrite?


 - actually, with a good design, it could be possible to add modify skins
 and themes with just a different set of images, maybe small code
 rewrite. Id never accept a toolkit that need to rewrite whole widget set
 for every available theme/skin it supports. About those transparency
 effects, OpenGL has alpha blending, so i dont see what major rewrites
 you are talking about. But i must say i havent tried vista yet, so im
 not even absolutely sure what transparency effects you are talking about.


 AFAIK application windows in Vista have a < 50% alpha value and a lame
 distortion effect on the window title bars by default. It's easy to do
 these things in OpenGL. You can even create animated, multitextured
 backgrounds with bump mapping without any greater problems - even with a
 terrible widget set design.


 
 You most certainly can do those things in OpenGL.
 
 Except Vista's desktop is composited using DirectX, so you can't simply
 "render" the window using OpenGL and expect it to blend with everything
 else.  Which means you would have to work out some way to grab all the
 pixels underneath the current window, and I'm not entirely sure how you
 would do that.
 
 Of course, once you've done that, you can load the pixels into OpenGL,
 then render, and then... oh wait, Vista turns off desktop compositing as
 soon as you try to use OpenGL.  Which means as soon as you fire up your
 windowed OpenGL app... all the desktop compositing and Vista theme
 disappears.  Oops.  Now your program looks out of place anyway >_<
 
 Unless of course Microsoft changes their mind about OpenGL... bloody
 monopolists... stupid DirectX...
 
 Anyway, my original motive was more directed to the "we should make a
 self-rendered toolkit" vs "no!  we should make a native toolkit!"
 comments.  I think we need at least once of each, since there are things
 each toolkit can't really do.
 
 	-- Daniel
 


- maybe i say something stupid, but...
- i suppose vista wants back compatibility with apps renderes with GDI. 
and GDI can do transparent stuff too. Actualy, both GDI and OpenGL work 
with the device context, which contains/points to (dunno the exact 
internals) to a pixel buffer hes connecte to. So you dont have to get 
all the pixels first, blend them and finally render them since they are 
already included in the device context. If they are not, i suppose theyd 
need a major rewrite of GDI too, and i dont think they can afford it. 
And i think that you can combine GDI rendering with Direct3D rendering, 
as well as GDI + OpenGL in current releases of Windows. So, i havent 
tried it yet, but i think that OpenGL + Direct3D could work too. Think 
Im going to find out :)
May 05 2006
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
freeagle wrote:

 Daniel Keep wrote:

 Jari-Matti Mäkelä wrote:

 freeagle wrote:

 Daniel Keep wrote:

 What is worse, what are you going to do about Vista?  When that comes
 out, all your work on the XP skin has to be re-done from scratch.  And
 even then, given that Vista uses all those transparency effects,
 will it
 even be possible without a major rewrite?


 - actually, with a good design, it could be possible to add modify
 skins
 and themes with just a different set of images, maybe small code
 rewrite. Id never accept a toolkit that need to rewrite whole widget
 set
 for every available theme/skin it supports. About those transparency
 effects, OpenGL has alpha blending, so i dont see what major rewrites
 you are talking about. But i must say i havent tried vista yet, so im
 not even absolutely sure what transparency effects you are talking
 about.


 AFAIK application windows in Vista have a < 50% alpha value and a lame
 distortion effect on the window title bars by default. It's easy to do
 these things in OpenGL. You can even create animated, multitextured
 backgrounds with bump mapping without any greater problems - even with a
 terrible widget set design.


 You most certainly can do those things in OpenGL.

 Except Vista's desktop is composited using DirectX, so you can't simply
 "render" the window using OpenGL and expect it to blend with everything
 else.  Which means you would have to work out some way to grab all the
 pixels underneath the current window, and I'm not entirely sure how you
 would do that.

 Of course, once you've done that, you can load the pixels into OpenGL,
 then render, and then... oh wait, Vista turns off desktop compositing as
 soon as you try to use OpenGL.  Which means as soon as you fire up your
 windowed OpenGL app... all the desktop compositing and Vista theme
 disappears.  Oops.  Now your program looks out of place anyway >_<

 Unless of course Microsoft changes their mind about OpenGL... bloody
 monopolists... stupid DirectX...

 Anyway, my original motive was more directed to the "we should make a
 self-rendered toolkit" vs "no!  we should make a native toolkit!"
 comments.  I think we need at least once of each, since there are things
 each toolkit can't really do.

     -- Daniel


 
 - maybe i say something stupid, but...
 - i suppose vista wants back compatibility with apps renderes with GDI.
 and GDI can do transparent stuff too. Actualy, both GDI and OpenGL work
 with the device context, which contains/points to (dunno the exact
 internals) to a pixel buffer hes connecte to. So you dont have to get
 all the pixels first, blend them and finally render them since they are
 already included in the device context. If they are not, i suppose theyd
 need a major rewrite of GDI too, and i dont think they can afford it.
 And i think that you can combine GDI rendering with Direct3D rendering,
 as well as GDI + OpenGL in current releases of Windows. So, i havent
 tried it yet, but i think that OpenGL + Direct3D could work too. Think
 Im going to find out :)


Fair enough.  But like I was saying, if you want your toolkit to look
like the host system, I imagine it would be easier to just wrap the
system's API :P

That said, I've been doing some searching, and if you wanted to do
borderless, translucent rendering in Windows, you might be able to get
away with using GDI and "layered" windows.  Some interesting stuff in
MSDN on it.

One of these days, I'll get around to writing that Konfabulator clone
I've always wanted :P

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/
May 05 2006
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
DBloke wrote:

 SDL and OpenGL could be a useful starting platform...





on Windows (but not on linux), which means that for each window resize 
you need to reload opengl and all its textures.
Apr 19 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:



 

 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
Apr 19 2006
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Apr 19 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 19 2006
next sibling parent reply DBloke <DBloke NoSpam.org> writes:
 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
Apr 19 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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



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
Apr 19 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
In article <e27ain$gu5$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

DBloke wrote:


 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 what you're referring to is that it is not practical to *mechanically*
convert many C++ apps. to D. I don't think there is really anything you could do
in C/++ that couldn't also be done with D, with the exception of some
compile-time macro/template stuff (which of course doesn't mean you couldn't
accomplish the same end-result w/ D, just not at compile time).


You shouldn't believe all those people telling you what you can't do ;-)
Apr 20 2006
prev sibling parent reply DBloke <DBloke NoSpam.org> writes:
 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 ?


Hi These are test results from samples built.
Tested on Windows XP SP2
1.5 GB Ram
Athlon XP 2800+
128 MB GeForce 4 MX GFX

Controls -- Exists with abnormal termination
Dialogs -- Selecting busy dialog gives abnormal termination
Dnd -- Selecting clipboard gives abnormal termination
Font -- GUI Code requested a wxFontMapper but we only have a 
wxFontMapperBase
Grid -- When selecting virtual table allocation with default setting 
exits with abnormal termination
HTML -- when selecting open from file menu and selecting an html file 
invalid encoding value in wxCSConv ctor -- abnormal termination
HtmlHelp -- When selecting Exit abnormal termination
HTMListbox -- when opening program abnormal termiation
Launcher -- after launching Dialogs and exiting Dialogs just get 
hourglass no way to quit only task manager
ListBook -- when selecting About program freezes only way to quit Task 
Manager
ListCtrl -- Selecting Sort program just exits
MDI -- when starting program immediately exits with abnormal termination
Printing -- When selecting Print Setup -- Abnormal termination
TreeCtrl -- program never displays and just runs as a process in Task 
Manager, only way to quit look through processes in Task Manager and end 
process
Xrcdemo -- exits immediately before displaying

How does 0.5 compare to 0.4?

DBloke
Apr 21 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
DBloke wrote:


 Hi These are test results from samples built.


Hmm, looking at the bug list like that does seem pretty bad :-)
"Abnormal termination" is pretty common in D programs, though.

Patches happily accepted :-)


 How does 0.5 compare to 0.4?


I fixed the platform macros, the bools, and added some docs.
Also added sound support, and a demo for that. Nothing major.

Email me for the beta of it.

--anders
Apr 21 2006
parent reply EricH <Eric.Heaton.UK -AT-Removegmail.com> writes:
Hello to all :)
Been playing with wxD and have noticed similar problems in sample programs.

 Hmm, looking at the bug list like that does seem pretty bad :-)
 "Abnormal termination" is pretty common in D programs, though.
 


"Abnormal termination" is pretty common in D programs"
Why is this? a D bug or a wxD one?


 Patches happily accepted :-)


I am a proficient C++ programmer, but will be happy to have a go, I use 
wxWidgets a lot of the time in C++, but don't ask me about Linux or Mac.

I tried Linux once about 3 years ago and could not see what all the fuss 
was about :) but millions of other people obviously do ;)

Do you think the problems lie in the samples or wxD itself?


 Email me for the beta of it.


If you don't mind I would like a copy of wxD 0.5, I understand a lot of 
D syntax and think dropping MI is a very good idea, shame C++ didn't do 
the same when it was standardised.

Interfaces and aggregated composite classes using SI are the way to go, 
afaics there is very little if anything the above can't achieve that MI 
can, plus Interfaces allow loose coupling of classes.
May 04 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
EricH wrote:


 "Abnormal termination" is pretty common in D programs, though.


 "Abnormal termination" is pretty common in D programs"
 Why is this?


What I mean was there is no "hand-holding" in D programs,
so if there was a problem it will crash hard and not put
up a stack dump or some other kind of similar exception ?

There are assertions and contracts, but those are off for "-release".


 a D bug or a wxD one?


But this in case, it's definitely a D bug. All the demos

should do so in wxD (D) as well ? Once "porting" is done.

Do compare with http://wxnet.sourceforge.net/, for most the examples ?


 Patches happily accepted :-)


 
 I am a proficient C++ programmer, but will be happy to have a go, I use 
 wxWidgets a lot of the time in C++, but don't ask me about Linux or Mac.


That is no problem, as I can easily handle testing on those platforms.


 I tried Linux once about 3 years ago and could not see what all the fuss 
 was about :) but millions of other people obviously do ;)
 
 Do you think the problems lie in the samples or wxD itself?


Definitely in wxD, I think it has to do with the destructors (in D,
all GC variables are undefined when the destructor finally runs...)
or just with plain old bugs or oversights (e.g. Unicode issues, etc)

--anders
May 04 2006
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Anders F Björklund wrote:


 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?


Ouch.  OK, I'll bottom post from now on.  Some groups seem to prefer that
anyway, though to me it seems more reasonable to intermix things.


 

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


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


Nice.

 

 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/
 


wxWidgets is well developed, indeed.  I've looked at using it with Python. 
I haven't considered it with D largely because of the low revision number
at SourceForge.  0.3 is a bit scarey.


...


 
 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)


For my purposes, size isn't a major consideration.  I've been considering
(among other things) C++ & Qt.  I just don't like to need to depend so much
on pointers.  And garbage collection is really a VERY nice feature.

 Another good feature would be documentation that says exactly which
...


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


Sorry, here I was talking about D's gui packages in general, which are
mainly hosted at DSource.

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


Sounds VERY nice. 


 ...

 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


Sorry, here I was talking about D's gui packages in general, which are
mainly hosted at DSource.


 

 ...


 
 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 ?


You are clearly MUCH more expert than I am.  I still build makefiles by
guess and try, based on what worked previously.  Programming I've done for
decades, but I'm in my early days with Linux and assoc GNU utils.

 
 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


Huuu... I would rate D as Beta.  If wxD is on the same level of stability as
D, perhaps I should think more seriously about it.  (Perhaps, anyway, I
should install gdc and see what can be done that way.  Would gdc link well
with wxD?)
-- 
Work in progress
Apr 21 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 22 Apr 2006 13:50:30 +1000, Charles Hixson  
<charleshixsn earthlink.net> wrote:


 Anders F Björklund wrote:


 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?


 Ouch.  OK, I'll bottom post from now on.  Some groups seem to prefer that
 anyway, though to me it seems more reasonable to intermix things.


No need to for that reason (but for other reasons yes, don't top post  
please.). The reason that Thunderbird, Opera, and 40Tude saw this as a  
signature is that the standard for emails is that everything that follows  
a line that *only* contains two dashes and a space, is the signature.

-- 
Derek Parnell
Melbourne, Australia
Apr 22 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charles Hixson wrote:


 I haven't considered it with D largely because of the low revision number
 at SourceForge.  0.3 is a bit scarey.


Hehe, I guess a version number of 0.04 would be just ghostly then :-)

I have been rewriting the http://wxd.sourceforge.net/ page, to make it
less scary, but there is no timeline for when it would reach a "1.0"...


 For my purposes, size isn't a major consideration.  I've been considering
 (among other things) C++ & Qt.  I just don't like to need to depend so much
 on pointers.  


Cutting down on the size is a *big* item on the TODO, but currently
if you link a (stand-alone!) program with wxD it's around 10 MB. :-(

One likely reason is probably that it doesn't strip the "dead code" ?
(if you link to the shared wx libraries, it's instead more like 3 MB)


 And garbage collection is really a VERY nice feature.


I think one of the gripes that people *seem* to have about SWT (& DWT)
is that the resources aren't garbage collected but need to be managed ?

They do have a pretty elaborate rationale why it does, though:
http://www.eclipse.org/articles/swt-design-2/swt-design-2.html


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 ?


 
 You are clearly MUCH more expert than I am.  I still build makefiles by
 guess and try, based on what worked previously.  Programming I've done for
 decades, but I'm in my early days with Linux and assoc GNU utils.


It's the other way around here. I've been using Linux and GNU tools
for a decade, but just trying to figure out Windows...  echo off ?

For the GNU tools, you do things like `wx-config --libs` and so on.
But it doesn't work so easy when working with Windows and Macintosh,
as they often require you to set it up explicitly in a GUI instead ?
(even if you *can* do it the GNU way too, in both MinGW and Darwin)

I think Bero made some progress with using Bakefiles, but it's still
somewhat tricky to get OpenGL or wx shared libraries working with DMD.
So for the moment there are two wxD compilation tracks: "DM" and "GNU"
And I'm mostly doing the three GNU ones, while yet others do the DM...


 Huuu... I would rate D as Beta.  If wxD is on the same level of stability as
 D, perhaps I should think more seriously about it.  


There are some crashes at the moment, but when I meant stability I was
more talking in terms of API and big features etc - D is still adding ?

Once we get the "crashers" out, and polish wxD a little (i.e. lose some 
wx.NET references and add some better documentation) - then it's a beta.

It's not many items left to decide, one of the last is if the classes 
should use short names like "Frame", or "wxFrame" - for compatibility ?


A *minor* setback is that the wx.NET project seems to have slowed to a 
stop, which means that our wxD project needs to pull a heavier load...

Our "wxc" is based on their "wx-c", and our "wxd" is based on "wx.NET",
as noted explicitly in the source code. It has been a big help for wxD.

I do plan on sending most of my D extensions upstream to wx.NET as well,
since I don't really want to fork but rather use the same base for both.



http://wxnet.sourceforge.net/ (versions for: Windows, Linux, Macintosh)

All these are open source projects, and pulling in the same direction:


All code is released under the LGPL-ish "wxWindows License", by the way.
It should work for everyone ? See http://www.wxwidgets.org/newlicen.htm



(Perhaps, anyway, I
 should install gdc and see what can be done that way.  Would gdc link well
 with wxD?)


Yes, wxD supports both DMD and GDC. It actually needs to detect which
D compiler is being used, since their ABI for arrays differs a little.

You'll find that the Makefiles do this, and set a __DMD__ or __GDC__
macro. They also add platform versions: __WXMSW__ __WXGTK__ __WXMAC__

(i.e. macros for the C++ library, and versions for the D library...)
wxD 0.04 uses some platform hacks, it has been rewritten for wxD 0.05

--anders
Apr 22 2006
parent reply kris <foo bar.com> writes:
Anders F Björklund wrote:

 Charles Hixson wrote:


[snip]

 And garbage collection is really a VERY nice feature.


 
 
 I think one of the gripes that people *seem* to have about SWT (& DWT)
 is that the resources aren't garbage collected but need to be managed ?


Hehe; that's what makes it perfectly suited to D :)

(relying on the D GC/dtor construct to release all resources would 
simply result in seg-faults -- I imagine you'll run into this with wxD, 
if any of the relevant resources are also GC managed)
Apr 22 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
kris wrote:


 I think one of the gripes that people *seem* to have about SWT (& DWT)
 is that the resources aren't garbage collected but need to be managed ?


 
 Hehe; that's what makes it perfectly suited to D :)


Yeah, the comments were actually from Java (should have read "(& DWT?)",
as I am not very familiar with the differences between SWT and DWT...)

Think it was mostly a critic from proponents of Swing instead of SWT ?
Here was one: http://cld.blog-city.com/comparing_swt_and_swing.htm

I think that you're right that explicit calls are easier to handle in D.


 (relying on the D GC/dtor construct to release all resources would 
 simply result in seg-faults -- I imagine you'll run into this with wxD, 
 if any of the relevant resources are also GC managed)


It has some kind of global wx object registry that keeps track of them,

But in the C++ wrappers, there is usually one ***_ctor and one ***_dtor.
It would be nice if it could be GC'd, but for now it's new and delete.


Looks something like this, in the C++ code:

extern "C" WXEXPORT
wxString* wxString_ctor(const char* str)
{
	return new _wxString(str, wxConvUTF8);
}

extern "C" WXEXPORT
void wxString_dtor(wxString *self)
{
	if (self != NULL)
		delete self;
}

(_wxString is a wrapper class for wxString)


I *think* wxD could be OK with D, asthe external "wxobj" is allocated
outside of the D garbage collector (which should be OK then, right ?)
i.e. as long as you use "auto" objects, or explicit deletes on them...
But we definitely need to dig in deeper in this, before any release.

As I believe that this matter could be a contributor to the wxD crashes,



Maybe Bero can shed some more light on the inner wxD workings of this ?

--anders
Apr 22 2006