Site Sponsors:
Angry Buddha Springs? 

Loco Motion

Well - true to form - yet another game is sweeping the blogs today. We see it on FaceBook. We see it on Android. We see it on T-shirts in Wal*Mart.

-What was even all the buzz at summer camp this year? Angry Birds, of course!

One of the fun things about AB is the way that objects can bounce, rock, and wobble after they are hit .... even well after they are hit!

How did they make all of that happen in C++? With physics, of course!


Since we have been ''into'' creating rich media applications of late, we decided to look into the actual software behind those 'wobbles in AB. Known as Box2D, in addition to C++, we were surprised to find portings of the Framework to Adobe Flash & Java.


After working the C++ download for awhile, we decided to give the Java version of Box2D a spin (I have someone else working on Flash.) We have pretty much abandoned Eclipse for reasons of code-loss (i.e. far too many files lost due to 'Workspace Issues.') -Fortunately, we have never lost so much as a semicolon with NetBeans.

1 + 1 = 11

Combining the two together, here is all we have to do:

1.) Get a copy of the SVN.

2.) Create a Maven Project on NetBeans.

3.) Point to the "Existing Code Base."

4.) Press "Finish"

While SVN will take a few moments to do it's thing(s), all works extremely well under Ubuntu. -Thereafter, moving it over to the Windows 2000 VM was a slice 'o cake, too.

RIA - Not?

While the documentation warns that the reference implementation for the Java rendering uses Java2D, it seems fine for appreciating the design and developer's use of the Box2D Framework. Gabe also had a great little snippet to share, too.



p.s. What is with the "Buddha Springs" you might ask? Well, it is part of the excellent theory of operations PDF, as offered by Master Erin Catto.

[ view entry ] ( 9941 views )   |  permalink  |  related link
The Neat Odd-Job Namesapce for C++ 
Just a quick note to let everyone know that we had a moment to update the STDNOJ Namespace on

Because we are working on for-profit commercial software applications once again, we have been switching from Java, back to using C++. Also, since we have recently switched from Windows to Linux, you can expect that the non-core classes (like StdSocket, etc.) will shortly be just as good as they are under Windows.

We continue to target Windows, OS X, Android and Linux.

Work has also resumed on the C++ Training.



[ view entry ] ( 2110 views )   |  permalink
System of Systems 


Writing quality software is an expensive, time consuming process. Once tested, packaged, and accepted, software created by the best developers is not only usable, but maintainable as well.

Interestingly, when creating reusable components today, few think that it is possible to include a user interface. Before the rise of Object Orientation this belief was perhaps understandable – user interface frameworks not only had to be self-authored, but the graphical underpinnings themselves were often extremely device-specific. Lacking patterns, poorly encapsulated, and complicated to maintain, re-using one team's display 'technology' often resulted in another team's loss of sleep. Rather than expose oneself to the follies of poorly designed frameworks, it was often easier to just write everything yourself.

Today however things have changed. From a graphical interface point-of-view, component writers should increasingly consider providing graphical views into their software and / or systems. No matter if we are using C++, C#, VB.NET, Delphi or Java –When it comes to designing our tools, why not include a few graphical component add-ons, as well?


Impossible, you might say? Not at all! Indeed, much like when designing any complex piece of hardware, we software developers need to appreciate that the components we create will invariably become part of a “system of systems:”

under the hood

For example, when we pull the covers off of any modern vehicle, we are not looking at any single system. Instead, what we see is a plethora of components being managed by a central processor.

While it can be amazingly enjoyable to assemble, program, & test discreet sensory systems, the pressure is on for everyone to provide turn-key business-solutions. Why? Because the man-hour savings to be had when re-using things like a compete radar system, weapons system, or even flight control - can provide some serious saving to our clients. Saving that can be quickly translated into markup for we original-equipment manufacturers.

Profits for all ... that cannot be ignored!

In order to make / save some amazing coin therefore, in software as in hardware, system architects & developers alike must expect that the interface to any of our components might indeed be custom, or self-provided.

While describing the process of operational abstraction is well beyond the scope of this article, I felt the need to clearly demonstrate one of the many ways we can include a graphical interface as an integral part of our re-usable components.

Instrumentation Panels?

Of course whenever we want to create add-ons, the first thing we need to have is a properly designed framework. Fortunately, from C# to Java everyone has been using their own version of Delphi's panel:

* Manage your configuration panel.
* @param file The configuration file to load / save your information to / from.
* @return Your component, as used to mange your display.
public JPanel getConfigureView(File file);

When seen as a “black box”, the above fragment of an interface-signature has all the artifacts necessary to maintain a useful configuration: A file for input, a panel for output, as well as the associated framework for passing signals (button clicks, focus notifications, etc.) back to our component.

By merely providing a file at the receiving-end of our API, whenever our panel is either provisioned or operated, our component can both read from, as well as maintain, a user-provided configuration file.

Bolting the Panel

From the user's point of view, even software component configuration can be part of many other systems.

When part of a series of operations (the above is from a tool manager I am writing at the moment from Java to C/C++ to a device: We changed the add-on names to make them more applicable to our analogy) the user is also free to use our JPanel to create their own mash-up. -From .NET to Java, I have done the same device-to-GUI tricks for legacy C, C++, and even Assembly Languages.

So here is the magic: Today, all GUI frameworks worthy of the name have components. In this case, components that can contain other components.

In Java, while we have a plethora of panel-hosting options, I decided to use a JScrollPane:

private void phatConfigure(iPhatTool tool, File file) {
this.tool = tool;
JPanel pan = tool.getConfigureView(file);
JViewport port = new JViewport();
this.jScrollPane1.add(JScrollPane.VIEWPORT, port);

Since our panel can be used by the JScrollPane, whenever the user selects my component, after reading a little about what to expect (the top panel is the factory) he or she can thereafter press the “Config” Button & get on with actually configuring my component. -All while enjoying both the add-on interface, as well as the add-on code, we provided.

For what it is worth, here is the complete configure-n-execute tool interface for my aforementioned add-on tool framework:

package com.soft9000.PhatFiles;

import com.soft9000.file.OpStop;
import com.soft9000.logger.StatusLog;
import javax.swing.JPanel;

* The protocol used to mange a (hopefully) ever-growing host of 'phat tools :)
* @author profnagy
public interface iPhatTool {

* Useful when a tool is to be used as part of a work-flow, or process, of
* previously-completed operations.
* The file passed to a previous startRun() is to be used as input
* to YOUR startRun().
* @return The tools to run, in proper order. Array length must be ZERO if
* the running of other tool(s) are not required.
public iPhatTool[] getPreviousWorkflow();

* A short name - suitable for use in a drop-down combo box.
* @return A short name (typically for your tool.
public String getToolName();

* A descriptive paragraph. Suitable for use in a rich-text (HTML) display.
* @return HTML text used to describe your tool.
public String getToolDescription();

* Manage your configuration panel.
* @param file The configuration file to load / save your information to / from.
* @return Your component, as used to mange your display.
public JPanel getConfigureView(File file);

* Begin running of your tool - (we will provide the main thread)
* @param status Check this status whilst running - we will signal if the user needs you to stop.
* @param fileRun Here is where you can read / save your results to / from. Can be used for work-flow (etc.)
* @param log The log - messages you want to share with the user.
* @return TRUE if you ran to completion, false otherwise. (Only TRUE operations can be displayed and/or used by work-flow.)
public boolean startRun(OpStop status, File fileRun, StatusLog log);

* Display the result of any completed asynchronous execution of your tool.
* @param fileRun The file passed to your run-tool.
* @return Your component, as used to mange your display.
public JPanel getResultView(File fileRun);



I hope you found this conceptual overview enlightening. No matter if the views we provide into our component be diagnostic, licensing, configuration... or even real-time monitoring, I am often surprised at how happy my clients are whenever we deliver alternative graphical interfaces as part of our designs, frameworks, & components.

[ view entry ] ( 3657 views )   |  permalink

<<First <Back | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Next> Last>>