Skip to content

13 posts with category “Code”

Problems I’ve encountered, solutions I’ve (hopefully) found, and weird itches that needed scratching

Chris Coyier on PostCSS

Chris Coyier on PostCSS:

We know that specs change. It happens all the time. Seems weird to base a syntax on a non-final spec. What happens when the spec changes? Do you change the language and let existing code break? How is that future-proof? Or support all past formats? Meaning the language isn’t really based on future CSS, it’s based on any experimental idea that was considered?

These have been exactly my thoughts since hearing about CSS post-processors. How can people honestly believe that the code they’re writing is future-proof? Sass source files certainly are prone to “spec rot”, but the CSS they generate isn’t (at least, insofar as anything can be immune to it).

On writing real CSS (again) | CSS-Tricks

One Response

Understanding GNU Screen’s hardstatus strings

My current development setup revolves mainly around Vim and GNU Screen. I use Screen only to keep sessions running between work days or in case I get disconnected, but lately I’ve been tempted to try using different windows inside Screen. In order to make this easier, I wanted one of those status lines that shows you all your windows as “tabs”.

Configuring this status line (the “hardware status line” or, as I’ll call it, “hardstatus”) is done with a single, often long string of characters in ~/.screenrc that at first can look entirely baffling:

hardstatus string "%{= KW} %H [%`] %{= Kw}|%{-} %-Lw%{= bW}%n%f %t%{-}%+Lw %=%C%a %Y-%M-%d"

Exactly.

To my dismay, almost everything I can find about hardstatus through Google are just dumps of other people’s strings, with little to no explanation about why they do what they do – it’s easy to imagine that the people who post them hardly know why they do what they do, either. GNU’s official documentation isn’t terribly helpful.

After finally deciphering a lot of what goes on in these strings, I wanted to spell it out to anybody else who might be hunting around for half a clue about this voodoo. There are (more than?) a few things I haven’t covered here, of course – truncation and conditionals, namely – but this should be enough to get you started.

Continue reading

19 Responses

HTML indent settings in Vim

Despite not agreeing with all of it, “Just Use Sublime Text” (an invective against Vim — or, more accurately, against recommending Vim to anyone who isn’t already indoctrinated by it) by Andrew Ray is an interesting read. The section dealing with indenting in particular struck a chord with me:

Paste this into an empty buffer:

<div>
<p>
<span>foo</span>
</p>
</div>

:set ft=html and then gg=G. Let me know what you get. In all seriousness, never, ever tell me what you get.

As I said in a tweet, what I got didn’t offend me too much. But many people would argue that the <span> tag should be indented inside the <p> tag. I’d probably do this myself, actually — and there have been aspects of Vim’s indenting that irk me. So I set about finding a solution.

Continue reading

Leave a Comment

Ubuntu’s Semantic Indicator Color Palette

It wasn’t until Mark Shuttleworth’s announcement of “windicators” that I learned of the rationale behind the palette of notification colors in the indicator applet. To quote:

[Windicators] would follow the same styling as Ayatana indicators: Semantically colored: with red for critical problems, orange for alerts, green for positive status changes and blue for informative states that are not the default or usual state.

This came as a real surprise given that I had (and still have) never seen a blue or orange indicator icon.

The obvious and primary objection is that four colors in a palette to convey meaning is far too many. Shuttleworth even said as late as April 1 — just four weeks before Lucid’s release — “Personally, my expectation is that green vs orange/red is as far as we want to go.” Two colors is an absolute maximum here — one for negative messages about something being broken, the other merely to notify you of something — although even one should suffice: “Something has changed; requesting your attention.”

If “orange is for alerts” and “green is for positive status changes,” then why do new IM messages turn the messaging icon green? Isn’t that an alert? What is “positive” about getting a new message? What if it’s your boss firing you? Your boyfriend breaking up with you? A spambot?

Continue reading

4 Responses

Building a Songbird Add-On: Part 0

songbird-artist-web-media-view-mockupAfter complaining about alphabetization in music libraries for — wow — almost a year, I’ve decided it’s time to do something about it.

I know very little about JavaScript and XUL, but that is going to have to change. My goal is to complete the add-on described here, an Artist Web media view, or perhaps “Constellations.”

To make the task appear less daunting, I’ve broken it up into many milestones of marginal improvements. If I follow this timeline, the plugin will be usable and released to the public as Constellations v0.1 on July 27.

Milestone ver Description Target Date Actual Date
i 0.0.1 display all artists in a vertical list 08 Jun 2009
ii 0.0.2 display most recent Last Played value for each artist 15 Jun 2009
iii 0.0.3 display total Play Count for each artist 22 Jun 2009
iv 0.0.4 vary font sizes according to total artist Play Count 29 Jun 2009
v 0.0.5 vary font colors according to total artist Play Count 6 Jul 2009
vi 0.0.6 vary font colors according to Last Played 13 Jul 2009
vii 0.0.7 arrange artist names left-to-right instead of vertically 20 Jul 2009
viii 0.1 focus first of the artist’s tracks in the playlist pane when the artist’s name is clicked 27 Jul 2009
ix 0.1.1 resize/re-color based on play frequency instead of play count 10 Aug 2009
x 0.2 options window that alternates between which variable is assigned to which font property 31 Aug 2009

I’m going to create a separate blog to track my progress on this, for several reasons:

  1. Threat of shame. If I emphasize publicly that I am going to do this, and I fail, I’ll be kind of embarrassed. Hopefully that will motivate me to actually complete the project.
  2. Geeks love proving that they’re smarter than you. If I’m having a tough time with some relatively elementary code, maybe people will mock me in the form of writing the correct code themselves. I’m certain that what I’m attempting could be done in no time flat if I’d been formally educated in things like JavaScript. Maybe the biting sarcasm of people who need to demonstrate their intelligence will show me where I’m going wrong.
  3. To encourage plagiarism. Look, I’ll admit that I’d be proud if the add-on that comes out of this bore my name. But ultimately, I don’t care. If somebody sees what I’m doing, likes it, wants it to be their own, and knows they can beat me to it, then great. At least we’ll have the add-on.

If you feel like mocking me or encouraging me you can email me at topdownjimmy@gmail.com, leave/follow comments on this post, or visit my dedicated Constellations blog to see where I’m taking this and how quickly I fail.

2 Responses