www.digitalmars.com         C & C++   DMDScript  

D - D gui

reply Ant <Ant_member pathlink.com> writes:
 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.)
Jan 15 2004
next sibling parent reply "Lars Ivar Igesund" <larsivar igesund.net> writes:
"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?


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.
  - Cool look might be alienating
  - Can be 3D


 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)


I would love to at least discuss the possibilities and implications.

Lars Ivar Igesund
Jan 15 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bu6m86$30me$1 digitaldaemon.com>, Lars Ivar Igesund 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.


 That is the way of the past!
 Can we go with an OpenGL toolkit?





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.


Realy! I though the bulck of the work
would be done by the hardware.


  - Cool look might be alienating


I can be as dull as you want it to be. :)


  - Can be 3D


Ins't that a pro? if properly used.

I would love to at least discuss the possibilities and implications.

Lars Ivar Igesund


Ant
Jan 15 2004
next sibling parent "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bu6mpd$31ii$1 digitaldaemon.com...

 Realy! I though the bulck of the work
 would be done by the hardware.


Yes, but older systems have very lacking 3D hardware and then
the main CPU must do the work (which is very intensive).


  - Can be 3D


 Ins't that a pro? if properly used.


Well, I put it under pro too ;)

Lars Ivar Igesund
Jan 15 2004
prev sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
inline

In article <bu6mpd$31ii$1 digitaldaemon.com>, Ant says...

In article <bu6m86$30me$1 digitaldaemon.com>, Lars Ivar Igesund 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.


 That is the way of the past!
 Can we go with an OpenGL toolkit?





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.


Realy! I though the bulck of the work
would be done by the hardware.


If it's available.  Most new systems shipped today have some
decent/minimal hardware accelerated graphics but this but this 
trend is only a couple of years old.  There are a lot of legacy
systems out there that would have trouble supporting this.


  - Cool look might be alienating


I can be as dull as you want it to be. :)


  - Can be 3D


Ins't that a pro? if properly used.

I would love to at least discuss the possibilities and implications.




It would be interesting to look at.  Isn't the GUI for MacOS X
done with OpenGL?
Jan 15 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <bu6nm5$1fk$1 digitaldaemon.com>, Patrick Down says...

inline


wxWindows is certainly a contender.


 That is the way of the past!
 Can we go with an OpenGL toolkit?





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.


Realy! I though the bulck of the work
would be done by the hardware.


If it's available.  Most new systems shipped today have some
decent/minimal hardware accelerated graphics but this but this 
trend is only a couple of years old.  There are a lot of legacy
systems out there that would have trouble supporting this.


Don't look back! Look forward!


It would be interesting to look at.  Isn't the GUI for MacOS X
done with OpenGL?


This is not a new idea.
The first time I remember was some years ago when I was
experiment with the fox toolkit.
( http://www.fox-toolkit.org ) 
One of the fox objectives is to be fast and the guy
said that he sould really skip all the layers and go
directly to OpenGL interface.

Ant
Jan 15 2004
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bu6op9$3fr$1 digitaldaemon.com>, Ant wrote:

 In article <bu6nm5$1fk$1 digitaldaemon.com>, Patrick Down says...

If it's available.  Most new systems shipped today have some
decent/minimal hardware accelerated graphics but this but this 
trend is only a couple of years old.  There are a lot of legacy
systems out there that would have trouble supporting this.


 
 Don't look back! Look forward!


Good principle, especially when basic hardware 2d/3d acceleration is
such an abundant feature that you can expect to have it everywhere. And
you could have different implementations for the toolkit, not
necessarily looking the same - implemented using OpenGL, DirectX, native
graphics primitives, even one using the native widget set if the
back-end is made high-level enough.


It would be interesting to look at.  Isn't the GUI for MacOS X
done with OpenGL?


 
 This is not a new idea.
 The first time I remember was some years ago when I was
 experiment with the fox toolkit.
 ( http://www.fox-toolkit.org ) 
 One of the fox objectives is to be fast and the guy
 said that he sould really skip all the layers and go
 directly to OpenGL interface.


Is Fox really implemented in "pure" OpenGL? I didn't find any mention
about it in the docs... Anyway, thanks for the link, it looks like a
nice toolkit. I had never heard about it before!

-Antti
Jan 19 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <slrnc0oa7s.1o3.jsykari pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
says...

Is Fox really implemented in "pure" OpenGL? I didn't find any mention
about it in the docs...


oh, no, I'm sorry if I miss lead you.
That's something he said on the mailing list several years 
ago when speaking on all the layers from the application
to the hardware. He said that OpenGL would a more direct route.


Anyway, thanks for the link, it looks like a
nice toolkit. I had never heard about it before!

-Antti


Ant
Jan 19 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Antti Sykäri wrote:

[...]

 Anyway, thanks for the link, it
 looks like a nice toolkit. I had never heard about it before!


Try a look at 
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html,
[cited 25.01.04]

So long.
-- 
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/  
2EA56D6D4DC41ABA311615946D3248A1
Jan 24 2004
prev sibling next sibling parent reply "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bu6m86$30me$1 digitaldaemon.com...

   - Fairly easy to make skinnable (for native and non-native looks.)


Of course, on Windows, there are currently no possibility to switch toolkit,
the OpenGL one would have to work on top of the Windows one.
This of course rules it out as a standard library GUI toolkit.

Lars Ivar Igesund
Jan 15 2004
parent "Lars Ivar Igesund" <larsivar igesund.net> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bu6mtk$77$1 digitaldaemon.com...

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:bu6m86$30me$1 digitaldaemon.com...

   - Fairly easy to make skinnable (for native and non-native looks.)


 Of course, on Windows, there are currently no possibility to switch


toolkit,

 the OpenGL one would have to work on top of the Windows one.
 This of course rules it out as a standard library GUI toolkit.


Duh. IMHO.

Lars Ivar Igesund
Jan 15 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 16 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
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
Jan 16 2004
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
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.
Jan 16 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 16 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
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.
Jan 16 2004
parent Ant <Ant_member pathlink.com> writes:
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
Jan 16 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:

 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.
 


I may be getting a bit carried away here, but I think that a definitive 
GUI toolkit for D, implemented in D would be a nice sort of litmus test 
for the same reason that it's neat that D's garbage collector is 
implemented in D. (let's see Java do that!)

The fact that the current attempts work as well as they do suggests that 
this isn't at all unreasonable.  It's just a matter of us getting our 
respective egos in line and working on one toolkit instead of 
three/six/eight/four hundred. :)

All this really requires is that a single interface be chosen.  Once we 
can decide on that (*if* we can decide on that), it's pretty much a 
matter of hacking up dig/windy/whatever and DUI so that they both match 
that interface.

  -- andy
Jan 16 2004
parent reply John Reimer <John_member pathlink.com> writes:
I may be getting a bit carried away here, but I think that a definitive 
GUI toolkit for D, implemented in D would be a nice sort of litmus test 
for the same reason that it's neat that D's garbage collector is 
implemented in D. (let's see Java do that!)


True, that would be nice.


The fact that the current attempts work as well as they do suggests that 
this isn't at all unreasonable.  It's just a matter of us getting our 
respective egos in line and working on one toolkit instead of 
three/six/eight/four hundred. :)


True.


All this really requires is that a single interface be chosen.  Once we 
can decide on that (*if* we can decide on that), it's pretty much a 
matter of hacking up dig/windy/whatever and DUI so that they both match 
that interface.


It would be nice to at least model a D GUI library after wxWindows.  It's just
so prevalent and familiar to C++ users.  Much of it's popularity is because of
an apparent good design and ease of use.  It would be interesting to see what
one could do using D features in the making of such a windowing kit.  It would
be good practice converting C++ code to D.  On the other hand, I may not have a
clue about what I'm talking about.  But I'm very interested to see what's
involved in a wxWindows system for D.  The more I read through the wxWindows web
site, the more interested I get in it.

Later,

John
Jan 16 2004
parent reply John Reimer <John_member pathlink.com> writes:
It would be nice to at least model a D GUI library after wxWindows.  It's just
so prevalent and familiar to C++ users.  Much of it's popularity is because of
an apparent good design and ease of use.  It would be interesting to see what
one could do using D features in the making of such a windowing kit.  It would
be good practice converting C++ code to D.  On the other hand, I may not have a
clue about what I'm talking about.  But I'm very interested to see what's
involved in a wxWindows system for D.  The more I read through the wxWindows web
site, the more interested I get in it.


I'm going to look into wxWindows and D.  I've been looking over wxWindows a bit
and the more I see the more I think it can be done.  When I get a chance I'll
download the source and see what kind of hunt/convert things are necessary
(automation would be easier, but my knowledge level is inadequate ATM).  Since
I'm working literally all weekend, that'll have to be sometime next week to even
get a glance.  For now I'll content myself with studying the design/structure to
get familiar with it.  Since I'll have to mix it with some real studies, this
may be a very slow process (now isn't that an original excuse?). But man it's
tempting to see a D version of wxWindows...  

At first I was horrified to see major use of C++ macros in the wxWindows design,
but I noticed that there are ways around it: specifically using the dynamic
event routing feature over the macros-based static event table.  The other nice
thing about wxWindows which will ease porting is the use of fairly basic C++
features.  It has avoided the use of templates, C++ exceptions, and C++ RTTI
(The templates were avoided because of variances in C compilers)  It should be
interesting to see how D can improve it with some features.  Oop, I'm getting
carried away with this...I may be over-extending myself...but

Later,

John

PS. There's also a wxGTK+ that encapsulates the GTK+ libraries with wxWindows on
Linux. If DUI could do this, an equivalent should be quite possible with D and
wxWindows here also.  Once the conversion is done on the windows side, it should
be easy to do equivalent changes on the to wxGTK+ following the windows versions
D structure.
Jan 17 2004
parent reply John Reimer <John_member pathlink.com> writes:
 It has avoided the use of templates, C++ exceptions, and C++ RTTI
(The templates were avoided because of variances in C compilers)  It should be
interesting to see how D can improve it with some features.  Oop, I'm getting
carried away with this...I may be over-extending myself...but


I'll be forever correcting myself :-(.  Templates are supported in wxWindows.
It's STL that isn't used because of variances across compilers. My apologies!
Jan 17 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
I wonder if we could port only parts of wxWindows? Or is
the code such that the difference in effort is negligible?

Like some parts of everything vs. every part of something?

Or, could we use wxWindows as a binary library? And then
make a thin layer on top of it in D?

I checked their screen shots, and it all was very impressive.
But I'm no pro at evaluating the needed effort.

Should we decide on a specific version of DMD for the job?
I think we should. Even so, the GUI library could be used 
from newer DMD versions, shouldn't this just be about 
linking, which I assume will not change?
Jan 17 2004
parent reply John Reimer <John_member pathlink.com> writes:
In article <bubh0q$24jo$1 digitaldaemon.com>, Georg Wrede says...

I wonder if we could port only parts of wxWindows? Or is
the code such that the difference in effort is negligible?


Definitely only parts to start with. There's just too many things there to try
to integrate completely.  The basic structure should be implementable with
wxObject, wxApp, wxFrames, a few controls and some wxEvents/handlers. The rest
can be added gradually, I think.  In the wee hours of this morning, I played
with a mock-up of a D style wxWindows program to get the feel for it.  I just
converted the wxWindows hello world app to D to see what it looked like.  If I
can actually implement a small app, it would be a start, and then slow
improvement additions from there.  


Like some parts of everything vs. every part of something?


Some parts for now would be better.  Like I said, too much there to cover at
once and most of it isn't that critical to a basic funtioning app.


Or, could we use wxWindows as a binary library? And then
make a thin layer on top of it in D?


Binary library? I don't understand. It's a C++ library. D can't interface it
unless someone knows some magic for D to C++ interfacing (SWIG anyone?). Fixing
the source, I think, will require going through the wxWindows files and trying
to convert structures to D style stuff.  What I can gather after looking at some
of the source in the cvs tree: removal of lots of C++ macros, use of D
version{}, reimplementation of bits and pieces, conversion of events to
delegates, etc. (and some snooping in the DUI source to see how some of it is
done ;-) Unless there's an easier way I didn't think about...which is quite
possible.


I checked their screen shots, and it all was very impressive.
But I'm no pro at evaluating the needed effort.


Heh, I know what you mean... After looking things over, I'm pretty sure this one
will be a big effort...


Should we decide on a specific version of DMD for the job?
I think we should. Even so, the GUI library could be used 
from newer DMD versions, shouldn't this just be about 
linking, which I assume will not change?


Why wait? I'm just going to see what can be done in a basic way for now. D is
easily ready for it, I think. I'm just wondering if I am.  Future D versions
just have to recompile the library if necessary.  If deprecated language
features eventually must be removed/replaced from the library, well that's been
done before. No promises.  This will be a little, quiet experiment from my end.
I'm just really interested in the possibilites.  It has strong potential for
beautiful interfacing on both Windows and Linux (and Mac OS if we ever get a D
backend for it).  Did I mention that there's an 

Later,

John
Jan 17 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bubkbb$29oj$1 digitaldaemon.com>, John Reimer says...

In article <bubh0q$24jo$1 digitaldaemon.com>, Georg Wrede says...

I wonder if we could port only parts of wxWindows? Or is
the code such that the difference in effort is negligible?


Definitely only parts to start with. There's just too many things there to try
to integrate completely.  The basic structure should be implementable with
wxObject, wxApp, wxFrames,


can we drop the "wx"? please.

Ant
Jan 17 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:


In article <bubkbb$29oj$1 digitaldaemon.com>, John Reimer says...
  


In article <bubh0q$24jo$1 digitaldaemon.com>, Georg Wrede says...
    


I wonder if we could port only parts of wxWindows? Or is
the code such that the difference in effort is negligible?
      


Definitely only parts to start with. There's just too many things there to try
to integrate completely.  The basic structure should be implementable with
wxObject, wxApp, wxFrames,
    


can we drop the "wx"? please.

Ant

  


Why not do what Burton did with dig/opengl and make it a namespace. 
Actually, dig supported both forms more-or-less.

Anderson
Jan 17 2004
prev sibling parent John Reimer <John_member pathlink.com> writes:
can we drop the "wx"? please.

Ant


I suppose, if no body wants them... That kind of loses the feel of wxWindows,
though.  It looks then that people want a library "based" on wxWindows and not
one that is a near duplicate.  That's fine.
Jan 17 2004
prev sibling parent reply "C" <dont respond.com> writes:
I used to use wxWindows alot , there are a couple of issues with it I found.

Its only truly cross-platform if you stay with in the wx framework , which
explains why its so huge , and even then there is some problems with spacing
correctly on each platform ( wxSizer is just an abstraction  layer for
some ) , resource scripts , icons and so on ( although in my experience it
didnt take much to fix it ).

Somebody mention this a while back  , but wxHaskell
 http://wxhaskell.sourceforge.net/ ) has a wxC interface , but after looking
it over it seems to only be C prototypes , and the definition of the
functions in haskell ( I really dont know though I dont use Haskell , it
would  be good if someone with knowledge of C/Haskell integration could
confirm ) ?  It also looks like C++ , not C.

I was hoping that wxUniversal which implements all its own widgets ( and
looks real good ) was C but no luck.  So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice ( once
for win32 , once for GTK).

Keep us updated on progress ?

C


"John Reimer" <John_member pathlink.com> wrote in message
news:bubkbb$29oj$1 digitaldaemon.com...

 In article <bubh0q$24jo$1 digitaldaemon.com>, Georg Wrede says...

I wonder if we could port only parts of wxWindows? Or is
the code such that the difference in effort is negligible?


 Definitely only parts to start with. There's just too many things there to


try

 to integrate completely.  The basic structure should be implementable with
 wxObject, wxApp, wxFrames, a few controls and some wxEvents/handlers. The


rest

 can be added gradually, I think.  In the wee hours of this morning, I


played

 with a mock-up of a D style wxWindows program to get the feel for it.  I


just

 converted the wxWindows hello world app to D to see what it looked like.


If I

 can actually implement a small app, it would be a start, and then slow
 improvement additions from there.


Like some parts of everything vs. every part of something?


 Some parts for now would be better.  Like I said, too much there to cover


at

 once and most of it isn't that critical to a basic funtioning app.


Or, could we use wxWindows as a binary library? And then
make a thin layer on top of it in D?


 Binary library? I don't understand. It's a C++ library. D can't interface


it

 unless someone knows some magic for D to C++ interfacing (SWIG anyone?).


Fixing

 the source, I think, will require going through the wxWindows files and


trying

 to convert structures to D style stuff.  What I can gather after looking


at some

 of the source in the cvs tree: removal of lots of C++ macros, use of D
 version{}, reimplementation of bits and pieces, conversion of events to
 delegates, etc. (and some snooping in the DUI source to see how some of it


is

 done ;-) Unless there's an easier way I didn't think about...which is


quite

 possible.


I checked their screen shots, and it all was very impressive.
But I'm no pro at evaluating the needed effort.


 Heh, I know what you mean... After looking things over, I'm pretty sure


this one

 will be a big effort...


Should we decide on a specific version of DMD for the job?
I think we should. Even so, the GUI library could be used
from newer DMD versions, shouldn't this just be about
linking, which I assume will not change?


 Why wait? I'm just going to see what can be done in a basic way for now. D


is

 easily ready for it, I think. I'm just wondering if I am.  Future D


versions

 just have to recompile the library if necessary.  If deprecated language
 features eventually must be removed/replaced from the library, well that's


been

 done before. No promises.  This will be a little, quiet experiment from my


end.

 I'm just really interested in the possibilites.  It has strong potential


for

 beautiful interfacing on both Windows and Linux (and Mac OS if we ever get


a D

 backend for it).  Did I mention that there's an

 Later,

 John
Jan 17 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bubp32$2h2q$1 digitaldaemon.com>, C says...

 So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice ( once
for win32 , once for GTK).


and once for mac, and once for BeOS, and once....

I thought that was the idea.
I thought that is what Walter suggested.

We are using wxWindows for 2 reasons (as I see it - mainly):
- C++ code can be converted to D (with more or less difficulty)
- it's a proven GUI so we don't get cought in common traps
  if we create a new one.

If we establish a sound API (copied and improved from wxWindows)
Different teams would be reponsable for different system
(probably I wont help on windows for instance).
So each team will have to code for one system only.

Ant
Jan 17 2004
next sibling parent "C" <dont respond.com> writes:
Thats alot of writing :).  Personally I don't like how everything is
prefixed with wx , but to each his own.

It would be good if we could take advantage of some existing code.  I tried
to look at SWIG but it looks pretty complex.  Has anyone  succfesully used
it to convert C++ -> D ?  I think we should see if this is doable , then if
it isnt re-write in D , what do you guys think ?

C


"Ant" <Ant_member pathlink.com> wrote in message
news:bubr5o$2kkc$1 digitaldaemon.com...

 In article <bubp32$2h2q$1 digitaldaemon.com>, C says...

 So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice




 once

for win32 , once for GTK).


 and once for mac, and once for BeOS, and once....

 I thought that was the idea.
 I thought that is what Walter suggested.

 We are using wxWindows for 2 reasons (as I see it - mainly):
 - C++ code can be converted to D (with more or less difficulty)
 - it's a proven GUI so we don't get cought in common traps
   if we create a new one.

 If we establish a sound API (copied and improved from wxWindows)
 Different teams would be reponsable for different system
 (probably I wont help on windows for instance).
 So each team will have to code for one system only.

 Ant
Jan 17 2004
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
In article <bubr5o$2kkc$1 digitaldaemon.com>, Ant says...

In article <bubp32$2h2q$1 digitaldaemon.com>, C says...

 So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice ( once
for win32 , once for GTK).


and once for mac, and once for BeOS, and once....

I thought that was the idea.
I thought that is what Walter suggested.


Yes, I thought I implied the need for rewrites.


We are using wxWindows for 2 reasons (as I see it - mainly):
- C++ code can be converted to D (with more or less difficulty)
- it's a proven GUI so we don't get cought in common traps
  if we create a new one.


We are basically taking advantage of the fact that the design is all thought out
and that the appropriate win32 or gtk+ code, which lies within the wxWindows
classes, can be used directly.  Conversion is a matter of converting C++ classes
layer and layer to D.  This is a big enough task as it is.


If we establish a sound API (copied and improved from wxWindows)
Different teams would be reponsable for different system
(probably I wont help on windows for instance).
So each team will have to code for one system only.

Ant


Your experience would be prime for the gtk+ version, I think :).
Jan 17 2004
parent Georg Wrede <Georg_member pathlink.com> writes:
Got another idea.

If we have an established, proven interface for an interpreted
language where wxWindows works excellently, then:

All we have to do is to have our D-GUI thin layer send commands
to the interpreted language!

So, for example, if there's a Python interface to wxWindows,
we just attach D to the Python interpreter. Then we can have 
a D API that receives window wishes, and then sends them to
the Python interpreter, so it can then use the windowing
thing.

This, of course would not be a quick-and-dirty solution.
It would more likely be called a now-and-filty solution.
But I think it gets the thing done! 

Since, for the time being, D is an Intel-only language,
it follows that we probably do have the horse power available
for this kind of "multiply indirect" solution.

This would buy us time to slowly, and in peace, develop the
Proper Solution? It also would let us take the necessary time
to carefully study the D GUI spec for the standard.
Jan 17 2004
prev sibling next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bubp32$2h2q$1 digitaldaemon.com>, C says...
..

I was hoping that wxUniversal which implements all its own widgets ( and
looks real good ) was C but no luck.  So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice ( once
for win32 , once for GTK).


Appologies for an entirely off-hand, not thought-out question:

With the number of C++ things that we, and D users in the future,
are facing, is there (or will there ever be) any way (even in theory)
to make the interfacing easier?
Jan 17 2004
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
Its only truly cross-platform if you stay with in the wx framework , which
explains why its so huge , and even then there is some problems with spacing
correctly on each platform ( wxSizer is just an abstraction  layer for
some ) , resource scripts , icons and so on ( although in my experience it
didnt take much to fix it ).


I understand this.  Code can be kept cross-platform, I am sure, by maintaining a
careful style and isolating platform specific code.  Parinya, one of the fellows
that visits this group, seems to have been successful in a fairly painless port
of his MingW Studio from Windows to Linux (using wxWindows).  His project
appears to be a fairly non-trivial one.  It seems wxWindows hugely eases the
pain for such porting.

Concerning the sizer problems, I read about them.  But there seem to be
well-documented ways of dealing with that problem.  So all seems surmountable.


Somebody mention this a while back  , but wxHaskell
 http://wxhaskell.sourceforge.net/ ) has a wxC interface , but after looking
it over it seems to only be C prototypes , and the definition of the
functions in haskell ( I really dont know though I dont use Haskell , it
would  be good if someone with knowledge of C/Haskell integration could
confirm ) ?  It also looks like C++ , not C.


I haven't looked at this. Anything that could ease the task are of interest to
me.


I was hoping that wxUniversal which implements all its own widgets ( and
looks real good ) was C but no luck.  So without the ability to  interface
with C++ , it looks like you'll have to re-write it entirely , twice ( once
for win32 , once for GTK).


Yes. Entirely is a ill-defined term. Once success is made on one platform, it
may be easier to port to another.  The Gtk+ and win32 layers should be pretty
much the same in D as C++.


Keep us updated on progress ?

C


Sure, once in awhile maybe. But it may be awhile until I have anything that
works. Or it may not... :)
Jan 17 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 17 Jan 2004 20:53:01 +0000, John Reimer wrote:


 

Keep us updated on progress ?

C


 
 Sure, once in awhile maybe. But it may be awhile until I have anything that
 works. Or it may not... :)


can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".

my swig is still running
let me see what I can do in 30 mn.
(maybe 20mn it's dinner time here)

what is wxUniversal is that what we need?

Ant
Jan 17 2004
parent reply John Reimer <John_member pathlink.com> writes:
can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".


You sure can try! I don't know much about swig, so it would be nice if you could
look into that.  The conversion may be pretty ugly, though.


my swig is still running
let me see what I can do in 30 mn.
(maybe 20mn it's dinner time here)


Sure thing.  I'm at work all weekend so I'm stuck using a limited station
computer.  I can't do much from here anyway other than study some of the
web-interfaced sources.


what is wxUniversal is that what we need?


www.wxwindows.org/wxuniv.htm 

That's the new port for all platforms that implements it's own widget sets
instead of calling OS dependent ones. This allows it to have a look/feel
consistant across platforms.  I'm sure it bloats wxWindows quite a bit too. It's
not really functional yet.  It might be best to stick to a msw (ms windows
branch) or gtk branch.

My own plan was to create a significantly reduced skeleton of wxWindows
following it's design.  I'm a little confused, though, at how to implement the
main in windows: I want to hide the winmain entry so no windows specific
functuality is revealed to the library user.  I'll have to check dig out again
to see how Burton did it. wxWindows uses a ton of macros to hide it.  Is there a
web viewable version of the dig source? I can't download it to this computer so
I need to view it somehow.

Later,

John
Jan 17 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
John Reimer wrote:
...

 My own plan was to create a significantly reduced skeleton of wxWindows
 following it's design.  I'm a little confused, though, at how to implement the
 main in windows: I want to hide the winmain entry so no windows specific
 functuality is revealed to the library user.  I'll have to check dig out again
 to see how Burton did it. wxWindows uses a ton of macros to hide it.  Is there
a
 web viewable version of the dig source? I can't download it to this computer so
 I need to view it somehow.
 
 Later,
 
 John


Here is some newly created html-ized dig source:
http://jcc_7.tripod.com/d/dig/

It's not all of the dig sources, but I hope it'll show you want you want 
to know.  (I can't tell you how dig works; I just know that it does work.)

* examples.scintilla is the shortest example.
* platform.frame has an event handler.

Good luck.

-- 
Justin
http://jcc_7.tripod.com/d/
Jan 17 2004
parent John Reimer <John_member pathlink.com> writes:
Here is some newly created html-ized dig source:
http://jcc_7.tripod.com/d/dig/

It's not all of the dig sources, but I hope it'll show you want you want 
to know.  (I can't tell you how dig works; I just know that it does work.)

* examples.scintilla is the shortest example.
* platform.frame has an event handler.

Good luck.


Thanks, Justin! I really appreciate this!

I'm thinking of getting a laptop so that I can carry all the code with me while
I'm away for my 4-5 day work stints.  Then I can experiment away as much as
necesary. That's one of the few advantages of my job.

Thanks again,

John
Jan 18 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bucjga$q2n$1 digitaldaemon.com>, John Reimer says...

can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".


You sure can try!


Couldn't even get to first base...


That's the new port for all platforms that implements it's own widget sets
instead of calling OS dependent ones.


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?)


This allows it to have a look/feel
consistant across platforms.  I'm sure it bloats wxWindows quite a bit too. 


Seems that wxWindows is just the API all those are implementations
of that API. How independent are they?


My own plan was to create a significantly reduced skeleton of wxWindows
following it's design.  I'm a little confused, though, at how to implement the
main in windows: I want to hide the winmain entry so no windows specific
functuality is revealed to the library user.


I wouldn't worry too much with implementation right now.
Let's see what we have and design a strategy before jump
into it.

If you start doing things "your way" people will avoid colaborating.
if we start slower maybe we can get into a faster speed later.

Do you wanna do it your self or create a colaborating group?

Ant
Jan 19 2004
next sibling parent reply John Reimer <John_member pathlink.com> writes:
Couldn't even get to first base...


I was wondering if that would happen.


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?)


I tend to think the same.  The user should get the look/feel of each platform
verses one universal one. Other opinions?


This allows it to have a look/feel
consistant across platforms.  I'm sure it bloats wxWindows quite a bit too. 


Seems that wxWindows is just the API all those are implementations
of that API. How independent are they?


Yes, I believe so.  As far as I can see, the different ports are mostly just
changing the underlying GUI code (win32 or gtk+).  Classes and such should stay
mostly the same.  There does appear to be some variances, such as enabling
support for proprietary "features" on each platform.  These are enabled/disabled
per user preference. 


My own plan was to create a significantly reduced skeleton of wxWindows
following it's design.  I'm a little confused, though, at how to implement the
main in windows: I want to hide the winmain entry so no windows specific
functuality is revealed to the library user.


I wouldn't worry too much with implementation right now.
Let's see what we have and design a strategy before jump
into it.


Ok, agreed. I was eager to see some results, that's all :).


If you start doing things "your way" people will avoid colaborating.
if we start slower maybe we can get into a faster speed later.

Do you wanna do it your self or create a colaborating group?


I initially wasn't thinking of collaborating, partly because it was a personal
curiosity, and I wasn't sure how many people would take active interest in it.
But now that you mention it, you're right.  I would be stupid to take on this
thing without collaborating. I'm not an experienced developer and could use some
direction here and plenty of collaboration with individuals of far superior
knowledge/experience.  That would be the only sure way to guarantee a
well-designed D port. If you are willing to take part in this, I would be
honoured to work it out with you.  I know you are a busy developer, but if you
could spare some time and experience with this, I think it is a worthy project.
At least, we'll find out if it is.

Later,

John
Jan 19 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buh7gc$27up$1 digitaldaemon.com>, John Reimer says...

 If you are willing to take part in this,


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
Jan 19 2004
next sibling parent reply John Reimer <John_member pathlink.com> writes:
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
Jan 19 2004
parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 19 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Jan 19 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
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
Jan 19 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Jan 19 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Mon, 19 Jan 2004 18:25:58 -0800, Andy Friesen wrote:


 

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

are you using dui_00.08_84b.zip

JCC was having the same problem but compiled OK
with dui_00.08_84b.zip (windows XP home)
I guess your talking about windows.
(if dui_00.08_84.zip was a bad upload the 'b' just
corrects the upload)


 

 
 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)


indeed :)


 

 

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 don't like the tree and table view (GTKTreeView for both),
I think java swing's TreeModel and TableModel are better,
but java is a full OO model. GTK is OO implemented in C
which is kinda of awkward.
(I'm not complaining about the intergration of table and tree that works
fine)


 

 
 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.


I thing I explain that on a past post.
basically put the imports inside the class body definition
(except super and interfaces obviouslly)
http://www.digitalmars.com/drn-bin/wwwnews?D/20837

  In dfbth's case, it was Control and 

 CompositeControl that caused the explosion.  They're both in control.d 
 now for this reason.
 
   -- andy
Jan 19 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
 
 3, 2, 1, go!
 (just can't give it all my free time)


Good, good. So how do you want to begin. Do you want to make a preliminary
discussion forum somewhere? Or do you just want maintain contact by email?
We need to start at least discussing our approach to the project.  


 
 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.


Oh, I don't necessarily need the most "interesting" coding task.  Just
need to get my feet wet.  I may take a peek at the above :).


 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.


Leds looks to be a worthy project.  I'll see if I can get familiar with it
and lend a hand here and there.


 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!)


(:-D. True, another implementation is entirely possible. We can certainly
keep it in mind.


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


I completely agree with this.  Native widgets should be the first go.

Let's keep looking into this.  Unfortunately, I've come down with a nasty
flu.  I'm home from work...but feeling pretty crappy.  Keep that in mind
if I'm slow to interact here over the next few days :-(.

Later,

John
Jan 20 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Tue, 20 Jan 2004 18:08:02 -0800, John Reimer wrote:


 

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


 
 Good, good. So how do you want to begin. Do you want to make a preliminary
 discussion forum somewhere?


for sure. but I think you could keep it here a little longer.
some more people might be interested (at least to make suggestions).
For more detailed discussion we get somewhere else to go.
Before commit to something we should post here the pros and cons
of our decision and listen to more ideas.


 Or do you just want maintain contact by email?


That's not going to be enough. I hope we are at least 4.
And we want any discussion to be public so that anybody
can join in at anytime.


 Leds looks to be a worthy project.  I'll see if I can get familiar with it
 and lend a hand here and there.


I hope to get the cvs for leds on sourceforge in 2 or 3 days.
Email me on that (antoniorm sourceforge.net)
if you see something you like or to ask anything.

But if you prefer to collect information on SWT and wxWindows
is also a good idea.

Ant
Jan 20 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Good, good. So how do you want to begin. Do you want to make a preliminary
 discussion forum somewhere? Or do you just want maintain contact by email?
 We need to start at least discussing our approach to the project.


I think d.gui deserves to be a newsgroup in its own right. Walter?
Jan 23 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Sat, 24 Jan 2004 15:53:45 +1100, Matthew wrote:


 Good, good. So how do you want to begin. Do you want to make a preliminary
 discussion forum somewhere? Or do you just want maintain contact by email?
 We need to start at least discussing our approach to the project.


 
 I think d.gui deserves to be a newsgroup in its own right. Walter?


That would be nice.

But we also need a repository for the code
and a version control system.

The first place I can think is sourceforge.net
but (probably) there are other options.

Ant

It's the "Lady Hawk" sindrome. You remember?
that movie with Michelle Pfiffer and that Dutch(?) guy?
she is a hawk by day he is a wolf by night.
they never meet as humans.
You start posting now I can't keep my eyes open...
dimming donw the monitor bright, dimming down the monitor,
dimming down, dimming... zzzzzzzzzzzzz
Jan 23 2004
prev sibling parent reply John Reimer <John_member pathlink.com> writes:
 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
Jan 19 2004
parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 19 2004
parent reply John Reimer <John_member pathlink.com> writes:
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
Jan 19 2004
parent Ant <Ant_member pathlink.com> writes:
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
Jan 19 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
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?)
Jan 19 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
Oops, my bad.  The C code is just to set up JNI on the local OS.  The 
real work is in the Java.  I took a look at that, and it would be a 
challenge to port to D, but the consistent API across platforms would be 
well worth it.

I think Ant's work on DUI is great, but for the app I'm working on, I 
don't want to have to distribute GTK+ libraries on Win32.  I like the 
SWT methodology of 'use native widgets where possible, implement others'.

How cool would it be to make a window on all platforms in D with the 
following (it's Java, but close to D):

/*
  * Copyright (c) 2000, 2003 IBM Corp.  All rights reserved.
  * This file is made available under the terms of the Common Public 
License v1.0
  * which accompanies this distribution, and is available at
  * http://www.eclipse.org/legal/cpl-v10.html
  */

/*
  * example snippet: Hello World
  *
  * For a list of all SWT example snippets see
  * 
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/dev.html#snippets
  */
import org.eclipse.swt.widgets.*;

public class Main {

    public static void main (String [] args) {
	Display display = new Display ();
	Shell shell = new Shell(display);
	shell.open ();
	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
    }
}




Brad Anderson wrote:

 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
Jan 20 2004
prev sibling next sibling parent reply JanC <usenet_spam janc.invalid> writes:
Ant <Ant_member pathlink.com> schreef:


 That's the new port for all platforms that implements it's own widget
 sets instead of calling OS dependent ones.


 
 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?)


wxUniversal is for platforms that have no native widget set or that have no 
(complete) port (yet) for the native widget set.

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jan 21 2004
parent Ant <Ant_member pathlink.com> writes:
In article <Xns947849B79C185JanC 213.119.4.35>, JanC says...

wxUniversal is for platforms that have no native widget set or that have no 
(complete) port (yet) for the native widget set.


That makes sense.

Ant
Jan 22 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:buh34c$2168$1 digitaldaemon.com...

 In article <bucjga$q2n$1 digitaldaemon.com>, John Reimer says...

can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".


You sure can try!


 Couldn't even get to first base...


That's the new port for all platforms that implements it's own widget




sets

instead of calling OS dependent ones.


 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.


Isn't it obvious?

Users want the same look and feel on a single platform. Developers want the
same look and feel for a single app between different platforms.

Which one's going to result in the most successful software?
Jan 23 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


"Ant" <Ant_member pathlink.com> wrote in message
news:buh34c$2168$1 digitaldaemon.com...
  


In article <bucjga$q2n$1 digitaldaemon.com>, John Reimer says...
    


can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".
        


You sure can try!
      


Couldn't even get to first base...

    


That's the new port for all platforms that implements it's own widget
      




sets
  


instead of calling OS dependent ones.
      


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.
    


Isn't it obvious?

Users want the same look and feel on a single platform. Developers want the
same look and feel for a single app between different platforms.

Which one's going to result in the most successful software?

  


Personally I prefer the same look of an app on all platforms. But then 
again I am an openGL/game fan.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 24 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:butevk$qqj$2 digitaldaemon.com...

 Matthew wrote:


"Ant" <Ant_member pathlink.com> wrote in message
news:buh34c$2168$1 digitaldaemon.com...



In article <bucjga$q2n$1 digitaldaemon.com>, John Reimer says...



can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".


You sure can try!


Couldn't even get to first base...




That's the new port for all platforms that implements it's own widget




sets



instead of calling OS dependent ones.


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.


Isn't it obvious?

Users want the same look and feel on a single platform. Developers want




the

same look and feel for a single app between different platforms.

Which one's going to result in the most successful software?


 Personally I prefer the same look of an app on all platforms. But then
 again I am an openGL/game fan.


And you're a developer. Like the rest of us, your opinion of what is an
important consistency is largely irrelevant, because most users are not
developers. This is a classic mistake of "informed" choices by developers
and power-user managers who fail to grasp the commercial realities. If we
want D to "win", then it has to have a UI that equals or betters that
provided by competing languages, which basically means it must be at least
as good in look and feel as .NET. ;/
Jan 24 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:butevk$qqj$2 digitaldaemon.com...
  


Matthew wrote:

    


"Ant" <Ant_member pathlink.com> wrote in message
news:buh34c$2168$1 digitaldaemon.com...


      


In article <bucjga$q2n$1 digitaldaemon.com>, John Reimer says...


        


can we just create the entire class hierarchy,
using swig. then we just "fill in the blanks".


            


You sure can try!


          


Couldn't even get to first base...



        


That's the new port for all platforms that implements it's own widget


          




sets


      


instead of calling OS dependent ones.


          


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.


        


Isn't it obvious?

Users want the same look and feel on a single platform. Developers want
      




the
  


same look and feel for a single app between different platforms.

Which one's going to result in the most successful software?



      


Personally I prefer the same look of an app on all platforms. But then
again I am an openGL/game fan.
    


And you're a developer. Like the rest of us, your opinion of what is an
important consistency is largely irrelevant, because most users are not
developers. This is a classic mistake of "informed" choices by developers
and power-user managers who fail to grasp the commercial realities. If we
want D to "win", then it has to have a UI that equals or betters that
provided by competing languages, which basically means it must be at least
as good in look and feel as .NET. ;/


  


Well I wasn't talking from my developer side.

Winamp looks the same on all OSs (it's skinned).  HTML looks the same on 
all OSs.  Warcraft 3 looks the same on all OSs.  I like it that way and 
I didn't develop those apps.   For many applications a common interface 
is better.  Now if someone is just going to stick with the *ugly* OS 
interfaces, then use their clients. But if their going to make a 
good-looking-skinnable type one, then use that.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 24 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:

 
 Personally I prefer the same look of an app on all platforms. But then 
 again I am an openGL/game fan.
 


The way I see it, applications running on Windows should look like 
Windows applications.  Applications running on OSX should look like OSX 
applications.  It shouldn't be at all obvious how the application was 
made, or even that it runs on any other platform at all.

  -- andy
Jan 24 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:buu7ps$20at$1 digitaldaemon.com...
| J Anderson wrote:
| >
| > Personally I prefer the same look of an app on all platforms. But then
| > again I am an openGL/game fan.
| >
|
| The way I see it, applications running on Windows should look like
| Windows applications.  Applications running on OSX should look like OSX
| applications.  It shouldn't be at all obvious how the application was
| made, or even that it runs on any other platform at all.
|
|   -- andy

Same here

-----------------------
Carlos Santander Bernal
Jan 24 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buuf0i$2blo$1 digitaldaemon.com>, Carlos Santander B. says...

"Andy Friesen" <andy ikagames.com> wrote in message
news:buu7ps$20at$1 digitaldaemon.com...
| J Anderson wrote:
| >
| > Personally I prefer the same look of an app on all platforms. But then
| > again I am an openGL/game fan.
| >
|
| The way I see it, applications running on Windows should look like
| Windows applications.  Applications running on OSX should look like OSX
| applications.  It shouldn't be at all obvious how the application was
| made, or even that it runs on any other platform at all.
|
|   -- andy

Same here

-----------------------
Carlos Santander Bernal


that's not that simple.
when you start your favority email client
why should you care what OS is supporting it?

but that's not here yet. give it another 3 ot 5 years.

Ant
Jan 24 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 

| The way I see it, applications running on Windows should look like
| Windows applications.  Applications running on OSX should look like OSX
| applications.  It shouldn't be at all obvious how the application was
| made, or even that it runs on any other platform at all.
|


 
 that's not that simple.
 when you start your favority email client
 why should you care what OS is supporting it?
 
 but that's not here yet. give it another 3 ot 5 years.
 


Because I want my mail client to behave as if it were an extension of 
the operating system, and not some freaky thing that latched onto it 
somehow. :)

  -- andy
Jan 24 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 24 Jan 2004 12:30:33 -0800, Andy Friesen wrote:


 Ant wrote:

 

| The way I see it, applications running on Windows should look like
| Windows applications.  Applications running on OSX should look like OSX
| applications.  It shouldn't be at all obvious how the application was
| made, or even that it runs on any other platform at all.
|


 
 that's not that simple.
 when you start your favority email client
 why should you care what OS is supporting it?
 
 but that's not here yet. give it another 3 ot 5 years.
 


 
 Because I want my mail client to behave as if it were an extension of 
 the operating system, and not some freaky thing that latched onto it 
 somehow. :)
 
   -- andy


you are wrong of course. ;)

if it's you preferred it's not freaky.
and you want it to be the same at home,
at work, in your palm, in your rist computer(limitation may apply),
in a public computer...

and not everybody will use the same look and feel for the
same application.

but that's not here yet. give it another 3 ot 5 years.
(hmmm.. i've said that before)

Ant
Jan 24 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 
 you are wrong of course. ;)
 
 if it's you preferred it's not freaky.
 and you want it to be the same at home,
 at work, in your palm, in your rist computer(limitation may apply),
 in a public computer...
 
 and not everybody will use the same look and feel for the
 same application.
 
 but that's not here yet. give it another 3 ot 5 years.
 (hmmm.. i've said that before)
 
 Ant
 


It's important to remember that most nontechnical folk consider the tool 
to be the *hardware*.  The application is just part of that tool.  If a 
part of that tool doesn't behave like all the others, then the users 
expectations are betrayed.

I know people who eschew GIMP on windows because it's 'weird and ugly'. 
  People avoid Blender for the same reason.

  -- andy
Jan 24 2004
parent Stephan Wienczny <wienczny web.de> writes:
Andy Friesen wrote:

 Ant wrote:
 

 you are wrong of course. ;)

 if it's you preferred it's not freaky.
 and you want it to be the same at home,
 at work, in your palm, in your rist computer(limitation may apply),
 in a public computer...

 and not everybody will use the same look and feel for the
 same application.

 but that's not here yet. give it another 3 ot 5 years.
 (hmmm.. i've said that before)

 Ant


 
 It's important to remember that most nontechnical folk consider the tool 
 to be the *hardware*.  The application is just part of that tool.  If a 
 part of that tool doesn't behave like all the others, then the users 
 expectations are betrayed.
 
 I know people who eschew GIMP on windows because it's 'weird and ugly'. 
  People avoid Blender for the same reason.
 
  -- andy


The easiest way was to have a swt like interface but making skinning 
possible. For example by writing a set of widgets using opengl that 
support skin loading. You could do this by having a object request 
broker for widget creation, that uses another table of classes for each 
skin.
This could look like:

import gui;

gui.GuiCreator guicreator = new GuiCreator();
guicreator.SetSkin("standard");
//guicreator.SetSkin("windows");
//guicreator.SetSkin("GTK");
Widget mywidget = guicreator.CreateWidget("Edit");

This way the developer could decide what he wants his application to 
behave.

Stephan
Jan 24 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Ant wrote:


 you are wrong of course. ;)


I wouldn't say someone on this discussion was clearly wrong.


 if it's you preferred it's not freaky.
 and you want it to be the same at home,
 at work, in your palm, in your rist computer(limitation may apply),
 in a public computer...


Hmmm... This is a point of view of a UNIX user, where all the same 
problem has always been: all standard UNIX command-line utilities have a 
different and unrelated interface. Nontheless, this has never been 
considered a problem. Although i must say i hate it, it just takes so 

as possible.

Now, in the UI aera it has not become different. The OS doesn't have its 
own mean of providing a look and feel of the application. Instead, each 
application *must* draw itself by its own means, be it even sometimes a 
more-or-less popular library such as GTK+.

Having look and feel like the platform, and work the same on all 
platforms, is not a conflicting target. Just look at any wxWindows 
application.


 and not everybody will use the same look and feel for the
 same application.


This is good, but on the level of an operating system or an OS addon.


 but that's not here yet. give it another 3 ot 5 years.
 (hmmm.. i've said that before)


Ouch.

-eye
Jan 24 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:buuhum$2g5g$1 digitaldaemon.com...

 In article <buuf0i$2blo$1 digitaldaemon.com>, Carlos Santander B. says...

"Andy Friesen" <andy ikagames.com> wrote in message
news:buu7ps$20at$1 digitaldaemon.com...
| J Anderson wrote:
| >
| > Personally I prefer the same look of an app on all platforms. But




then

| > again I am an openGL/game fan.
| >
|
| The way I see it, applications running on Windows should look like
| Windows applications.  Applications running on OSX should look like OSX
| applications.  It shouldn't be at all obvious how the application was
| made, or even that it runs on any other platform at all.
|
|   -- andy

Same here

-----------------------
Carlos Santander Bernal


 that's not that simple.
 when you start your favority email client
 why should you care what OS is supporting it?

 but that's not here yet. give it another 3 ot 5 years.


The *vast* majority of users do not work on multiple operating systems. They
quite reasonably want their apps to all look and work in the same way.

Everyone always craps on about Windows being boring because there's only one
"Window Manager", and yet no-one seems to realise the Microsoft have been so
successful because they provide very few surprises to their users over years
and years. The operating systems even have the same propensity for crashing
and inordinate greed for the latest memory and disk capacities! <G>
Jan 24 2004
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <butevk$qqj$2 digitaldaemon.com>, J Anderson says...


Personally I prefer the same look of an app on all platforms. But then 
again I am an openGL/game fan.


It's okay for a game to look the same on all platforms. Game users
are used to games not looking native. Actually they kind of expect
it. And it's good for the game to look the same on all platforms.

Office workers, and "adults" in general, want every program to look
native. They don't want to deal with differences in functionality
or even the look of things between apps.
Jan 25 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Georg Wrede wrote:


In article <butevk$qqj$2 digitaldaemon.com>, J Anderson says...

  


Personally I prefer the same look of an app on all platforms. But then 
again I am an openGL/game fan.
    


It's okay for a game to look the same on all platforms. Game users
are used to games not looking native. Actually they kind of expect
it. And it's good for the game to look the same on all platforms.

Office workers, and "adults" in general, want every program to look
native. They don't want to deal with differences in functionality
or even the look of things between apps.


  


That's my point. It's not the same in all fields.

-- 
-Anderson: http://badmama.com.au/~anderson/
Jan 25 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:bv0c3e$26t3$1 digitaldaemon.com...

 Georg Wrede wrote:


In article <butevk$qqj$2 digitaldaemon.com>, J Anderson says...




Personally I prefer the same look of an app on all platforms. But then
again I am an openGL/game fan.


It's okay for a game to look the same on all platforms. Game users
are used to games not looking native. Actually they kind of expect
it. And it's good for the game to look the same on all platforms.

Office workers, and "adults" in general, want every program to look
native. They don't want to deal with differences in functionality
or even the look of things between apps.


 That's my point. It's not the same in all fields.


No-one's saying it is. The point I'm making is that people like you and I
are the minority, and "ordinary" users are the massive majority. Hence, D
needs UI support that satisfy these people, not us.
Jan 27 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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.

First, i can see OpenGL melt the battery of a 3D-accelerated notebook in 
no-time - definately not something i would want in a real application. 
Besides, this other notebook would be too slow since it doesn't have an 
3D accelerator. However, for an application which needs OpenGl anyway, 
this would be a viable option.

We all know GUI in Blender, which is completely implemented in OpenGL. 
Well, not competely anymore. While there have never been problems with 
3D core of the application, they have constantly been in trouble with 
the GUI part, because drivers don't comply with specification. Sometimes 
Z-Buffer test doesn't get turned off. Sometimes the 
direct-to-framebuffer drawing doesn't work or works too slowly to be 
practical. Sometimes there are problems with the mouse pointer in 
corellation to the blitting mode... Finally, in the latest version, the 
framework was changed from GLUT (pure window manager for OpenGL) to 
libSDL, and some drawing has been postponed to it. Nontheless, the GUI 
of Blender takes a significant fraction of a second to redraw on my 
mininotebook, and it does it too often. So i would say that even for 
embedding OpenGL traditional toolkits, such as GTK, FLTK, and Windows, 
give a better performance and less problems.

With libSDL, a good GUI toolkit would be thinkable. But then, window has 
to be redrawn completely every time it gets dirty, you don't have acess 
to line accelerator, you cannot support graphic tablets, your window 
position control is too limited, and so on.

I would say that GTK GUI makes quite some sense. The bad thing on it is 
that GTK is a huge monster which is not installed on Windows by default, 
and only works well on Unix systems. ;) But maybe DUI-compatible 
libraries could be written to work with Windows GUI directly, and 
similar for other GUIs such as MacOS-X, BeOS/Zeta, AmigaOS and QNX, 
whatever is to come next...

-eye
Jan 15 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
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.


[...]

I would say that GTK GUI makes quite some sense.


me too ;)


The bad thing on it is 
that GTK is a huge monster which is not installed on Windows by default, 
and only works well on Unix systems. ;)
But maybe DUI-compatible 
libraries could be written to work with Windows GUI directly, and 
similar for other GUIs such as MacOS-X, BeOS/Zeta, AmigaOS and QNX, 
whatever is to come next...


That would be one very big task (times each system).
I believe GTK was already seen on the Mac.


-eye


overall that's not good news...

let me check the references you made.

Ant
Jan 15 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
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
Jan 16 2004
prev sibling next sibling parent reply "news.digitalmars.com" <acrodrigu3z yahoo.com> writes:
Actually, why not get SWT from IBM and port it directly
to D? you don't even need the dynamic libraries that IBM
built for making it java accesible.  Has anybody thought
of this or event better worked on it?

Cheers.


"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.)
Jan 15 2004
parent Ant <Ant_member pathlink.com> writes:
In article <bu7199$jit$1 digitaldaemon.com>, news.digitalmars.com says...

Actually, why not get SWT from IBM and port it directly
to D? you don't even need the dynamic libraries that IBM
built for making it java accesible.  Has anybody thought
of this 


Yes,
There has been same discussion on the past about a D GUI.
We even had a contribution from someone that worked on
the SWT team.


 or event better worked on it?


No (That I know about),
I think D is getting stable enough to start
something more definitive.

we have now (at least) 5 started GUI:
- dig (abandoned by the creator)
- DUI
- windy (by C)
- Andy's something (by Andy)
- and another just announced today (check post...?)

I believe that we will always have
a GTK binding, being it DUI or some other one,
that means that anything done with DUI
will not be lost because, in the worst case,
it will be easely ported to any GTK binding.

Ant

htt://dui.sourceforge.net
Jan 15 2004
prev sibling next sibling parent reply Stephan Wienczny <wienczny web.de> writes:
Ant wrote:


Any suggestions as for which GUI library is the best one?  wxWindows?




 
 
 Walter said:
 
 

wxWindows is certainly a contender.


 
 


I suggest to use the way Julian Smart went when he designed the second 
version of wxWindows.
wxWindows uses the native interface on every platform (Win32 Api on 
Windows, GTK on Linux, whatever on MacOS etc.)
You could see this library as abstraction layer beetween the system's 
widget and your application. This way your application runs almost as 
fast as a native one and it's code is platform idenpendent.

Stephan Wienczny
Jan 15 2004
parent Mark T <Mark_member pathlink.com> writes:
I suggest to use the way Julian Smart went when he designed the second 
version of wxWindows.
wxWindows uses the native interface on every platform (Win32 Api on 
Windows, GTK on Linux, whatever on MacOS etc.)
You could see this library as abstraction layer beetween the system's 
widget and your application. This way your application runs almost as 
fast as a native one and it's code is platform idenpendent.


This is also the idea behind SWT which probably could be ported to D. Eclipse
and SWT is supported by large companies (which can a good or bad thing). But
Borland is hopping on the wxWindows bandwagon for C++.

Is anyone working on a Java to D translator? Of course D is missing most of the
libraries that Java has builtin.
Jan 16 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:


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 would like a openGL GUI, in openGL, although I don't think it should 
be the main one.  People would be able to really show off in D if there 
was one.  When I last when looking for a good openGL gui in C++/C, I 
couldn't find one that met my specifications and ended up designing the 
entire thing myself (sorry I can't release it).  It had buttons, 
textboxes, listboxes, menus, scrollbars, updownboxes, combo boxes and 
windows.  It looked good as well, and was very customisable.  I can't 
give any time on this at the moment but parhaps in the future I could 
contribute.

I think what would be better is something that allows users to switch 
from openGL to standard windows GUI without changing the programming 
used.  The openGL ones would of course have many extensions to make them 
cooler.  I also think that if possible the openGL GUI shouldn't nessarly 
be tied to any event handling system, ie the users should be able to 
substitute their own. That was the major reason I developed my own.

Anderson
Jan 15 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <bu7a2u$13je$1 digitaldaemon.com>, J Anderson says...

Ant wrote:


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?


I would like a openGL GUI, in openGL, although I don't think it should 
be the main one.  People would be able to really show off in D if there 
was one.  When I last when looking for a good openGL gui in C++/C, I 
couldn't find one that met my specifications and ended up designing the 
entire thing myself (sorry I can't release it).  It had buttons, 
textboxes, listboxes, menus, scrollbars, updownboxes, combo boxes and 
windows.  It looked good as well, and was very customisable.  I can't 
give any time on this at the moment but parhaps in the future I could 
contribute.

I think what would be better is something that allows users to switch 
from openGL to standard windows GUI without changing the programming 
used.  The openGL ones would of course have many extensions to make them 
cooler.  I also think that if possible the openGL GUI shouldn't nessarly 
be tied to any event handling system, ie the users should be able to 
substitute their own. That was the major reason I developed my own.

Anderson


So, it is possible!
And you say it's a one man job?!

You only enumerate the good things. What are the draw backs?
(I was already ready to give up on the idea...)

It's a good idea, what proves that is that there are several
tries at it, maybe the available hardware and libs aren't
yet up to the quality of the idea. I don't know.

Anybody else has a OpenGL toolkit on the drawer? :)

Ant
Jan 15 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
 So, it is possible!
 And you say it's a one man job?!

  


Actually I worked on a team, but did all the GUI myself, among other 
things, in rushed 4 weeks (the guy who was supposed to do it left the 
group).  It was part of a games engine, but the GUI was pretty generic 
(although it was tide into the game engine).  Basicly everything was 
derived from a button (ie everything has mouse up/down events ect...).  
There were 4 basic classes of which you could build basicly anything 
menu, scrollbar, button and textbox.



The tab list along the button is a menu. The images in the background 
are actually a menu as well, with the free floating option on.  
Everything animates when you move the mouse over.

Of course my GUI didn't support some of the most import things such as 
file-dialogs.


 You only enumerate the good things. What are the draw backs?
 (I was already ready to give up on the idea...)

  


Humm.
 * I imagine the windows gui libraries have been really put through
   their paces and do just about everything.
 * You can only run it on machines with some sort of 3d acceleration.
 * When the OS vendor (ie MS) add some new feature to their controls,
   all the programs get it.
 * (This is a big one) Slow to load up -> particularly if you use
   lots of pictures.  You would need a heavy focus on pre-fetching in
   a separate thread.
 * No dialog/arc builder (I suppose you could make one).
 * Feels kinda separate from the OS (ie like java swing does).
 * Not to many to copy from (this is a plus for D also).

But.

 * I found the special effects and stuff you can do with it are quite
   amazing. For example, instead of using pictures, I used
   animations. That meant that every part of the GUI could animate,
   which is great for skinning.
 * Everything is skinable.
 * Make the controls more functional then their windows counterparts.
   ie if you don't like it you can override it and re-program how it
   works using openGL, which is far more flexible then using windows
   graphics routines.
 * IMHO can look great.


 It's a good idea, what proves that is that there are several
 tries at it, maybe the available hardware and libs aren't
 yet up to the quality of the idea. I don't know.

  


I think if you have a reasonably machine it's up to scratch, but you'll 
be waiting for ever if you expect everyone to have n up-to-scratch 
machine.  GUI doesn't require as much CPU as 3d games do, but it does 
eat up allot of resources if you use big textures.  I guess it would be 
used 90% of the time in games and 3d applications. But hay the game 
industry is one of the biggest industry players and that's where most of 
the showing off is done.  A word process done like the above would be so 
cool.

But if your looking for a GUI that everyone will use, then your probably 
barking up the wrong tree.

-Anderson
Jan 15 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:


   A word processer done like the above would be so cool.


Or leds, that would be even cooler.
Jan 15 2004
prev sibling next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Fri, 16 Jan 2004 10:14:39 +0800, J Anderson wrote:


 
 
 But if your looking for a GUI that everyone will use, then your
 probably barking up the wrong tree.


If you're not alone you are not leading the way... :}

Thanks!
I'm trying to install one more "formal" OpenGL GUItoolkit 
to see how it feels.

Ant
Jan 15 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Ant


Can we go with an OpenGL toolkit?



I should add that before you brought this up I was seriously considering 
doing an openGL toolkit for Windy, basing it of dig's openGL but taking 
it further.  Parhaps forming a group (Yeah right you say! Are there any 
D groups at all?) to do small parts of the openGL toolkit such as 
texture loading, scenegraphs, gltext and an openGL gui toolbox -> some 
of which would simply be converted C libraries. The openGL part of Windy 
could be separted, to reduce size if it got to large.

However, that was one of the many spare-time-projects I may consider 4 
or 5 months from now when I get free time.  And I'm not commiting to 
anything at the moment ;)

-Anderson
Jan 17 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sun, 18 Jan 2004 02:52:16 +0800, J Anderson wrote:


 Ant
 

Can we go with an OpenGL toolkit?


 
 
 I should add that before you brought this up I was seriously considering 
 doing an openGL toolkit for Windy, basing it of dig's openGL but taking 
 it further.  Parhaps forming a group (Yeah right you say! Are there any 
 D groups at all?)


there are lots of D groups (one element each)

I still didn't give up.
I'll post here 'significative' milestones on this idea.
please do the same.


 to do small parts of the openGL toolkit such as 
 texture loading, scenegraphs, gltext and an openGL gui toolbox -> some 
 of which would simply be converted C libraries. The openGL part of Windy 
 could be separted, to reduce size if it got to large.
 
 However, that was one of the many spare-time-projects I may consider 4 
 or 5 months from now when I get free time.  And I'm not commiting to 
 anything at the moment ;)


In 4/5 months we should have the API for the main D GUI toolkit
(positive thinking - in reality this all project will be forgotten
in 1 week :( ) so maybe it's a better idea to use the API from that.
That will mean we will have another implementations of the D GUI
that is good for "new systems" not dependent on a "battery charge"...

Ant
Jan 17 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Ant wrote:


On Sun, 18 Jan 2004 02:52:16 +0800, J Anderson wrote:

  


Ant

    


Can we go with an OpenGL toolkit?
      


I should add that before you brought this up I was seriously considering 
doing an openGL toolkit for Windy, basing it of dig's openGL but taking 
it further.  Parhaps forming a group (Yeah right you say! Are there any 
D groups at all?)
    


there are lots of D groups (one element each)

I still didn't give up.
I'll post here 'significative' milestones on this idea.
please do the same.

  


to do small parts of the openGL toolkit such as 
texture loading, scenegraphs, gltext and an openGL gui toolbox -> some 
of which would simply be converted C libraries. The openGL part of Windy 
could be separted, to reduce size if it got to large.

However, that was one of the many spare-time-projects I may consider 4 
or 5 months from now when I get free time.  And I'm not commiting to 
anything at the moment ;)
    


In 4/5 months we should have the API for the main D GUI toolkit
(positive thinking - in reality this all project will be forgotten
in 1 week :( ) so maybe it's a better idea to use the API from that.
That will mean we will have another implementations of the D GUI
that is good for "new systems" not dependent on a "battery charge"...

Ant

  


Yeah, something like that. But generally, your still going to need all 
the basics in openGL (such as glText ect...) before you can have a GUI.  
Plus, I wasn't only thinking openGL GUI.  Common things like scene 
graphs and static material graphs could be put into the openGL toolkit, 
which wouldn't nessarly be related to openGL.

The trouble I've had with openGL, is that it's missing allot of things, 
such as text and menus.  And in most cases using the OS standard GUI, 
just doesn't look right (game like).  Everybody that uses it virtually 
has to go hunting for the right opengl extensions or write them themselves.

I was also think parhaps having something that could be used cross-gui. 
The gui's would simply do the ralivent interfacing. ie both Windy and 
DUI would interface to the same openGL toolkit.  But all that's (for me 
at least is 4 or 5 months away).

-Anderson
Jan 17 2004
prev sibling next sibling parent Felix <Felix_member pathlink.com> writes:
First time I hear about but I think it will be wonderful...
I think we (you) should keep a similar window class architecture (as most
gui's). I know nothing on OpenGL except that's a renderer....



In article <bu6jhe$2s6g$1 digitaldaemon.com>, Ant says...

 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.)
Jan 16 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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!
Jan 16 2004
parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 16 2004
parent reply John Reimer <jjreimer telus.net> writes:
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
Jan 16 2004
parent reply John Reimer <John_member pathlink.com> writes:
I need to correct myself here: wxWindows does not support multiple langauges.  I
jumped the gun.  It's a GUI that is C++ with hacks for Python and a version of
BASIC.
Jan 16 2004
parent reply John Reimer <John_member pathlink.com> writes:
In article <bua7ei$2srf$1 digitaldaemon.com>, John Reimer says...

I need to correct myself here: wxWindows does not support multiple langauges.  I
jumped the gun.  It's a GUI that is C++ with hacks for Python and a version of
BASIC.


OK, scratch that.  Now I see there are Lua, Perl, and Javascript versions.  It
seems mostly interpreted languages can interface with wxWindows.
Jan 16 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
John Reimer wrote:

 OK, scratch that.  Now I see there are Lua, Perl, and Javascript versions.  It
 seems mostly interpreted languages can interface with wxWindows.


I heard it's through SWIG already.

-eye
Jan 20 2004