Results 1 to 6 of 6
Thread: GTK+ and OpenGL
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jan 2013
GTK+ and OpenGL
gtk is a widget toolkit. It provides things like windows, menus, buttons, labels and sliders. All graphical programs need to use a widget library of this sort and most use either gtk or qt. gtk usually goes with gnome and qt with KDE.
OpenGL is a system for drawing directly on video cards, if the card supports it (which any decent modern card does). It speeds things up in games, etc. Programs call openGL functions and the X-server directs them either to the card's gpu to be executed by the firmware or, if necessary, to the cpu to be executed rather more slowly using mesa library functions.
So the two things are quite different. And btw C doesn't have a GUI interface as such but there are GUI development tools that will help you to write C programs."I'm just a little old lady; don't try to dazzle me with jargon!"
- Join Date
- Jan 2013
Thank you Hazel for your response, It cleared up a lot!
Let's stop at the 'beginning' - you're learning C to familiarize yourself with the Linux Kernel. May I suggest picking up a Linux Kernel Architecture book. There's millions of lines of C code which makes the Kernel, it's not a 50 line calculator program... Picking up the source to try and familiarize yourself with it without the proper backing, I feel, is the wrong approach. Learn the architecture, then dive into the code. Learning C at its base level (as a language) is easy, there's not a whole lot to the language. The hard part isn't knowing C, it's system familiarity, that is, "why is this code doing this" - which you learn in the architecture. Quite easy to score perfectly on a C proficiency test, but that doesn't mean you'll be able to pick up a piece of source from the Linux kernel and spit out its functionality. Learning the system architecture is much more difficult than learning C, so I wouldn't combine "learning C" so you can "learn the Linux kernel" - as I feel they're 2 very different directions that only slightly go hand-in-hand.
Alright, now that I've got that whole bit out of the way, let's talk about GTK vs OpenGL. OpenGL is a hardware accelerated, low level graphics library. It is low level, it is hardware dependent (it must be supported in hardware), it is hardware accelerated, it is VERY basic rendering engine. Examples of GL primitives are things like the ability to draw GL_TRIANGLES given 3 3D points (combining many of these triangles to shape 3D meshes). Libraries such as GLU and GLUT are often used on top of or along side OpenGL in order to extend the capabilities of OpenGL. Libraries such as GLU extend the functionality of it by providing a larger API while libraries such as GLUT provide what's essentially a canvas for OpenGL renderings to exist in. Using OpenGL embedded in a GLUT window is very common. One thing you have to remember is that OpenGL is ONLY the specification that is defined. So does it come with a windowing tool kit? No, not even slightly, it is only a standard. You can embed an OpenGL rendering (let's just say a sphere, for simplicity sake) in a GLUT window, but you can take that same OpenGL rendering code and put it inside anything else that supports OpenGL, for example either a GTK or QT GL widget. As OpenGL is standardized, that part of the code is standardized. GTK on the other hand is a GUI toolkit. The goal is to create GUI's. GUI's are typically what we 'click' and interact with and interact with an operating system or program. The Gnome 3.X desktop environment is centric around the GTK+ 3.X core libraries. As such, many core GTK+ libraries are required to run Gnome 3. There's further widgets that exist which are powered by GTK which would be parts that you interact with (sliders, check boxes, etc.) and surprisingly, GTK GL widgets, where you can actually make a 'canvas' that can support an OpenGL rendering.
So for example, I can make a program C, using the GTK+ toolkit. I drop down a GL widget, and in the GL widget I write the OpenGL rendering code to draw a cube. Then in the program, I make X, Y, and Z sliders (GTK widgets), and I can control how rotated the OpenGL cube along the X, Y, and Z axes, by the positions of the sliders. When it comes time to actually render the OpenGL cube, the rendering is hardware accelerated, as the OpenGL libraries are so, and the window loos like any other GTK window, but with an 'empty' space, where the OpenGL widget is, as that can be anything. You can then take that OpenGL code and copy it into a different OpenGL widget (let's say a QT GL Widget), use pretty much the same code (same code for the OpenGL rendering, though possibility different interaction code), and instead of powered by the GTK+ toolkit and OpenGL, it would be the same thing but powered by the QT toolkit and OpenGL.
So I guess you can say in short, thinking of the differences:
- high level
- user interfaces (things you click)
- low level (hardware accelerated)
- Typically exists inside other 'containers' (ie. QT, GTK, GLUT, etc.)
- Rendering language, very very very simplistic capabilities, meant to render things quickly
- Can't easily render complex shapes (programmer limitation, it simply doesn't lend itself easy to do so, the language will do it just fine, and will actually accel at it).
Now, as for C for a GUI interface, C is a generic programming language, it has no GUI interface. GUI's have bindings for many common programming languages such as C#, C/C++, Python, and Java. Pretty much the only language you're going to find that 'comes' with a GUI is Java (which comes with Swing and AWT), but there's bindings for Java to interact with many other GUI libraries. GUI languages and programming languages are two very different things most of the time. Keep this in mind.
I hope that clears it up some. Let me know if it doesn't.
- Join Date
- Jan 2013
Thanks Syndacate! Your answer was over the top for me haha, I guess I'll start reading some Linux kernel books. Can you practically do anything with the kernel?