Qt success!

Finished my mp_edit program.  Halariously, the final problem was rendering text.  I was using the Qt renderText method in the QGLWidget object.  I noticed that my text was just not working, but then, it sort of worked when I only specified an x and y coordinate and no z coordinate.  Which -- made some tiny amount of sense, maybe, if I had the clipping planes wrong or something like that.

But no -- read the following description:

void QGLWidget::renderText ( int x, int y, const QString & str, const QFont & font = QFont(), int listBase = 2000 )
Renders the string str into the GL context of this widget.
x and y are specified in window coordinates, with the origin in the upper left-hand corner of the window. If font is not specified, the currently set application font will be used to render the string. To change the color of the rendered text you can use the glColor() call (or the qglColor() convenience function), just before the renderText() call.

void QGLWidget::renderText ( double x, double y, double z, const QString & str, const QFont & font = QFont(), int listBase = 2000 )
This is an overloaded member function, provided for convenience.
x, y and z are specified in scene or object coordinates relative to the currently set projection and model matrices. This can be useful if you want to annotate models with text labels and have the labels move with the model as it is rotated etc.
Note that this function only works properly if GL_DEPTH_TEST is enabled, and you have a properly initialized depth buffer.

OK, now, silly my, I read that the second function was an overloaded version of the first one, and thought that they did sort of the same thing -- but note that they really don't at all.  The first one takes two integer arguments, and works in screen space, and the second one takes three floating point arguments, and works in 3d space, and requires that the GL_DEPTH_TEST flag to be enabled.  They're two methods that share a name, but they are so wildly different in usage that, to my C-influenced mind, should be different commands.  I am certain that this is standard C-double-cross idiom, but it's going to take me a while to get used to it.

OK, the window resizing doesn't work yet, but everything else is fine.

I resurrected my old gdiff program for my new Mac -- I'm sure there's something better out there but I couldn't find it quickly.  It was nice to see that it compiled and ran almost immediately -- it was the first OpenGL program I wrote not on an SGI back probably 8 or 9 years ago.  If you want a copy of it, drop me a line to thadbeier@gmail.com

Qt Progress

Well, of course the problem I was having with the events not working is that my meta-objects were out of date.  I don't mean this blog to become an anti-C++ rant, but it could happen.  Easily.

See, C++ (most people pronounce it incorrectly, it's "C Double-Cross") is an abortion of a language.  Mr Stroustrup crammed as much OO-ness into C as he could, and stopped only when it became unstable -- it's sort of the Peter Principle applied to computer languages.  In any case, there are significant things you'd like to be able to do in an object-oriented language that are unavailable in C++, and one of them is determining the type of an object.  So, people extend C++ in wacky ways, and the Qt people have decided to build a meta-object system that processes header files into short C++ programs that encode the type information.

Of course, what happened to me is that one of these "moc" files was out of date.  There were no obvious warnings except that the program was just unresponsive -- none of the events caused any response whatsoever.

Anyway, now things work better -- the only thing remaining for me to declare mp_edit finished is the text -- I get an error that says "QOpenGLPaintEngine: Failed to create fragment programs." whenever it tries to draw text.  I'm not sure what this means.  Still, the program is somewhat useful at this time.

Qt experiences -- 11/29

Today I tried to get the mp_edit program working, and it now comes up, and displays a curve, which is great.  The interface panel works as expected.

Unfortunately, events in the OpenGL window don't work at all.  I get no mousePressEvent, mouseReleaseEvent, mouseMoveEvent, or keyPressEvent events.

As usual, it's very difficult to tell what is going on.  It just sits there laughing at me and not doing anything.

I tried setting the setFocusPolicy, but it didn't help.

I'll next go back and try to use the hellogl window instead of my editing window, see if that gets events, and then see what that does different from what I am doing.  

mood: frustrated

Qt on my mac

Well, as I've said (but nobody has gotten the joke) I've gone over to the white side, and got a MacBook Pro. I'm going to be trying to port all of my code over to the mac, using the Qt library as the UI toolkit instead of my own Hui (Hammerhead UI) toolkit that I've been using for some 12 years now.

This means converting also to C++, and I suppose I have to just bite the bullet on this too.

I've ported a program over to Qt on Linux, and was trying to get it to work on my MacBook and had horrible problems.

I downloaded the Qt 4.3.2 source, configured and compiled it, and it just didn't work very well. Most of the OpenGL applications come up with a white featureless screen, as did the qtdemo application launcher. Basically, it looked hopeless -- and a plain white screen is pretty hard to debug.

However, downloading the binary .dmg version of Qt 4.3.2 things work better! Yeah!

My first program that I'll be porting is the mp_edit program, then I'll do my image viewer, and then my roto and tracking programs.

I've written a hui->qt convertor, and I'll be using that at least for the first pass of the ports.

I'm going to have to see how to draw text in the QGLWidget windows, but I don't expect that to be too challenging.