In article <bu70il$i7n$1@digitaldaemon.com>, Ilya Minkov says...
>
>Ant wrote:
>> That is the way of the past!
>> Can we go with an OpenGL toolkit?
>> Is that even an hipoteses?
>
>I had already thought about something like that, but it is very problematic. In fact, ld0d (a well known finnish demoscene coder) dropped the idea when i mentioned GUI toolkits running upon libSDL.

Most of OpenGL GUI toolkits seem to have been abandoned. :{
I installed glow (abandoned 3+ years ago) and it feels OK.
I'm gonna look into the code to see how the widgets are generated
and if there are any hidden tricks. It's glut based. I don't know
how glut does it.
I'll install a couple of other ones to see how they feel.
I'll let you guys know if I start this project (not soon anyway)
Any more advices are welcome but I'm donne take this discussion
somewhere else until it becames relevant for D. For now it's
becaming just an OpenGL thing.

Ant

While it was 15/1/04 6:37 pm throughout the UK, Lars Ivar Igesund sprinkled little black dots on a white screen, and they fell thus:

<snip>
>> There are a few OpenGL wizards here.
>> What do you thing? Is that a good idea?

Hold on ... what do we mean by "OpenGL wizards" here?

> Good and bad.
> 
> Pros:
>   - Look cool and possibly very different.
>   - Relatively easy to port (like mentioned)
>   - Can be 3D
>   - Fairly easy to make skinnable (for native and non-native looks.)
> 
> Cons:
>   - Likely very system demanding and that means that it's a no no for
>       older and/or portable systems.

Really?  Do a lot of GUI libraries have that much of an overhead for the simplest of cases worth considering?

>   - Cool look might be alienating
>   - Can be 3D
<snip>

Not to mention that if I'm creating a native Windows app, I for one would prefer to use the native Windows way of defining dialogs, menus and the like.  This is the principle behind native Windows libraries like OWL, MFC and the like, and behind my own project SDWF (Stewart's D Windows Framework).

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <bu9043$so5$1@digitaldaemon.com>, Stewart Gordon says...
>
>
>Hold on ... what do we mean by "OpenGL wizards" here?

people that know more then I do.

>
>Not to mention that if I'm creating a native Windows app, I for one would prefer to use the native Windows way of defining dialogs, menus and the like.  This is the principle behind native Windows libraries like OWL, MFC and the like, and behind my own project SDWF (Stewart's D Windows Framework).

that's why wxWindows is being suggested. With the advantage of not being tied to windows only.

I just had a different idea, doesn't mean it's a good idea and it does not interfere with windows centric stuff.

Ant

If I had my way, we'd create the minimum library with which you can make GUI programs. This library would be just a thin layer on top of the native (or in Linux, some of the most used GUI alternatives, such as KDE, Gnome) windowing system, giving us the native look and feel.

Only the essential widgets would be supported. While this would preclude doing fancy programs (which the younger generation always are eager to do), it would let people and companies to start making 'bread-and-butter' applications right now. And those would be portable as such.

This should be incorporated in the D standard. A little
like we now have basic math, file, uri, stream, and thread
libraries in the standard. This way anybody programming in D
could take for granted that they have a drop-down box, a
text input area, etc. and an SDI window, a message box,
a file dialog, etc. -- But nothing that is not absolutely
essential.

Then, if one wants to do Serious Maths, or 3D apps, or skinned UIs, or whatever, they could choose from the available fancy libraries for their OS, or application area.

A KDE, Gnome, or Windows professional could write the stuff to our standard spec in just a few days? And when D comes available for other OSs it would just be a matter of days to port the stuff there too.

I feel this is a no-brainer. Really. A practical solution for a practical language for practical programmers.

Again, "Simplicity, Clarity, Generality", Kernighan & Pike.

In article <bu94h8$13l1$1@digitaldaemon.com>, Georg Wrede says...
>
>If I had my way, we'd create the minimum library with which you can make GUI programs. This library would be just a thin layer on top of the native (or in Linux, some of the most used GUI alternatives, such as KDE, Gnome) windowing system, giving us the native look and feel.
>
>Only the essential widgets would be supported. While this would preclude doing fancy programs (which the younger generation always are eager to do), it would let people and companies to start making 'bread-and-butter' applications right now. And those would be portable as such.
>

doesn't that describes java's AWT?

Ant

"Ant" <Ant_member@pathlink.com> wrote in message news:bu6jhe$2s6g$1@digitaldaemon.com...
> >> Any suggestions as for which GUI library is the best one?  wxWindows?
>
> Walter said:
>
> >wxWindows is certainly a contender.
>
> That is the way of the past!
> Can we go with an OpenGL toolkit?
> Is that even an hipoteses?
>
> There are a few OpenGL wizards here.
> What do you thing? Is that a good idea?
>
> there are already a couple of open GL GUI toolkits
> started. I would start from scrach but looking
> of the good toolkits available.
>
> The advantages are many and include:
> - protability! - write once compile any where
> - capabilities that current toolkits can't even dream of
>
> the disadvantage are few and include:
> - non native look :((((( unless something like java swing is used
>
> I wouldn't mind colaborating on such a thing,
> for old, retrograde toolkits I already have DUI.
> (I might even start one after... and if nobody
> takes up on the idea)
>
> Ant
>
> DUI - D graphical User Interface
> http://dui.sourceforge.net
>
> (I have my reasons not to post the links to the existing
> OpenGL toolkits that I'm not disclosing, sorry.
> It's not shameless promotion of DUI.
> They should be easy to find anyway.)

I am no expert on GUI programming. From an outsider, the advantages of wxWindows are:

1) it has been around for a while, and it works
2) it's free
3) it's been ported to many platforms

I am not in a position to judge the relative technical merits. If DUI is better, great!

In article <bu96dl$16vu$1@digitaldaemon.com>, Ant says...
>
>In article <bu94h8$13l1$1@digitaldaemon.com>, Georg Wrede says...
>>
>>If I had my way, we'd create the minimum library with which you can make GUI programs. This library would be just a thin layer on top of the native (or in Linux, some of the most used GUI alternatives, such as KDE, Gnome) windowing system, giving us the native look and feel.
>>
>>Only the essential widgets would be supported. While this would preclude doing fancy programs (which the younger generation always are eager to do), it would let people and companies to start making 'bread-and-butter' applications right now. And those would be portable as such.
>>
>
>doesn't that describes java's AWT?

Well, about. Prune a little here and there, prioritize textual
components over some of the more labourious graphic stuff,
skip audio, concentrate on keeping native look&feel.
And I'm not sure about the layout managers.

The event model should also be such that it is easy to
implement on the various platforms. Usability for business
apps and ease of programming (of both client apps (users)
and the GUI itself (us)) is paramount.

This GUI API should be easy to implement soon. It should be expected that it will later become a secondary api, when more complete D GUI APIs become widely available. But still, I expect this api to stay too, later it will be used for smaller programs and rapid prototyping.

The AWT is old. Today we have a lot more experience on what is needed and what was wrong/too costly with the AWT. And what parts people really didn't use enough to warrant the cost of implementing.

In article <bu9joh$1su1$1@digitaldaemon.com>, Georg Wrede says...
>
>In article <bu96dl$16vu$1@digitaldaemon.com>, Ant says...
>>
>>In article <bu94h8$13l1$1@digitaldaemon.com>, Georg Wrede says...
>>>
>>>If I had my way, we'd create the minimum library with which you can make GUI programs. This library would be just a thin layer on top of the native (or in Linux, some of the most used GUI alternatives, such as KDE, Gnome) windowing system, giving us the native look and feel.
>>>
>>>Only the essential widgets would be supported. While this would preclude doing fancy programs (which the younger generation always are eager to do), it would let people and companies to start making 'bread-and-butter' applications right now. And those would be portable as such.
>>>
>>
>>doesn't that describes java's AWT?
>
>Well, about. Prune a little here and there, prioritize textual
>components over some of the more labourious graphic stuff,
>skip audio, concentrate on keeping native look&feel.
>And I'm not sure about the layout managers.
>
>The event model should also be such that it is easy to
>implement on the various platforms. Usability for business
>apps and ease of programming (of both client apps (users)
>and the GUI itself (us)) is paramount.
>
>This GUI API should be easy to implement soon. It should be expected that it will later become a secondary api,

I disagree here!
that api must be done in such away that would be extensible,
in fact maybe the full feature design could be made and
implemented in phases.


>when
>more complete D GUI APIs become widely available. But still,
>I expect this api to stay too, later it will be used for
>smaller programs and rapid prototyping.

Probably the same idea of phases or stages could be used here. I don't think two independed APIs are needed for that.

>
>The AWT is old. Today we have a lot more experience on what is needed and what was wrong/too costly with the AWT. And what parts people really didn't use enough to warrant the cost of implementing.

no wheel reinvention needed, indeed.

Ant

In article <bu9jk5$1sp7$1@digitaldaemon.com>, Walter says...
>
>
>"Ant" <Ant_member@pathlink.com> wrote in message news:bu6jhe$2s6g$1@digitaldaemon.com...
>> >> Any suggestions as for which GUI library is the best one?  wxWindows?
>>
>> Walter said:
>>
>> >wxWindows is certainly a contender.
>
>I am no expert on GUI programming. From an outsider, the advantages of wxWindows are:
>
>1) it has been around for a while, and it works
>2) it's free
>3) it's been ported to many platforms
>
>I am not in a position to judge the relative technical merits. If DUI is better, great!
>

I believe the wxWindows deserves a closer look.
It's an obvious choice.
When starting DUI I did consider wxWindows but
seemed to me that it would be easier to wrap GTK.

If we can get a team to work on the GUI lib other considerations might be more important.

Ant

>>I am no expert on GUI programming. From an outsider, the advantages of wxWindows are:
>>
>>1) it has been around for a while, and it works 2) it's free
>>3) it's been ported to many platforms
>>
>>I am not in a position to judge the relative technical merits. If DUI is better, great!
>>
>>
> I believe the wxWindows deserves a closer look. It's an obvious choice. When starting DUI I did consider wxWindows but seemed to me that it would be easier to wrap GTK.
> 
> If we can get a team to work on the GUI lib other considerations might be more important.
> 
> Ant

From what I've seen, wxWindows would be a good choice.  Like Walter says, it is very cross platform and supports multiple languages.  If ever a project is worthwhile, I think this one warrants looking into.  The main problem would be the shear size of wxWindows.  It's not a small project, to say the least.  I think we still need independent "small" GUI's to serve specific purposes. But wxWindows would be a good crossplatform project to start with for D.

I definitely think DUI (which should almost be called GtkD or something to reveal its intentions; the name "DUI" gives the impression of an independent GUI library) should stick around as another Gtk binding. I also think other D language bindings for Gnome libraries and others would be important eventually. Gtk may be cross-platfrom, but I don't consider that it's main strength (I don't much like the windows version of it). It's a very good library for unix-based systems and popular enough there that it's important for D to support it. But the main thing I don't like about it is it's endless dependencies and library inclusions (so many that you need to run pkg-config to round up all the required libs).  This may be a normal thing for Linux, but it's disturbing for the windows version. I wish things were a little simpler, and we had a good solid simple library.

In summary,

my opinion is that 3 GUI versions should be supported for D:

1) wxWindows -- cross-platform for D
2) DUI -- Linux/BSD Gtk2 based GUI
3) DIG or Windy -- specific windows based GUI

I don't have much experience in interface design and big coding projects, but I'd be interested to try to help with the wxWindow projct conversion. But I think quite a few people would be needed to make it a success. One issue: I was under the impression that it was a C++ library.  If so a quick conversion wouldn't be that easy; I think this was discussed before in a previous post in which the SWIG tool was brought up. It would be very interesting to see if this works now. Has anybody tried to use SWIG yet?

The other 2 can evolve with time, but perhaps people should continue to make serious projects of them.  I definitely think DUI is an important addition to the Linux development scene. Keep up the good work Ant.

Later,
John