this looks like a job for... tomorrow!

Pinta Effects for Your .NET Apps

Pinta wouldn't exist today without the amazing code from the previously open source Paint.NET.  Now we've decided to pay it forward and make that same code available for other developers to easily use in their applications.

To accomplish this, we've extracted the code for all of Pinta's effects into a graphics toolkit agnostic library called Pinta.ImageManipulation and posted it up on NuGet for easy use.  This includes over 35 multi-threaded effects exposed as cancelable Tasks.

The core of Pinta.ImageManipulation is graphics toolkit agnostic and only works on arrays of BGRA bytes, but we've also included wrappers for System.Drawing (GDI+) and Cairo (GTK+).

Now that you've got all those great new holiday photos, let's see how to apply an effect to them in 5 lines of code.

Create a new project, bring up the NuGet dialog, and search for Pinta:

Select the Pinta.ImageManipulation.System.Drawing package and install it...

..which adds 2 new project references, the toolkit agnostic core and the System.Drawing wrapper.

Now we need to:
  • Load an image into System.Drawing.Bitmap
  • Wrap it into a BitmapWrapper we can pass to Pinta.
  • Create a new emboss effect.
  • Render the emboss effect to the image.
  • Save the result.
var photo = new Bitmap (@"C:\helo.png");
var photo_wrapper = new BitmapWrapper (photo);

var blur = new EmbossEffect ();
await blur.RenderAsync (photo_wrapper);

photo.Save (@"C:\helo2.png");
Resulting in:

A full list of available effects can be found here.

Pinta.ImageManipulation retains Paint.NET and Pinta's MIT X11 license, so feel free to use this in your applications.

If you want to submit new effects, send us a pull request on GitHub:


Mono for Android Portable Libraries in VS

Thanks to Scott Hanselman's recent article on .NET's support for Portable Class Libraries (PCLs), there has been some renewed interested in using them for Mono for Android.

If you try to add a reference to a compiled PCL assembly, things should work, as VS simply checks that the version of mscorlib.dll referenced is the same as the MFA project (2.0.5).  However, if you try to add a reference to a PCL project, you get this nasty dialog box:

The bad news is we don't ship any tooling for supporting these out of the box yet.  The good news is it's trivial to do it yourself!

The portable libraries are installed in .NET's Reference Assemblies folder, which is here:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0

If you explore around in that folder, you will see there are something called "Profiles" which specify the common assemblies for a given set of targets.

For example, "Profile2" targets .NET 4, Silverlight 4, and Windows Phone 7.  This is the set that matches Mono for Android best, so we want to tell Visual Studio that it's okay for Mono for Android projects to use this set as well.

This is done by files in the "SupportedFrameworks" folder, specifically:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile2\SupportedFrameworks

You can see there are already files for .NET 4, Silverlight 4, and Windows Phone 7:

In order to support Mono for Android, we just need to add a .xml file to this directory called "MonoAndroid,Version=v1.6+.xml":

The contents of the file are simply some metadata to tell Visual Studio about our target:

<?xml version="1.0" encoding="utf-8"?>
<Framework DisplayName="Mono for Android"
  MaximumVersion="*" />

Once you have this file created, restart Visual Studio, and you should be able to add references to PCL projects in Mono for Android projects!

NOTE: Last time I checked, the Mono for Android profile is not an exact match for Profile2.  There are a few rarely used methods that Mono for Android lacks, so you still have to be slightly careful about what you use.

Playing With Roslyn

As a tools guy, I've been fascinated with Roslyn ever since Microsoft previewed it. It looks like it provides lots of power for tools to consume. Now that the first CTP is out, I spent some time over the weekend playing with it.

The first thing it gives you access to is parsing source code, giving you an object model you can play with, and then letting you spit the modified source code back out. Reading source code in is easy:
var source_text = File.ReadAllText ("input.txt");

var tree = SyntaxTree.ParseCompilationUnit(source_text);
var root = (CompilationUnitSyntax)tree.Root;
Now we have an object model we can play with. We can search through the model for specific tokens and replace them with new ones, like this:
// Replace "Hello World!" with "Goodbye World!"
var output = root.GetFirstToken (p => p.Kind == SyntaxKind.StringLiteralToken);

var new_output = Syntax.StringLiteralToken ("\"Goodbye World!\"", "Goodbye World!", output.LeadingTrivia, output.TrailingTrivia);

root = root.ReplaceToken (output, new_output);
We can do source code formatting:
// Add a space in front of all open parentheses
var parens = root.DescendentTokens ().Where (p => p.Kind == SyntaxKind.OpenParenToken && p.LeadingWidth == 0);

var new_parans = parens.Select (p => p.WithLeadingTrivia (Syntax.WhitespaceTrivia (" ")));
root = root.ReplaceTokens (parens, (p, q) => p.WithLeadingTrivia (Syntax.WhitespaceTrivia (" ")));
Finally, we can do syntax highlighting:
private static void OutputNode (CompilationUnitSyntax token)
  var default_color = Console.ForegroundColor;

  foreach (var t in token.DescendentTokens ()) {
    // Make keywords blue
    if (SyntaxFacts.IsKeyword (t))
      Console.ForegroundColor = ConsoleColor.DarkCyan;

    Console.Write (t.ToString ());
    Console.ForegroundColor = default_color;
Putting this all together and running it results in:

Note the "Hello World" has changed to "Goodbye World", open parentheses now have spaces in front of them, and we colored the keywords blue with very few lines of code.

The tools guy inside of me loves playing with the API, but the Mono guy inside me has to go further and actually play with implementing the API, so the screenshot is actually running on a toy implementation of Roslyn's VB syntax tokenizer that I whipped up. I want to stress that it's just a quick hack that pretty much only parses my sample program and I know nothing about writing parsers, but it was a fun exercise.

The other nice feature of the Roslyn APIs is that it makes each compiler step independently testable, so I know I produce the same 59 syntax tokens as the MS implementation with the same leading and trailing trivia.

If you want to play with the code, it's available on GitHub:

My Naive Plan to Put America Back to Work

Disclaimer: I am a computer programmer, not an economist, politician, or even a fancy space chicken lawyer. Read at your own risk.

Where We Are

The Department of Labor recently released their unemployment figures for July. Currently we stand at 9.1% unemployment, which is roughly 13.9 million people unemployed. This is pretty much where unemployment has stagnated for about a year.

What We've Tried

We've basically tried 2 things, increasing government spending and decreasing taxes. Both were part of the "stimulus" bill passed. Of the $787 billion stimulus, $507 billion was dedicated to spending (though not all of it ended up getting spent). The other $282 billion was dedicated to tax cuts.

The stimulus bill was likely pivotal in halting the 2 year trend of unemployment going up, but didn't do much to put people back to work. One problem with increased spending and tax cuts is that they are indirect methods of creating jobs. The government buys more goods and services, hoping businesses will need to hire more workers to fulfill new demand. Cutting taxes is pretty much the same, hoping that more money in consumers' and businesses' pockets will cause them to buy more, creating new demand.

My Proposal

My proposal would be to *directly* influence private sector hiring. Instead of giving more money to consumers and businesses hoping it will influence hiring, let's flat out give businesses money for hiring employees.

I suggest that the federal government pay 50% of the cost of any additional employees a business hires for 2012, and 25% of that employee's cost for 2013.

At first glance, that sounds like that would cost our government a fortune, but it actually would be relatively cheap and effective. Let's assume the average cost of a new employee is a generous $60,000 (salary + benefits). For 2012, the government is going to pick up half that amount: $30,000. We currently spend roughly $200 billion per year in Iraq and Afghanistan, so for 1 year, let's spend that much on putting America back to work.

For $200 billion at $30,000 per employee, we could pay for creating 6.67 million new jobs, which would reduce unemployment to the normal rate of 4.8%. Naturally, this plan will cost us a $100 billion in 2013, for a total of $300 billion, which is less than 2 years of wars and less than half the cost of the stimulus.

One can also assume that the actual cost easily be much lower, as each new employee is now contributing income tax, social security tax, and medicare tax to the government, and is no longer being paid unemployment from the government.


There are several benefits to this proposal.

- First off, it is increasing private sector hiring, not public sector. The plan doesn't expand the headcount of the federal government, so we aren't creating jobs that are going to continue adding to the federal budget year after year.

- Secondly, it's not a giveaway for businesses. By requiring a 50% investment from the private sector, we are giving businesses a vested interest in creating useful, productive employees. They aren't just gorging on free labor for a limited time.

- Third, it's a temporary, limited cost to the government. 50% for year 1, 25% for year 2, 0% for year 3. Will there be businesses that lay off their new employees after the 1st or 2nd year is up? Sure, but probably not as many as you might initially think. It's not like these employees were free and now they cost 100%. Because businesses were already themselves investing in these workers, if they're worth keeping, the 25% is going to be worth it. And even if the employees get laid off, they at least spent a year or two participating in the private sector, paying taxes and growing the economy, rather than sitting around on unemployment.

- Finally, it only costs money if it's effective. If businesses don't think it's worth it to hire new employees at half cost, then the plan doesn't work, but it didn't cost us anything. However, I think there's plenty of employers who are on the fence about hiring who would jump at getting new employees at a discount.


Yes, you have to carefully craft the bill to enforce actual new jobs, not playing with numbers like firing 10 people and then rehiring them back as "new" employees. If your headcount was 50 at the end of 2011, then only headcount over 50 would be creating new jobs.

The bill would probably have to be introduced and passed rather quickly. Once the bill is introduced, people are going to freeze their hiring until the bill goes into effect. Maybe the initial headcount date is set at a date before the bill is introduced, and the 50% will be retroactive to that date.

Obviously you would need loop-hole-ologists to carefully craft a bill with the desired results, but that's one job we probably have an abundance of in DC.

Pinta 1.0 Released

After roughly 16 months of development, Pinta is proud to join the ~1% of open source projects that make it to version 1.0!

I am extremely pleased of how Pinta has turned out, and extremely grateful for everyone who sent encouragement, bug reports, patches, and translations.

Some 1.0 Links:
- Release Notes
- Downloads
- Bug Tracker
- Feature Requests

In the next month or so I'll get up a roadmap of where future Pinta development will be going. Hint: Plugins.

Thanks again to everyone who helped make this happen, and here's hoping for another great 16 months of development!

Lesson of the Week

Apparently if you want third parties (Apple App Store, Google Marketplace, MS App Store) to distribute your software for you, you shouldn't choose a license that forces requirements on distributors.

MonoDroid Progress

About 4 months ago, I worked on porting some of the Android SDK samples to run on MonoDroid. It was a soul-crushing failure. Every line of code I wrote exposed a new bug in MonoDroid which I had to wait until it got fixed to continue. Eventually I gave up on doing anything more than the absolutely trivial Hello World.

What a different story things are today!

I dusted off my unfinished Snake port, and it now works without modification.

Since I did it so long ago, there was no telling what magic I had in there to make it work on MonoDroid, so I ported another one from scratch. I grabbed the hardest sample I think they have: JetBoy. It's basically a fast-paced, Guitar Hero-esque game where you have to fire your laser to the music as each asteroid passes across the beat line.

After an afternoon of literal translation to C# (over 1k LOC), I fixed up the few Java porting issues like anonymous classes and nested classes accessing the parent class's private variables, and it *just worked*.

I think we're getting pretty close on finishing up our first release MonoDroid, and I can't wait to see what apps people write with it.

Both samples are available in our MonoDroid samples GitHub repository.