Sublime Text Comment and Next Line Shortcut

Dec 10 2015

Send to Kindle

Just a quick tip. I’ve been using Android Studio extensively, daily, for the last year and a half. One minor editing feature I’ve grown to love is the way it handles commenting lines. You have your keyboard shortcut, Ctrl-/ or Cmd-/. This toggles the comment on the current line and then moves to the next line. So if you want to comment, or uncomment a bunch of lines, you can just hit that shortcut a few times and it will move through the lines and do its thing.

When I started doing a lot more personal JS work and dove back into Sublime Text, I really missed this feature. So I figured out how to re-create it.

First, you have to make a macro. Just put your cursor at the start of a line, and choose Tools -> Record Macro. Then hit your comment shortcut. Then hit down arrow. Then go to Tools -> Stop Recording Macro and then Tools -> Save Macro.

Now you just need to hook that up to your comment toggle keyboard shortcut. Go to Preferences -> Key Bindings – User and add this line:

{ "keys": ["ctrl+/"], "command": "run_macro_file", "args": {"file": "Packages/User/comment_next_line.sublime-macro"} }

Obviously, “ctrl” is for Windows / Linux. You’ll probably want “cmd” “command” for Mac. And the “file” argument is the path to where you saved the macro you just recorded.

Send to Kindle

5 responses so far

Two Pixels

Dec 09 2015

Send to Kindle

Say you are a designer tasked with creating an image. The only specs you have are that the size of the image needs to be one pixel high and two pixels wide. Seems pretty simple, right?

Just considering RGB colors, that gives you 16,777,216 color choices for the leftmost pixel. And another 16,777,216 for the rightmost pixel. Combined, that means that for that 1×2 pixel image, there are over 281 trillion different images you can create. 281,474,976,710,656 to be exact.

If you were to generate every possible image and lay them out in a grid, it would be large enough to fill over 271 million iPhone 6 Plus screens. Or almost 68 million 4K TV screens.

Two pixels.


RGB is 16,777,216 colors per pixel. Two pixels means 16 million per pixel, multiply them to get 281,474,976,710,656 different images.

Each image is composed of two pixels, so a grid of all possible images would take up 562,949,953,421,312 pixels.

An iPhone 6 Plus resolutions is 1920×1080, or 2,073,600 pixels. Divide the grid size by that, you get 271,484,352 (and a half) iPhone 6 Plus screens to display all the images.

4K resolution is 3480×2160, or 8,294,400 pixels. So 67,871,088 (and change) 4K screens to display the grid.

Send to Kindle

One response so far

More Codes: Weave!

Oct 29 2015

Send to Kindle

Just playing around and came up with a neat little library for drawing weave patterns on a canvas.

Not a whole ton to say about it. Not sure how useful it would actually ever be to anyone except… those rare cases when… you just need a weave pattern… done in canvas. But anyway, it was fun to make, and I used QuickSettings extensively during the development to try out different parameters quickly and easily. And that gave me the ideas for several improvements to QuickSettings itself. If you could compare the code before and after the QuickSettings binding and global change handler features, you’d see how useful those are.

Anyway, check out the demo.

Send to Kindle

One response so far

Quick Settings Updates

Oct 28 2015

Send to Kindle

I’ve done some updates to QuickSettings over the last few weeks. First, I added quicksettings_minimal.css and quicksettings_minimal_dark.css style sheets, which bring everything down in size somewhat and get the range control sliders looking a bit more consistent across browsers and platforms. OK, OK, what I’m trying to say is that the whole thing looks more like good old MinimalComps. But it’s still all made with standard HTML controls and CSS.

I added a dropdown control that creates… well, a dropdown. Or an HTML Selection control, if you want to call things by their proper names.

There are now methods for setting values, changing range parameters and removing controls from the panel.

And the two most recent changes are really useful.

First, I added a setGlobalChangeHandler method. You pass a callback function to that and any time any control in the panel is changed, that callback will get called.

Secondly, I added a bunch of “bind” methods. These are analogous to the “add” methods, but rather than taking a callback function as the last argument, they take an object. When that control value changes, the property on that object that has the same name as the title you passed in will get assigned the new value of that control. Yeah… not sure that was very clear. Let’s try an example.

settings.bindBoolean("visible", false, model);

OK, so ‘model’ is an object that has a ‘visible’ property. This creates a checkbox. When the checkbox is clicked, model.visible will change to the value of the control. Simple, actually.

So these two latest changes make using the panel much more concise. You create a single model object, bind controls to properties on the model and set a global change handler. In the handler, you read the properties of the model. You can see it all in action in the binddemo.js file in the demos folder.

I’ve been using the panel myself in some personal projects, and I do really enjoy it. So the changes are coming from (my own) real world use.

Send to Kindle

Comments are off for this post

New JS Library: QuickSettings

Oct 17 2015

Send to Kindle

Let’s recall the glory days of Flash and ActionScript. Initially, ActionScript was a scripting language with built in graphics and animation capabilities. There was a simple button object, but no other high level ui controls built in to the language.


Before long though, people figured out how to code them and all kinds of UI component libraries popped up. Macromedia created their own component set, which eventually evolved into Flex.


A stumbling block with virtually every ui component set created was styling and skinning, that is, making the controls look the way you wanted them to. This involved assigning multiple bitmaps to individual controls or classes of controls, or some kind of half-baked, compiled-in pseudo-CSS, and in many cases, in order to style a control, you had to subclass it and override the rendering methods.

For the most part, ui controls are fairly simple. Until you get into lists and data grids, and calendars, they’re all pretty straightforward views that respond to input and trigger events. But the styling aspect tended to bloat these component libraries all out of proportion to their usefulness and complicate them beyond belief.


I was doing a lot of experiments with math and physics,that often involved changing parameters at run time. I needed some simple buttons and sliders and checkboxes and a few other things that I could create quickly and easily to be able to do this. But I wasn’t happy with anything out there. So I created MinimalComps.


This was my own UI component set. It was designed to be drop dead simple to use. Generally, you could create and configure any control with a single line of code. Create it, pass in the parameters and an event callback. An important aspect of them was that I totally ignored all styling considerations. I gave them what I consider was a fairly attractive minimal look, and that’s what you got. Later I added support for dark and light themes, but that’s as far as that went.


MinimalComps were not designed to build websites or enterprise applications with. They were designed as an easy and very lightweight way to add standard user interaction to some kind of experimental, art or engineering piece. And they were hugely successful. People tell me they still use them to this day. They wound up being used in games and sites and all kinds of apps. If you do a Google image search for “MinimalComps”, you’ll see a bunch of examples. They were even spotted in an Adidas video for the Megalizer app made with them.

In short, they filled a niche and even outgrew that niche.

It’s been a long time since I’ve even touched Flash, and some years since I did any recreational programming with ActionScript. I do all that stuff with JavaScript and HTML5’s Canvas now. But I’ve always missed the ease of MinimalComps in JavaScript. I know that there are a few similar libraries out there, but if you know anything about me, you know that I like to create my own tools from the ground up.

I made several attempts to port MinimalComps to JavaScript, using Canvas and custom elements to make the components. But I was never happy with the result. A big difference between HTML and Flash is that HTML does have its own UI controls built in. It didn’t feel right to reinvent the wheel.

However, going into the HTML, creating a control and configuring it, then going back into the JavaScript and getting reference to it and adding listeners was always enough of a pain that I just never did it. Instead I just tried to get by with straight up mouse or keyboard handlers that I could do in code alone. The invisible user interface. Not ideal.

Finally, I decided to try to combine the two approaches. Make a JavaScript library that creates the HTML controls for you. So you say, “give me a slider with these parameters and this callback.” And bang, it exists and it works. One line of JavaScript code.

So I did it. And with that long-winded intro, I present QuickSettings.js

I consider QuickSettings the JavaScript spiritual successor to MinimalComps. It is not anywhere near what you’d consider a port, but it fulfills many of the same original purposes. It probably won’t fulfill many of the extended purposes that MinimalComps evolved to have.

Rather than going through a long explanation of how to use them, I’ll just refer you to the github page, where the readme outlines all of the main methods.

And here’s a demo of the QuickSettings panel in use.

I’m also working on a video that will walk through the process, though honestly, it’s drop dead simple.

Send to Kindle

3 responses so far

New JS Library: grid

Aug 02 2014

Send to Kindle

I’m continuing to dig through old code and consolidate and release it.

This new library, grid, is not a CSS layout util, but draws grids of various kinds on an HTML5 Canvas. Here’s a demo of the various kinds of grids it can currently draw. Click for full size.


I could go into all the options and so forth, but it’s all pretty straightforward and you can just check the readme at the github site:

There may be some minor bugs in this or some tweaks needed. If so, just let me know, and I’ll fix it up. There’s definitely a lot of optimization that can go on here. I may experiment with creating an offscreen canvas the size of one cell, drawing one cell there, and then blitting that across the rest of the grid. We’ll see. In the meantime, it mostly works. Enjoy.

Send to Kindle

Comments are off for this post

New JS Library: Shapes

Jul 21 2014

Send to Kindle

Another week, another JS library.

Again, I’m sure there are hundreds of other libraries that add improved functionality for Canvas drawing. There’s even CreateJS, which is super powerful, creating a Flash-like display list with animation, etc. That’s cool, but it kind of becomes a framework that you need to buy into fully. My goal was not to create a new paradigm, just make the existing one a bit easier to work with.

Almost everything in the library is stuff that I’ve created before. Again, I just decided to consolidate it all into one code base, clean it all up and put it up on github. If nothing else, I won’t need to write that stuff again. And if someone else finds it useful, either as a whole, or something to borrow bits and pieces from, that’s great.

Like the shaky library from last week, shapes wraps both the Canvas and Context2D. I’ve proxied most of the existing Context2D methods to the shapes object, so you can work directly from that for 99% of what you need to do. A lot of it is obvious stuff – circles, ellipses, rounded rects, polygons, etc. But there are some unique and fun items in there as well. Explore. The demo page will give you a few ideas of what’s possible.

The source for the whole demo page is in the repo as well, so you can easily see the code that is used to create the examples.

Send to Kindle

2 responses so far

shaky Library for HTML/Canvas/JS

Jul 15 2014

Send to Kindle

A few days ago, I released my clrs color library for HTML/JS/Canvas/CSS. It’s not that I thought it was revolutionary or anything. In fact I’d be surprised if you couldn’t dig up at least a dozen other similar libraries out there. I’ve already been shown two. But it was code that I’d written myself a few times, so I consolidated it all into one place and put it on line. If nothing else, it will keep me from writing it again. And judging from the number of favorites and retweets on twitter, it seems like others thought it might be useful as well. If one person uses it and likes it, my job is done.

It’s occurred to me that I’ve written a lot of other code over the last few years that has never seen the light of day. Some has been for my Art From Code site, for other apps or experiments I’ve done, and other ideas that I’ve just messed around with and never did a damned thing with. So rather than keeping that stuff all on a hard drive somewhere, I’m slowly gathering it together, cleaning it up, rewriting some of it, and releasing it, bit by bit. Again, maybe nobody will find this stuff useful. Maybe there are other similar projects out there. But I’m going to github it so it’s in one place where I can find it, and if anyone else can possibly benefit from it, that’s just icing on the cake.

The next library I’ve just released is called “shaky”. I first did this in ActionScript years ago, and more recently in Canvas. It’s simple enough, it draws shaky lines and shapes. The problem, if you want to call it a problem, with computer drawing, is that all the lines are perfectly straight. It’s good in most cases, but sometimes you want to replicate a hand-drawn look, or just mix it up a bit and draw some jittery lines. You’ll probably never need it, but if you do, here it is:

It basically wraps the canvas and context 2d. So you can call most of the usual Canvas drawing methods like moveTo, lineTo, rect, arc, quadraticCurveTo, bezierCurveTo, and instead of drawing perfect shapes, it will draw shaky versions. I’ve also added some convenience methods like circle, ellipse, and fill and stroke versions of those, as well as setSize and clear methods. Other methods like beginPath, stroke, fill, clearRect are proxied right through to the context2d object, so you can do most of your drawing without ever accessing the context itself.

The shakiness of the drawing is utterly tweakable via two properties, segSize and shake. Any single line will be broken down into a series of short line segments. The rough length of these segments is controlled by segSize. And the shake property controls how much randomness will be applied to each segment.

The following image demonstrates these two properties interacting. Here, shake is increasing left to right, and segSize is decreasing top to bottom.

At the top left is 0 shake and a large segSize. This gives you straight lines. At the bottom right is a large shake and small segSize. This gives you lots of individual segments, each of which is randomly offset by a lot. You can crank that up even higher and get complete chaos.

But tweaked just right, somewhere in the middle, you get stuff that looks a lot like hand-drawn lines. Useful? You tell me.

Send to Kindle

Comments are off for this post

clrs: A Color Library for HTML/JS/CSS/Canvas

Jul 13 2014

Send to Kindle

As most of you know, I grew up as a programmer using Flash and ActionScript, and in the last few years have been much more into web programming, particularly with HTML’s Canvas. In general I do like Canvas a lot. It’s a different mindset than Flash, but I enjoy the challenge.

One thing that has consistently annoyed me, though, is using colors. In ActionScript, colors were 24-bit or 32-bit numbers. So they were easy to manipulate. Want RGB? 0xffcc00. Combine channels? red << 16 | green << 8 | blue. Extract a channel? red = color >> 16, green = color >> 8 & 0xff, blue = color & 0xff. Because everything is numbers, numbers, numbers, it’s super easy to create random colors, tween colors, generate colors based on any math formula, etc.

Then you get into HTML/CSS/JS/Canvas. It’s all strings. You can do named CSS color: “cornflowerblue” or hex values “#ffcc00″ and you can even do rgb/rgba: “rgb(255,128,0)” or “rgb(255,128,0,0.5)”. It looks all about as easy as ActionScript until you actually try to do it. Those rgb numbers must be integers, so if you have red, green blue values that might be floating point numbers, its:

"rgb(" + Math.round(red) + "," + Math.round(green) + "," + Math.round(blue) + ")";

GAH! You write that a few times and you want to kill someone.

So I’d usually write some kind of function that would deal with that.

function rgb(red, green, blue) {
    return "rgb(" + Math.round(red) + "," + Math.round(green) + "," + Math.round(blue) + ")";

This past week, I took it a bit further and made a little library that did that and added a bunch of other neat features as well. Introducing “clrs”:

Essentially, clrs is an object that has a bunch of methods on it. These return a color object. So you can say:

var myColor = clrs.rgb(255, 128, 0);

The color object is just an object, but its toString method returns an “rgba(…)” string concatenated as above. It turns out that if you use an object for anything that needs a color value, it will call that toString method and will get the string you set. Thus, you can use color objects anywhere you need a color value in JavaScript: = myColor;
context.fillStyle = myColor;

So now you can set colors with rgb values (floats or ints), rgba values, 24-bit numbers, strings of any kind, even hsv values. I threw in some random functions as well. Not functions that do random things, but functions that return random colors. You can even interpolate between two colors.

So that’s cool in itself, but there’s more. That color object has a bunch of other methods. So once you have a color, you can set or get any of its red, green, blue or alpha channels, or all at once. Any of the set methods are chainable, so you can say:


Another neat feature is binding. you can bind a color to a particular property of an object, say fillColor of a context2d.

myColor.bind(context, "fillStyle");

Now, whenever you change anything about that color, by calling setRed, setGreen, setRGB, etc. it will automatically update the context’s fill color with the new color.

Anyway, it’s early code. It needs to be more extensively tested. I welcome all feedback and contributions. I’d like to make it require.js compatible at some point. Any other standardization / best practice issue you see, or any methods you would like to see added, let me know, or do a pull request.

Send to Kindle

5 responses so far

New job: DreamSocket!

May 27 2014

Send to Kindle

At the beginning of March, I was laid off, along with a few hundred others, from Playdom/Disney Interactive. Due to a very generous severance package, I was able to, and in a very real sense, was required to, take a 60 day sabbatical. (Think of it as a paid vacation with full benefits.) No complaints there. I had a great time. But like all good things, it came to an end. Not that I mind working, not at all, but if I could find someone to pay me to do whatever I want for the rest of my life, I’d jump on it. I guess that’s called retirement. If so, I’m looking forward to it.

But anyway, time to move on and get back to work. While I was off, I explored several opportunities. I even went through some interview processes at some big name companies. None of those panned out, but in the long run I’m glad. I don’t think I’m a large company kind of guy. All those HR processes and red tape and forms for this, forms for that, etc. rub me the wrong way. And being a small cog in a large machine, handling some small details of some large application that someone else built years ago, is, to me, about the most mind numbing thing in the world. This was most of the work I did at Playdom. Not all, but a good deal of it. So I’m not sure why I was applying to other large companies.

Actually, I was looking into tech writer / dev support / evangelist positions for a while. But as I started actually looking for and applying for jobs, it became obvious to me that I wasn’t really sure what I wanted to do in that field. Some of the developer support positions wound up being more in the realm of tech support call center things. Nope. The tech writer jobs seemed to be largely writing API docs. Hmm… Not exactly creative either. So all in all, it’s most definitely better that none of those things worked out.

What did work out was that I was contacted by Kenny Bunch, a name I’ve known for ages, back from the old Flash community days, but not sure we ever met in person. Kenny started up a company called DreamSocket years back, at first doing lots of Flash stuff, but now mainly native mobile and web apps. We talked a lot and I was really impressed with the work they are doing and got a glimpse into some of the technology they’d developed to do things and was even more impressed. It’s a small company and one of the big draws was that the dev teams are usually a single dev or maybe a couple. In other words, I could own a project from start to finish, not just bang on Jira tickets from some massive code base that I barely understand. So after a few conversations, I got and accepted an offer and started last week.

So far, I’m honestly very excited and happy to be working here. There was a certain prestige about working at Disney – working for the Mouse – but that wears off really quickly when the work itself is not satisfying. What I’m doing now, even in the first week, is really fun. I’ve finally got a reason to buckle down and do real native Android dev. And eventually brush back up on iOS and Objective-C, though it’s only been about a year or so since I did much with that. And there will be some real web work as well. I’m not going to bash Flash, but if I never have to work with the mobile AIR publishing process again, I’ll be perfectly happy.

I’ll still be working remotely, which is nice as well. At least I’ll be on an east coast schedule. Working at Playdom, I adopted a mostly west coast schedule. I’d start working around 11:30 a.m. and go to around 7:30 p.m. Having the mornings was nice, but I also just got lazy and often accomplished nothing in the mornings. I think I’m happier being back on a tight morning schedule. I get up at 6:00 a.m., go for a run, come back, eat, walk the dog, take a shower and start work by 9:00 a.m. And I’m done in time to have dinner with my family, not at my desk.

Send to Kindle

10 responses so far

« Newer posts Older posts »