Pleasing Software

Particle Strain: Another Family Project

2014-09-04T10:14:00.002-07:00

We had so much fun with our first family project that we decided to do one more before the end of the summer. The kids -- if I may use that term to describe two awesome young men in high school -- decided it would be fun to do a software project as a family; a game, to be exact.

It's been a long time since mom and dad have worked on a game, so it sounded like fun to us. We did add one stipulation, however: it would have to be done in two weeks and at the end of those two weeks we had to have a complete, finished game that could be accepted into the various app stores.

The kids' response? Challenge accepted.

Particle Strain title screen.

Two weeks to make a technology decision, design and program a game (along with all of the various art and sound assets) made for an interesting constraint. We were also constrained by the fact that we're programmers first and foremost, with not a lot of artistic or musical ability among us. This definitely shaped the type of game we could make.

Me not doing so well at the whole "make patterns" thing.

We eventually settled on a action/puzzle game where the player flies through wormholes collecting particles to make patterns on the screen. Pretty much everything in the game such as levels, textures, and effects are procedurally generated. We ultimately decided on Unity3D as a technology framework, mainly for its built-in asset pipeline and its ability to target a variety of mobile platforms. This also gave us the chance to shake the rust off of our C# skills.

And don't forget about all those little things like app stores, code signing, and even a little website to go along with it. All in all we had a really great time doing this project. We even met our programming deadline with 20 minutes to spare, getting the last bug fix in at 11:40 PM on the last day.

As of yesterday, Apple finally approved Particle Strain for the iTunes store. It is now available as a free download in all of the usual places: iTunes, Google Play, and Amazon. There is a big difference between writing code and developing a complete, finished product. I'm glad we were able to help the kids experience it, even if in a small way.

If you end up trying out Particle Strain, we hope you enjoy our little game. I, for one, can't wait to figure out what our next project will be!

Identifying Balloons Using Computer Vision

2014-06-16T16:56:00.000-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

This is a followup to my previous article describing how to compile a hardware accelerated version of OpenCV. You can find that article here, but to briefly recap: part of the Sparkfun AVC is finding and popping red balloons. We wanted to do this using on-board vision processing. For performance reasons we need to hardware accelerate the vision system. We are using the Jetson TK1 board from NVIDIA with the OpenCV library.

What follows is a description of the vision system we developed. The full code for the vision system can be found on github at https://github.com/aiverson/BitwiseAVCBalloons

The OpenCV Project

The Open Computer Vision project (OpenCV) is easy to use and allows you to quickly program solutions to a wide variety of computer vision problems. Normally, the structure of a simple computer vision program using OpenCV is:

read in a frame from a video camera or a video file
use image transformations to maximize the visibility of the target
extract target geometry
filter and output information about the target.

For hardware accelerated applications, OpenCV provides hardware accelerated replacements for most of its regular functions. These functions are located in the gpu namespace which is documented at http://docs.opencv.org/modules/gpu/doc/gpu.html

The Algorithm

When trying to identify our balloon targets, the first thing I tried was converting the video stream to Grayscale because it is fast and cheap. However, this did not give sufficient distinction between the sky and balloons. I then tried converting the stream to HSV (Hue Saturation Value) because it is good for identifying objects of a particular color and relatively simple to do. The balloons are quite distinct in both the hue and saturation channels, but neither alone is sufficient to clearly distinguish the balloons against both the sky and the trees. To resolve this, I multiplied the two channels together, which yielded good contrast with the background.

Here is the code implementing that section of the algorithm.

gpu::absdiff(hue, Scalar(90), huered);

gpu::divide(huered, Scalar(4), scalehuered);

gpu::divide(sat, Scalar(16), scalesat);

gpu::multiply(scalehuered, scalesat, balloonyness);

gpu::threshold(balloonyness, thresh, 200, 255, THRESH_BINARY);

Hue is normally defined with a range of 0..360 (corresponding to a color wheel) but to fit into eight bits, it is rescaled to a range of 0..180. Red corresponds to both edges of the range, so taking the absolute value of the difference between the hue (with a range of 0..180) and 90 gives how close the hue is to red (huered) with a range of 0..90. The redness and saturation are both divided by constants chosen to give them appropriate weightings and so that their product fits the range of the destination. That result, which I call balloonyness (i.e. how much any given pixel looks like the color of the target balloon) is then taken through a binary threshold such that any pixel value above 200 is mapped to 255 and anything else is mapped to zero, storing the resulting binary image in the thresh variable. The threshold function is documented at http://docs.opencv.org/modules/imgproc/doc/miscellaneous_transformations.html#threshold, the GPU version is equivalent.

Once the image has been thresholded, I extract external contours. The external contours correspond to the outlines of the balloons. The balloons are nearly circular, so I find the minimal enclosing circle around the contours. Then, to deal with noise (red things that aren't shaped like balloons), I compare the area of the circle with the area of the contour it encloses to see how circular the contour is.

The image below illustrates this process.

I could also have used an edge detector and then a Hough circle transform (http://en.wikipedia.org/wiki/Hough_transform) to detect the balloons, but I decided not to because that method would not be able to detect balloons reliably at long range.

The Joys of Hardware Acceleration

Before hardware acceleration, this algorithm was running at between two and three frames per second on the Jetson board. With hardware acceleration, it now runs at over ten frames per second, and it is now limited by how quickly frames from the camera can be captured and decoded. This equates to about a five times speedup overall. It is even greater if you only consider the image processing phase.

Writing computer vision systems seems very intimidating at first, however there is very good library support so many types of problems can be solved easily with only a little research and experimentation.

Hardware Accelerated OpenCV Configuration

2014-06-15T16:55:00.001-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

Part of the Sparkfun AVC is finding and popping red balloons. We wanted to do this using on board vision processing. For performance reasons we need to hardware accelerate the vision system. We are using the Jetson TK1 board from NVIDIA with the OpenCV library. Here are instructions for configuring OpenCV with CUDA hardware acceleration on the Jetson TK1.

Imaging the Jetson Board

The first step is to image the Jetson TK1 with the latest version of Linux 4 Tegra (L4T); at the time of writing this is Rel-19 which is available at https://developer.nvidia.com/linux-tegra-rel-19. There are good instructions for this available from NVIDIA in the quick start guide available on the L4T page.

I did "sudo ./flash.sh -S 8GiB jetson-tk1 mmcblk0p1"

Installing Cuda

You must be part of the CUDA/GPU Computing Registered Developer program to get CUDA. Signing up is free on the NVIDIA developer website. You will have to login or create an account.

Download the CUDA Toolkit; at the time of writing this is CUDA 6.0 Toolkit for L4T Rel-19.2 which is available from developer.nvidia.com/jetson-tk1-support. That page also contains a getting started with linux guide which has more instructions; I only give the minimum required for this specific case. For troubleshooting refer to the getting started with linux guide.

Install the CUDA Toolkit:
cd Downloads/
sudo dpkg -i cuda-repo-l4t-r19.2_6.0-42_armhf.deb
sudo apt-get update
sudo apt-get install cuda-toolkit-6-0

Create symbolic links for the CUDA Libraries for compatibility. I put them in /usr/local/lib:
cd /usr/local/cuda-6.0
sudo ln -s *.so /usr/local/lib

Ensure that your PATH contains the CUDA executables:
export PATH=/usr/local/cuda-6.0/bin:$PATH

Ensure that your LD_LIBRARY_PATH includes the CUDA libraries and custom built libraries:
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/cuda-6.0/lib:$LD_LIBRARY_PATH

Compiling OpenCV

Download and extract the OpenCV code. I am using version 2.4.9 because, at the time of writing, that is the latest version.

Create a build directory in the same directory as the source directory. I put the source code in my Downloads directory, which currently contains "cuda-repo-l4t-r19.2_6.0-42_armhf.deb", "opencv-2.4.9.zip", "opencv-2.4.9", "opencv-2.4.9-build".

The GUI functions in OpenCV depend on GTK, so if you plan to use them, install libgtk2.0-dev:
sudo apt-get install libgtk2.0-dev

You need CMake to configure OpenCV so install that:
sudo apt-get install cmake

Change into the build directory for OpenCV

Configure OpenCV with the appropriate CUDA_ARCH_BIN for your GPU's Compute Capability, which can be determined with the deviceQuery CUDA sample. For the Jetson TK1, this is 32, so I ran:
cmake -DCUDA_ARCH_BIN=32 ../opencv-2.4.9

Run the compile and install using make; The command I used was:
sudo make -j4 install

The -j4 flag instructs it to run four jobs simultaneously, which gives a considerable speed-up when run on the Jetson which has four large ARM Cores, but allows some of the output to be out of order or interleaved.

Using GPU accelerated OpenCV

The GPU module for OpenCV is quite simple to use. The functions in the gpu namespace generally have identical semantics to the cpu variants, with the only difference being that they take cv::gpu::GpuMat arguments instead of cv::Mat arguments. Data must be uploaded and downloaded between the CPU and GPU in order to be used. GpuMat provides upload and download functions that take a single Mat as an argument to transfer the data between the CPU and GPU.

For example, the code below shows the difference between using the CPU and the GPU for the threshold function.

using namespace cv;

Mat src_host, dest_host;

//on the CPU
threshold(src_host, dest_host, THRESH_VAL);

//on the GPU
gpu::GpuMat src, dest;
src.upload(src_host);
gpu::threshold(src, dest, THRESH_VAL);
dest.download(dest_host);

My next article will discuss the specific algorithm we are using to find balloons.

GroovyFX 0.4.0 Released

2014-06-01T14:43:00.001-07:00

GroovyFX makes writing JavaFX code fast and easy. The latest version is available from Maven Central using the coordinates

org.codehaus.groovyfx:groovyfx:0.4.0

This new version includes support for Groovy 2.3.x as well as Java 8 and JavaFX 8. Please try it out and let us know if you have any problems by sending email to the mailing lists.

If you are a current user of GroovyFX and have any thoughts or questions on future directions, please send those to the mailing lists as well!

Day Four: Bomb's Away!

2014-05-30T13:18:00.000-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

Day four was our final day of prototyping so we really wanted to get the ball drop working. We felt that being able to launch, fly a significant distance, drop the ball on a target, and return to a safe landing would give us a minimally viable entry for the Sparkfun AVC.

Having had no success with the passive drop on day three, today was all about programming the Pixhawk to activate a servo motor to initiate the drop. We constructed a simple prototype using some of the parts we had previously printed and then figured out how to wire it into the Pixhawk. It took some time to learn the idiosyncrasies of Pixhawk programming and get it to send the correct servo command at the right time. Perseverance was the word of the day, and it paid off in the end.

You can see the culmination of our four days of prototyping in the summary video, and then read on for all of the (hopefully) interesting details.

You Got Servo-ed

After constructing a quick and simple prototype of the drop mechanism, we attached it to the quad-copter using duct tape, that time-honored prototyping tool.

One of the major pain points of the day was finding good documentation for our specific situation. It's very possible that we just never happened to find the correct, up-to-date docs, but this was a major source of confusion.

The Pixhawk has 8 ports labeled MAIN OUT and 6 additional ports labeled AUX OUT. Based on the best information we could find, our initial guess was that the AUX ports should be used for controlling servos, and that we should pass a servo number of 1 to the DO_SET_SERVO command if we wanted to use AUX port 1. The command's position parameter was another uncertainty. We read that typical position parameter values ranged from 1000 to 2000, so we began with values in that range hoping to just see any movement that would confirm that we were on the right track. When we tried to run the program, the servo just sat there silently mocking us. At this point, the list of potential problems was long:

Was the servo connected properly?
Which port should we use?
Did we use the right servo number in the command?
Were we sending it valid position values?
Is our DO_SET_SERVO command even executing?
Did we need to initialize the port or set other initialization parameters?

What were we doing wrong? Well, as it turns out, all of the above. Let's take them one at a time and we'll share our discoveries and solutions along the way.

Was the servo connected properly?

It was time to go down to the hardware level and eliminate some of our unknowns. We started probing the Pixhawk's output ports with a volt meter and an oscilloscope.

We discovered some things that surprised us. The Pixhawk does not supply power to any of the power pins on its bank of PWM output ports. The only port that has a working 5V power pin is the RC IN port, which is used to talk to the receiver. We couldn't see an obvious place to get 5V power from the Pixhawk itself, so as a work-around we used one of the PWM outputs of the receiver module, which was powered by the Pixhawk's RC IN port. This is a bit of a hack, but it worked.

Which port should we use? Did we use the right servo number in the command?

We discovered that there is a servo test interface in the Mission Planner app. The docs say that it doesn't actually work, but some reports from the internet indicate that it does. When we initially used this interface to test our servo, it would never move, but we couldn't be sure if it was a working test.

After figuring out the servo connection as described above, we were able to confirm that the servo test interface in Mission Planner does indeed work! We were able to see output on MAIN port 8 when toggling the output of servo 8 on the UI. Some quick probing verified that servo numbers 5 - 8 correspond to ports 5 - 8 on the Pixhawk's MAIN OUT ports. The AUX OUT ports 1 - 3 map to servo numbers 9 - 11 on the test interface. Presumably, AUX OUT 4 - 6 map to servo numbers 12 - 14, but the UI didn't allow us to test that. We chose to use MAIN OUT port 8 for our servo, so as to avoid ports 1 through 6 since they will be used by the motors on our hex-copter.

Were we sending the servo valid position values?

Using the servo test UI, we could now determine that the proper position values for our mechanism were 100 and 1900 for the open and close position. This was an exciting moment - the servo was finally moving. It was a big step for us even though it could only be controlled through the test UI. We were finally confident that our servo should work if we could figure out how to execute the commands properly

Is our DO_SET_SERVO command even executing?

There are some gotchas in getting the DO_SET_SERVO command to execute properly. First, you can't just run a mission to move a servo. The servo command needs to be sandwiched between two navigation commands. But, not just any two navigation commands. The navigation commands need to take long enough to execute that the servo has time to complete its movement. This means that the waypoints must be far enough apart that they will not trigger before the servo has the chance to open all the way. We ran into a few more gotchas before Matt figured out a workable solution of a nav command followed by a single servo command, followed by another nav command (not too close to the first one), followed by another single servo command, and one final nav command. Trying a servo command followed by a condition delay didn't work.

We had hoped to test the servo with a tiny mission that we could execute indoors with the propellers removed from the quad-copter, but were unable to get that to work. We are still looking for a good way to debug mission programming, so let us know if you know how to get feedback from Pixhawk that would let us know when our commands are being executed.

The end result was a mission that could reliably and accurately drop a tennis ball on target, but it was a bit of a struggle to get there.

Other Progress and the Future

Aside from helping us debug servos, Alex was also able to make some good progress on the vision front. He installed a patch that allowed him to build a version of OpenCV that was able to properly enumerate menu items when using V4L2 (video for Linux 2). The bottom line is that we are finally able to capture frames from the USB camera that is connected to the Jetson board. That was a big step forward for our vision effort. Now that we have frames to process, we can start writing code to identify our balloon targets.

This brings us to the end of an extremely fun week. Matt and Alex are off to Las Vegas to compete with the Colorado ARML team (editor's note: Good luck, boys!) and so we are concluding this series of daily updates. This week has given us a great start at building an entry for this year's AVC, but we certainly have a lot more to do. We cannot yet find and pop balloons, but hopefully we'll be able to solve that problem in time for the competition on June 21st. We will post future updates and videos as we go, albeit less frequently. Thanks for reading!

Day Three: Flipping Out

2014-05-29T10:41:00.002-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

Any project in which a lot of learning takes place will inevitably experience setbacks. But those kinds of projects are where the real fun happens, so days like this are a great experience for the aspiring engineers on the team. If failures can teach you more than successes, then we surely learned a lot during day three. After all the highs of day two, day three was packed with... challenges.

We experienced all kinds of problems from the small to the large, from 3D printer filament tangles to a major crash that has put our main copter out of commission. Be sure to check out the video below, but I think what this means is that the easy part is over and now we're on to the real engineering portion of this project!

Ball Drop Brainstorming

We started the day by brainstorming ideas for tennis ball dropping. The simplest thing that we thought might work was a passive drop where we put the ball in a container and attempt to tip or flip the copter to cause it to drop. For testing this "passive" drop, we chose a tall cup to ensure the ball misses the propellers on the way out. Unfortunately, we couldn't tip the copter enough to cause the ball to fall out. Flipping the copter didn't do any better either since the copter accelerates through the whole flip and the ball stays pressed to the bottom of the cup.

On the bright side, we did get some practice at acrobatic flying, so that was fun. We tried both manual and autonomous flips, which gave us the opportunity to learn how to trigger an autonomous flip command from our transmitter.

The other idea we pursued was an active drop using a servo motor to release the ball. We modeled the parts in Creo for printing on the 3D printer and we created a quick Arduino-controlled test circuit to test the mechanism. Thanks to filament tangles and other challenges, this part of the project got a little bogged down today. The final parts didn't finish printing until about 2 AM, so we'll have to test the active drop tomorrow.

A Few Wins and a Big Loss

In a day filled with nagging little problems, we did manage to get a few other things accomplished. Sondra and Matt did some more research on getting the autopilot to talk to the vision system. Alex successfully re-flashed the Jetson board with the latest version of the OS. The re-flashing process was giving us problems, so it was nice to finally get that to work.

The day's largest setback occurred during a nighttime test flight of yet another passive drop design. The copter was handling a little strangely but we decided to go forward with the test anyway. We lost control of the copter during a flip and it crashed from a height of about 30 feet straight into concrete. The DJI air frame is tough, but it couldn't withstand that impact and we broke one of the motor arms and both the upper and lower boards.

Fortunately, we had initially ordered a F450 quadcopter for this project. When we decided to try onboard vision processing with the Jetson board, the extra weight led to the switch to the larger F550 air frame. Alex and Matt were able to quickly transfer all the components to the smaller quadcopter and we managed to get it flying before we called it a day.

I guess the good news is that we'll be able to use the quadcopter to continue prototyping our active ball drop mechanism while we wait for replacements for our damaged hexcopter parts.

Next: Day Four

Day Two. Objective: Autonomous Flight

2014-05-28T12:04:00.004-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

Day two was an insanely fun day. We all agree that this project is even more fun than we thought it would be. We logged a lot of time flying and crashing the hexcopter today. Side note: I am, hands down, the worst pilot in the family. You won't see me at the controls on competition day.

I will say that the DJI F550 is one tough little copter. We've abused it pretty thoroughly and the only damage it's taken is some scrapes and chips on the propellers. There are a couple of new propeller sets on order.

Spinning Out of Control

As we left off from the previous night, we had a copter that would just spin around every time we took off. Our first guess was that it was a transmitter calibration problem, but that checked out fine. Is it possible that there is a trim setting in the autopilot that was off? Our research turned up nothing. Alex finally figured out that our motors were rotating backwards from what the autopilot expected. The diagram below shows the correct configuration, we had fixed the motor numbers but had not noticed that each pair was rotating exactly backwards from what the Pixhawk expected. Another silly mistake, but we're learning!

After rewiring our motors - yet again! - controlled flight was finally achieved. This was an exciting milestone and we all took turns flying our new creation.

After a few very small, very controlled flights around our living room, we took it out to the back yard so we could get some elevation. This allowed the younger, more dextrous members of the team to get some real flight time in. I guess we can no longer claim that all that video game playing is a complete waste of time. If you've never flown a quadcopter, I highly, highly recommend it. So much fun.

We then spent some time testing out the stabilize, loiter, and land modes that we bound to a switch on our transmitter. Stabilize mode attempts to keep the copter level but otherwise gives you complete control. Loiter mode attempts to maintain the copter's current altitude and position. It turns out that you can still control the copter and move it around in this mode, but it's quite a bit less sensitive to control input from the joysticks. This mode was the easiest for me to fly. Land mode, as you'd expect, just executes a soft landing and it does a remarkably good job. The altitude sensor seems very accurate, which will make maneuvering around the obstacles on the AVC course a bit easier.

On to Autonomous

The next step was to add our GPS unit to the copter and connect it to the autopilot. We really need to mount it on a platform above the electronics, but for this prototype we just zip-tied it to the quad base. This may have hampered our accuracy somewhat and probably led to a crash that you'll see in the video below.

We elected to recalibrate our compass since the GPS receiver has its own, although this may have not been necessary. Matt then initialized the flight planning software by setting the home location, adjusting the altitude down to a safe testing height (no higher than our backyard fence) and creating a flight plan. He also replaced loiter mode with autonomous mode on our transmitter switch so we could take the copter in and out of autonomous mode with the flip of a switch in case of emergency.

Matt's first flight plan was to manually takeoff, engage auto mode, go to a waypoint and loiter, and then re-engage manual flight and land. As mentioned previously, it turned out that our GPS receiver really isn't accurate enough to reliably navigate a space as small as our back yard. It may be a problem with our compass, the magnetic declination settings, or maybe we're getting some interference with our GPS receiver. Classifying this problem is on our task list for future investigation.

Eventually we worked around the accuracy issue and progressed to a flight plan with full autonomous take off, proceeding through two waypoints in our backyard, and a fully autonomous landing. Check out this video for the day's highlights!

Tomorrow's objective will be to fly to a waypoint and drop a tennis ball from the hexcopter and return to the start point for landing - our first real mission simulation for the AVC! Check back tomorrow to see how we do.

Next: Day Three

Day One. Objective: Achieve Manual Flight

2014-05-28T07:50:00.000-07:00

Note: This is a series of articles in which we document our attempt to build an autonomous drone for the Sparkfun AVC. The previous post is here.

We owe a proof of concept video to Sparkfun by the end of May. Since Alex and Matt are leaving town to compete in a regional mathematics competition on Friday morning, that gives us about four days to get a prototype put together and flying. It's an aggressive schedule, but we like a challenge!

We knew this first day was going to be a rough one. There's just so much we don't know and all we're starting with is a pile of parts and a lot of enthusiasm. By the end of the day, we're hoping to see a copter get off the ground under manual control. So today's agenda was:

Build a hex copter
Get the autopilot module installed and calibrated
Figure out how to get it talking to a transmitter
Learn to fly it

Oh So Many Pieces

My first order of business was to build the air frame. Step number one is always to inventory the parts and see what we're up against.

Power distribution board, arms, motors, ESCs (electronic speed control - see I'm learning already!), props, and miscellaneous screws and straps. Check! Here is a close up of the parts.

That is a lot of parts, but thanks to some great assembly video tutorials, putting it together was pretty easy. The eagle eyed reader might notice that those ESCs are marked as 30A. That's A as in amps, meaning that they are capable of providing a continuous current of 30 amps to its motor. Multiply that by 6 motor/ESC pairs, and you have a system that can draw 180 amps continuous. If that sounds like a lot of current to you, you're right! This might be a good time to talk about batteries.

Where do we get a battery that's light enough and small enough for a hex copter but can supply a lot of current? My solution is a 5000 mAh, 3-cell 25C LiPo battery as shown below with its charger.

A 5000 mAh (milliamp-hour) battery can supply 5000 milliamps, or 5 amps, of current for one hour. Or it can supply 30 amps for 10 minutes. Since I expect each motor to draw about 5 amps continuous during flight, I would guess that we'll get about 10 minutes of flight time, which should be enough to accomplish the mission. If you're wondering, 25C is the battery's capacity rating. This means that it can safely provide 25 * 5000 mA of current - or roughly 125 amps. Of course, it could only supply that much current for about 2.5 minutes before draining the battery!

While I was busy assembling the F550 base, Sondra and Matt started trying to figure out how the Pixhawk, the GPS module, the mission planner software, the transmitter, and the receiver all work together. As with everything, there are a lot of great docs and video tutorials on getting our transmitter to talk to our autopilot. After trying both versions of the mission planning software, they decided to go with Mission Planner rather than APM planner, at least for now. Mission Planner is older, but it seems a little more feature complete.

It can take a long time to calibrate accelerometers, compass sensors, GPS receivers, and gyros, but it's not at all optional. Battling impatience was a theme today. Below is the assembled F550 with the Pixhawk autopilot temporarily mounted. It's a match made in heaven, we hope.

The next step was to calibrate the sensors on the on the Pixhawk and try to get it talking to the transmitter. In addition to helping with everything else that was going on, Alex managed to start some OpenCV development on the Jetson board to try to get it talking to the USB camera.

The Jetson TK1 development board is a really incredible piece of technology. If you haven't heard about it, it's a board that features Nvidia's latest TK1 SoC. This chip features a 4+1 ARM quad-core configuration in a big.LITTLE arrangement. That means that it has 4 big, powerful cores for heavy number crunching and 1 smaller, more power-efficient core that handles all of the less time-critical, more mundane work. In addition, this SoC has a 192-core Kepler GPU so it packs a very serious graphics punch. We're hoping to try to get OpenCV running in a hardware accelerated mode on this baby in order to give us all the performance we need to find and identify our balloon victims.

In addition, the board runs a version of Ubuntu which means it's really easy to develop right on the board itself. This makes hardcore Linux development geeks like Alex very happy.

Oh So Many Mistakes

As always it's the things you don't know that you don't know that get you. Here is a fair sample of our lessons learned for today.

Did you know that if you don't bind the transmitter to the receiver, they won't talk to each other? (that sound you hear is the experienced R/C guys laughing at us... :-)
It pays to make sure that the axes on your transmitter match your autopilot's expectation. It's really tough to fly when an axis is reversed or what you think is the pitch control is actually yaw.
Your autopilot will probably want to be mounted on the center axis of your copter. There is a reason for this (think gyro sensor).
Those loud annoying beeping sounds that never quit are your ESCs complaining because they have no signal input from your autopilot. It will stop once you have things talking properly, I promise. In the mean time, covering your ears and humming loudly to yourself may help you, but it will also annoy your team mates/family members even more. Not recommended.
If you don't pay close attention and number your motors the way your autopilot expects, your copter will invariably flip over on its back as soon as you try to lift off. If you don't actually know how to fly a hex copter, you'll probably think "boy, I really suck at this." And you'll probably be right, but you should also check your motor numbering.

So did we manage to get a copter built and flying after all of that? Well yes and no, we did manage to achieve level flight for a few seconds, but we definitely have a spinning problem. Even so, we had a great first day and we made a bunch of progress! Below is a short video of some of our flight tests.

Hopefully tomorrow we'll achieve some real flight!

Next: Day Two

A New Adventure!

2014-05-27T12:59:00.000-07:00

We have just completed another long but satisfying FIRST robotics season. Since only myself and my oldest son participate in FRC, as a family we tend to spend a lot of time apart during the season. Toward the end of the season, our family started looking for a fun summer project we could do together that would satisfy our inner geeks. The solution was obvious...

Build an Autonomous Weaponized Drone

And a big welcome to our government friends who have just joined us. Before I get myself into too much trouble, I'll point out that this drone's meager weaponry won't be dangerous to anyone who is not a large red balloon. You see, we have decided to enter Sparkfun's Autonomous Vehicle Competition. We'll be competing in the arial vehicle class, and the tasks our autonomous flying machine will have to complete are: maneuver around obstacles, drop a tennis ball onto a target, and, if possible, find and pop the three large red balloons that will be randomly placed around the course.

This will not only give our family the chance to geek out together over the summer, but having never done any kind of R/C or flying robot project, we will be learning a bunch of new things. And that is the key, right? Never stop learning.

The Team and the Parts

The team name we picked is "Bitwise, Byte Foolish" and our drone will be officially named Nibble, although we've nicknamed it Splashy (the competition takes place over water!). We will all be doing a bit of everything, but there will be some areas of main responsibility among the team (er... family). I will be handing the hardware and electronics. My wife Sondra and our younger son Matt will be responsible for programming the autonomous navigation and path planning. Our older son Alex will be handling the computer vision programming that we plan to use to find and pop the balloons.

We have spent the last couple of weeks discussing and ordering most of the main components that we plan to use. Now that school is over, we plan to start the project in ernest this week. Sondra and I have taken the week off from work in order to focus on this project. I cannot wait!

Here is a preview of some of the parts we've chosen:

The flight base will be a DJI F550 hex copter, pictured above. This air frame is supposed to be sturdy and it fits our budget.
We will be using a Pixhawk autopilot (right) and GPS receiver from 3D Robotics.
We have selected a Taranis X9D transmitter and X8R receiver from FR Sky just in case we need to take manual control in an emergency.
And finally, the heavy lifting (from a computer vision standpoint) will be done by an Nvidia Jetson TK1 board, pictured below.

This is going to be fun. We will be keeping everyone updated on our quest to actually get this thing airborne this week, so check back here to see how we're doing on this adventure. I'm hoping that I can even talk Matt and Alex into writing an entry or two describing their parts in the project. Fingers crossed.

I hope we'll end up with a drone we can be proud of when the AVC competition rolls around on June 21st. I don't know how competitive we'll be, but if we can send a drone out to run the course and bring it back safely, I'll count that as a win! Just please don't let it crash into the lake. Did you hear that Splashy?

Next: Day One

GroovyFX First Official Release

2012-03-04T11:02:00.000-08:00

GroovyFX v0.1 is now available from Maven Central or as a binary Jar file directly from the GroovyFX web site (click the Download link under Community or just click here). This release is compatible with JavaFX v2.0.2.

If you need to use GroovyFX with theJavaFX v2.1 developer preview then you will have to use a snapshot of GroovyFX v0.2. I'll show an example of that later in this post.

Grabbing Grapes
Having GroovyFX in Maven Central (thanks to Sonatype's OSS hosting!) makes it simple to use GroovyFX in everything from simple test scripts to larger projects. Consider the simple script below, which uses Groovy's Grab annotation, a part of the Grape system.

This script can be easily run from the command line using

groovy -classpath $JAVAFX_HOME/rt/lib/jfxrt.jar helloGroovyFX.groovy

Pro Tip: Fellow GroovyFX project member Dierk König suggests using the following tip (as discussed on this page) to make your JavaFX libraries available to all of your Groovy scripts:

mkdir ~/.groovy/lib
ln -s $JAVAFX_HOME/rt/lib/* ~/.groovy/lib/

Then you can just type:

groovy groovyFXHello.groovy

Project Builds
GroovyFX can become part of a larger Gradle or Maven project by simply including it in your build file's dependencies as shown by this Gradle script.

The build script uses the JAVAFX_HOME environment variable to locate the JavaFX libraries. It also declares a dependency on GroovyFX 0.1 from the Maven Central repository.

The script also incorporate's Dierk's makeDirs task. Once you've copied this script to the root directory of your new project, you can run gradlew makeDirs to create a standard Maven/Gradle project structure that includes directories like src/main/ and src/test.

Next you can copy the GroovyFX Hello World script shown above into your src/main/groovy directory (minus the @Grab annotation, since we now explicitly declare the dependency on GroovyFX in our Gradle build script). Then run gradlew clean run and you should see your new project compile and run, producing the window shown at the top of this post.

The Maven script is left as an exercise to the masochistic reader.

Using GroovyFX 0.2-SNAPSHOT
You will need to grab a snapshot of the latest GroovyFX 0.2 library if you want to use it with the latest JavaFX 2.1 developer previews. Because we also have a snapshot version of the latest 0.2 changes available from Sonatype's repository, using it is a... um, snap... as shown by the following modifications to the previous Gradle build script.

One thing to be aware of is that the startup syntax in GroovyFX 0.2 has changed a bit. You no longer need to create an explicit reference to SceneGraphBuilder since one is created for you and passed as the delegate to your start closure. The script below shows our Hello World example modified to be compatible with GroovyFX 0.2.

That's all there is too it! Please try out these new releases and let us know if you have any problems or suggestions for improvements.

GroovyFX vs ScalaFX

2011-09-27T10:08:00.000-07:00

Oh, it's on now.

My good friend and new alternative language nemesis, Stephen Chin, published a blog post last night introducing a project he's been working on called ScalaFX. A nice, easy way to write JavaFX 2.0 code in Scala.

I, of course, have been working with Jim Clarke on his GroovyFX project. Stephen points out that his ScalaFX library creates code that is more concise and more readable than the Java equivalent. That is undeniably true, but picking on poor Java because it is succinctness-challenged is too easy. How about picking on a language that can defend itself with respect to conciseness, programmer productivity, and modern language features?

I give you the GroovyFX version of the Colorful Circles demo:

GroovyFX.start { primaryStage ->
  def circles
  def sg = new SceneGraphBuilder(primaryStage)

  sg.stage(title: 'GroovyFX ColorfulCircles', resizable: false, visible: true) {
    scene(width: 800, height: 600, fill: black) {
      group {
        circles = group {
          30.times {
            circle(radius: 200, fill: rgb(255, 255, 255, 0.05), 
                   stroke: rgb(255, 255, 255, 0.16),
                   strokeWidth: 4, strokeType: 'outside')
          }
          effect boxBlur(width: 10, height: 10, iterations: 3)
        }
      }
      rectangle(width: 800, height: 600, blendMode: 'overlay') {
        def stops = ['#f8bd55', '#c0fe56', '#5dfbc1', '#64c2f8', 
                     '#be4af7', '#ed5fc2', '#ef504c', '#f2660f']
        fill linearGradient(start: [0f, 1f], end: [1f, 0f], stops: stops)
      }
    }

    parallelTransition(cycleCount: indefinite, autoReverse: true) {
      def random = new Random()
      circles.children.each { circle ->
        translateTransition(40.s, node: circle, 
                            fromX: random.nextInt(800), fromY: random.nextInt(600),
                            toX: random.nextInt(800), toY: random.nextInt(600))
      }
    }.play()
  }
}

Update: Stephen updated his version to make it shorter! He even stole GroovyFX's new gradient stop syntax to do it. That was low. :-) I have no choice but to respond by shortening the GroovyFX version even further. (Thanks to Jim Clarke for the idea of using the parallelTransition in place of the timeline).

Not only is the GroovyFX version even shorter than the ScalaFX version, it is, in my humble opinion, much more readable. By my reckoning that's GroovyFX 1, ScalaFX 0.

What will the final score be? To find out, join Stephen and I for our JavaOne session "JavaFX 2.0 with Alternative Languages" on Wednesday, October 5 at 4:30 PM in the Hotel Nikko. It should be a great time as Stephen and I battle it out to convince you that our language and library is the best choice for JavaFX development.

Who will be the winner? Why, developers of course. No matter which of the two languages you choose, you will have a great JavaFX 2.0 library to go with it!

And here is the psychedelic output of the program, which of course matches Stephen's ScalaFX version and the original Java version.

Happy JavaFX-ing and stay Groovy!

JavaFX on Griffon: Events and Binding

2011-08-21T10:12:00.000-07:00

I have just uploaded a second screencast (embedded below) in the "JavaFX on Griffon" series. If you missed the first screencast, you can find it here. This screencast concludes the basic introduction I wanted to provide to writing JavaFX applications with Griffon.

In my previous article, I was remiss in forgetting to thank Andres Almiray, the leader of the Giffon project, for all his help in creating these plugins. I am thoroughly convinced that Andres spent about twice as much time answering all of my silly questions as it would have taken him to just write the plugins himself.

So Mr. Almiray, thank you for all the time you spent teaching me about Griffon plugins and the Griffon build system. You, sir, are a scholar and a gentleman!

Writing JavaFX Applications with Griffon

2011-08-20T15:20:00.001-07:00

I'm really happy to share one of the side projects I've been working on for a while now. Those of you who follow me on Twitter will have seen images of this in the past, but now I'm finally able to open up the sandbox and let others play.

I have posted a screencast on YouTube that shows how to get started with Griffon, GroovyFX, and JavaFX. I hope you will agree that it is a really fun and easy combination for writing Java desktop clients. If you are ready to try it out for yourself, the archetype I used in the video can be downloaded from my GitHub page. The screencast is embedded below, broken into two parts since it is a little on the lengthy side.

In other GroovyFX news, Jim Clarke and I will be doing an in-depth technical session on GroovyFX at JavaOne. The session will be the last session of the day on Thursday. It's titled "GroovyFX: JavaFX is my bag, baby, yeah!" This session will also touch on using GroovyFX with Griffon so I hope you can squeeze it into your busy JavaOne schedule!

Jim and I have also been busy adding more features to GroovyFX. I hope to post a new article soon describing new features like IDEA code completion and improved event declarations. There is so much Groovy JavaFX stuff to talk about!

Update: The next screencast in this series is now available. This screencast goes into more binding functionality and discusses event handling in JavaFX Griffon applications.

Introducing GroovyFX: It's About Time

2011-08-08T00:14:00.001-07:00

GroovyFX is an open source project whose goal is to combine the conciseness of Groovy with the power of JavaFX 2.0. Jim Clarke, the originator of the project, and I have been working hard to make GroovyFX the most advanced library for writing JavaFX code with alternative JVM languages. As you are about to see, it is more than a mere DSL that provides some syntactic sugar for JavaFX code. We have decided that it is past time to share our progress with the wider JavaFX community; this article is long overdue (right, Jonathan?).
This is the first of many articles I'll be writing about GroovyFX. If you want to stay up to date with the GroovyFX project you can follow this blog or follow me on Twitter.

How to Play

The GroovyFX website has all the information you need to get started but I will summarize it here:

Download and install the latest version of JavaFX and set a JAVAFX_HOME environment variable that points to the root directory of your JavaFX installation.
Download the latest version of Gradle (1.0 milestone-4 or better), unzip it, and add it to your path. Gradle provides the easiest and quickest way to build and run the demos.
Check out the GroovyFX source from http://svn.codehaus.org/gmod/groovyfx/trunk/.

Now you are ready to build and run the demos. You can build the project by changing to the GroovyFX root directory and typing

gradle build

Once the project builds successfully, you can start running one of the many demos included with the project by typing a command like

gradle AnalogClockDemo

That will start the application pictured at the top of this article. You can see a complete list of available demos by typing

gradle tasks

and examining the "Demo" task group.

Setting the Table

Setting up and populating a TableView is something that is not only common but can take a surprising amount of code in Java. So we will start with the GroovyFX TableViewDemo shown in the image below.

The code for this example, in its entirety, is as follows.

@Canonical
class Person {
    @FXBindable String firstName
    @FXBindable String lastName
    @FXBindable String city
    @FXBindable String state
}

def data = [
    new Person('Jim', 'Clarke', 'Orlando', 'FL'),
    new Person('Jim', 'Connors', 'Long Island', 'NY'),
    new Person('Eric', 'Bruno', 'Long Island', 'NY'),
    new Person('Dean', 'Iverson', 'Fort Collins', 'CO'),
    new Person('Jim', 'Weaver', 'Marion', 'IN'),
    new Person('Stephen', 'Chin', 'Belmont', 'CA'),
    new Person('Weiqi', 'Gao', 'Ballwin', 'MO'),
]

GroovyFX.start {
    def sg = new SceneGraphBuilder()

    sg.stage(title: "GroovyFX TableView Demo", visible: true) {
         scene(fill: groovyblue, width: 650, height:450) {
             stackPane(padding: 20) {
                 tableView(items: data) {
                     tableColumn(text: "First Name", property: 'firstName')
                     tableColumn(text: "Last Name", property: 'lastName')
                     tableColumn(text: "City", property: 'city')
                     tableColumn(text: "State", property: 'state')
                 }
             }
         }
    }
}

Compare that with other "simple" JavaFX TableView examples, and it's easy to see that GroovyFX can save you both time and code. There are three main sections to this code: our Person class, the declaration of the data List, and the scene graph itself. The Person class contains the four properties that will be displayed in the TableView. It is annotated with the standard Groovy @Canonical AST transformation that adds a tuple constructor. This allows us to construct a Person instance using new Person('Jim', 'Clarke', 'Orlando', 'FL') in our data List. @Canonical also adds appropriate overrides for the hashCode, equals, and toString methods. These are all generated for us at compile time; this is the power of Groovy's AST transformations.
The @FXBindable annotation is a custom AST transform that Jim and I have added to GroovyFX. When you use it to annotate a standard Groovy property, the property will be transformed into a JavaFX property. Its job is to generate all of the boilerplate associated with declaring JavaFX properties. For each annotated property it will generate three methods:

public void setFirstName(String value)
public String getFirstName()
public final StringProperty getFirstNameProperty()

This setup allows you to access your JavaFX properties just as you would any standard Groovy property.

def name = person.firstName
person.firstName = 'James'
person.firstNameProperty.bind( /* some binding expression - more on that below */ )

Considering all of the boilerplate involved when creating JavaFX properties in Java, this will be a real productivity win for GroovyFX users. One last thing to note is that you can also use @FXBindable to annotate a class. The following code is equivalent to the class declaration above. The FXBindable transform will iterate all of the class properties and transform each one into a JavaFX property.

@Canonical
@FXBindable
class Person {
    String firstName
    String lastName
    String city
    String state
}

We'll now turn our attention to the GroovyFX scene graph declaration. All scene graphs in GroovyFX begin with the GroovyFX.start method, which takes a closure as its argument. The first few lines of the closure are almost always the same: instantiate a SceneGraphBuilder and use it to declare your stage and scene. The root of our scene graph is a StackPane layout container. This is a nice container to use as a root node since it will be resized as the scene size changes and will also grow and shrink its child nodes if they are resizable (like TableView is). After the stackPane we add a tableView with its data items and its four tableColumn declarations. It is a very concise way to declare your scene graph.
You have probably noticed that the naming convention for GroovyFX scene graph nodes matches the JavaFX class names with the first letter converted to lower case. This is a convention we follow for all of our nodes. Another convention is that you specify properties for a node using Groovy's propertyName: value Map syntax. There are a couple of other fun things to note about the scene graph code.
There is a new color "groovyblue" that is added to JavaFX's Color class at runtime. We use it as the background of all of our demos, but you are free to use it in your code as well (it's the color of the star in the Groovy logo). Any JavaFX color constant can be declared using just its lowercase name such as red, blue, or burlywood. There are also shortcuts for specifying the padding of a node. Above we have just used a single integer value which will be used as the padding on all sides. You can also specify a list with 1, 2, 3, or 4 integers that will be assigned just as they are in CSS. See the GroovyFX PaddingDemo for the options. These are just a few of the many short cuts and productivity boosters we've incorporated into GroovyFX.

A Time for Binding

GroovyFX also has a nice surprise for those of you that miss the simple but powerful binding syntax in JavaFX Script. When JavaFX was ported to Java, the team at Oracle came up with a nice fluent API for specifying binding. Here is an example of this API:

        hourAngleProperty().bind(Bindings.add(hoursProperty().multiply(30.0),
                                              minutesProperty().multiply(0.5)));
        minuteAngleProperty().bind(minutesProperty().multiply(6.0));
        secondAngleProperty().bind(secondsProperty().multiply(6.0));

Not bad, but all of the method calls do tend to obfuscate the rather simple binding expression. Wouldn't it be great if you could write these kinds of binding expressions in a more natural way? Say, something like this?

        hourAngleProperty.bind((hoursProperty * 30.0) + (minutesProperty * 0.5))
        minuteAngleProperty.bind(minutesProperty * 6.0)
        secondAngleProperty.bind(secondsProperty * 6.0)

This is exactly what Jim has just added to GroovyFX. This functionality uses Groovy's operator overriding ability combined with its ability to add methods to existing classes. The result is all-natural binding goodness with only the essence of the binding and little ceremony. In fact the above expressions are part of the AnalogClockDemo pictured at the start of this article. The code for the demo's Time class is below.

@FXBindable
class Time {
    Integer hours
    Integer minutes
    Integer seconds

    Double hourAngle
    Double minuteAngle
    Double secondAngle

    public Time() {
        // bind the angle properties to the clock time
        hourAngleProperty.bind((hoursProperty * 30.0) + (minutesProperty * 0.5))
        minuteAngleProperty.bind(minutesProperty * 6.0)
        secondAngleProperty.bind(secondsProperty * 6.0)

        // Set the initial clock time
        def calendar = Calendar.instance
        hours = calendar.get(Calendar.HOUR)
        minutes = calendar.get(Calendar.MINUTE)
        seconds = calendar.get(Calendar.SECOND)
    }

    /**
     * Add a second to the time
     */
    public void addOneSecond() {
        seconds = (seconds + 1) % 60
        if (seconds == 0) {
            minutes = (minutes + 1)  % 60
            if (minutes == 0) {
                hours = (hours + 1) % 12
            }
        }
    }
}

Note the use of @FXBindable for easy property declarations, the simple expressive binding, and the natural way of accessing the properties. You use the property name by itself for getting and setting values. You use the property name followed by "Property" to access the underlying JavaFX property class when you need to add listeners or bindings. For completeness, the scene graph code used to draw the clock face is shown below.

time = new Time()

GroovyFX.start {
    def width = 240.0
    def height = 240.0
    def radius = width / 3.0
    def centerX = width / 2.0
    def centerY = height / 2.0

    def sg = new SceneGraphBuilder()

    sg.stage(title: "GroovyFX Clock Demo", width: 245, height: 265, visible: true, resizable: false) {
       def hourDots = []
        for (i in 0..11) {
            def y = -Math.cos(Math.PI / 6.0 * i) * radius
            def x = ((i > 5) ? -1 : 1) * Math.sqrt(radius * radius - y * y)
            def r = i % 3 ? 2.0 : 4.0

            hourDots << circle(fill: black, layoutX: x, layoutY: y, radius: r)
        }

        scene(fill: groovyblue) {
            group(layoutX: centerX, layoutY: centerY) {
                // outer rim
                circle(radius: radius + 20) {
                    fill(radialGradient(radius: 1.0, center: [0.0, 0.0], focusDistance: 0.5, focusAngle: 0,
                                        stops: [[0.9, silver], [1.0, black]]))
                }
                // clock face
                circle(radius: radius + 10, stroke: black) {
                    fill(radialGradient(radius: 1.0, center: [0.0, 0.0], focusDistance: 4.0, focusAngle: 90,
                                        stops: [[0.0, white], [1.0, cadetblue]]))
                }
                // dots around the clock for the hours
                nodes(hourDots)
                // center
                circle(radius: 5, fill: black)
                // hour hand
                path(fill: black) {
                    rotate(angle: bind(time.hourAngleProperty))
                    moveTo(x: 4, y: -4)
                    arcTo(radiusX: -1, radiusY: -1, x: -4, y: -4)
                    lineTo(x: 0, y: -radius / 4 * 3)
                }
                // minute hand
                path(fill: black) {
                    rotate(angle: bind(time.minuteAngleProperty))
                    moveTo(x: 4, y: -4)
                    arcTo(radiusX: -1, radiusY: -1, x: -4, y: -4)
                    lineTo(x: 0, y: -radius)
                }
                // second hand
                line(endY: -radius - 3, strokeWidth: 2, stroke: red) {
                    rotate(angle: bind(time.secondAngleProperty))
                }
            }
        }
    }

    sequentialTransition(cycleCount: "indefinite") {
        pauseTransition(1.s, onFinished: {time.addOneSecond()})
    }.playFromStart()
}

Once again, this is the AnalogClockDemo located in src/demo in the GroovyFX project. These binding expressions should still be considered experimental, but you can see them in action If you run the demo with Gradle. It should appear as shown here.

The GroovyFX AnalogClockDemo was inspired by one of the JRuby examples on javafx.com

Conclusion

GroovyFX is a young project and it is advancing rapidly. We are only just now getting close to releasing our first version, but it already has a lot of very useful functionality. It has support for virtually every JavaFX shape, control, and chart. It even provides great integration with the brand new FXML functionality (see the FXMLDemo).
There is quite a lot of documentation and many examples on the project's web site. We invite you to get involved: download and play with the code then let us know what you think. You can file JIRA issues for things that don't work or features you would like to see. Our goal with GroovyFX is to make it fun and easy to write client Java applications. So join in!

Xoom, Xoom, Xoom

2011-02-24T17:44:00.001-08:00

Android really shines on a tablet. After playing with my new Xoom tablet and Android Honeycomb for a few hours now, I get the sense that Android was really meant for the larger screen. The notifications, the multitasking, the widgets; they all combine to make an incredibly powerful and rich tablet OS. Having a home screen with your calendar and email at your finger tips is incredibly more useful than page after page of icon matrixes.

And switching between applications is much nicer on Honeycomb.

To think that all this time Android has really been a tablet OS crammed into a smart phone just bursting to get free. By the same token, I can see now just how lame iOS is as a nice, but limited phone OS when running scaled up to a larger screen on the iPad.

And the Xoom hardware is very impressive. It is slightly taller but significantly narrower than the iPad and has much smaller bevels around the screen as well. Although this does make it harder to carry the Xoom without leaving finger tip smudges. The dual core Tegra2 processor makes everything feel pretty snappy as well.

The Xoom has a higher resolution packed into a slightly smaller screen which makes for higher DPI. Games like Angry Birds and eBooks look incredible on the Xoom's higher density screen.

Notice how the status bar at the bottom of the screen goes into a minimal mode when reading a book? The same thing happens when viewing a movie in order to minimize the distraction of that bottom strip. These are really nice touches that I would usually expect from Apple rather than Google.

Of course, I'm talking here in terms of environment only. With a few exceptions, as far as applications go, iPad wins hands down. No question. No contest.

As we have seen in the past, a superior OS usually doesn't win against an OS with more apps so this should be an interesting fight.

A Sweet Combination: JavaFX 2.0 EA, Griffon, and Groovy

2011-02-12T17:42:00.001-08:00

Working with the recent early access release of JavaFX 2.0 has been interesting. On one hand, the scene graph API you know and love translates surprisingly well to Java. The team at Oracle has done a nice job of keeping the new API simple to use. The animation support still makes it easy to do the simple things, and possible to do the sophisticated. The memory overhead is down while performance is up. All good.

There are definitely places where JavaFX Script (now Visage) is missed. Binding, object literals, functional programming, and easy internationalization were all particularly useful language features. To make up for this loss, you can now use all of the old, familiar Java tools to write JavaFX including all of the awesome testing libraries and IDEs that Java is known for. In my opinion, this more than makes up for the loss of the awesomeness that was the JavaFX Script syntactic sugar.

You can always add some of that sweetness back in by using one of the many great JVM languages at our disposal. My weapon of choice happens to be Groovy and I can tell you that Groovy and JavaFX are a potent combination. Apparently Groovy is a terrific language for expressing application frameworks as it boasts two of the best in the Java world: Grails for web applications and Griffon for desktop applications.

Yesterday I decided to take a quick look at what would be involved in creating a JavaFX application plugin for Griffon. I was pleasantly surprised at how easy it was. Griffon's architecture is clean and the documentation was great. It took me a lot longer than it should have just because I was enjoying looking around under Griffon's hood.

A video showing the results of my little experiment is embedded below.

I plan to continue developing this plugin with the ultimate goal being first-class Griffon support for JavaFX applications when JavaFX 2.0 ships later this fall.

The JavaFX team at Oracle has a lot of work ahead of them. There are some missing features and some rough edges, but this Early Access release is a great start. I can't wait to see the finished product.

My Bads

2010-07-17T14:08:00.001-07:00

Just a quick update (long overdue - sorry!) to correct a couple of errors in my last two posts.

First, going all the way back to my post So What's It All Good For?, I realized while using my 'X' shape on another control that I had flubbed one of the coordinates in the SVG path. This made the 'X' look a little hinkey. Although it was really only noticeable at larger sizes, I went back and fixed the SVG path in that post. Now the 'X' checkbox looks better.

My second mistake was of a larger variety. I incorrectly claimed in my Into the Background post that you couldn't use a gradient as the background of a ScrollView because once you added other Nodes, the CSS engine would throw an exception. Turns out it was user error.

You see, I was assigning the gradient to the -fx-background property in the .scene style. The fact is that this property must evaluate to a color, not a gradient, because it is used later in the default Caspian style sheet as the base color from which other gradients are calculated. For some reason the CSS engine objected to me trying to force it to using a gradient as a color stop in another gradient. Go figure!

This is the reason that the error would only manifest once another control was added to the scene as that was when the gradient-based-on-gradient calculation would be triggered.

My mistake was kindly pointed out by David Grieve in response to my initial bug report here. I have also updated the original article to demonstrate a variation of the technique that David suggested. Thanks David!

Hopefully these kinds of mistakes will be less likely to happen in the future now that some nice documentation of the JavaFX CSS engine exists. There is also a new JIRA case opened to add better error handling and reporting to the CSS engine, which should also be a big help.

p.s. If you haven't signed the petition to open source the JavaFX runtime, please do so now! Having access to the source code could also help avoid these kinds of "misunderstandings" in the future.

Into the Background

2010-05-29T12:36:00.001-07:00

Update: This post has been edited to show you how to use a gradient as the background of a ScrollView.

The new and improved support for CSS in JavaFX 1.3 includes a .scene style class which is a convenient place to initialize all sorts of application settings such as fonts and colors. Therefore, you would also think that the .scene class is the place to specify the background color for the scene, right? If you do, you're in good company. And just like the rest of us, you would be wrong.

It turns out that the only place to set the fill property of the Scene is in your JavaFX code. But there are some tricks you can use if you want the ability to control the background of your scene from a CSS file.

ScrollViews and Rectangles

The simplest way to create a background that can be styled is to use a ScrollView as the background node in your scene. The advantage of using a ScrollView is that if the window is resized to be smaller than the content, scrollbars will automatically appear. This is a handy feature to have in a main window. The following code demonstrates the technique.

Stage {
    var sceneRef: Scene;
    title: "ScrollView Background"
    scene: sceneRef = Scene {
        width: 400
        height: 300
        stylesheets: "{__DIR__}scrollViewBackground.css"
        content: [
            ScrollView {
                width: bind sceneRef.width
                height: bind sceneRef.height
                node: // Rest of your content goes here
            }
        ]
    }
}

Here I simply placed the ScrollView first in the Scene's content and bound its width and height to the size of the Scene. Instant background.

If you then create a style sheet that sets the -fx-background property on the .scene selector, the ScrollView will pick it up automatically.

.scene {
    -fx-background: skyblue;
}

The results are pictured below.

Using a gradient as a background for the ScrollView is also possible, although it requires a little more work in your style sheet. You need to add two new styles that redefine the default background of the ScrollView so that it incorporates a gradient rather than a solid color.

.scene {
    -fx-background: skyblue;
    -my-scene-background: linear (0%, 0%) to (0%, 100%) stops (0%, derive(-fx-background, 25%)) (100%, derive(-fx-background, -35%));
}
#sceneBackground {
    -fx-background-color: -fx-box-border, -my-scene-background;
}
#sceneBackground:focused {
    -fx-background-color: -fx-focus-color, -fx-box-border, -my-scene-background;
}

Note that I have used an ID selector for these new styles so that it overrides only the -fx-background-color of the single ScrollView that I have designated as my scene's background. I was careful to preserve the -fx-box-border and -fx-focus-color settings of the default ScrollView styles (from caspian.css) so that, other than the gradient, the background will look exactly like a standard ScrollView.

I have also defined my background gradient in the .scene section of the style sheet so that it can be reused in both of the #sceneBackground styles. Declaring CSS "variables" like this is a feature of the JavaFX CSS support.

Once these additions to the application's style sheet have been made, you just need to add the proper ID to the ScrollView being used as the scene's background and you are done. This is what the JavaFX code and our window look like now.

Stage {
    var sceneRef: Scene;
    title: "ScrollView Background"
    scene: sceneRef = Scene {
        width: 400
        height: 300
        stylesheets: "{__DIR__}scrollViewBackground.css"
        content: [
            ScrollView {
                id: "sceneBackground"
                width: bind sceneRef.width
                height: bind sceneRef.height
                node: // Your content goes here...
            }
        ]
    }
}

Rectangle Backgrounds

Another lightweight option for creating a styled background is to use a simple Rectangle.

Stage {
    var sceneRef: Scene;
    title: "Rectangle Background"
    scene: sceneRef = Scene {
        width: 400
        height: 300
        stylesheets: "{__DIR__}rectangleBackground.css"
        content: [
            Rectangle {
                styleClass: "background"
                width: bind sceneRef.width
                height: bind sceneRef.height
            }
            // Rest of your content goes here
        ]
    }
}

This is similar to the ScrollView version except that a Rectangle is inserted as the first node in the Scene and its width and height are bound to the Scene's size. Note that I assigned a styleClass of "background" to the Rectangle. The style sheet now looks like this:

.scene {
    -my-scene-background: linear (0%, 0%) to (0%, 100%) stops (0%, derive(skyblue, 25%)) (100%, derive(skyblue,-25%));
}
.background {
    -fx-fill: -my-scene-background;
}

In the style sheet above, I've assigned a gradient to the -my-scene-background property in the .scene section and then used it to set the Rectangle's fill (-fx-fill) in the .background section which was the styleClass for the background Rectangle. Of course, I could have just assigned the gradient to the -fx-fill property directly, but as was pointed out above, doing it this way makes that gradient available for use by other styles in the style sheet.

Regions: Imagine the Possibilities

For the more adventurous, you can also use a Region for your background. This gives you the ability to have background colors, borders, and even images!

Warning! Non-public APIs in use beyond this point. Proceed at your own risk! (It's really not that risky)

All of the core controls in JavaFX 1.3 are made of Regions. Because of this, Regions are heavily tied into the new CSS support and have a lot more styling options than any other type of node. You can assign background colors and images, style borders, and even change the shape of the Region all from a style sheet.

But you don't have to write a control to make use of a Region. Regions are a subclass of the public Stack container and therefore can be used anywhere in the scene graph. Which means that a Region makes a great background for a Scene.

The top image shows a window with a gray gradient background that is typical of a default Caspian color scheme. The bottom image shows a combination of a background color and a background image that is positioned along the bottom of the window and repeated in the x-direction to fill the window with flowers in a celebration of Spring (with apologies to all of our friends in the Southern Hemisphere).

The code and the stylesheet are shown below in their entirety.

Stage {
    var sceneRef: Scene;
    var backgroundRef: Node;
    title: "Region Background"
    scene: sceneRef = Scene {
        width: 600
        height: 300
        stylesheets: ["{__DIR__}jfxtras.css", "{__DIR__}sceneStyles.css"]
        content: [
            backgroundRef = Region {
                styleClass: "background1"
                width: bind sceneRef.width
                height: bind sceneRef.height
            }
            VBox {
                var fillWidth = LayoutInfo { hfill: true }
                spacing: 10
                padding: Insets { top: 10, right: 10, bottom: 10, left: 10 }
                content: [
                    XEtchedButton {
                        text: "Business As Usual"
                        layoutInfo: fillWidth
                        action: function () {
                            backgroundRef.styleClass = "background1"
                        }
                    }
                    XEtchedButton {
                        text: "Yay, It's Spring!"
                        layoutInfo: fillWidth
                        action: function () {
                            backgroundRef.styleClass = "background2"
                        }
                    }
                ]
            }
        ]
    }
}

.scene {
    -fx-font: 24pt "Amble Condensed"
} 
.background1 {
    -fx-color: lightgray;
    -fx-background-color: -fx-body-color;
    -fx-background-image: null;
}
.background2 {
    -fx-background-color: #81E2F7;
    -fx-background-image: "flowersbluesky.png";
    -fx-background-position: left bottom;
    -fx-background-repeat: repeat-x;
}

Regions definitely provide the most flexibility and power as the background of a Scene. The only drawback is that Region is not part of the JavaFX runtime's public API. As such, there is always the possibility that the class may change or disappear in future releases. In this case, I think the fact that the core controls now rely on Regions means that they will be around in one form or another for a long time.

Back Off, Steve

2010-04-29T10:07:00.000-07:00

I cannot express my indignation adequately in 140 characters.

Apple has published a well-written open letter from Steve Jobs about the iPhone/iPad vs Flash kerfuffle.

Being used to the JVM, I will admit that the Flash Player does not seem as fast or robust. But I do find it to be a fairly pleasant development environment. And it is very good at what it was designed for.

The real problem I have with the open letter is the last, most important reason Jobs lists. It boils down to: we just want to protect our developers from making bad choices (as defined by us). By force if necessary. This is just so wrong for so many reasons.

If Apple wants to ban the Flash Player from their platforms, fine. But don't try to dictate what languages developers can use under the guise of "supporting open standards." Apple, if the use of ActionScript leads to inferior applications, they will be killed off by the native applications. The point is: fair competition should always be allowed to determine the winner.

If Adobe's tools make it easy for developers to create nice applications that people want to use, you do everyone a disservice by imposing additional artificial restrictions on your already closed-garden app store. Stop hindering free competition!

I really enjoy developing applications on my brand new MacBook Pro. But my next mobile device is going to be powered by a little green robot. Not because I want to make a statement. Just because I want to be able to decide how to write applications for my own device. And for me personally, neither Objective-C nor HTML5 are appealing choices.

Just my worthless opinion. We now return to our regularly scheduled JavaFX addiction.

So What's It All Good For?

2010-04-27T09:02:00.000-07:00

Ok, so my previous post (which I refer to facetiously as the Encyclopedia of JavaFX Styling) was a tad on the long-ish side. It contained a lot of not-so-trivial-to-understand information. It contained information that was biased toward helping control authors understand the new system rather than application developers.

So I can certainly understand the reactions of some folks: "Holy cow that looks complicated!" or "Why should I learn all of that?" or "What's this new-fangled system even good for?". The reason application developers should learn the new styling system is very simple: you can now do things with a few lines of CSS that used to take many lines of JavaFX code.

Like all of JavaFX, it's all about developer productivity!

Let's say as an application developer you decided that:

All of your application buttons should be round, or
Your checkboxes should have red X's rather than black checks and the text associated with them should turn red when the checkbox is selected, or
You want an awesome slider for your "number of gold stars" rating system complete with a star-shaped thumb bar that casts a drop shadow! (Really? Ok...).

Pre-JavaFX 1.3 you would be doing some combination of styling and overriding skin classes and rewriting skin code. Now with JavaFX 1.3, all of this is just a style sheet away.

.scene {
    -fx-font: 16pt "Amble"
}

.button {
    -fx-base: dodgerblue;
    -fx-shape: "M 50,30  m 0,25  a 1,1 0 0,0 0,-50  a 1,1 0 1,0 0,50";
    -fx-scale-shape: false;
}

.check-box:selected *.label {
    -fx-text-fill: red
}

.check-box:selected *.mark {
    -fx-background-color: red;
    -fx-shape: "M 0,0 H1 L 4,3 7,0 H8 V1 L 5,4 8,7 V8 H7 L 4,5 1,8 H0 V7 L 3,4 0,1 Z";
}

.slider *.track {
    -fx-base: derive( goldenrod, 50% );
}

.slider *.thumb {
    -fx-shape: "M 50,5 L 37,40 5,40 30,60 20,95 50,75 80,95 70,60 95,40 63,40 Z";
    -fx-background-color: derive(goldenrod,-50%), goldenrod;
    -fx-background-radius: 0, 0;
    -fx-background-insets: 0, 2;
    -fx-padding: 10;
    -fx-effect: dropshadow( two-pass-box , rgba(0,0,0,0.6) , 4, 0.0 , 0 , 1 );
}

Just apply this style sheet and BLAM! All your buttons are round, all your checkboxes are X'ed, and all of your sliders are golden. Life is good. Behold.

Although... we may want to re-think that red checkbox label. Ick.

Advanced JavaFX Control Styling

2010-04-26T11:45:00.001-07:00

JavaFX v1.3 includes a brand new and much more powerful CSS-based styling and skinning engine. This article will take a peak under the covers and show you how to get the most out of JavaFX styling so you can develop a unique look for your applications. I'll even show you how to do some basic re-skinning of the core controls - changing not just their color scheme but also their shape! - all from the comfort and convenience of your style sheet. That is a lot of ground to cover so we better get started.

Understanding Regions

Warning!! The Region API is not public and is not considered a finished work. It can, and certainly will, change in future versions. Maybe even in JavaFX v1.3.1. The code presented here is for demonstration of the concepts underlying the new styling system in JavaFX 1.3. If you are considering using this information to build your own custom controls, be sure you understand the down side of using private APIs!

In v1.3 the core controls are made up of regions. Regions are basically a shape with one or more backgrounds and borders. All core control skins inherit from SkinBase which extends Region. Take the LabelSkin as an example. Its inheritance hierarchy looks like this:

LabelSkin -> SkinBase -> Region -> Stack

So the controls are regions, but they can also have zero or more sub-regions. Think of a scroll bar control. It is a region, but it also has sub-regions for the thumb button, the track, and the up and down arrow buttons.

Regions are tied into the new CSS system and can be fully specified, right down to their shape, from a style sheet.

Note that SkinBase does not inherit from Skin at any point. A SkinBase can be assigned to a custom control's skin variable through the use of the SkinAdapter class. The SkinAdapter will take care of passing along the control and behavior assignments to the SkinBase when SkinAdapter is set as the Control's skin.

Creating a Demonstration Control

I simply define a class that extends Control, assign the skin using the SkinAdapter, and override the styleClass variable.

public class DemoControl extends Control {
    // This is the class I'll use in style sheets
    override var styleClass = "demo-control";

    // SkinAdapter lets me use a Region as a Skin
    override var skin = SkinAdapter {
        rootRegion: DemoControlRegionSkin{}
    }
}

Next I define a Region-based skin by creating a class that extends SkinBase.

public class DemoControlRegionSkin extends SkinBase {
    // SkinAdapter will set up SkinBase's control and behavior vars
    var cc = bind control as DemoControl;

    // You should always give your control skins a default preferred size
    override function getPrefWidth( height ) { 100 }
    override function getPrefHeight( width ) { 100 }
}

JavaFX Styling Techniques

I think it's best to start with a basic example and build up from there. So I'll begin by creating a simple scene and adding our new demo control.

Stage {
    title: "JavaFX CSS Controls"
    scene: Scene {
        var stack:Stack;

        width: 300
        height: 300
        stylesheets: "{__DIR__}controlStyles.css"

        content: [
            stack = Stack {
                width: bind stack.scene.width
                height: bind stack.scene.height
                content: [
                      DemoControl {
                          layoutInfo: LayoutInfo {
                              width: 250
                              height: 250
                          }
                      }
                ]
            }
        ]
    }
}

I created a simple Scene that is 300 by 300 pixels and has a Stack container that fills it completely. I then created a new instance of my DemoControl and set it's preferred width and height to be 250 pixels. Note that this will override the preferred width and height of 100 that I entered into the control skin itself when I added those functions. By default a Stack will size its children to their preferred size and center them. Therefore, when this program is run we should see a 250 by 250 rectangle (a.k.a. a square) centered in the scene. I'll now add some minimal styling in controlStyles.css (which is added to the Scene above) so the Region's rectangle will be visible.

.scene {
    -fx-font: 16pt "Amble";
    -dean-slightlydarkergreen: derive( green, -25% );
}

.demo-control {
    -fx-background-color: skyblue;
    -fx-border-color: -dean-slightlydarkergreen;
    -fx-border-width: 2;
}

This small style sheet first sets a default font for the Scene. I haven't added any controls with text yet, but I will later and it's always nice to set these things up in one place. Below the font attribute, I demonstrate a feature of JavaFX styling: the ability to derive a new color from an existing one and store it for later use. In this case, I created a darker version of Green and named it -dean-slightlydarkergreen. Not only am I now immortalized in my own style sheet, but the DemoControl can reference this attribute later as shown above for the control's border color. Note that I use the same class string "demo-control" that I hard-coded into my DemoControl class. Let's see how this looks so far.

Gradients

You can also specify linear gradients in your style sheet. The image and code below shows a fancier version of the DemoControl.

#gradient.demo-control {
    -dean-lightnavy: derive(navy, 100%);
    -dean-navygrad: linear (0%,0%) to (100%,0%) stops (0%, -dean-lightnavy) (100%, navy);
    -fx-background-color: linear (0%,0%) to (0%,50%) stops (0%, derive(deepskyblue, 80%)) (30%, deepskyblue) reflect;
    -fx-border-color: -dean-navygrad null -dean-navygrad null;
    -fx-border-width: 8 0 8 0;
}

You can see by the CSS selector "#gradient.demo-control" that this style will be applied to DemoControls with "gradient" for an ID. I didn't have to change any JavaFX script code to make this work other than adding the id: "gradient" attribute to the DemoControl's object literal declaration in the Scene, thereby picking up this new style.

In this style, I also derive a new light navy color and then reference it again when I define my navy gradient (-dean-navygrad). This gradient is then used as the border color. I use it on the top and bottom while setting the left and right border colors to null. Similarly, I set the top and bottom border widths to 8 pixels while the left and right borders have a 0 width. Many style attributes of a Region have this ability to specify top, right, bottom, and left properties individually. On the other hand, if I were to simply say "-fx-border-width: 8" then all borders would be 8 pixels wide.

The Region's background color is a slightly more complicated linear gradient. It goes half way down the rectangle and is then reflected so the bottom half matches the top. Note that you can even embed "derive" functions inside of linear gradient definitions. More power!

Multiple Backgrounds

As I said at the beginning, Regions are made up of a shape and one or more backgrounds and borders. Let's take a look at how you define multiple backgrounds and borders for your region. Once again, I will make no changes to our source code other than the control's ID in the scene and a new style in the style sheet.

#multibg.demo-control {
    -fx-background-color: skyblue, mediumaquamarine;
    -fx-background-radius: 15 0 15 0;
    -fx-background-insets: 0, 20;
    -fx-border-color: navy, darkcyan;
    -fx-border-style: dotted;
    -fx-border-width: 2;
    -fx-border-radius: 15 0 15 0;
    -fx-border-insets: 0, 20;
}

Most of the style attributes of a Region can take multiple items in their declarations. You can see examples of this in the declarations of the -fx-background-color, -fx-background-insets, and the -fx-border-color attributes. In these cases, the first item is applied to the first background, the second item is applied to the second background and so on. Therefore we end up with a skyblue rectangle with navy border and a medium aquamarine rectangle with a dark cyan border. The first background has no insets (it is filled right to the border of the control), while the second rectangle is inset by 20 pixels on all sides.

In cases where there are multiple backgrounds but only one item specified, the first item will be applied to all backgrounds. For example, both rectangles have top-left and bottom-right rounded corners defined by the -fx-background-radius and -fx-border-radius attributes. Since only one set of radius attributes are defined, it will be applied to both backgrounds.

The thing to remember is that commas separate multiple items in a single attribute (as in the two items specified by -fx-background-color above), whereas spaces are used as the separators in an item that can take multiple values (as in the one item having 4 values specified by -fx-border-radius above). Crystal clear? Good. Let's take it up a notch.

Getting Fancier

Here's a twist: many of those attributes that can take multiple values in a single item (like -fx-border-radius) can also take multiple items. This allows you, for example, to specify a different set of border radius values for each background.

#multibgoppcorners.demo-control {
    -fx-background-color: skyblue, mediumaquamarine;
    -fx-background-radius: 15 0 15 0, 0 15 0 15;
    -fx-background-insets: 0, 20 40 20 40;
    -fx-border-color: navy, darkcyan;
    -fx-border-style: dotted, dashed;
    -fx-border-width: 2, 1;
    -fx-border-radius: 15 0 15 0, 0 15 0 15;
    -fx-border-insets: 0, 20 40 20 40;
}

Here I specify a completely different set of values for the -fx-background-radius, -fx-background-insets, -fx-border-radius, and -fx-border-insets attributes for each background. Remember, multiple values within a single item are separated by spaces while multiple items are separated by commas.

Styling Conclusions

In this section I've experimented with the most common style attributes that are used on Regions. You can also use the regular Node style attributes that I covered here. Of interest will be Node's -fx-opacity, -fx-effect, and -fx-cursor attributes. It should also be noted that Regions have a corresponding set of attributes for image-based backgrounds and borders (i.e. -fx-background-image and -fx-border-image and so on). I'm not going to cover them here, but I would expect Oracle to publish full documentation on these attributes very soon.

Shaping Controls

So far, I've just used the default rectangular shape but by using the style sheet I can make a region take on just about any shape that can be imagined. The shape of a Region is specified using SVG path notation. This notation uses a compact encoding to describe shapes using a series of commands and coordinates. Commands are represented by a single letter. For example, M is the move-to command. If the command letter is upper case then the coordinates that follow are considered absolute coordinates whereas the coordinates are interpreted as relative if the letter is lower case. So "M 0 1" means move to location 0,1 while "m 0 1" means move 1 unit in the y direction from the current location. See this page for details of the SVG path syntax.

Movement and Lines

Drawing shapes with one or more lines is extremely easy. The format of the commands is shown in the following table.

Move to	M x y m x y
Line to	L (x y)+ l (x y)+
Horizontal line to	H x
Vertical line to	V y
Close the current path	Z z

Suppose I wanted a triangular region instead of the default rectangle.

#line.demo-control {
    -fx-shape: "M 0,1 L 1,1 .5,0 Z";
    -fx-background-color: skyblue, blue;
    -fx-background-insets: 0, 20 20 10 20;
}

The coordinate system used in these paths is the same one used in JavaFX: x increases to the right, y increases down. So our shape is defined as:

Move down one unit in the y direction
Draw a poly-line to the coordinate 1,1 and then 0.5,0
Close the path

By the way, the use of commas to separate the x,y coordinates in a SVG path command are purely optional. I like to use them because it makes the command more readable to me. I'm using capital letters so those coordinates are absolute, not relative to each other. By default, the shape is scaled to fill the area of the control, so the scale of the coordinates doesn't matter. I could have just as easily used 0, 50, and 100 rather than 0, 0.5 and 1.0. You can see that even though the shape has changed, our ability to specify multiple backgrounds with offsets hasn't. One thing to watch our for is that, with non-rectangular shapes, the insets may need to be adjusted to keep the inner shape centered. Here I had to adjust the bottom inset of the second background to make the triangles look centered. I don't know if this is a bug or a feature, but for JavaFX 1.3 be aware that you may need to play with the insets to get things to look exactly as you want. And although the coordinates of the shape are scaled, the insets are still specified in pixels.

Cubic Curves

The SVG path commands for drawing cubic Bezier curves are shown in the following table.

Cubic Bezier curve to Draws a curve from the current point to x,y. x1,y1 is the control point at the beginning of the curve. x2,y2 is the control point at the end of the curve.	C (x1 y1 x2 y2 x y)+ c (x1 y1 x2 y2 x y)+
Cubic Bezier curve to (shorthand) Draws a curve from the current point to x,y. The control point at the beginning of the curve is the reflection of the second control point from the previous curve. x2,y2 is the control point at the end of the curve.	S (x2 y2 x y)+ s (x2 y2 x y)+

So let's take a look at a region shaped with cubic curves.

#cubic.demo-control {
    -fx-shape: "M100,200 C100,100 250,100 250,200 S400,300 400,200 Z";
    -fx-background-color: skyblue, blue;
    -fx-background-insets: 0, 10;
}

This is admittedly a somewhat fanciful shape for a control. It is important to note that the control's clickable area still takes up the whole 250 by 250 pixels even though the Region's backgrounds take up a smaller area.

Quadratic Curves

The quadratic Bezier curve commands are shown in the table below.

Quadratic Bezier curve to Draws a curve from the current point to x,y. x1,y1 is the control point of the curve.	Q (x1 y1 x y)+ q (x1 y1 x y)+
Quadratic Bezier curve to (shorthand) Draws a curve from the current point to x,y. The control point at the beginning of the curve is the reflection of the control point from the previous curve.	T (x y)+ t (x y)+

Let's take a look at a quadratic curve example.

#quadratic.demo-control {
    -fx-shape: "M0,200 Q100,50 200,200 T500,100";
    -fx-background-color: skyblue, blue;
    -fx-background-insets: 0, 10;
}

The shape of our region just keeps getting more interesting!

Elliptical Arcs

The arc command is easily the most confusing of the SVG path commands. Use of SVG graphical editors is highly recommended!

Elliptical arc to rx ry - The radius of the resulting arc x-axis-rotation - Rotation of the x in degrees large-arc-flag - If 1 then the largest arc between the start and end points will be drawn. If 0 then the smallest are will be drawn. sweep-flag - Indicates the direction in which the arc is drawn. A 1 specifies the positive direction, a 0 specifies the negative direction. x y - The end point of the resulting arc. These are absolute coordinates or are relative to the start point (the current location) depending on whether the A or a command is used.

A (rx,ry x-axis-rotation large-arc-flag sweep-flag x,y)+ a (rx,ry x-axis-rotation large-arc-flag sweep-flag x,y)+

What are arcs good for? Lot's of things, of course, but circles are an obvious choice. However, drawing a circle with arc commands is not as trivial as you would imagine. Here is an example.

#arc.demo-control {
    -fx-shape: "M 50,30  m 0,25  a 1,1 0 0,0 0,-50  a 1,1 0 1,0 0,50";
    -fx-background-color: skyblue, blue;
    -fx-background-insets: 0, 10;
}

As you can see, you actually need to define two arcs: one for each 180 degree ellipse.

Final Thoughts on Shapes

The ability to change, not just the colors, but the actual shapes of the regions that make up the core controls gives application developers unprecedented control over the look of their applications. Need a slider with a gold star for the thumb track? Easy. Buttons that look like clouds? Very do-able. The only limit is your imagination. Just remember, as with many of the things that JavaFX makes easy for developers: with great power comes great responsibility!

Using Caspian Styles

One last thing I want to address is the subject of using that styles in caspian.css with your own controls. The Caspian class in JavaFX 1.2 contained several nice utility functions that would generate nice gradients that tied into the Caspian theme. That class no longer exists in JavaFX 1.3. To use the Caspian theme with your own controls, you will need to use the values defined in the caspian.css style sheet.

Let's return to the DemoControl and make it look like it fits in with the Caspian controls.

#caspian.demo-control {
    -fx-background-color: -fx-body-color;
    -fx-background-radius: 5;
    -fx-border-color: null;
}

As you can see, all I've done is use the -fx-body-color attribute from caspian.css as my background color, added a corner radius to match Caspian's, and turned off the border I would normally inherit from the default demo-control style. In order for the -fx-body-color attribute to be defined, the caspian.css has to be loaded into the scene. Instantiating any core control will take care of this. In this case, I not only instantiated a button, but I also added it to the scene's Stack container just for comparison.

Adding Borders

Now I'll go the whole nine yards and add Caspian-style borders as well. I can take these right out of the button style in caspian.css.

#caspianborders.demo-control {
    -fx-background-color: -fx-shadow-highlight-color, -fx-outer-border, -fx-inner-border, -fx-body-color;
    -fx-background-radius: 5, 5, 4, 3;
    -fx-background-insets: 0 0 -1 0, 0, 1, 2;
    -fx-border-width: 0;
}

Here I have actually defined four different backgrounds for the DemoControl's region. The insets are used to make sure they appear properly as a shadow, two borders and the body. Using the Caspian-defined attributes for body, border and shadow color means that my DemoControl will respond to changes in the application-defined -fx-base attribute. This is the attribute you would set if you wanted to change the base color of all Caspian controls in the entire application. I can set -fx-base to a new color in the .scene style and both DemoControl and the button will pick up the change.

.scene {
     -fx-font: 16pt "Amble";
     -fx-base: dodgerblue;
}

Final Conclusion

I really like the power and flexibility of the new CSS support in JavaFX 1.3. Styling and skinning controls is now easier than ever. If you need to, you can create an entirely unique look for your application without having to change any lines of JavaFX source code. It brings us a true separation of presentation and program logic. All in all, I give it a gold star. A gold star button even!

#star.button {
     -fx-shape: "M 50,5 L 37,40 5,40 30,60 20,95 50,75 80,95 70,60 95,40 63,40 Z";
     -fx-base: goldenrod
}

References

I found these things handy while learning about all of this:

The caspian.css style sheet located in com/sun/javafx/scene/control/skin/caspian/caspian.css in the javafx-ui-controls.jar packaged with the JavaFX SDK.
The Style Editor example at: http://www.javafx.com/samples/StyleEditor/index.html

A Brief Introduction to Styling Controls in JavaFX 1.3

2010-04-22T19:51:00.000-07:00

Support for styling the core controls using CSS has been greatly enhanced for JavaFX 1.3. In fact, the default skin for the core controls, called Caspian, is now written as a style sheet rather than in JavaFX Script code. Below is an example of a small JavaFX 1.3 style sheet that I wrote for Jim Weaver's 3D Calendar application:

.scene {
   /* default font for all content, inherited by all nodes */
   -fx-font: 16pt "Amble Cn";

   /* main color palette */
   -fx-base: #AEBBD2;
   -fx-accent: #385589;
   -fx-mark-color: #3E857C;
}

.text-box {
   -fx-effect: innershadow( two-pass-box, rgba(0,0,0,0.2), 10, 0.0, 0, 2 );
   -fx-text-fill: #385589
}

#title.text-box {
   -fx-font-size: 125%;
}

.button:strong {
   -fx-text-fill: #D3DAE9;
}

If you have used JavaFX's CSS support in previous versions, you will notice some changes in how style sheets are now written.

Where you used to write Scene, TextBox, and Button, you should now write .scene, .text-box, and .button. These are CSS class selectors, which kind of makes sense since you are selecting JavaFX control classes.
All JavaFX style attributes now start with the -fx extension in order to avoid conflicts with standard CSS attributes. For example, you should now write -fx-font rather than just font.
This style sheet also contains an example of one of the new features in JavaFX 1.3's style sheet support: the ability to an inner shadow effect. You can also specify a drop shadow using a similar syntax

Here is a table of some more new and fun attributes that can be set from style sheets.

Attribute	Example Value(s)	Works On	Notes
-fx-cursor	crosshair \| default \| hand \| move \| text \| wait	Nodes
-fx-opacity	0 .. 1.0	Nodes
-fx-rotate	0 .. 360	Nodes	Defaults to 0. Not taken into account in layoutBounds
-fx-scale-x	Number	Nodes	Defaults to 1. Not taken into account in layoutBounds
-fx-scale-y	Number	Nodes	Defaults to 1. Not taken into account in layoutBounds
-fx-scale-z	Number	Nodes	Defaults to 1. Not taken into account in layoutBounds
-fx-translate-x	Number	Nodes	Defaults to 0. Not taken into account in layoutBounds
-fx-translate-y	Number	Nodes	Defaults to 0. Not taken into account in layoutBounds
-fx-translate-z	Number	Nodes	Defaults to 0. Not taken into account in layoutBounds
-fx-focus-color	white \| #FFEEDD \| #FFF	Controls	Color of the focus outline
-fx-control-inner-background	white \| #FFEEDD \| #FFF	TextBox, PasswordBox, ListView
-fx-mark-color	blue \| #0000FF \| #00F	CheckBox, RadioButton, ScrollBar
-fx-echo-char	"\u263A";	PasswordBox	Make your password boxes friendly!

This is just a sample of some of the power of the new CSS support. I haven't even touched on linear and radial gradients, deriving colors using derive( pink, -20% ), the ladder function, or alternative ways of specifying colors: rgb(), rgba(), hsb(), and hsba(). So much left to cover!

Creating Custom Caspian Controls

2009-12-11T10:51:00.000-08:00

Creating custom controls in JavaFX is not difficult. Creating custom controls that fit nicely with the default Caspian theme, with its pervasive use of gradients and animation, is a little trickier. This is only because the utility classes and methods that make it simple lie buried within com.sun packages that are not publicly documented. A little digging reveals a few gems that can be used to make your controls fit right in with the core JavaFX controls.
If you are observant, you will not fail to notice that this post also serves to emphasize some of the many reasons that I love, and love working with, Caspian.

Warning #1 This post is not an introduction to writing controls in JavaFX. I will not cover the basics of the Control - Skin - Behavior classes. A quick and simple tutorial on this topic can be found here.

Warning #2 All of the information in this post applies only to JavaFX 1.2.1. One of the dangers of using non-public classes is that they can change significantly from version to version (and they certainly will for JavaFX 1.3). If there is interest, I will update this information after JavaFX 1.3 is released.

Apology #1 I discovered the information I'm about to present here while writing my own controls. None of this should be considered official Caspian documentation since I do not work for Sun and I do not have access to their source code (but hopefully I will when they release the source someday). Everything here is accurate as far as I can tell, but I apologize if I have any of the details wrong. Hopefully someone from Sun will read this and let me know if I've made any mistakes.

Knock-knock Joke #1 (of 100) Knock, knock. Who's there? Yewben. Yewben who? Yewben warned, now on with the post!

Caspian 101 - Colors and Gradients

Caspian controls in JavaFX 1.2.1 all make use of a mixin class called Colorable. This mixin provides the ubiquitous base and accent properties that can be used to style the controls. The base property specifies the base color of the control while the accent property specifies the accent color on those controls that support it. ListView, for example, uses the accent property to specify the color with which it draws the selection highlight in the list. Usage of the Colorable mixin makes Caspian controls incredibly easy to style.
Two other colors are generated from the base color: the over color, which is used when the mouse pointer is over the control, and the pressed color, used when a control is (you guessed it) pressed. Caspian also generates five Paint objects from the base color: the body paint, the text paint, the border paint, the highlight line paint, and the shadow highlight paint. The screenshot below shows an application that displays these various colors and paints. It has been annotated with lines that show where they are used on a Caspian button (click the image to see a larger version).
If you launch the application, you can see that the button is a live control that has been scaled up to four times its normal size. If you hover the mouse cursor over the button or click on it, you will see the control's use of the over and pressed colors as well. Caspian is remarkably clever about generating nice looking controls from a single color.

The Caspian class in the com.sun.javafx.scene.control.caspian package provides easy access to these color-generating capabilities via module level functions:

Caspian.getOverColor( base: Color )
Caspian.getPressedColor( base: Color )
Caspian.getBodyPaint( base: Color )
Caspian.getTextPaint( base: Color )
Caspian.getBorderPaint( base: Color )
Caspian.getHighlightLinePaint( base: Color )
Caspian.getShadowHighlightPaint( base: Color )

Therefore, the first step in creating a control that fits in with the native Caspian controls is to use the Colorable mixin class and use it's base property to generate the other colors for your control.

public class MyControlSkin extends Skin, Colorable {

def bodyPaint = bind Caspian.getBodyPaint( base );
def overPaint = bind Caspian.getBodyPaint( Caspian.getOverColor( base ) );
def pressedPaint = bind Caspian.getBodyPaint( Caspian.getPressedColor( base ) );

var mousePressed = false;

def background = Rectangle {
   fill: bind {
       if (mousePressed) {
           pressedPaint
       } else if (background.hover) {
           overPaint
       } else {
           bodyPaint
       }
   }
   stroke: bind Caspian.getBorderPaint( base )
   blocksMouse: true
   onMousePressed: function( me: MouseEvent ) {
       mousePressed = true;
       // ... may also need to notify the Behavior ...
   }
   onMouseReleased: function( me: MouseEvent ) {
       mousePressed = false;
       // ... may also need to notify the Behavior ...
   }
}

// ... I'm too modest to show more skin ...
}

With just a few lines of code you get nice Caspian gradients for your control plus your custom control will respond to the same base style property as any core JavaFX control. In this simple example I only changed the body paint in response to mouse events. The core JavaFX controls also tend to update their border and highlight colors in response to hover and pressed events. You can see this when you run the Caspian Colors application above and interact with the button.

Caspian 102 - Animated State Transitions

Getting the colors and gradients right is only half the battle. Caspian also uses nice animated transitions when the control changes its state. For instance, when a button is disabled it doesn't just flip to a disabled state, it animates the transition with a smooth fade of the button's opacity. Similar animations occur when a control gets enabled, gains or loses focus, gets hovered over, or gets clicked. Caspian provides a smooth and fluid user experience.
This is something I want to support in my own controls since I am a subscriber to the Chet Haas school of thought regarding the positive role that good, subtle animation cues can play in a user interface. Animating all of those state transitions could become a real chore, so it's a good thing that you can cheat and take advantage of the hard work already done by the team at Sun. Allow me to introduce you to the States, State, and StateTransition classes. All of these little beauties are found in the com.sun.javafx.animation.transition package.
The State class allows you to define each state of your control. The class has four properties of interest:

`id`	The name of the state.
`defaultState`	Should be set to `true` if this state is the one in which your control starts.
`active`	Should be set to `true` when this state is active. Normally this will be bound to some property of the control. For example, when defining the "hover" state, you would bind the state's `active` property to the skin node's `hover` property.
`priority`	An integer value that is used to establish precedence when multiple states are active at the same time.

The StateTransition class derives from Transition and allows you to define the animation that will occur when your control moves from one state to another. The properties of interest in this class are id, fromState, toState, and animation. The fromState property is a string that allows you to specify the id of the state you are transitioning from. Likewise for the toState property.
And finally, the States class keeps track of your control's states and manages the transitions between them. The following code shows an example of the states and transitions for a custom control.

def FAST_TRANSITION = 250ms;
def SLOW_TRANSITION = 500ms;

public class MyControlSkin extends Skin, Colorable {
override var color = base;  // color is another property defined in Colorable

def over = bind Caspian.getOverColor( base );
def pressed = bind Caspian.getPressedColor( base );

var mousePressed = false;

def states = States {
   states: [
       State { id: "disabled", active: bind control.disabled }
       State { id: "armed",    active: bind mousePressed }
       State { id: "hover",    active: bind control.hover }
       State { id: "enabled",  active: bind not control.disabled, defaultState: true }
   ]
   transitions: [
       StateTransition {
           id: "Enter-Enabled"
           toState: "enabled"
           animation: ParallelTransition {
               content: [
                   ColorTransition {
                       colorable: this
                       toValue: base
                       duration: SLOW_TRANSITION
                   }
                   FadeTransition {
                       node: bind node
                       toValue: 1.0
                       duration: FAST_TRANSITION
                   }
               ]
           }
       }
       StateTransition {
           id: "Enter-Hover"
           toState: "hover"
           animation: ColorTransition {
               colorable: this
               toValue: over
               duration: FAST_TRANSITION
           }
       }
       StateTransition {
           id: "Enter-Armed"
           toState: "armed"
           animation: ColorTransition {
               colorable: this
               toValue: pressed
               duration: FAST_TRANSITION
           }
       }
       StateTransition {
           id: "Enter-Disabled"
           toState: "disabled"
           animation: FadeTransition {
               node: bind node
               toValue: 0.33
               duration: FAST_TRANSITION
           }
       }
   ]
}

// ... Move along, nothing more to see ...
}

True to the spirit of JavaFX's declarative syntax, all you have to do is declare your states and the transitions between them and the rest is handled for you! You can't ask for easier animations than that.
In addition to those shown above, many controls also have "focused", "focused+hover", and "focused+armed" states defined as well (along with their corresponding transitions). Note that I did not specify any priorities in the State declarations above. That is because the order in which the states are declared establishes a default priority. You only need to specify an explicit priority if you want to override this default. Also note that I didn't specify a fromState in any of my state transitions. I was telling the States class that it can use that transition when entering the target state from any other state. You only need to specify a fromState if you want the transition to be used only when entering a state from one other particular state.
This code makes use of another Caspian gem, the ColorTransition class which is found in the com.sun.javafx.scene.control.caspian package. It will animate the Colorable mixin's color property from one value to another. This is yet another reason to make use of the Colorable mixin in your code - easy color animations!

The Etched Button Control

This control was created because I wanted a close button for the XPane control that looked like it was etched into the background of the title bar. I wanted the etched button to fit in as closely as possible with the other Caspian controls as well. The resulting control is shown in the image below.

The button features animations for over and pressed states as well as the disabled state. There are a few other nice features as well. The button can display text or a graphic, or both. It can optionally apply an etched effect to its content. The effect is similar to the one Jasper shows in a recent blog post.
Clicking on the disable check box will disable both the etched button and the normal Caspian button. You can also compare their over and pressed animations to verify that they are a close match. This control shows that it is possible to match the look and feel of the Caspian controls very closely by simply using some of the classes that are provided with the standard JavaFX runtime.

P.S.

Knock, knock. Who's there? Yewer. Yewer who? Yewer afraid I was going to tell 100 knock-knock jokes weren't you!

Kids + Robots = FUN!

2009-12-02T19:42:00.000-08:00

Every year from August to December, somewhere between 90 and 99.9 percent of my free time is taken up as a volunteer helping to organize the Poudre Qualifier, a regional FIRST LEGO League robotics tournament. FIRST LEGO League (or FLL) is a robotics competition for teams of kids from 9 to 15 years old. At the Poudre Qualifier, we host over 300 kids on 48 teams. These kids have spent the last 2 months (or more) building a robot using a LEGO MindStorms robotics kit and creating a research project. Their robot will try to do as many missions as possible on a 8-foot by 4-foot playing field in two and a half minutes.

Of all of the FIRST (For Inspiration and Recognition of Science and Technology) robotics competitions, FLL is unique in that the robot is completely autonomous. It must be smart enough to go out and accomplish its missions and return to base all on its own. If the kids have to rescue the robot out on the table they incur a penalty. Here is a video of a robot doing its thing during a past competition. The kids also do a research project based on the theme of that year's competition. Recent themes have included nanotechnology, energy, and transportation. At the tournaments, a team presents their research project to a panel of experts. Teams are also judged on a technical interview, where they answer questions about their robot's design, construction, and programming; as well as a teamwork exercise to test their ability to solve problems as a team.

With well over 100,000 kids on over 15,000 teams all over the world, FLL is a terrific program for getting young people interested in science and technology in an exciting and fun way. By talking to and learning from experts, kids find out that they can use science and technology to make a positive difference in their world. They also learn many valuable life skills for a future engineer or scientist: teamwork, public speaking, being interviewed, working and performing under the pressure of deadlines, and most of all, how to compete while treating teammates and opponents with respect and courtesy. That is a concept called Gracious Professionalism and it is the core value of FIRST.

What FIRST really needs is volunteers who want to share their passion for science and technology with a new generation of enthusiasts. So my request to you, dear reader, is to find a FIRST event near you and volunteer! Be a referee, a judge, a coach... whatever you want. Just get involved! It will only cost you a few hours or a day, and I guarantee that you will have an amazing time. All of the FIRST events are free and open to the public, so you can also come out and watch these kids having a great time solving difficult problems. If you live here in Colorado, we have the state championship tournament coming up. Information can be found here. And by the way, more photos from our tournament can be found here.

JavaFX Interview

2009-10-02T19:51:00.001-07:00

The folks at Sun were kind enough to ask me to visit with them about one of my favorite subjects: JavaFX.

Check it out if you're so inclined.