www.digitalmars.com         C & C++   DMDScript  

D - GUI - how about a portable one?

reply Mark T <Mark_member pathlink.com> writes:
Now that D on Linux is a reality (thanks Walter), how about creating a standard
portable GUI for D? It seems all the GUI effort is focused in the Windows arena.
As mentioned previously in another thread, the Java Standard Widget Toolkit
(SWT) would be a great place to get ideas. This would be a good college project
for a small group. You could host it on SourceForge so it wouldn't die an early
death (after your semester ends). Give it a BSD or similar style license so
companies won't be afraid to use it. 

"The most succinct description of the Standard Widget Toolkit component is this:

The SWT component is designed to provide efficient, portable access to the
user-interface facilities of the operating systems on which it is implemented."

INFO
http://www.eclipse.org/articles/index.html
look for SWT in the article title

SOURCE
http://download2.eclipse.org/downloads/drops/R-2.1-200303272130/index.php
look for:
SWT Binary and Source
May 18 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
SWT has a severe problem: it is a huge, unmaintainable monster. Its 
analogue in the C++ world is wxWindows.

Due to almost all the code being platform-specific, and severe 
differencies in widget set implementations on different OSes, it's a 
very difficult project for a new and rather unpopular language. What i 
think could be done is the following:

- Java is a simple language. It can be almost viewed as a subset of D. 
Maybe its trandlation to D can be automated? Then convert AWT. This 
would also transfer some Java fans to D.

maybe TK?)
- Write a client-draw library which skins itself to an OS. Most popular 
example of this approach is Qt, which is used by e.g. Opera browser. 
FLTK is more practical, and ceratinly has some ideas (and probably 
low-level code) to share with a possible D implementation. A client-draw 
library is most certainly faster and easier to debug and maintain than a 
"real" cross-platform monster.

I intended to write something like this in Sather using LibSDL as a 
low-level backend, but i think it can not understand external update 
regions, and thus only good for top.level windows, but not for everything.

Also consider the metagrid placement system from TK - i find it interesting.

-i.

Mark T wrote:

 Now that D on Linux is a reality (thanks Walter), how about creating a standard
 portable GUI for D? It seems all the GUI effort is focused in the Windows
arena.
 As mentioned previously in another thread, the Java Standard Widget Toolkit
 (SWT) would be a great place to get ideas. This would be a good college project
 for a small group. You could host it on SourceForge so it wouldn't die an early
 death (after your semester ends). Give it a BSD or similar style license so
 companies won't be afraid to use it. 
 
 "The most succinct description of the Standard Widget Toolkit component is
this:
 
 The SWT component is designed to provide efficient, portable access to the
 user-interface facilities of the operating systems on which it is implemented."
 
 INFO
 http://www.eclipse.org/articles/index.html
 look for SWT in the article title
 
 SOURCE
 http://download2.eclipse.org/downloads/drops/R-2.1-200303272130/index.php
 look for:
 SWT Binary and Source
May 18 2003
parent reply Stephan Wienczny <wienczny web.de> writes:
Ilya Minkov wrote:


 SWT has a severe problem: it is a huge, unmaintainable monster. Its 
 analogue in the C++ world is wxWindows.
 
 Due to almost all the code being platform-specific, and severe 
 differencies in widget set implementations on different OSes, it's a 
 very difficult project for a new and rather unpopular language. What i 
 think could be done is the following:
 
 - Java is a simple language. It can be almost viewed as a subset of D. 
 Maybe its trandlation to D can be automated? Then convert AWT. This 
 would also transfer some Java fans to D.

 maybe TK?)
 - Write a client-draw library which skins itself to an OS. Most popular 
 example of this approach is Qt, which is used by e.g. Opera browser. 
 FLTK is more practical, and ceratinly has some ideas (and probably 
 low-level code) to share with a possible D implementation. A client-draw 
 library is most certainly faster and easier to debug and maintain than a 
 "real" cross-platform monster.
 
 I intended to write something like this in Sather using LibSDL as a 
 low-level backend, but i think it can not understand external update 
 regions, and thus only good for top.level windows, but not for everything.
 
 Also consider the metagrid placement system from TK - i find it 
 interesting.
 
 -i.
 


I think Java got popular because of it's easy GUI interface.

When writing C++ GUIs I use wxWindows. It's problem are the different 
C++ compilers, but there is currently only one D-compiler. We should not 
try to wrap around wxWindows 'cause it is very slow.
We should try to have an easy interface like Delphi's VCL. DIG goes that 
way. If we tryed to create a interface compatible GTK2 layer, we had a 
very good x-platform interface.
I already thought about it, but didn't know how to create a portable 
event system as I've never used native ones ;-)
Maybe someone else has a good idea?

CU Stephan
May 18 2003
parent reply Ilya MInkov <Ilya_member pathlink.com> writes:
In article <ba9350$1jab$1 digitaldaemon.com>, Stephan Wienczny says...

I think Java got popular because of it's easy GUI interface.

When writing C++ GUIs I use wxWindows. It's problem are the different 
C++ compilers, but there is currently only one D-compiler. We should not 
try to wrap around wxWindows 'cause it is very slow.


i don't think we would have a problem with diverting specs - even with different
compilers.


We should try to have an easy interface like Delphi's VCL. DIG goes that 
way. If we tryed to create a interface compatible GTK2 layer, we had a 
very good x-platform interface.


Delphi's VCL is mostly easy because of a GUI editor which helps you a lot. As of
to the rest, it mixes OO and procedural concepts in a not very gentle manner.
BTW, writing an automated converter from Delphi into D should be fairly easy.

I don't have Java experience so i have yet to evaluate AWT for any ideas.

As to GTK, it has *very* severe performance problems under Win32. Really. Noone
wants to use that. But wrapping it is fairly easy and so might make sense
anyway. However, GTK is a client-draw toolkit. As FLTK shows, it's also not much
harder to write our own.

You are probably right - wrapping wxWindows would only produce a lot of bloat
and 5 or more levels of indirection:
- D objects dereferencing;
- function call into C;
- dereferencing & function call into C++;
- function call into an underlying widget set;
- in the case of GTK back-end, which is client-draw, an additional function call
into the underlying windowing system.


I already thought about it, but didn't know how to create a portable 
event system as I've never used native ones ;-)
Maybe someone else has a good idea?


urgh... take a look how some library does it?
Most do through usual function callbacks, which can be enhanced by D delegates.
A notable exception is wxWindows which distributes events through inheritance.

-i.
May 19 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 Most do through usual function callbacks, which can be enhanced by D


delegates.

 A notable exception is wxWindows which distributes events through


inheritance.

(Just a side-note: wxWindows seems to also support
callback functions (recently?). Never used it, though.)

Sz.
May 19 2003
parent Stephan Wienczny <wienczny web.de> writes:
Luna Kid wrote:

Most do through usual function callbacks, which can be enhanced by D


 
 delegates.
 

A notable exception is wxWindows which distributes events through


 
 inheritance.
 
 (Just a side-note: wxWindows seems to also support
 callback functions (recently?). Never used it, though.)
 
 Sz.
 
 


Have a look at:

http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin466.htm#eventhandlingoverview

Vadim Zeitlin wrode something about it.

SW
May 19 2003
prev sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Mark T wrote:

 
 Now that D on Linux is a reality (thanks Walter), how about creating a standard
 portable GUI for D? 


I would try to support this.


 It seems all the GUI effort is focused in the Windows arena.


I think that the Windows GUI is better developed and designed than the 
various Unix GUI APIs, so I think that it would be a good idea to reproduce
the Windows GUI functionality under Linux. 


 As mentioned previously in another thread, the Java Standard Widget Toolkit
 (SWT) would be a great place to get ideas. This would be a good college project
 for a small group. You could host it on SourceForge so it wouldn't die an early
 death (after your semester ends). Give it a BSD or similar style license so
 companies won't be afraid to use it.


I think that a GUI is a critical point for the success of D in the marketplace.
This should not be left to students, however large their commitment may be.
 

 "The most succinct description of the Standard Widget Toolkit component is
this:
 
 The SWT component is designed to provide efficient, portable access to the
 user-interface facilities of the operating systems on which it is implemented."


I don't know the SWT, but I never heard anything else about any Toolkit,
API or programming language. 

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 19 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Helmut.


It seems all the GUI effort is focused in the Windows arena.


 
 
 I think that the Windows GUI is better developed and designed than the 
 various Unix GUI APIs, so I think that it would be a good idea to reproduce
 the Windows GUI functionality under Linux. 


Ouch... This statement is bound to draw flames...

If you mean the stuff developed by Microsoft (Visual C++, MFC, ActiveX, 
etc), there will be real problems porting it.  There might be hope for 
non-Microsoft stuff.

So far as I can tell, the good portable GUI stuff is all non-Microsoft.

Is there a specific Windows GUI platform you'd like to port, or are you 
thinking of broader support, using something like Wine?

Bill
May 19 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Bill Cox wrote:

 I think that the Windows GUI is better developed and designed than
 the various Unix GUI APIs, so I think that it would be a good idea
 to reproduce the Windows GUI functionality under Linux.


 
 Ouch... This statement is bound to draw flames...


Bill, you are right. Windows API doesn't give the applications all of 
the elements they very usually need. So, for example, Toolbars in 
Internet Explorer are an add-on -- though they can be used by other 
applications. But Microsoft Office uses more enhanced toolbars, which 
don'thave any standard component behind them.

I frankly don't know why Helmut has such a bad impression about Unix GUI 
toolkits. Yes, motif is utter crap. But noone uses it these days. The 
alternatives for appications are:

  - FOX GUI Toolkit: a C++ based toolkit which has a look-and-feel of 
Windows. It is client-draw, very fast, and arguably more functional than 
the Windows standard widget set. It is not very well documented though. 
Non-skinnable client-draw. LGPL allows use in commercial applications. 
Windows port OK.
http://www.fox-toolkit.org/

  - Qt toolkit, C++, GPL/Commercial. Yet more advanced than FOX, a basis 
for KDE. Skinnable client-draw. Windows port commercial only.

  - GTK+, C. It is gaining up and becoming more powerful. It is 
comparable with the previous ones nowadays. (LGPL/GLP???) Skinnable 
client-draw. Windows port very buggy.

  - FLTK, C++. The only toolkit on this list that is less powerful than 
Windows. However, it's very lightweight and fast and lends itself to be 
used in tiny applications. Limited skinning, developing. Windows port OK.

Usually windows programs use many client-draw parts - but since Windows 
didn't offer any skinning capabilities before recently, writing widgets 
which maintain the same look-and-feel was easy, and i guess they are 
responsibe for a myth of the power of windows interfaces.

-i.
May 19 2003
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
I frankly don't know why Helmut has such a bad impression about Unix GUI 
toolkits. Yes, motif is utter crap. But noone uses it these days.


maybe not in the Linux world but the other UNIXes seem to cling to this dinosaur
(why did IBM choose this for their standard SWT UNIX mapping?) 
But anything is faster than SWING - try a SWING app on Windows and you will be
appalled at how slow it is.  The Java people seem excited about SWT that's why I
mentioned it. I have no free time to look at the code.


  - FOX GUI Toolkit: 
  - Qt toolkit, C++, 


Borland Kylix for Linux uses this underneath

  - GTK+, C. >  
  - FLTK, C++.  


It seems one of these could be a better inspiration than SWT, any takers out
there? (maybe all the students are in-transit after the semester). I would
rather see a limited functionality but cross-platform first as long as the
overall design wasn't broken.


Limited skinning


I have no idea what this is?  I haven't done any GUI work in about 5 years and
the stuff I did was very standard. From my perspective most of the
Windows/Office XP GUI stuff is just extra decoration on the cake (it doesn't
taste any better :)


Good suggestions
May 20 2003
parent reply Ilya Minkov <Ilya_member pathlink.com> writes:
In article <bad0lq$28ns$1 digitaldaemon.com>, Mark T says...


maybe not in the Linux world but the other UNIXes seem to cling to this dinosaur
(why did IBM choose this for their standard SWT UNIX mapping?) 
But anything is faster than SWING - try a SWING app on Windows and you will be
appalled at how slow it is.  The Java people seem excited about SWT that's why I
mentioned it. I have no free time to look at the code.


Other unixes also change. Sun chose GNOME to be their standard window manager
from the next version on, and will change to use GTK+ as their standard toolkit.

And don't forget all other non-commercial unixes, like ****BSD, which are under
the same arsenal as Linux.

C++ people are also very excited about wxWindows, especially if they ever get to
compile their proggies under MacOS X. :>


  - FOX GUI Toolkit: 
  - Qt toolkit, C++, 


Borland Kylix for Linux uses this underneath


I know. :>


  - GTK+, C. >  
  - FLTK, C++.  





It seems one of these could be a better inspiration than SWT, any takers out
there? (maybe all the students are in-transit after the semester). I would
rather see a limited functionality but cross-platform first as long as the
overall design wasn't broken.


GTK is not an inspiration, it is a sad fact. :) FLTK is quite a good
inspiration.


Limited skinning


I have no idea what this is?  I haven't done any GUI work in about 5 years and
the stuff I did was very standard. From my perspective most of the
Windows/Office XP GUI stuff is just extra decoration on the cake (it doesn't
taste any better :)


GTK+ currently supports full skinning - stuff like Windows XP. Rather
questionable whether that's good or not. It also seems to me that it becomes
rather unmaintanable and thus it's less likely that a windows port will get rid
of bugs. Before skinning GTK looked like Motif. :(

Qt supported limited skinning from the beginning on: there was a Motif skin, a
Windows skin, and a Platinum skin built-in from the very beginning. They weren't
based upon bitmaps, as GTK is, but on separate drawing code. This kept things
rather maintainable and allowed it to tune to a platform's look and feel.
Recently full skinning was added.

FLTK is based on a fact that drawing a box is actually much simpler than asking
a window manager to do so. :) So, it's completely based upon pluggable boxes. A
few box drawing routines are standard, the programmer can also supply his own.
Then, the look of any widget can be configured by telling it what box types are
to be used. By default, FLTK selects a somewhat different look depending on an
underlying OS. You can easily imagine that this scheme is easily expanded to
full skinning if requiered - however i prefer to stay with simple routines. :)
In FLTK, a box is not necessarily a box. Arrows and other common elements are
made in the same manner.

To sum it up, any kind of diversity hinders the development of custom widgets,
but the scheme used in FLTK seems to be the least painful direction.


Good suggestions 


I believe i have more. :)

The placement system of TKInter - a standard TK-based GUI used with Python - has
really impressed me: it's very simple and very flexible. You place widgets on a
dynamically-sized grid with inferred constraints. Widgets are expanded to take
optimal space... i'm afraid it takes more than a few lines to explain it, but
it's really very impressing!

I also have to study other systems to be able to come up with something.

Another important aspect is redraw. How should the redraw be controlled? Qt
sometimes redraws in software-buffer and blits to screen to reduce flicker.
However, drawing on-screen is faster with modern hardware. However, drawing must
then be separated into incremental parts: do not draw a large grey field just to
immediately overdraw it with an almost as large white field - that's what often
happens in windows programs. I have to read more about it.

So, if anyone has any pointers to any useful information, i will gladly evaluate
it and sum it up on a Wiki or here.

-i.
May 20 2003
next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
 FLTK is based on a fact that drawing a box is actually much simpler than


asking

 a window manager to do so. :) So, it's completely based upon pluggable


boxes. A

 few box drawing routines are standard, the programmer can also supply his


own.

 Then, the look of any widget can be configured by telling it what box


types are

 to be used. By default, FLTK selects a somewhat different look depending


on an

 underlying OS. You can easily imagine that this scheme is easily expanded


to

 full skinning if requiered - however i prefer to stay with simple


routines. :)

 In FLTK, a box is not necessarily a box. Arrows and other common elements


are

 made in the same manner.


Is this, what's called client-draw?

(Actually, I also worked on a pretty ambitious C++ GUI
project, but that was some 8 years ago. I still may have
some stuff to contribute (I was the event + listbox +
editor guy), but my GUI coding experience is dusty, at
best... And no free time, either. :-( )

Cheers,
Sz.
May 20 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
Hi, Ilya.

Ilya Minkov wrote:

 In article <bad0lq$28ns$1 digitaldaemon.com>, Mark T says...
 
 

maybe not in the Linux world but the other UNIXes seem to cling to this dinosaur
(why did IBM choose this for their standard SWT UNIX mapping?) 
But anything is faster than SWING - try a SWING app on Windows and you will be
appalled at how slow it is.  The Java people seem excited about SWT that's why I
mentioned it. I have no free time to look at the code.


 
 
 Other unixes also change. Sun chose GNOME to be their standard window manager
 from the next version on, and will change to use GTK+ as their standard
toolkit.


This is why we chose GTK+ for our latest GUI.  I'm hoping that with Sun 
backing it, GTK will become a better GUI platform, even with it's 
current weakness.

Your description of FLTK really makes me want to try it out.  However, 
being a C++ system, it might be hard to import into D.  That's another 
reason to keep looking at GTK+.

I found a Lua FLTK link when I Googled FLTK.  It looks like they've 
succeeded in wrapping FLTK and importing it into Lua.

http://lua-fltk.sourceforge.net/

They're aproach for translating header files sounds like it could become 
a nightmare for D.  How would we translate classes using multiple 
inheritance, for example?

Bill
May 20 2003
parent reply Mark T <Mark_member pathlink.com> writes:
 
 Other unixes also change. Sun chose GNOME to be their standard window manager
 from the next version on, and will change to use GTK+ as their standard
toolkit.


This is why we chose GTK+ for our latest GUI.  I'm hoping that with Sun 
backing it, GTK will become a better GUI platform, even with it's 
current weakness.


For a near term business decision this is sound,  D supports C API libraries
very well

Your description of FLTK really makes me want to try it out.  However, 
being a C++ system, it might be hard to import into D.  That's another 
reason to keep looking at GTK+.


Importing or wrapping C++ based toolkits is bad, D should either venture forth
and create it's own standard portable GUI toolkit or maybe stay out of GUI
(remember D is designed to be a systems programming language, which typically
translates to scientific data crunching, tools like compilers, etc, embedded
May 22 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
Your description of FLTK really makes me want to try it out. 
However, being a C++ system, it might be hard to import
into D.  That's another reason to keep looking at GTK+.


Importing or wrapping C++ based toolkits is bad, D should
either venture forth and create it's own standard portable
GUI toolkit or maybe stay out of GUI (remember D is designed
to be a systems programming language, which typically
translates to scientific data crunching, tools like

have made little incursion on C and C++)


What if we had an API for GUI work? Not directly included in
the official D spec, but as an informal, yet de facto standard?

Then anyone who ports or creates a GUI toolkit would try to
follow this API -- within reason. What needs to differ from
the API would then be well documented in the GUI programmers
docs.

This would give economy of development to app programmers,
and ease porting their D apps to several GUIs.

I think a Wiki and a mailing list are needed for this.
May 22 2003
next sibling parent Mark T <Mark_member pathlink.com> writes:
What if we had an API for GUI work? Not directly included in
the official D spec, but as an informal, yet de facto standard?


this is a good idea but it the API still needs to be proven by instance there of

the design may look good on paper but needs to be implemented to really iron it
out
May 23 2003
prev sibling parent Toyotomi <io219 attbi.com> writes:
On Thu, 22 May 2003 15:42:48 +0000 (UTC), Georg Wrede
<Georg_member pathlink.com> wrote:



What if we had an API for GUI work? Not directly included in
the official D spec, but as an informal, yet de facto standard?

Then anyone who ports or creates a GUI toolkit would try to
follow this API -- within reason. What needs to differ from
the API would then be well documented in the GUI programmers
docs.


Python has a DB API that tries to do this... I personally find it annoying
and use native database wrappers instead. I imagine it could be even more
annoying for something as complex as a GUI abstraction.
May 28 2003
prev sibling next sibling parent Karl Bochert <kbochert copper.net> writes:
 
   - FOX GUI Toolkit: a C++ based toolkit which has a look-and-feel of 
 Windows. It is client-draw, very fast, and arguably more functional than 
 the Windows standard widget set. It is not very well documented though. 
 Non-skinnable client-draw. LGPL allows use in commercial applications. 
 Windows port OK.
 http://www.fox-toolkit.org/
 
   - Qt toolkit, C++, GPL/Commercial. Yet more advanced than FOX, a basis 
 for KDE. Skinnable client-draw. Windows port commercial only.
 
   - GTK+, C. It is gaining up and becoming more powerful. It is 
 comparable with the previous ones nowadays. (LGPL/GLP???) Skinnable 
 client-draw. Windows port very buggy.
 
   - FLTK, C++. The only toolkit on this list that is less powerful than 
 Windows. However, it's very lightweight and fast and lends itself to be 
 used in tiny applications. Limited skinning, developing. Windows port OK.
 


Any comments on IUP? <http://www.tecgraf.puc-rio.br/iup/>
Its cross-platform and does layout  with "boxes and glue", (like Tkinter??)
It is C, very simple and easy to learn, and supposedly very high-performance
(with a GUI, who can tell?)
I interfaced it to my interpreter in a matter of days, including adding an OO
interface.
 
Karl Bochert
May 20 2003
prev sibling parent John Reimer <jjreimer telus.net> writes:
  - FOX GUI Toolkit: a C++ based toolkit which has a look-and-feel of 
 Windows. It is client-draw, very fast, and arguably more functional than 
 the Windows standard widget set. It is not very well documented though. 
 Non-skinnable client-draw. LGPL allows use in commercial applications. 
 Windows port OK.
 http://www.fox-toolkit.org/
 
  - Qt toolkit, C++, GPL/Commercial. Yet more advanced than FOX, a basis 
 for KDE. Skinnable client-draw. Windows port commercial only.
 
  - GTK+, C. It is gaining up and becoming more powerful. It is 
 comparable with the previous ones nowadays. (LGPL/GLP???) Skinnable 
 client-draw. Windows port very buggy.
 
  - FLTK, C++. The only toolkit on this list that is less powerful than 
 Windows. However, it's very lightweight and fast and lends itself to be 
 used in tiny applications. Limited skinning, developing. Windows port OK.
 
 Usually windows programs use many client-draw parts - but since Windows 
 didn't offer any skinning capabilities before recently, writing widgets 
 which maintain the same look-and-feel was easy, and i guess they are 
 responsibe for a myth of the power of windows interfaces.
 
 -i.
 


Interesting.  I found an example of what can be done with some 
cross-platform toolkits.  In this case, SDL is used (of all things!)

The software is alpha, but it certainly does an impressive job of 
reproducing a GUI (note that the user interface is completely skinnable).

http://pixel32.box.sk

The site has been difficult to get to recently.  It's a heavy-duty 
shareware photo-editing program.

A GUI toolkit for D would be great.  Looks like D has an exciting future,

Later,

John
May 20 2003
prev sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Bill Cox wrote:

 
 Hi, Helmut.
 

It seems all the GUI effort is focused in the Windows arena.



 I think that the Windows GUI is better developed and designed than the
 various Unix GUI APIs, so I think that it would be a good idea to reproduce
 the Windows GUI functionality under Linux.


 
 Ouch... This statement is bound to draw flames...


Sorry, I think I didn't make clear that this statement is from the user 
viewpoint, focusing on the overall graphical design and the standardization 
of the GUI. This doesn't take the API into account. 

What I meant is "reproduce the look and feel of the Windows GUI".

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 19 2003
parent Bill Cox <bill viasic.com> writes:
Hi, Helmut.

Nothing to be sorry for...  I should put more :-) symbols in.

I agree that reproducing the look and feel of Windows is critical for 
portable GUI efforts.

I don't know much about GUI development, but I do know one thing:  Most 
good GUI's are developed by GUI experts.  These guys do nothing but play 
with new widgets all day long.  They're value is in knowing a GUI system 
inside and out.  Basically, these guys pick a winning GUI system, and 
make a career out of it.

Most of the guys I know that are into GUI use MFC, or Java.

There are huge advantages in going with a winning platform.  Is there 
any way of building a portable GUI system for D where there might 
actually be jobs writing GUIs?  D would somehow have to wrap MFC or 
Java, or some other very popular system.

Bill

Helmut Leitner wrote:

 
 Bill Cox wrote:
 

Hi, Helmut.



It seems all the GUI effort is focused in the Windows arena.



I think that the Windows GUI is better developed and designed than the
various Unix GUI APIs, so I think that it would be a good idea to reproduce
the Windows GUI functionality under Linux.


Ouch... This statement is bound to draw flames...


 
 
 Sorry, I think I didn't make clear that this statement is from the user 
 viewpoint, focusing on the overall graphical design and the standardization 
 of the GUI. This doesn't take the API into account. 
 
 What I meant is "reproduce the look and feel of the Windows GUI".
 
 --
 Helmut Leitner    leitner hls.via.at   
 Graz, Austria   www.hls-software.com
May 20 2003