Thread: x,xlib, xt, motif or ??

I have just started designing a program that has some very extensive graphics requirements. The program is being written in C/C++. (Actually it is quite far into development.)
My question is what is the easiest path to building a functional graphics gui. These are financial charts and graphs.
From what I have seen I can use x, xlib, xt, or motif to handle the graphics, but each seems to have a slightly different level of abstraction and functionality. Having never before written this level of functionality on a unix/linux system, I am somewhat unsure of what is the best path to take.
I have no problem with the rest of the app, things such as dialogs, menus, db access, etc, etc only with the the graphics portion.
Any suggestions or insights would be greatly appreciated.

thanks

tom

>> I have no problem with the rest of the app, things such as dialogs, menus
Dialogs and menus would be part of the GUI. How did you do those?

X/XLib is the lowest level for GUI programming - all other libraries are build on top of this.

Motif is proprietary (last I checked) but there's LessTif which is free and "source compatible". It's a C API so if you're using C++ this probably isn't the best choice.

For C++ I recomend Qt. KDE is built on Qt so it's widely used. There's also gtkmm and wxWidgets. You can find links to all these here: http://cboard.cprogramming.com/showthread.php?t=79619

gg

I was planning on using the GTK for Dialogs and Menus - however I have not found any really decent doc on it's graphic capabilities. I need to plot xy, scale objects and place them dynamically and the only decent graphics seem to be at lower levels than GTK provides. I was thinking of using OpenMotif which is not proprietary.

tom

I don't think you'll gain anything by using Motif just for the graphics end of things...

GTK+ or gtkmm (the C++ API for GTK+) are not a bad choice. Finding documentation to just "do what you want" can sometimes be frustrating, but GTK+ is a mature and widely used platform so I believe the resources are out there.

I started here: http://www.gtk.org/ Then I scanned the FAQ and found "5.25. How do I render pixels (image data) to the screen?"

Originally Posted by GTK+ FAQ

There are several ways to approach this. The simplest way is to use GdkRGB, see gdk/gdkrgb.h. You create an RGB buffer, render to your RGB buffer, then use GdkRGB routines to copy your RGB buffer to a drawing area or custom widget. The book "GTK+/Gnome Application Development" gives some details; GdkRGB is also documented in the GTK+ reference documentation.

If you're writing a game or other graphics-intensive application, you might consider a more elaborate solution. OpenGL is the graphics standard that will let you access hardware acceleration in future versions of XFree86; so for maximum speed, you probably want to use OpenGL. A GtkGLArea widget is available for using OpenGL with GTK+ (but GtkGLArea does not come with GTK+ itself). There are also several open source game libraries, such as ClanLib and Loki's Simple DirectMedia Layer library (SDL).

You do NOT want to use gdk_draw_point(), that will be extremely slow.

I then google'd that book and found it online: http://developer.gnome.org/doc/GGAD/ggad.html
If you're serious about using GDK+, even if just for dialogs and such, I would sit down read that from the beginning.

Using OpenGL or SDL, as the FAQ suggests, sounds like a pretty damn cool approach for your project - I'm thinking 3D charts and graphs - with hardware acceleration The downside being that it's another API to become familiar with.

gg

Thanks for the info, I now have some reading to do

tom

If anyone has any direct experience with graphics programming under linux and can render a first person recommendation - not what they found on google, I would love to hear about it. The prior recommendations are for earlier versions of the gdk and won't even remotely come close to compiling.
At this point I am leaning quite heavily toward doing the graphics in Xlib - may not be the easiest route but at least it compiles and it works.

tom

Originally Posted by nga_tom

If anyone has any direct experience with graphics programming under linux and can render a first person recommendation - not what they found on google, I would love to hear about it.

wxWidgets. You can get bindings for many languages. It's even cross-platform. Yes, I've used it.

I strongly recommend writing the GUI using an easy scripting language like Python (which of course has a wx binding available), and have the GUI communicate with the back end through pipes or sockets. This is basically a "model-view" architecture taken to the extreme, where the model exists in another process entirely.

if the scripting language is not fast enough to render objects at the speed you need, then you can call out to native code (any decent scripting language will let you) for the speed-critical bits, like drawing millions of lines.

1) GUI crashes won't crash the underlying app. It's stupid to crash and lose important data just because of a GUI bug. Let the GUI crash -- just restart it. GUIs written in scripting languages probably won't crash at all.

2) When you get the urge to completely rewrite the GUI, possibly in a different language, you don't have to rewrite the rest of your app.

Yeah - that's an old book. Here's the official reference: http://library.gnome.org/devel/gtk/stable/

Like I said, the resources are out there - but you'll have to use google, or whatever search engine you prefer to find them.

gg

I'm also interested in this. There's a virtual maze of dated info when I do web searches. Finally settled on GTK+ but its tough going. And GTK+ 2 has been released along with Glade, Glade2 Glade-Gnome etc. QT is C++ so forget that...

The idea of using Python with wxwidgets sounds nice. I briefly looked at wxwidgets but I don't know C++ and my code is already written in C. I know a fair amount of Python and like it so maybe that will save me from the GTK+ nightmare.

For Python, there's Matplotlib - http://matplotlib.sourceforge.net/

gg

There's PyQt and a fine book on it.