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... #1) Ant seems to stick around and is doing a superb job with it. #2) DWT is Windows only and to make DWT cross platform means to 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. #3) Is there anyone else around here with enough experience to write 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.
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. Not being written all in D (but half in C++ and half in C# -> D), 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/ * C# http://wxnet.sourceforge.net/ * 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. Not being written all in D (but half in C++ and half in C# -> D), 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/ * C# http://wxnet.sourceforge.net/ * 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... #1) Ant seems to stick around and is doing a superb job with it. #2) DWT is Windows only and to make DWT cross platform means to 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. #3) Is there anyone else around here with enough experience to write 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
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... #1) Ant seems to stick around and is doing a superb job with it. #2) DWT is Windows only and to make DWT cross platform means to 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. #3) Is there anyone else around here with enough experience to write 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 ?

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

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

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

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

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?

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?

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.

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?

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.

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

#1) SDL can not support multiple windows #2) Every time you resize an SDL window the OpenGL context is destroyed on Windows (but not on linux), which means that for each window resize you need to reload opengl and all its textures.
Apr 19 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
clayasaurus wrote:

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

Ouch, to both of them! Maybe it's just suitable for fullscreen game-like interfaces then. Which, accidently, was where I was using it (without problems) :-) Anyway, it would still mean lots of work to implement say a "tree control" or an "open file dialog" etc. etc. with such a UI system ? And that's not even going into things like Grids or HTML panes. Or all the other widgets that you need when doing applications... And then there is the lack of editors and documentation, and so on. --anders
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 D classes are in turn based on the wx.NET project - written in C#... So you end up with something reminding a little of C# (like: "IntPtr") calling C++ methods exported as C functions, and your app written in D. :-D
 I've been working on such a list for wxD 0.05, but it's a lot of demos 
 and I'm testing them on three platforms - so it amounts to some work...

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

Sure! There's "only" wxD 0.04 at the site at the moment, but I might as well upload wxD 0.05 too as a "Release Candidate" or something similar ? D doesn't do 64-bit yet, but I guess you could run regular X86 too ? Start with the instructions at http://wxd.sourceforge.net/#installation
 In the long run there needs to be a tutorial or longer documentation,
 explaining how to get started - with more words than just a Readme...

Could it be possible to use wxWidgets docs for wxD?

Definitely! Especially the excellent whole book on wxWidgets: http://www.wxwidgets.org/book/, we just need to highlight the syntax differences - but the classes and the API are the same... For a simple C++ vs D comparison, see http://wxd.sf.net/Hello.html The biggest difference is all the missing macros and header files ? One can also follow the wx.NET docs at http://wxnet.sf.net/docs.html
 I must have missed something somewhere I thought it was not possible to 
 port C++ to D I am sure I read a post somewhere or on the D site saying 
 that it is almost impossible to port C++ to D ??

You shouldn't believe all those people telling you what you can't do ;-)
 Been readin up on SDL this could be a good base with wxD for multimedia 
 framework ??

Yes, at least when you bundle it with GL (and AL) for hardware features. --anders
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 ?

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.
 

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.

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 work fine in wxWidgets (C++) and in wx.NET (C#), so they 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.

 
 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/

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

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

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

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 ?

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

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. If you're interested in C#, you should definitely check the project out! http://wxnet.sourceforge.net/ (versions for: Windows, Linux, Macintosh) All these are open source projects, and pulling in the same direction: wxWidgets (C++) --> wx.NET (C#) --> wxD (D). With mutual benefits, too ? 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:

 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, and I think most of that system was actually ported over from C#... :-) 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, I understand that the garbage collector works differently in D and C# ? Maybe Bero can shed some more light on the inner wxD workings of this ? --anders
Apr 22 2006