I took a look at SWT and found IBM's source for Win32.  See the attached screenshot.

The other folders are all for Java and its role in Eclipse, but if we could rewrite the SWT core for each platform :( and call it with consistent methods/functions, would we have reproduced a native GUI library for D?  I'm not saying it would be easy, due to the 704K total source file size, but if we could bang out Win32 and Linux, it would be a good start.  And efforts in the future would have a framework to go from.

I guess you could do the same thing with wxWindows, but from Ant's list, eclipse SWT looks like the best compromise for speed and comprehensiveness.

BA

> Interesting (roughly and roughly chronological):
> java AWT - use only common native widgets
> java swing - don't use native widget, implements "full" set of widgets
> eclise SWT - use native widgets where possible, implement others
> wxWindows - use native widgets
> wxWindowsUniversal - don't use native widgets.
> 
> Seems people still doesn't know what's more important,
> give the user a consistent look and feel on a specific platform or
> give the same application the same look and feel accross different
> platforms.
> 
> (Definitivly the user sould have a consistent look and feel in one platform. Or maybe that's a view of the past?)

>
>Sure, but I also want to finish my other D projects.
>DUI is still valid.
>Ant I wouldn't start this without a minimum IDE (ie leds;)
>

Ok, but you seem to be a little vague as to when you are ready to start the project.  What do I do in the mean time? Just wait?  Maybe I can give you a hand with something.  I was eager to get some sort of a start on the GUI, but I could use some programming practice while I wait for you ;-).

Also, there was some mention of use of OpenGL as the rendering platform for a GUI library.  I'm interested to see how this may work with wxWindows as well. More brain-storming definitely required here.  This would be a good spot for wxUniversal, possibly (I believe the current one is implemented using MGL). This may be much more effectively cross-platform if D ever made it to other processors.

Later,

John

> Sure, but I also want to finish my other D projects.
>DUI is still valid.
>Ant I wouldn't start this without a minimum IDE (ie leds;)
>
>Ant
>

Just to let you know, I tried LEDS (most recent static build) last week on my Gentoo Linux (kernel 2.6.1rc2 on Gnome 2.4).  It ran and looked very nice, but it would not do much.  It kept crashing whenever I opened the options dialogue to set up the path directories for the compiler and libraries.  As soon as I said "ok," it just shut the whole program down with narry a word.  I couldn't do anything with it.  No ability to open, setup, or save a project without crashing either. So I gave up trying to develop with it. I'm still wondering why one of the other fancy Linux IDE's can't be modified to work with DMD.  I guess with LEDS, you are intent on proving the ability to develop serious apps with D and DUI, is that correct?

Later,

John

In article <buhjpv$2ruc$1@digitaldaemon.com>, John Reimer says...
>
>Just to let you know, I tried LEDS (most recent static build) last week on my Gentoo Linux (kernel 2.6.1rc2 on Gnome 2.4).  It ran and looked very nice, but it would not do much.  It kept crashing whenever I opened the options dialogue to set up the path directories for the compiler and libraries.  As soon as I said "ok," it just shut the whole program down with narry a word.  I couldn't do anything with it.  No ability to open, setup, or save a project without crashing either.

Thank you for this report!
Did you create the leds home directories as it says on the
leds online manual?
leds was started when phobos didn't know how to create a directory
so it trusts on the user to do that(I'm hopping it's just that
but if so it would have thrown a file error exception).
(I'm working on the first 'user friendly' version of leds to deal
with this 'little' things).

> So I gave up trying to develop with it.

I would have done the same thing! :(

> I'm still wondering why one of
>the other fancy Linux IDE's can't be modified to work with DMD.

- I can't stand VMs anymore
- it's nice to have one develped in D
- I don't want to 'relearn' C++
--- too much trouble
--- and many new things since I used it.
--- we have better language (D)
- It's a nice application to show off DUI

> I guess with LEDS, you are intent on proving the ability to develop serious apps with D and DUI, is that correct?

Leds is suppose to be the "Light Editor for D"
the 's' stands for Superfluous (because there are others) has you noted but
with a few more months it will stands for Superb.
All the main features (although incompled) are in.
check the dantfw page for the envisioned complete development environment

http://dantfw.sourceforge.net (will redirect to the old page)

Ant

In article <buhlhh$2v49$1@digitaldaemon.com>, Ant says...
>
>Thank you for this report!
>Did you create the leds home directories as it says on the
>leds online manual?

Uhhhh....Nooo. Read the manual? You should know users don't read manuals ;-).

I'll check this out.  I definitely didn't read the manual, and tried to run it from my home directory after extracting it there.  I'll check on this tomorrow when I'm able to access my home computer.  Very likely that was the problem.

>> I'm still wondering why one of
>>the other fancy Linux IDE's can't be modified to work with DMD.
>
>- I can't stand VMs anymore
>- it's nice to have one develped in D
>- I don't want to 'relearn' C++
>--- too much trouble
>--- and many new things since I used it.
>--- we have better language (D)
>- It's a nice application to show off DUI

Ok, understandable.

>check the dantfw page for the envisioned complete development environment
>
>http://dantfw.sourceforge.net (will redirect to the old page)
>

Looks impressive!

-John

In article <buhja7$2r3l$1@digitaldaemon.com>, John Reimer says...
>
>>
>>Sure, but I also want to finish my other D projects.
>>DUI is still valid.
>>Ant I wouldn't start this without a minimum IDE (ie leds;)
>>
>
>Ok, but you seem to be a little vague as to when you are ready to start the project.

3, 2, 1, go!
(just can't give it all my free time)

> What do I do in the mean time? Just wait?  Maybe I can give you a hand
>with something.

That is tempting!

DUI's work is just boring.
the most interesting thing on DUI is to find out how to make
the combo box work (it's incomplete and crashes on the windows version).
Also if you're interested on OpenGL the windows version needs work
but it sould be only debuging.

If you like leds help is welcomed.
leds is more interesting, actually there are some interesting problems
still looking for a solution.
I think leds is going to be much better then I antecipated.

> I was eager to get some sort of a start on the GUI, but I could
>use some programming practice while I wait for you ;-).
>
>Also, there was some mention of use of OpenGL as the rendering platform for a GUI library.  I'm interested to see how this may work with wxWindows as well.

If we like the wxWindows API the OpenGL could be just another
implementation. (to take full advange of it some extensions
would be created) isn't JA that is interested on that
(sorry bad with names here, for a long time I thought
Carlos Santander and Charles Sanders were the same person!)

>More brain-storming definitely required here.

yep.

> This would be a good spot for
>wxUniversal, possibly (I believe the current one is implemented using MGL). This may be much more effectively cross-platform

Just looked at MGL. maybe you're right. but again it's some thing else to include on the distribution. No native widget set, one size fits all.

I think a native look and feel for windows is important for X11 (linux)
it just needs to be good.

Ant

In article <buhnpe$1l3$1@digitaldaemon.com>, John Reimer says...
>
>In article <buhlhh$2v49$1@digitaldaemon.com>, Ant says...
>>
>>Thank you for this report!
>>Did you create the leds home directories as it says on the
>>leds online manual?
>
>Uhhhh....Nooo. Read the manual? You should know users don't read manuals ;-).

hey! it's still alpha!

Ant

Ant wrote:
> In article <buhja7$2r3l$1@digitaldaemon.com>, John Reimer says...
> 
>>>Sure, but I also want to finish my other D projects.
>>>DUI is still valid.
>>>Ant I wouldn't start this without a minimum IDE (ie leds;)
>>>
>>
>>Ok, but you seem to be a little vague as to when you are ready to start the
>>project.
> 
> 
> 3, 2, 1, go!
> (just can't give it all my free time)
> 

oh oh oh.  Me too.

I've started incorporating a GTK+ backend into dfbth, more for the purpose of prototyping than anything.  (dfbth is just yet another toolkit, except that I coded it, so it's awful beyond mortal reckoning)  You can have a looksee at

<http://ikagames.com/andy/d/dfbth-19-jan-2004.tar.bz2>

(win32 libraries for GTK2.0 are at <http://ikagames.com/andy/d/gtk2.0-0libs-dmd.zip> )

All that's implemented on the GTK+ end are frames and buttons, as well as the obligatory messaging backbone.  (GTK+'s event semantics are much more straightforward than win32's, so this was very easy)

I'll probably switch it over to DUI; there's no sense in writing my own GTK+ wrapper if that's exactly what DUI already is.  (if I can get the durned thing to compile right :)

Unless there are scary platform issues I'm not aware of, the whole toolkit seems to be a pretty simple library.  There must be something I'm not taking into account here, as so much effort has gone into these things.

Anyhow, it's topical, so I thought I'd present something to dissect. (however little it may be) Comments/code are welcome.

 -- andy

On Mon, 19 Jan 2004 16:32:52 -0800, Andy Friesen wrote:

> Ant wrote:
>> In article <buhja7$2r3l$1@digitaldaemon.com>, John Reimer says...
>> 
>>>>Sure, but I also want to finish my other D projects.
>>>>DUI is still valid.
>>>>Ant I wouldn't start this without a minimum IDE (ie leds;)
>>>>
>>>
>>>Ok, but you seem to be a little vague as to when you are ready to start the project.
>> 
>> 
>> 3, 2, 1, go!
>> (just can't give it all my free time)
>> 
> 
> oh oh oh.  Me too.
> 
> I've started incorporating a GTK+ backend into dfbth, more for the
> purpose of prototyping than anything.  (dfbth is just yet another
> toolkit, except that I coded it, so it's awful beyond mortal reckoning)
>   You can have a looksee at
> 
> <http://ikagames.com/andy/d/dfbth-19-jan-2004.tar.bz2>

it's nice to recognize some of the stuff :)

> 
> (win32 libraries for GTK2.0 are at <http://ikagames.com/andy/d/gtk2.0-0libs-dmd.zip> )

You distribute them! I just make DUI users to go through the pain of creating them from the dlls or whatever... :(

> 
> All that's implemented on the GTK+ end are frames and buttons,

do the ComboBox, do the ComboBox (if I can copy it),
I think the main problem I have with the combobox is my
level of knowledge (ignorance) of C.

> as well as the obligatory messaging backbone.  (GTK+'s event semantics are much more straightforward than win32's, so this was very easy)
> 
> I'll probably switch it over to DUI;

Can I use your event processing on DUI?
I still wasn't sure on how to do it.

> there's no sense in writing my own GTK+ wrapper if that's exactly what DUI already is.  (if I can get the durned thing to compile right :)

What's the problem?

If you do a common API for GTK and for native windows there is much sence on it. But that's our new project, right?

> 
> Unless there are scary platform issues I'm not aware of, the whole toolkit seems to be a pretty simple library.  There must be something I'm not taking into account here, as so much effort has gone into these things.

I don't understand what you mean.

> 
> Anyhow, it's topical, so I thought I'd present something to dissect. (however little it may be) Comments/code are welcome.
> 
>   -- andy

comment:
nice

comment:
I did try to use the D facility of defining more than one public
class on one module. It's a bad idea. give it up.

Ant

Ant wrote:
> On Mon, 19 Jan 2004 16:32:52 -0800, Andy Friesen wrote:
> 
>>All that's implemented on the GTK+ end are frames and buttons,
> 
> do the ComboBox, do the ComboBox (if I can copy it),
> I think the main problem I have with the combobox is my
> level of knowledge (ignorance) of C.
> 

Anybody can copy any portion of dfbth for any reason.

> 
> Can I use your event processing on DUI?
> I still wasn't sure on how to do it.
> 

Absolutely.

> 
>>there's no sense in writing my own GTK+ wrapper if that's exactly what DUI already is.  (if I can get the durned thing to compile right :)
> 
> What's the problem?

Currently, it's:

src\ddi\WindowG.d: class WindowG forward reference of base class Drawable

> 
> If you do a common API for GTK and for native windows there
> is much sence on it. But that's our new project, right?
> 

I just mean that DUI is easier to use than pure GTK+. (C sucks)

> 
>>Unless there are scary platform issues I'm not aware of, the whole toolkit seems to be a pretty simple library.  There must be something I'm not taking into account here, as so much effort has gone into these things.
> 
> I don't understand what you mean.
> 

Just that it's been pretty easy to work out thus far.  There has to be some obscenely scary part of all this that I haven't seen yet.

> 
> I did try to use the D facility of defining more than one public
> class on one module. It's a bad idea. give it up.
> 

heheh.  I try to, because it's a nice way to organize things.  But I have seen the problem with interdependant classes in separate modules causing DMD to cry.  In dfbth's case, it was Control and CompositeControl that caused the explosion.  They're both in control.d now for this reason.

 -- andy