"Mark Evans" <Mark_member@pathlink.com> schrieb im Newsbeitrag news:albltl$39t$1@digitaldaemon.com...

> I like OpenAmulet, but the project has gone stale; no one works on it any
more.

Hi, yep that's the petty. I really don't have any time to spend on it.. :-(( even it has such a great concept. And noone else took the stake. Robert

>
>Why not just port one of the C++ open source ones?
>

That's possible.  I would argue instead for something like a SWIG wrapper that can make C++ accessible to D without rewriting the whole library; e.g. the way that wxPython works with wxWindows.

Developing and maintaining a D port is a huge proposal, but maintaining a D interface to the C++ is manageable.  The burden of feature enhancements and bug fixes remains on the shoulders of the C++ library developers.

Mark

>
>Anyone who believes strongly that a gui should be done a certain way won't get any argument from me, other than encouragement to implement it in D! D will be better off having a rich assortment of gui toolkits available.
>

Fully agreed, Walter!  The more the better!

D does not need "built-in GUI support" any more than C++.

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:algbei$2i6b$1@digitaldaemon.com...
>
> >
> >Why not just port one of the C++ open source ones?
> >
>
> That's possible.  I would argue instead for something like a SWIG wrapper
that
> can make C++ accessible to D without rewriting the whole library; e.g. the
way
> that wxPython works with wxWindows.
>
> Developing and maintaining a D port is a huge proposal, but maintaining a
D
> interface to the C++ is manageable.  The burden of feature enhancements
and bug
> fixes remains on the shoulders of the C++ library developers.

That's probably the right initial way to do it, especially if it is a large, complex code base.

On Sun, 01 Sep 2002 20:43:26 -0500, Toyotomi <io219@attbi.com> wrote:

>On Thu, 29 Aug 2002 11:59:56 -0500, "Craig Black" <cblack@ara.com> wrote:
>
>>I could help but notice the:
>>"Attempts to create a common GUI class library between Windows, Mac, and
>>other GUI operating systems have all to my knowledge failed."
>>
>>Qt is a feature-rich cross platform GUI framework for C++: www.trolltech.com
>>
>
>And don't forget the new SWT from IBM used with Java
>but written in a compiled language with multi-platform
>abstractions. Maybe D should even use SWT.
>
>Seriously, check it out if you have clout...

The problem is, like C++, those C++ toolkits do not suit us.
SWT is the best I know of ( though VCL is more complete & flexible )
SWT was designed for use with Java but is NOT written in Java.
( Java2D is not written in Java either, it's straight portable C )
SWT is multiplatform, but uses native widgets when possible.
Someone should work on getting SWT support in D.

90% of the many C++ toolkits are rather hilarious.

Toyotomi wrote:

> SWT was designed for use with Java but is NOT written in Java.
> ( Java2D is not written in Java either, it's straight portable C )
> SWT is multiplatform, but uses native widgets when possible.
> Someone should work on getting SWT support in D.

Where can I download SWT as a separate package?

"Toyotomi" <io219@attbi.com> wrote in message news:rp2qnu8bdjp3j9helj81oai1cts650s4l7@4ax.com...
> SWT was designed for use with Java but is NOT written in Java.

Which is why Java is not a systems language.

> 90% of the many C++ toolkits are rather hilarious.

Sure. That leaves 10% which can be mined for great ideas!

Toyotomi wrote:

> On Sun, 01 Sep 2002 20:43:26 -0500, Toyotomi <io219@attbi.com> wrote:
> 
>>On Thu, 29 Aug 2002 11:59:56 -0500, "Craig Black" <cblack@ara.com> wrote:
>>
>>>I could help but notice the:
>>>"Attempts to create a common GUI class library between Windows, Mac, and
>>>other GUI operating systems have all to my knowledge failed."
>>>
>>>Qt is a feature-rich cross platform GUI framework for C++: www.trolltech.com
>>>
>>
>>And don't forget the new SWT from IBM used with Java
>>but written in a compiled language with multi-platform
>>abstractions. Maybe D should even use SWT.
>>
>>Seriously, check it out if you have clout...
> 
> The problem is, like C++, those C++ toolkits do not suit us.
> SWT is the best I know of ( though VCL is more complete & flexible )
> SWT was designed for use with Java but is NOT written in Java.
> ( Java2D is not written in Java either, it's straight portable C )
> SWT is multiplatform, but uses native widgets when possible.
> Someone should work on getting SWT support in D.
> 
> 90% of the many C++ toolkits are rather hilarious.

SWT is written almost completely in java. There is a small native dll/so written in C, but this is nothing more than a bridge to the native OS calls, with no functionality. Trust me on this one, I used to work on the SWT team.

Curt

>
> SWT is written almost completely in java. There is a small native dll/so written in C, but this is nothing more than a bridge to the native OS calls, with no functionality. Trust me on this one, I used to work on the SWT team.
>
I've been looking through the SWT code, very interesting, especially the thick layering (multipul versions of the same high level class)  rather than more layers of wrapper classes (like the AWT with its Peer Classes).

one complaint I would have about this is maintanability, and reliance on
underlying OS support not changing
features like CoolBars, are emulated under GTK, and are mapped to the Win32
common control if present on Win32. (good thing/bad thing I'm not 100%
desided)

so here's my 10pen'th on cross-platfrom GUI's

Java forces some rather unpleasant effects within the SWT i.e. the win32
Control has 60+ virtual functions just to handle the windows messages. I
know that Delphi has a dynamic method that the VCL uses to reduce the vtable
usage (quite what they are I don't know) and my own beginings of a GUI
Library I chose to use a uint to delegate assoc array to handle the
messages. if there was a language feature many GUI libraries require its
call by id, (where id is an int).
the gtk's use of strings and callbacks lowers this to about 20.

when I started working on my Gui code, I had the feeling it should be "all
or nothing" with respect to features
so I wrote it to just ease Message handling, so it processes all messages,
WM_COMMAND/NOTIFY are separated out becuase they are message groups in
themselves and WM_DESTROY is processed.
every thing else is just a message including paint
if you want the paint message you attach a delegate that takes a HDC as a
param and in there all graphics are done by using standard win32 calls.
meaning that the only difference between writing in Win32 C and my lib, is
you never have to use SendMessage or write a WndProc. all the rest is the
same (ish).

then I intended to write a cross-platform GUI lib over the top using just
two base classes (written for each underlying OS and with no dependant
features)
NativeRootFrame and NativeBaseWidget
with all message passing, rendering and other stuff handled by OS/Platform
independant code.

but stumbled straight back to the "all or nothing",
and just ended up with a list of questions:

how rich does the 2D Gui API have to be ?
you can get by with a renderable Widget that has horizontal and vertical
straight line draw, pixel plot, rect fill, image 1:1 render, and text
rendering support.
draw/fill arc is nice if you want MacOS/PalmOS rounded buttons (transparent
images can be use)

OS/GUI library each have their own Mouse behaviours e.g. Windows, Beos, GTK,
Java AWT
which one is "right" ?

can a widgets children overlap each other ?
when you put radio buttons visually into a frame , should they be children
of the frame or of the dialog (like the frame is)  [my vote is no
overlapping] ?

Resources or Dynamic creation only ? [I'm in favor of a good XML based OS independant Resource format]

which is more important syntax (and ease of programming an app) or
implemented features ?
[I think syntax, today, tomorrow I'll want features  :) ]

how cross platform is cross platform the same as the compiler (win32 and
GTK), planned for most GUI OS's(win32, Beos, GTK, X (no gtk or motif),
MacOs, WinCE, PalmOS) or anything with a screen (including embedded, Gamboy
Advance, Playstations etc) ?

well that was more like £2.50 but never mind.

Just found this
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
the only item it misses that I know about is TurboVision even has a link to
Netscapes IFC (Java)

> >>
> >>>I could help but notice the:
> >>>"Attempts to create a common GUI class library between Windows, Mac,
and
> >>>other GUI operating systems have all to my knowledge failed."
> >>>
> > 90% of the many C++ toolkits are rather hilarious.
>
> SWT is written almost completely in java. There is a small native dll/so written in C, but this is nothing more than a bridge to the native OS calls, with no functionality. Trust me on this one, I used to work on the SWT team.
>