One tool that I have written or owned that you may know about is the Intel® Manageability Checker v2.0.  Released just last month, it is a great tool to confirm your program’s application of the Intel® AMT Use Cases.  There are a few new features that make using this tool easier than the v1.0 tool.  With version 1.0 you could save your packet capture session into a .pcap file for use with other tools.  Now, Intel Manageability Checker v2.0 can import those previously saved files and analyze the loaded packets.  You can also create the packet file with another tool and then use Intel Manageability Checker to analyze it.  When a file is loaded, the tool will tell you how many packets have been imported.  If you use the custom search string, it also informs you how many of the loaded or collected packets contained the search string.  Each time you reach the last page you have an opportunity to create a report file that will save the results.  Also, this version of the tool supports the newer features in Intel AMT 6.0 and 7.0.  In addition, there are new links inside the tool to get support if needed or to submit a report file when you are ready.  Check it out here: http://software.intel.com/partner/home

Ok, this is one tool that is out there to help you enable one Intel® vPro™ feature.  Now, it’s your turn. :-)  What other tools would you like to see?  Is there some gadget or application that would really help you incorporate Intel vPro abilities?  What is your special focus right now?  It doesn’t have to be Manageability <keeping my head low and looking around cautiously>.  It might be Intel® AES New Instructions (AESNI) or maybe Intel® Anti-Theft Technology. Respond to this blog and let everyone in on the secret.  Who knows, in no time you could be an Intel vPro “Hero” for thinking of the tool that makes the “Top 10 Hot Tool” list.  Ok, I don’t know if that list actually exists, but you get the general idea. Speak up!  I’ll be back in a while to recap the ideas you submitted.  Cheers!

With One Animation Path Running With A Few Bugs

Update 12/7/09: I’ve now completed a second animation path and restructured the code so that the paths are now read from individual files. This allows me to easily change directions and angle percentages on the fly. I've posted a second picture below this paragraph. I’m currently working on a third path, and soon I will start putting in the collision code. It is very interesting work, but I’m finding it more and more difficult to set aside time to work on this project. I’m hopeful that I’ll be able to complete it near the start of 2010. I’ll blog again…

For those of you who missed the previous blogs, here are some links:

Blog 1: "Threaded Graphics to MID: A New Journey"
Blog 2: "From DirectX to OpenGL - Wheels Up"
Blog 3: "OpenGL Graphic Formats and Conversion"
Blog 4: "Scene Graphs and Instancing"
Blog 5: "Load, Follow, or Get Out of the Way"
Blog 6: "Round and Round, In and Out"

With 3 Animation Paths Going

code used to hide the cursor

As you can see, I create a pointer to a Graphics Window object and I set the “useCursor” option to false. This hides the cursor so the user can focus on where the cannon is positioned, rather than the cursor. Another bit of code I added sets the starting position of the cursor to the middle of the screen. Because I start the application with a window that is 800x600, the beginning position is (400, 300). I originally set this position to (0,0) since when you are setting angles, the center point is (0,0). However, it turns out that this is not correct for setting this function. Here’s the line that sets the cursor:

code used to center the cursor

One thing I discovered is that you have to set this cursor position AFTER the window is realized, even though you hide the cursor previous to this.
Now that I have the cannon moving with the mouse and the camera following the cannon, I want to be able to move the cannon to the right and left as well as backwards and forwards. Although the cannon will move to the “right” or “left”, the actual movement I want to generate is a circular movement around the central object which is the castle. So the center of this circle is (0, 0, 0). The cannon is originally positioned at (2000, 9000, 180). At first I was thinking that the radius of the circle would be 9000. Remember, in OSG the ‘z’ axis is up, so the ‘y’ axis is the “distance” direction (for lack of a better description). The actual radius of my circle, then, is found by use of the Pythagorean Theory. The equation is below:

The radius then turns out to be approximately 9219.544. Using the radius as the distance from the Castle leaves me with the following code:

Moving the Cannon Right and Left

The change in location around the diameter of the circle with a radius of 9219.544 is determined by dividing 2PI by one less than an arbitrary number (g_scnNumCircleDivisions). The sin of this value is then multiplied by the radius found in the global “g_fDistanceFromCastle” . The height above ground is retained from the original position of the cannon. This vector is added to the circle center vector to obtain the correct position around the circle. I use “g_v3TerrainPos” as the center mark because it is centered on (0, 0, 0). To circle right, I add the delta amount to the total angle and to circle left I subtract it from the total.
The code for moving forward and backward is pretty much the same as above except that the changing value is the distance from the Castle (g_fDistanceFromCastle). This section also clamps the distance value so that the cannon cannot get too close or too far away from the castle. The code follows:

Code used to move the Cannon Forward and Back

For those of you who missed the previous blogs, here are some links:

Blog 1: "Threaded Graphics to MID: A New Journey"
Blog 2: "From DirectX to OpenGL - Wheels Up"
Blog 3: "OpenGL Graphic Formats and Conversion"
Blog 4: "Scene Graphs and Instancing"
Blog 5: "Load, Follow, or Get Out of the Way"

If you have been following along with me as I continue to develop this application, you know that I have started using OpenSceneGraph (OSG) as a method for loading and displaying all of the many objects I need to have for the demo. I mentioned in the last blog that I was able to load all of the object files into my OpenGL application with the use of OSG. What I didn’t tell you was that the time to load all of these files was terrible. In this case, it was taking upwards to 10 minutes before the scene was drawn and the application ready. I had to find a better way to load my objects.

After doing some research on loading the .x files directly with OSG (yes, this is possible, although I found that the .x files I have are not compatible with the .x file loader that OSG currently has), I found another tool provided by OSG called osgconv. This tool converts other formatted graphics files into “.ive” files, which is an OSG proprietary native binary format. Another neat thing about the tool osgconv is that you can convert many .obj files into one .ive file. Oh, it’s so easy to say that, but it did take me a while to figure out how to do it. I have over 400 separate blocks that make up the castle, and osgconv is a command line tool. I tried opening a text file and setting up the command in the file first, then copying and pasting to the command line. It didn’t work the first time. It didn’t work the second time I tried, either, after making some adjustments. There were just too many files. Finally, I decided to convert 10 blocks at a time. That resulted in almost 50 files. Then I combined those files into one big .ive file. That did the job. Now, with all my objects converted into .ive files, guess how long it takes my application to start? Less than 2 seconds! Awesome!

Ok, so the objects are loading fast and I now have the home view I want (see previous blog). Next step was to anchor the scene so that first the cannon was centered in the scene and then fix it so the cannon rotates and move up and down based on the movements of the mouse.

I solved this step in two sections. First, by setting up my camera so that it follows the cannon as it moves. OSG has quite a few camera manipulators in its API, and hundreds of functions. While my main irritation with OSG remains the lack of references WITH EXAMPLES, they do have some tutorials that are useful to help you learn how to use all the tools available within OSG. One of those tutorials shows how to set up a manipulator to follow a particular node or object. I used this implementation to set the camera to follow the cannon. Now all I had to do was get the cannon moving.

My first rudimentary implementation was simply to find the X and Y locations of the mouse and split the screen in half in both directions. It the mouse’s X location was greater than the half the screen length plus 10 percent, then I rotated the cannon a very small amount ( one tenth of a degree) in that direction. So then the cannon would move to the right if the mouse was clicked on the right-hand side of the screen and move to the left if the mouse was clicked on the left-hand side of the screen. If you clicked in the middle of the screen, the motion stopped. It worked, but it didn’t fulfill all of my requirements. Also, it would continue to move in the direction of the last click until the middle was clicked.

One of the really nice things about OSG is that it is open source. I was able to dip down into the manipulator code and see how mouse movement was handled there. This helped me to develop my second implementation. In this version, I calculate the angle that the cannon needs to be moved based on the X and Y coordinates of the mouse location (when it is moved or pushed, not just clicked ). To do this requires that you translate the X and Y mouse location into x, y and z coordinates and then get the angle that the cannon needs to be moved to face that location. It took me a while to figure out how it was done and even more time to take what I learned and adapt it to my code so the cannon follows the mouse. The code I am now using is in three parts (from three different files) and is shown below:

From the Matrix Manipulator Handle

<

From the Handler function of PickHandler.cpp

And Finally, the Code from the Cannon Callback Function

Last little section also from Cannon Callback Function

OpenGL Castle Destruction as it stands now

Until next time....

For those of you who missed the previous blogs, here are some links:

Blog 1: "Threaded Graphics to MID: A New Journey"
Blog 2: "From DirectX to OpenGL - Wheels Up"
Blog 3: "OpenGL Graphic Formats and Conversion"
Blog 4: "Scene Graphs and Instancing"

When I explained my issues with one of the graphics gurus I’m very fortunate to work around, he said that there were two main ways to handle the objects: Scene Graphs and Instancing. We took a look at the DirectX code and discovered that the writers of this code used Instancing for the bugs and the castle blocks. In case you haven’t seen the Destroy the Castle demo, here is a screen shot:

According to Wikipedia, A scene graph is a general data structure commonly used by vector-based graphics editing applications and modern computer games. They have links to several commonly used programs. I went to the Open Scene Graph (OSG) website. After reading about what they could do and seeing tutorials available to help, I decided to install it on my system and try it out. It was fairly easy to install in onto my system with the help of an article or two. I ended up changing some of the environment variables from ones using a reference to another environment variable to a direct reference to the file. But it compiled on the first try, and I think that is a major accomplishment all by itself! After using it for over a week, I’m impressed but also a little frustrated. Well, that’s par for the course, isn’t it? The great thing is that OSG was able to load and texture my .obj files with no trouble. All of my .obj files! So I think I can say that my Perl script works. In OSG, I have recognizable landscape and objects. See the picture below:

The lighting isn’t right yet, and I still don’t pivot the view with the cannon, but the castle is there and several bugs are stationed on the left side. Notice the “break” in the castle that you don’t see in the original? It actually exists there as well, but we don’t see it because the original angle of the cannon is set so it doesn’t show. Take a look at these side by side shots after I move the camera.

OpenGL program once the view is moved.

Original program showning break in castle.

Another thing I’ve discovered is that OSG can be easily attached to your OpenGL/GLUT code. They have some example code to show you how to do it, and that makes incorporating OSG into your program fairly easy. The thing I do find frustrating is that the reference documentation list those functions that are available, but in many cases don’t even tell you what they should be used for. For instance, I was having a hard time changing the initial view in the window. The default view shows objects with the standard backdrop blue behind them. My sky object (a hemisphere with the sky material used on the inside ) displays as a black object against the blue background. See the picture below:

Original Camera Position for OpenGL program.

What happens is that you have to use the mouse to scroll INTO the hemisphere and there you can see the scene as rendered above. I will not tell you how long it took me to set the code so it would start inside the globe, but take it from me, it was a long time.
Here are a couple of lines of the original code:

Global:
osgGA::TrackballManipulator *Vman = new osgGA::TrackballManipulator();

Inside Main:
viewer = new osgViewer::Viewer;
window = viewer->setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer->setSceneData(root);
viewer->setCameraManipulator(Vman);

And here are the ammended lines :

Global:
osgGA::TrackballManipulator *Vman = new osgGA::TrackballManipulator();
Inside Main:
osgGA::TrackballManipulator *Vman = new osgGA::TrackballManipulator();

viewer = new osgViewer::Viewer;
window = viewer->setUpViewerAsEmbeddedInWindow(100,100,800,600);

Vman->setHomePosition(osg::Vec3d( -500, 12150, 380),osg::Vec3d(-500,0,0), osg::Vec3d( 0, 0, 1 ), false );

viewer->setSceneData(root);
viewer->setCameraManipulator(Vman);

The one new line tells the Camera Manipulator where to start. Notice, too that the “z” direction is “up” rather than the standard “y”. From what I understand, this is specific to OSG. It does kind of throw you for a loop at first, though.

All in all, I am finally beginning to see how to go about completing this project. My next job is to get the lighting right, and get the view pivoting about the camera. Keep your chin up, and I’ll let you know soon how it goes. Cheers!

At this point I have a menu bar that works fairly well and I’m able to load the background sky and parts of the terrain. The way I’ve been doing this is to take the DirectX object files (.x files) and use my own Perl script to convert them into .obj files. I am able to get this to work, but some of the files I have converted have issues when they are drawn in the window. If I load the .obj file into a mesh processing program (such as Blender or MeshLab ) it displays just fine. Take a look at this bug object in MeshLab:

Bug Object in MeshLab

Now, after loading it into the OpenGL window, take a look at the object. Yes, the texture shown is not actually for this bug object. Try to look beyond the texture. See the incorrect rendering?

Object Rendered in OpenGL Window

Yes, the legs on one side of the bug do not connect the way they should. This is the same .obj file, but for some odd reason, it has trouble rendering correctly in the OpenGL window. I have the correct object for the material, by the way. It loads just fine in MeshLab and, with the debugger attached, it displays fine in the window as well. Pretty gruesome bug, isn't it?:

A Different Bug Object in MeshLab

Bug Rendered in OpenGL Window

But if you run the application without debugging (staying with the debug configuration), the application won’t display at all. So, is it my conversion script? Or something I am doing when I draw the objects? I’m not sure yet. If you have an idea, let me know.

I don’t know if this is standard practice with .x files or not, but the .x files I have include a few or many different objects in each one. For instance, I have a castle.x file which has 493 different objects included in that one file. I modified my conversion script to put each object into its own file, just so I could see each item individually. Found some interesting surprises during this process. Check out object number 263 below:

Surprise Object in .X File

Just recently I talked with another engineer here who had done a lot of work with OpenGL just last winter. He suggested that rather than going to .obj files, I should create Collada files. Blender will import a .x file and you can export that object into a .dae file, which is the extension for Collada files. If you download Collada, there are several examples included along with both a dll producing project and a static library producing project. One of the samples is a "rubber ducky" complete with texture file. I can load this file into MeshLab and it adds the texture to the object. So now I'm trying to figure out how to insert a material into a Collada file so that it will load the texture as well. There are two different Collada based c++ APIs for loading and saving Collada files; Collada DOM and FCollada. I chose the Collada DOM API. If you want to use the Collada DOM, you have to pay special attention to the instructions on the site about compiling and setting up your links in the project properties and don't do what I unintentionally did at first and try to connect both the static library and the dll library. After a great deal of work, I was able to get one of the samples to load successfully. I haven’t managed to actually display it in the window yet, but I’m working on it now.

The same engineer who suggested Collada files also thought that eventually I would need to use VBOs (Vertex Buffer Objects) to hold all of the objects I will be drawing in the window. I can see already that my code is going to need to load lots of different objects to make up the castle, all of its blocks, the bugs, the cannon and finally the cannonballs. I’m not sure how that’s all going to come together, but I’m certain that I’ll figure out a way. Well, that’s all for right now. I’ll write again in a couple of weeks and let you know what progress I’ve made.

Take the first DirectX element I came to in the code: D3DXVECTOR2. This should be a fairly easy transistion, right? Just replace it with the OpenGL variable and move on. Hmmm….I wish it was that easy. You see, OpenGL doesn’t really have special variables for vectors. OpenGL has commands, glVertex2f, glVertex2i, etc, that are used inside another set of commands, glBegin() and glEnd() to form a primative. But they won’t work as stand alone variables. So, to replace D3DXVECTOR2 you use a GLfloat array, such as this:

GLfoat fVariableName[2];

You could create your own struct which has two floats( or 3 or 4) and use the structs instead. That is perfectly acceptable. It really doesn’t alter the fact that the coder has to break down the DirectX variables into their basic types. In some cases that is fairly easy, as in the example shown above. But in other cases the methods used vary so greatly that there isn’t a reliable substitute. There is a whole interface in DirectX that is used to manipulate various resources: IDirect3DResource9. The code I am porting from creates a pointer to this interface type, like this:

IDirect3DTexture9* pTexture;

There are no texture variables in OpenGL. If you look at the references for this interface in DirectX, there are a lot of associated methods that help the developer achieve the look they want. OpenGL also has methods to help the developer, but they aren’t all packaged up together as they are in DirectX.

Try this variable: CDXUTDialog from the DX Utility Toolkit. There are no dialogs in OpenGL, and there aren’t any in GL Utility Toolkit either. Yes, there are sub-windows, but even using sub-windows you don’t have any of the typical control elements you might expect to find, such as buttons, text boxes and entry boxes. To display a menu box, I found a user interface library called GLUI which does have many of the control devices you might need. There are other libraries available. I looked at several of them, and chose GLUI based on three factors: First, it had most of the controls that I wanted to use ; Second, it was most recently updated, indicating that there was still some interest in improving the code and keeping it updated; Third, it has a clearly indicated license. I can’t speak for others, but I have spent way too much time searching for a license for some bit of code I used when working on the release of a project. Now before I use code from another source I make sure I have the license information. But, I digress. GLUI does a fairly good job. It works well with GLUT and that makes my life easier. The menu is not as “pretty” as the original menu, but it has the essential control elements and it interacts well with the main window. You can see a picture of my GLUI menu beside the original DirectX menu below. Several of the original controls have been removed because they were deemed un-needed for the new application.

Menu using GLUI

Menu on DirectX application

The next step in the porting process deals with models and meshes. DirectX uses a file format with the extension “.x”. I would like to use these same models if I can, but wasn’t sure about how to go about loading a .x file into my OpenGL program. What I ended up doing was writing a script in Perl that would convert a .x file into a .obj file. There are several different implementations available to open an .obj file in a OpenGL program. I took what I considered to be the best of them and incorporated it into my code (carefully checking the license information first!). Although the imported code read in the vertex information, it didn’t handle any of the material information in the .obj file, so I modified it to be able to load the material information as well. Finally, I wrote an additional function to draw the object on the OpenGL screen. In the process I have found and fixed two bugs in the original code and sorted the faces from the .obj file by the material type they use. That last is to reduce the number of times that glBegin() and glEnd() need to be called. So far, the code is working for objects having only one material. Which seems to indicate that my sorting material code isn’t helping. Well, more on that in my next blog. I’ve been sitting on this one for a while, so I want to go ahead and post this. I should be back soon with some more insights. Until then…

The first phase is to translate the graphics code in the demo to use OpenGL. I’ve never used OpenGL before, so that is going to be a steep learning curve for me. I’ve also done very little with DirectX code, but since that is already in place, my task will be to find the corresponding functions in OpenGL. The good news here is that I have plenty of experts in groups near me to help me out if I get stuck. I’ve already started looking at the DirectX code in the application and it uses the utility toolkit DXUT. While that might initially be considered a difficulty, OpenGL now has GLUT, its own utility toolkit. So, finding replacement functions may not be as difficult as it might have been.

The second phase will be to put this new version onto a netbook running a Windows OS and using the Intel® Atom processor. This will be challenging in a second way as we are porting a large demo over to a device that works with less power and available space. The application is also threaded, and since the Intel Atom is a one-core processor, CPU usage could impact playability quite a bit. And then there is the question of whether the Atom chipset has sufficient OpenGL support.

If I am at least partially successful on phase 2, then phase 3 will be to get the demo working on a netbook using Moblin 2.0. This OS is just coming out and it looks to be a big improvement over 1.0. But, will the demo work on it? By the time I start working on this phase I will know whether the demo will work on Atom, so the challenge here is to determine how well Moblin 2.0 works with OpenGL graphics.

The last phase of this project is to see if I can get the demo to work on a MID with Moblin 2.0. Again, this is another type of challenge, since we will know at that point that the demo will work on Moblin 2.0 and the Intel Atom. The challenge this phase is to see what design changes need to be made in order to play the demo on a small-screen device which may or may not have access to control buttons.

I’m looking forward to each and every one of these challenges, and I plan to continue discussing the difficulties and solutions I find along the way with all of you. So keep checking back here now and then to see how I’m doing and offer your comments and suggestions. The journey begins now…

 Actually, it isn’t that easy for someone unfamiliar with the different flavors of Linux.  These two operating systems use different package installation tools.  You have to learn how to use both, and then you have to find the right packages to install.  Dependencies were haunting me for quite a while, and I’m not talking about foreign oil.  My tool needs two packages to be installed before use.  Only, on a clean system, one of those two packages needs 2 other packages and the second package needs 3.  And so it goes.  Eventually, you end up with a long list of libraries that you need to install in each new system, or you learn what I learned this week.  You bundle the needed libraries into the distribution package.   Now, there are at least two ways to accomplish this.  First, you can add the libraries as static libraries in your source code.

 I started with this method, but with the Anjuta IDE, even though I marked the libraries as being static, didn’t include them in the executable.  This might have been my fault, although I had a team member look as well, and we couldn’t find anything to change.  I also <gasp> checked the user manual for Anjuta and tried to follow it, but again I ended up frustrated.  So, I went to the Linux guru in our department and he gave me some pearls of wisdom which I will pass along to those of you who, like me, are fairly new to Linux.

 A second possible way to add the libraries is to include them in your distribution tarball in a separate folder.  Here is the way I was shown:

1. Create two folders, named “bin” and “lib”.  Actually, you can name them anything you want, but the example below uses those two names.  Put the binary in the “bin” folder and the libraries that need to be included in the “lib” folder.  To easily get the libraries into the bin folder, first run the “ldd” command on the binary:           

You should see something like this list although it will probably be longer:       

linux-gate.so.1 =>  (0xb7f8d000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xb7f5d000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb7f27000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f21000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f18000) libglademm-2.4.so.1 => /usr/lib/libglademm-2.4.so.1 (0xb7f0e000)

This is the list of libraries that your program depends on. You can use any method you prefer to put all those libraries into the “lib” folder.  Our guru suggested this shell command:

$ for i in `ldd <binary name> | cut -f2 -d"=" | cut -f2 -d" " | grep .so`; do cp i ../lib/; done

The above command assumes that you are in the “bin” folder where you have put your binary.  

  2.     Now, we want to force the OS to look in our “lib” folder first, rather than the default location, so we change the LD_LIBRARY_PATH environmental variable to our new folder:

$ LD_LIBRARY_PATH=../lib ldd ./<binary name>

This will result in the following list:

linux-gate.so.1 =>  (0xb7f8d000) libdbus-glib-1.so.2 => ../lib/libdbus-glib-1.so.2 (0xb7f5d000) libdbus-1.so.3 => ../lib/libdbus-1.so.3 (0xb7f27000) libgthread-2.0.so.0 => ../lib/libgthread-2.0.so.0 (0xb7f21000) librt.so.1 => ../lib/librt.so.1 (0xb7f18000) libglademm-2.4.so.1 => ../lib/libglademm-2.4.so.1 (0xb7f0e000)

As you can see, the system is now finding these libraries in our “lib” folder.  The one problem with this method is that we have to set that environmental variable every time the program is run.  The common solution for this is to create a script that is used as a “wrapper” for your application.  Here’s how to do it:

3.    To create the script:   

•  Rename your binary to something else, such as <binary name>.bin              

$ mv <binary name>  <binary name>.bin

•  Create a shell script with the original name of the binary:             

#!/bin/bash #Get full path to this script filename="${BASH_SOURCE[0]}"                                                            dir=`dirname $filename` cwd=`cd $dir; pwd`  #Execute binary, after setting variable and pass all args to binary LD_LIBRARY_PATH=$cwd/../lib "$cwd/<binary name>.bin" $*

• Change the permissions on the script to make it executable:

$  chmod +x <binary name>

Armed with this new technique and with a renewed sense of hope, I loaded my tool onto a new build of MIDinux.  The first time I ran it, this is what I got:

****MEMORY-ERROR****: <binary name>.bin[19643]: Gslice: assertion failed: sys_page_size >= 2 * LARGEALIGNMENT

Slightly disappointing, wasn’t it?  The key to this problem was in the “lib” folder.  When using the “ldd” command, I got ALL the libraries that the application depended on.  MIDinux seems to prefer to use the default library location for the libraries it already has rather than using them in another location.  Or, maybe it just doesn’t like two copies of the same library.  Whatever the reason, I found that by removing all of the libraries that were already loaded on the OS from the “lib” directory I was able to run my tool successfully.  Whew! 

Well, I hope this blog will help any of you that have been struggling with just such a situation.  If you have any tips or suggestions you would like to share, I’d be happy to hear them, and I’m sure other people would, as well.  Until next time…

 Note:  Our Linux guru graciously gave me his permission to share his suggestions with all of you.

Here’s the setup: A member of my team developed a tool some time ago for Win32.  He has been updating it and revising it for over a year now and it has gained in popularity.  Recently, his tool was developed for Linux by another member of our team. The Linux version is strictly command line driven.  To tie both of these two programs together, I was asked to come up with a GUI wizard that would look the same in both Win32 and Linux and make using the tool a little less confusing and more intuitive for the user.

My first step was to find the right development tools.  Python had been suggested as being a good choice for cross-platform development, so I took a look at that.  I also talked to a senior software engineer and got a recommendation for wxWidgets.  I had not heard of wxWidgets before, but with his suggestion in hand I went online and had a look at it.  Do you know about wxWidgets?  It’s a pretty cool toolkit.  You can use it with C++, Perl, Python, and even C#.  There are distributions of it for Win32, Mac OS X, any version of Linux that uses GTK+, and several more.  I’m not really sure how I got to wxFormBuilder, but it seemed like the perfect interface to get started with, being a wxWidgets GUI builder, designer and RAD tool that was easily connected to Anjuta (my development IDE in Linux).  I was soon up and running with it.  Unfortunately, wxFormBuilder did not have wxWizard as part of its available widgets.  I didn’t know if a wizard widget existed so I started out designing with a notebook widget.  It’s not the same, but it did give me pages that were connected together.  I was just about finished with my design when I located this wonderful book entitled “Cross-Platform GUI Programming with wxWidgets.”  It really helps you to understand wxWidgets and gives lots of examples.  Under documentation on the wxWidgets website you can find the latest online manual which is terrific, but sadly sparse on example code.  This book helps bridge that gap.  Guess what I found detailed in the book?  That’s right, a wxWizard class!

So now I have moved to using straight wxWidgets in Anjuta.  Saying that makes me feel like I’m hitting the hard stuff, and honestly it does feel like a little richer and more intense experience.  I miss having the visual format to develop the pages but I was able to cut and paste most of the design from my wxFormBuilder notebook design into the wizard pages, which saved a lot of time.  Extensive use of the documentation on the wxWidgets site was extremely helpful when I wanted to do something beyond the norm to individual controls.  The wizard is just about finished now and ready to be connected.  I’ll start by connecting it to the Linux command-line version, and after that is successful I will port it over to Win32.  I know that it will work, however.  I already have wxWidgets set up in my development studio on Win32.  That’s a very reassuring bit of knowledge.  My original tool, wxFormbuilder, is portable to Win32 as well and although I got the correct download I have not been successful in integrating it into my development studio there.  Now I don’t have to do so.

I’ll let you know in my next blog how the integration process is going for the wizard and also tell you about anything new and different I learn about the Linux environment, C++, wxWidgets, Glade, Anjuta or any other programming subject.  Take care until then!

I wasn't able to find very much to help me on the warning so for a while I just lived with it. I kept trying different things to help relieve it. I tried putting in a pthread mutex and locking and unlocking between the call I made in the signal handler. That didn't fix it. Then I found out about gdk_threads_enter() and gdk_threads_leave() and tried those in the signal handler in the main thread. I couldn't get the g_thread_init(NULL) call to work inside the main thread. Then, finally I tried putting the init functions in a thread other than the main GUI thread and I was able to do that. After reading some more at the GDK Reference Manual I realized that the function I added was a GTK+ function which cannot be called from another thread without the gdk_threads_enter() and gdk_threads_leave() functions being used. What I ended up doing is putting the "enter" and "leave" functions in the second thread around the function call that updated data in the main thread. It worked! By doing this, I found I didn't even need the GTK+ function forcing a refresh in the signal handler. The data was updated right away. Whew!

But, while that was nice to have cleared up, I had uncovered another problem. A segmentation fault was driving me nuts. One of the main features of my application was the use of the DBus system to receive information about the MID system. DBus is a system designed and used for interprocess communication in most Linux systems. There are defined calls to be made and quite a few tutorials on the web. The major tutorial seems to be D-Bus Tutorial. All of my DBus calls were made on one particular thread, which makes sense. Except that sometimes when I was running the program it would have a segmentation fault and the program would crash. At first, it was happening about 1 out of every 3 or 4 times. I had a friend who is a long-time coder take a look at the code. He pointed out some areas I needed to tighten up and I gladly took his recommendations and made the changes. The segmentation fault was still there. I had some of the other software engineers take a look at the code. They also had some recommendations, most of which I agreed with and implemented. The segmentation fault still came and went at will (it seemed to almost take on a life of its own). We had a group look and talk session to see if together we could find it. Apparently, we couldn't. The group did recommend that I load up a tool called Klocwork which is a bug analysis tool. Klocwork found 5 minor problems which I fixed, but the fixes did not result in the segmentation fault disappearing. Finally, I took the code home with me and remove the DBus code from the threaded environment. I made a simple GUI and ran the DBus code in single thread mode. No segmentation fault over 80 iterations. Then I created a second thread and put the DBus code in the second thread. Guess what? The segmentation fault was back. Have you already figured out what the solution was? Yes, the gdk_threads_enter() and gdk_threads_leave() functions! By surrounding the DBus calls with those two functions, my program runs without any crashes at all. Looking back, most of the "code monkeys" I asked to look at my code had never written code in the Linux environment, so it is not too surprising that they weren't familiar with GTK+ critical section needs.

My program is now going through code inspection, and I don't expect it to be a difficult experience at all, since so many people have already given me their suggestions and tips. My last big hurdle is to actually get my program running on an actual MID. We have received some MIDs to use as test vehicles so I have the hardware I need. Will there be another adventure while actually getting the program into the MID? Stay tuned, friends and neighbors, and I'll let you know soonest.

Setting screen resolution to 1024x600

DISPLAY already set to  :0.0

Starting dbus

 * Starting system message bus dbus                                      [ OK ]

 * Starting network connection manager NetworkManager                    [ OK ]

 * Starting network events dispatcher NetworkManagerDispatcher           [ OK ]

 * Starting System Tools Backends system-tools-backends                  [ OK ]

Starting UI in Xephyr

 

Extended Input Devices not yet supported. Impelement it at line 625 in ../../../../hw/kdrive/src/kinput.c

Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!

Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!

 

waiting for X server to shut down FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be 1; fixing.

In order to solve this, I ended up joining the Moblin mailing list and posting the problem there.  The response took a while, but it turned out that this was a known issue and the fix is relatively simple.  All you have to do is type “killall gconfd-2” at the target prompt (without the quotes).  This will allow the screen to be displayed.  Cool!

Working through the development guides has been illuminating.  I found several typos and a few places where the documents needed to be updated.  Thanks to the mailing list, I was put in contact with the website owners and those items are being updated as I write this.  Hopefully, those who come behind me will have an easier time of going through the guides. 

I haven’t gotten an image successfully from the Image Creator to the MID I have in the lab.  I tried a live image that had some of my stuff on it, and when that didn’t work, I tried a standard image I found on the website.  The standard seemed to load, but then it just shut the MID off, so I’m not sure what’s going on there.  Work continues.  Until next blog, please let me know if you have any suggestions.  Cheers!

The most interesting thing about this whole process has been the search for relevant information that combines one or more of the elements of my development environment.  You can find lots of information about GTK + in the GNOME Documentation Library, but not so much about using the Glade Interface Designer with it.  Of course, the Glade site has some documentation that helps with the program itself, but little on using it with Gtk. The Gdkmm documentation is excellent and has helped me the most.  It even includes a section on Glade and libglademm which gives a lot of information.  Down at the bottom of the page is a link to a great collection of example code.

Then there is C++ in Linux.  It is basically the same as in Windows, but some things are different.  I miss my CStrings.  Yeah, I know it’s a crutch, but there you go.  When I tried to use itoa, I couldn’t make it work.  I’ve learned since then that the way to call itoa on Glib is g_ascii_strtoull (Thank you, Daniel Harbin).   But I have found some interesting ways to use strings in Linux.  This site, C++ String class Examples and Tutorial is great!  It contains all the things I’d forgotten that could be done with regular strings.

My application is a four thread program.  It has a main GUI thread that then spawns off three additional threads.  One of these threads has a link back to the GUI class.  When it is ready, it sends data to the GUI and changes the text in some widgets.  The problem that I mentioned earlier was that although I was getting the information posted correctly, the GUI itself was not refreshing until the mouse was moved.  Since my program sends new information every second, several changes could have occurred before a mouse move triggered the update.  This just wasn’t going to work.  I tried the show(), flush(), locking the gdk_thread, even GdkWindow::invalidate_rect.  Nothing seemed to work.

Then someone else pointed out that I was trying to update the GUI from another thread.  Part of the solution was to set the signal in Glade to go to a signal handler when the widget was changed.  Then in the signal handler, I put in the following code:

          p_eEntry->show();

while(Gtk::Main::instance()->events_pending())

          Gtk::Main::instance()->interation();

What this code does is to tell the GUI to stop and handle all updates right away.  The solution works.  I do get a warning in the terminal that says “Glib-WARNING **: g_main_context_prepare(): main loop already active in another thread.”  I’m still researching why this happens and how to fix the warning.  Some online comments suggest that it is a bug while others say to use the “child watch” functionality of GLib. If you know of something that will help, I hope you will post a reply.  Regardless, I will post more comments as I go along with the hope that others will benefit and /or contribute.