On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:

> Brad Anderson wrote:
> 
> 
> This is an awesome idea.  I've since learned that GTK takes a very.... unique approach to grouping and arranging widgets.

I fond it natural and familiar!?...
Maybe I on the past I used the same toolkit the designer of GTK did.

> For one, I can't for the life of me find *any* way to simply set the position/size of a UI element.

I'm still looking for the xtToolkit way; I think is the best:
you just say this widget goes to the left or that
and the other goes bellow that one over there...

> While it's commendable that GTK+ takes the layout manager notion to this extent, it makes wrapping it and win32 a serious pain.
> 
> For this reason, converting DUI to call win32 instead of GTK would be difficult.

If DUI get's extremelly popular someone will do it (not me:)

> 
> Now it's apparent why this crossplatform GUI thing is so hard. ;)

That's why we are going to base the work on some proven existing one.
In your GUI you have 2 complete independent implementations
of your API.

> 
> (it's all GTKs fault!)

???

So, do we think that SWT deserves a look right.
(I kinda don't like the look of wxWindows web page and the demos
are crappy).

Again without looking in detail seems to me that wxWindows
is more like a cross platform "environment"
and SWT a cross platform GUI toolkitk.
It's confusing seeing ODBC as part of wxWindows...

I wanna look in more detail to wxWindows and SWT.
(but leds is is dragging me away)

Ant

On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:

> It is nothing more than a "gut" feel on SWT.  You touched on some of the
> issues.
>     (More recent toolkit, heavy support from IBM).
> 
> SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to native Win32 have the same wrappers.
> 
> I have thought that maybe DUI's wrappers of GTK could be modified to use native Win32 calls and then we have the beginnings of a platform independent GUI.  Then we've created a third option in addition to wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM has had experience far beyond GTK/linux and Windows, as has wxWindows with their long history.  So I lean toward one of the existing two, and for some reason I lean further toward SWT.
> 
> One reason may be that it's in Java, a language far easier for me to port to D than C++.  (By the way, we are talking about a port to D, right?  I wouldn't be interested in wrapping the Java and requiring a JVM.)  That just has to do with my skill set.  The C portion of SWT source has to do with the JNI/native calls, and the meat of SWT is in the Java classes.  D doesn't need JNI, except to wrap the calls in an *.h file.
> 
> I am only investigating SWT, but everything looks favorable.  I haven't downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of sense, and looks like it could be moved to D.  If you want to research SWT more, that would be great.  And I'll definitely join you and help however I can...
> 
> Cheers,
> Brad


After a basic investigation of SWT, I have to admit that it looks
promising, probably much more promising than wxWindows.  The C++ code in
wxWindows along with it's religious use of macros makes it a difficult
port to D.  It's possible, but not easy.  SWT uses JNI to connect
to platform specific C code.  It looks like it is designed to do what we
really wanted to do with D.  If we could do a D version of SWT, it likely
would be a much easier port than wxWindows.  The similarities between D
and Java are extremely useful in this case (garbage collection,
programming style) as was mentioned.

I guess my question is, developing ease aside, what would attract more D users? Is SWT as popular as wxWindows?  Would the general consensus within the D community be to use one over the other?  Since SWT is java oriented thing, I don't know if C++ developers would even be interested in it (as a way to attract them to the D language).  On the other hand, perhaps we just need to take the plunge, and get a good solid, crossplatform GUI library implemented.  One modeled after SWT might be a good bet.  So what would we call it? DWT? :-)

Later,

John

On Tue, 20 Jan 2004 19:40:34 -0800, John Reimer wrote:

> On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:
> 
>> It is nothing more than a "gut" feel on SWT.  You touched on some of the
>> issues.
>>     (More recent toolkit, heavy support from IBM).
>> 
>> SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to native Win32 have the same wrappers.
>> 
>> I have thought that maybe DUI's wrappers of GTK could be modified to use native Win32 calls and then we have the beginnings of a platform independent GUI.  Then we've created a third option in addition to wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM has had experience far beyond GTK/linux and Windows, as has wxWindows with their long history.  So I lean toward one of the existing two, and for some reason I lean further toward SWT.
>> 
>> One reason may be that it's in Java, a language far easier for me to port to D than C++.  (By the way, we are talking about a port to D, right?  I wouldn't be interested in wrapping the Java and requiring a JVM.)  That just has to do with my skill set.  The C portion of SWT source has to do with the JNI/native calls, and the meat of SWT is in the Java classes.  D doesn't need JNI, except to wrap the calls in an *.h file.
>> 
>> I am only investigating SWT, but everything looks favorable.  I haven't downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of sense, and looks like it could be moved to D.  If you want to research SWT more, that would be great.  And I'll definitely join you and help however I can...
>> 
>> Cheers,
>> Brad
> 
> 
> After a basic investigation of SWT, I have to admit that it looks
> promising, probably much more promising than wxWindows.  The C++ code in
> wxWindows along with it's religious use of macros makes it a difficult
> port to D.  It's possible, but not easy.  SWT uses JNI to connect
> to platform specific C code.  It looks like it is designed to do what we
> really wanted to do with D.  If we could do a D version of SWT, it likely
> would be a much easier port than wxWindows.  The similarities between D
> and Java are extremely useful in this case (garbage collection,
> programming style) as was mentioned.
> 
> I guess my question is, developing ease aside, what would attract more D users? Is SWT as popular as wxWindows?  Would the general consensus within the D community be to use one over the other?  Since SWT is java oriented thing, I don't know if C++ developers would even be interested in it (as a way to attract them to the D language).  On the other hand, perhaps we just need to take the plunge, and get a good solid, crossplatform GUI library implemented.  One modeled after SWT might be a good bet.  So what would we call it? DWT? :-)
> 

very well said.

I don't believe there are many project using SWT

What's the license on SWT?

(One detail I just saw on SWT it uses the beloved listener interfaces.
we would probably change the entire event processing (?))

A couple of (almost random selected) SWT links
(go to IBM.com and search for SWT):
http://www-106.ibm.com/developerworks/opensource/library/os-ecgui1/
http://www-106.ibm.com/developerworks/java/library/j-nativegui2/

(DWT as name is awfull)

Ant

Ant wrote:
> On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:
> 
>>This is an awesome idea.  I've since learned that GTK takes a very.... unique approach to grouping and arranging widgets.
> 
> I fond it natural and familiar!?...
> Maybe I on the past I used the same toolkit the designer of GTK did.
> 

I'm not judging, I just mean that it's very different from most everything else I've used.

> 
>>For one, I can't for the life of me find *any* way to simply set the position/size of a UI element.
> 
> I'm still looking for the xtToolkit way; I think is the best:
> you just say this widget goes to the left or that
> and the other goes bellow that one over there...
> 

wx does quite a lot of work to make GTK+ behave like the other implementations. (not the least of which is the custom GtkPizza widget)

> 
>>Now it's apparent why this crossplatform GUI thing is so hard. ;)
> 
> That's why we are going to base the work on some proven existing one.
> In your GUI you have 2 complete independent implementations of your API.
> 

Yup.  I never expected to get anywhere.  I'm just prototyping for my own amusement.

(by the way, I intentionally took exactly the same approach as SWT)

> 
>>(it's all GTKs fault!)
> 
> ???

That was a joke. ;)

> 
> So, do we think that SWT deserves a look right.
> (I kinda don't like the look of wxWindows web page and the demos
> are crappy).
> 

SWT already looks like the better choice to me.  D has more in common with Java than it does C++.  The similarities run deep enough that the conversion would be pretty easy.  (large amounts of it could be automated)

 -- andy

My undoubtedly unpopular opinion:

I think that the GUI should _never_ be in the standard library, and that there should _always_ be at least two competing GUI libraries. Otherwise, stagnation beckons.



"John Reimer" <jjreimer@telus.net> wrote in message news:pan.2004.01.21.02.23.37.232507@telus.net...
> Ok, I guess you guys are discussing the possibility of dropping wxWindows for SWT.  Keep discussing it a little bit more before you do, please.  It would be nice to see both sides of the argument.  I'll take a peek at SWT since I have little knowledge of it (other than having played with Eclipse).  The interface looks good.  It's developed in Java, you say? Does it have it's own widget set or does it interface to an underlying platform API? Unfortunately I'm not a Java developer and don't much like Java. But since there appear to be more people interested in this port than wxWindows, it's really hard to argue against it.
>
>
> On Tue, 20 Jan 2004 22:55:31 +0000, Ant wrote:
>
> > In article <buka0h$12k4$1@digitaldaemon.com>, Brad Anderson says...
> >>
> >>
> >>2.  I am investigating porting SWT to D to have a GUI that would use native widgets on the host OS when possible, and implemented widgets otherwise.  IBM has had great success with this library, its primary use being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - however I want a platform-independent GUI without having to distribute GTK+ or any other library on Win32.
> >
> > Before you start that maybe you could influence us to change to SWT instead of wxWindows. maybe it's better!
> >
> > we are not married to wxWindows. SWT looks very good actually. As a more recent toolkit it has all the probability of being better.
> >
> > (the wx Project probably will not have a GTK soon. I thought we were
going
> > to do the native windows and one X11 (or universal) to start with.)
> >
> > Will you be interested in join us if we change to SWT?
> >
> > What do you say guys is SWT better then wxWindows (I'm telling you, it might be - not that I looked in detail to any... ;)
> >
> > these projects are huge (unless you have full time for it) so 4/1 is
> > better then (3+1)/2.
> >
> > Ant
>

On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:

> My undoubtedly unpopular opinion:
> 
> I think that the GUI should _never_ be in the standard library,

I thing you're right.

The idea is to create something that would
be widelly used for D GUI development
and that attracts support from many developers.

How is distributed is irrelevant.
If it has quality it will be used
and DM will endorse it.
(hey, even DUI has a link from the D pages ;)

> and that
> there should _always_ be at least two competing GUI libraries.
> Otherwise, stagnation beckons.

You can always start your own;)
(that why I'm gonna start the D++ project
it's a joke)

DUI is here to stay, don't worry.
Already has (almost complete) support to Linux and Windows.
(but still is going to have a major change on the
event processing)

Ant

http://dui.sourceforge.net

On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:

> My undoubtedly unpopular opinion:
> 
> I think that the GUI should _never_ be in the standard library, and that there should _always_ be at least two competing GUI libraries. Otherwise, stagnation beckons.
> 
> 

The GUI in the standard library? I don't think that was our intention. I
may have slipped and made it sound that way earlier. All we want to do is
make a good crossplatform GUI toolkit for D. Where it goes can be decided
later. I guess some competition would be very good, yes. But at this point
there aren't an over abundance of developers to try developing
different GUI toolkits. One good solid kit would be nice for now with
several people contributing.  Otherwise, we still have DUI and
DIG.

Our main goal, so I thought, was to develop a comprehensive, well-supported, crossplatform library for D, something it does not have at the moment (DUI comes closest).  This library could, at some point perhaps, be included as an extra with the compiler suite (it doesn't have t be THE standard library, though). This library should provide an interface that should compile without changes on either platform. wxWindows almost achieves this goal for C++. That's why it was one of my first interests as a port. But C++ does not translate well to D, so it may not be a wise initial task to take on.  Not without experienced help at least.  I may play with it a bit behind the scenes for interest sake, but I still want to see a main GUI project come to fruition.

Later,

John

In article <buktia$212c$1@digitaldaemon.com>, Matthew says...
>
>My undoubtedly unpopular opinion:

Er, let's change that to 'controversial'. :-)

>I think that the GUI should _never_ be in the standard library, and that there should _always_ be at least two competing GUI libraries. Otherwise, stagnation beckons.

You're absolutely right, on both accounts.

However, we do need a gui that comes with at least Digital Mars D,
and which has precisely the same API on both Windows and Linux.
And, while DMD is not Open Source, the GUI should be. (I think Walter
would okay this?)

As to stagnation, while you're right there too, I think it is a matter
of _perceived_ competition. For the time being, the D community
perceives other languages that have GUI libraries, as competition.
Later, when D gets established, stagnation becomes a risk unless
we then have more than one GUI.

Also, we do not have to, and actually should not, divide our powers between GUIs right now! We are too few to pull it off.

If all goes like we wish, then by this time next year, D has a large enough following that we will see another port emerge anyhow. This would give us more than one good, working, GUI by the time any risk for GUI stagnation would emerge.

"Brad Anderson" <brad@sankaty.dot.com> wrote in message news:bukd2i$17hb$1@digitaldaemon.com...
> One reason may be that it's in Java, a language far easier for me to port
to D
> than C++.

I never thought about that. It might even be possible to do machine translation of Java to D. (Of course, that wouldn't help with the differences in the underlying runtime libraries, and one has to be careful that the Java code being translated is public domain or freely redistributable or GPL.)

>  (By the way, we are talking about a port to D, right?

Yes.

>  I wouldn't be
> interested in wrapping the Java and requiring a JVM.)

I doubt many would be interested in the results of that, either <g>.

"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.01.21.03.44.02.162329@yahoo.ca...
> What's the license on SWT?

That's the first thing to check. If it doesn't have a compatible license, there's no point in looking at it any further. It must be one of:

1) public domain
2) copyrighted, but freely modifiable and redistributable for any purpose
3) GPL