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

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.
- Wrap wxWindows - following the way C# port guys are doing it. (or 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

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.
> - Wrap wxWindows - following the way C# port guys are doing it. (or 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

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.

> 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.

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

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

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

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.

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