Fox: best GUI Lib?

[gamaron]

Summary
---------

Is Fox Toolkit ( http://www.fox-toolkit.org/ ) the "best" C++ GUI
library/toolkit?

My key goals (at least those that come to mind right now):
* Portability (Windows, Linux, MacOS, other unix)
* Open source
* Maturity
* Broad feature set
* Large community following & support

More Details
-------------

I'm an ex-C++ programmer/designer that has come back to "the fold" after a
long hiatus doing non-programming work (program management, sales,
marketing, etc).

After browsing ( http://www.thefreecountry.com/sourcecode/gui.shtml ), Fox
Toolkit seems to be a clear winner for my goals above.

Maybe I missed something? Can anyone provide other toolkit/library
suggestions...a nd (very important) their associated reasoning? Nothing
I've looked at thus far seems to be nearly as "open-source" available,
popular, and mature. Fox's web presence (web page, mailing lists,
documentation) also seems quite professional, mature, and popular.

(Disclaimer: I realize it's difficult to label something as "best."
Often a solutions choice might heavily depend on the problem to solve and
the problem's associated "environmen t"--be it technical, political,
personal preference, etc. However, I use the word "best" here mostly to
be concise...and to spark some feedback. ;)

Thanks for any help!
-Matt

[Ioannis Vranos]

Steven T. Hatton wrote:

There /is/ a very capable opensource subset of Qt. The entire KDE[*] is
written using that subset and extensions thereof. I'm not going to get
into the game of judging what is the best. Qt, from what I've seen, is the
most successfull in terms of creating useful application. GTK has it's
bragging rights [**] as well, but since this is a C++ newsgroup, I have to
observe that it is not a C++ toolkit. It does have some C++ wrappers,
however.

My approach has been to write code that remains as independent of any
particular toolkit as possible, and to treat the GUI as an interface. That
is often easier said than done. Quite often much of what a program does is
to provide a user interface.

I find the "hard parts" of figuring out the algorithms and logical
structures are usually far easier than providing an interface to them.

I think a good approach for this is what Bjarne says in an interview:
http://www.artima.com/intv/elegance.html

" I think people should mentally separate programming into building
libraries and using them. Today you write a supporting library, and
tomorrow you use it. Far too many times people try and build their
systems as one big conglomerate. Even when I do individual work for only
a short time, I tend to build some supporting functions and classes, and
I design them to be supporting. I don't dive straight into building the
whole thing that can do the whole job. So, whether you are by title a
library designer or application designer, you should think about how you
can separate logically the different parts of your system."


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

gamaron wrote:

Summary
---------

Is Fox Toolkit ( http://www.fox-toolkit.org/ ) the "best" C++ GUI
library/toolkit?

My key goals (at least those that come to mind right now):
* Portability (Windows, Linux, MacOS, other unix)
* Open source
* Maturity
* Broad feature set
* Large community following & support

In the Windows world, we are coming to WinFX (which is a managed API),
with Win32 becoming deprecated.
WinFX which is now .NET is a CLI VM. CLI is a standard defining how such
a *multilingual* VM works, its assembly language and a *minimal* API.
CLI: http://www.ecma-international.org/pu...s/Ecma-335.htm

There are becoming many CLI VMs out there, the current mainstream ones are:

NET framework (Windows): http://msdn.microsoft.com/netframework

Mono (GNU/Linux, Unix, Mac OS X and Windows): http://www.mono-project.com

DotGNU (GNU/Linux, Mac OS X, Windows): http://www.gnu.org/projects/dotgnu


QT etc are great, however I do not know how they will encapsulate CLI
environments.

Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

I think a good approach for this is what Bjarne says in an interview:

http://www.artima.com/intv/elegance.html

" I think people should mentally separate programming into building
libraries and using them. Today you write a supporting library, and
tomorrow you use it. Far too many times people try and build their
systems as one big conglomerate. Even when I do individual work for only
a short time, I tend to build some supporting functions and classes, and
I design them to be supporting. I don't dive straight into building the
whole thing that can do the whole job. So, whether you are by title a
library designer or application designer, you should think about how you
can separate logically the different parts of your system."

Add Features not Modules

During a project's growth, the code always supports its current feature set
with the fewest design elements and fewest source statements possible, no
more. Groom the code to preen out Cruft; this frees the schedule, and lowers
the defect rate. Compete to add features elegantly.

Developers gifted with the ability to plan a design that could cover all
potential features are welcome here, if they hold that complete design up
for a goal but not the path. Teams expect members to specialize, and to
teach others how they do what they do. Nobody "owns" any module, and pairs
switch frequently.

A feature is not finished without its servants and clients in other modules.
At all times a program should form a useable round-trip application. And at
all times a user can comfortably drive all of a system's current features,
without gaps.

Developers volunteer to complete User Stories that affect modules they
understand. No module grows in isolation without immediately satisfying
other modules. Each User Story requires changes to any number of modules.

Libraries are modules for sale. Application-specific modules are skeletons
of libraries, presenting clean interfaces over only those few features their
applications need.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Keith H Duggar]

> > My key goals (at least those that come to mind right now):

* Portability (Windows, Linux, MacOS, other unix)
* Open source
* Maturity
* Broad feature set
* Large community following & support

Personally, I think native widget libraries blow in so far
as portability goes. If portability is key I would much
rather use something built on OpenGL such as GLOW, GLUI,
etc. I've used GLOW for a few small projects and it was
simple, clear, and effective. Though it doesn't have a
"broad" feature set nor a large community for support.
However, both of those are easily overcome if you are a
capable programmer and you understand OpenGL.

Also, GLOW is nicely coded C++. No macro crap or huge
complicated make files and utilities to get the thing
to compile. You just include and compile, that's it.

[Matt]

On 31 Oct 2004 12:44:58 -0800, du****@alum.mit .edu (Keith H Duggar)
wrote:

Personally, I think native widget libraries blow in so far
as portability goes. If portability is key I would much
rather use something built on OpenGL such as GLOW, GLUI,
etc.

Ok. I see that GLOW has not released a new version in 4 years. Is
this a good or a bad sign? Maybe this is indicative of maturity;
maybe there's no ongoing work/development? Is any needed?

http://sourceforge.net/project/showf...?group_id=3417

Also, is this the the "home page" for GLUI?

http://www.cs.unc.edu/~rademach/glui/

At first glance, OpenGL ( http://www.opengl.org/ ) seems to be
oriented towards "High Performance Graphics." My goals at this time
are not high-peformance graphic oriented. I'm wondering if this is a
good fit for my work? Maybe there's more to it then meets the eye?
Like you say, it's simple, clear, and effective. I'll keep this in
mind. Thanks for the input!

-Matt

[Natros]

On Sun, 31 Oct 2004 04:55:45 -0500, Steven T. Hatton wrote:

Phoenix Fyrestar wrote:

The only problem with Qt is that you have to buy a book* (C++
GUthereafterrrm ing with Qt 3)** to get the GPL version for windows. I
agree that it's a great toolset, and if you don't already know Qt, the
caveat about buying the book doesn't really apply, since this is simply
the
best documentation on Qt available, and you'll want to fork over for the
book anyway (I think it cost me $30 at Barnes and Nobel, probably be able
to find it cheaper if you look on Amazon).

* Since it's the GPL version, you really don't have to buy the book, just
find someone to give you a copy of the libraries, but that's the only
"official" way to get it for windows that I know of.

** Qt 4 should be comming out soon (or is it out now?) and soon thereafter
a new book.

You are correct. I had forgotten about that. I haven't booted into Chi Rho
in months, so I haven't had to deal with issue lately. As for the Qt book,
it's a damn good book!

http://www.accu.org/bookreviews/publ...p/cp003567.htm

And can now be download in pdf format from
http://phptr.com/title/0131240722

[Billy Patton]

my $0.02.

Ask your self "What do I need?".
My experience.
my need "to display cells/designs of an IC". From k's to megs of figs
Steps I took: all on unix platform
1. raw X. Too much code to get basic GUI but did draw fast.
2. Xt reduced the amount of code for GUI but did draw fast.
3. libsx Simplest of all the gui's to get a GUI. Was slow drawing
be developemnt was VERY fast. THis has to be the most simple GUI
in the world.
4. QT. fast easy to set up windows. Drawing was fast
UNTIL i gave it 2million+ rectangsle and polygons.
brought it to it's knee's. Every rectangle was it's own
instance of a class. Very good work for a few k rectangles.
but not for millions
5. wxWindows fast and easy to create basix windows. Allowed me
to draw all figs to bitmap and blit bitmap to screen. 1 call to X server
very quick to draw, even millions of rects.
evolution of wx made it look like and behave a lot like QT.
QT might have allowed the drawing to bitmap and blit'ting but I
did not go back
6. gtk A little more trouble than qt or wx to GUI.
drawing was VERY fast. Dealing with colors, line textures and fill patterns
was much more difficult. But executable size was very small compared to
others.

bottom line.
You want a very pleasing GUI to communicate with user -> use QT
You need a data intensive program with a (can be plaesing also) GUI -> use gtk.
You want something VERY simple and very functional -> use libsx

___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-******@ti.com

On Sat, 30 Oct 2004, gamaron wrote:

Summary
---------

Is Fox Toolkit ( http://www.fox-toolkit.org/ ) the "best" C++ GUI
library/toolkit?

My key goals (at least those that come to mind right now):
* Portability (Windows, Linux, MacOS, other unix)
* Open source
* Maturity
* Broad feature set
* Large community following & support

More Details
-------------

I'm an ex-C++ programmer/designer that has come back to "the fold" after a
long hiatus doing non-programming work (program management, sales,
marketing, etc).

After browsing ( http://www.thefreecountry.com/sourcecode/gui.shtml ), Fox
Toolkit seems to be a clear winner for my goals above.

Maybe I missed something? Can anyone provide other toolkit/library
suggestions...a nd (very important) their associated reasoning? Nothing
I've looked at thus far seems to be nearly as "open-source" available,
popular, and mature. Fox's web presence (web page, mailing lists,
documentation) also seems quite professional, mature, and popular.

(Disclaimer: I realize it's difficult to label something as "best."
Often a solutions choice might heavily depend on the problem to solve and
the problem's associated "environmen t"--be it technical, political,
personal preference, etc. However, I use the word "best" here mostly to
be concise...and to spark some feedback. ;)

Thanks for any help!
-Matt

[Benjamin Lau]

GTK+ is actually a C toolkit, so if you are interested, you can use
gtkmm instead, which is just a C++ wrapper. (http://www.gtkmm.org)
However, if you are looking for a native look and feel, here's my
opinion:

wxWindows(wxWid gets) : very good, reasonable native looks (10+ years
of history)

GTK+ : Quite decent, very gnome-like, but quite similar to Win32(Tip:
no MDI however but can be feigned by using a notebook)
gtkmm : same as GTK+

FLTK : not very good, may be portable to Macs and Win32, but looks
like it's running on X

Qt : very good, with good native looks, plus...you can make your
application adopt different styles

Also, for ease-of-use, here's what I think:

wxWindows : quite ok, uses Model-View architecture, can be abit of a
slow development without a UI builder(many available, recommend wx
Dev-C++ http://wxdsgn.sourceforge.net/)

GTK+ : If you're used to doing things in very much the C way, it is
quite good
gtkmm : good use of C++ features, quite fast to develop, quite
flexible
(both come with a UI builder called Glade)

FLTK : Quite reasonable, but because of the use of function pointer
callbacks, i don't quite trust it, but there is a projetc on
sourceforge attempting to cure its "fn ptr" usage. Comes with a UI
builder Fluid, but I can't make heads or tails of Fluid.

Qt : excellent, best I've seen so far, easy to write, syntax is very
natural, UI builder is very good

So far it sounds like Qt is the best, one catch though...if you are
writing commercial applications, be prepared to fork out USD $1550 for
a single platform package (for more info, go to
http://www.trolltech.com/products/qt/pricing.html), because Qt comes
in both GPL and commercial versions. Also, there isn't a free version
for Win32, only a non-commercial, which you still pay for and cannot
be used for commercial work, and a commercial version.

If you don't have that kind of cash, use wxWindows if you have more
time, and use gtkmm if you have less.

Use FLTK only if none of the above are viable (I'm kind of biased
towards toolkits which have a native look and feel, fast development,
and a good UI builder, and FLTK only has speed in coding, so I don't
really like it)

If you are doing GPL software, use Qt, but you probably can't port it
to Win32, so it's either wxWindows or gtkmm (wx has more nativity, but
a bit slower coding)

Here's a summary of what I have said:

wxWindows : When you have no money, you need to develop commercially,
you have more time, and you go for native looks

gtkmm or GTK+ : When you have less time, no money, and you just want
it to look something like WIndows, but don't really care nitty-gritty
(commercial)

Qt : when you have $$, but, if you aren't looking towards Win32, use
its GPL versions(genera ted apps MUST be GPL)

FLTK : Use only when necessary (like can't obtain above)

P/s gtk+ and gtkmm and FLTK are supplied as LGPL, so always use shared
libraries (like DLLs or .so files)

P/ps Hope I was useful :)

P/pps Feel free to bludgeon me for my postscripts, but sorry if I am a
bit long winded :) Have a good day