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

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.

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

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

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

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

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

>> 
>> 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 programming;  areas where Java and C# have made little incursion on C and C++)

>>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 programming;  areas where Java and C# 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.

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