Senistive touchpads and Ubuntu

Last fall Meetup furnished me with a ThinkPad X1 Carbon. I was excited about this model because, as much as I love the x201 I use at home, the X1 Carbon is an all-new machine that finally starts a new chapter in the legendary laptop’s design. As I said back then:

It’s unfortunate that Lenovo like most companies, when they hit on a winning hardware design (or buy one), will just tack on a few bells and whistles year after year instead of, you know, refining the design.

But no longer! Not only is the phone jack (!??!) gone, they’ve given up ethernet, VGA, and (I think… I’m not really an expert on this stuff…) the “PC Card” slot. There’s also no removable battery.

In other words they made a number of difficult tradeoffs, very much following in the footsteps of tradeoffs that Apple made years ago for the Air and for the same reasons: to innovate in design. But unlike most other companies following in the Air’s footsteps, Lenovo actually did innovate. Instead of yet another slippery metal or faux-metal case, the Carbon has grippy black plastic that looks distinguished and feels great.

Here are some X1 Carbons poorly composited with an enormous pencil.

Thinkpads X1 Carbon, giant pencil

Sensitive touchpads and Ubuntu

But this post’s title promises information about Ubuntu and I hope that googlers do indeed land here to find it. Because I had this laptop for 8 months before I spent a weekend day figuring out how to make the large super-sensitive touchpad work well with Ubuntu.

Under the default configuration it was just not possible for me to use tap-to-click, as I prefer, or even press-to-click. In both cases the cursor would jump right as the click registered. (i.e. the worst possible time.) So instead of clicking the coordinates I had painstakingly positioned the cursor above, I would be clicking some other dumb place and often as not miss the area defined for whatever action I was trying to take.

I just couldn’t use the big fancy touchpad much at all, and stuck with the trackpoint. What a shame.

Anyway, here’s my new config, the comments at the top tell you how to make it take effect. I keep the file under my home directory and softlink to where the system will read it. I’m pretty happy with this config. It’s not 100% perfect and I’ll probably be tweaking it until the day I die, but at least now I can use my touchpad without despair.

# softlink this file into:
# /usr/share/X11/xorg.conf.d

# and prevent the settings app from overwriting our settings:
# gsettings set org.gnome.settings-daemon.plugins.mouse active false


Section "InputClass"
    Identifier "nathan touchpad catchall"
    MatchIsTouchpad "on"
    MatchDevicePath "/dev/input/event*"
    Driver "synaptics"

    # three fingers for the middle button
    Option "TapButton3" "2"
    # drag lock
    Option "LockedDrags" "1"
    # accurate tap-to-click!
    Option "FingerLow" "50"
    Option "FingerHigh" "55"

    # prevents too many intentional clicks
    Option "PalmDetect" "0"

    # "natural" vertical and horizontal scrolling
    Option "VertTwoFingerScroll" "1"
    Option "VertScrollDelta" "-75"
    Option "HorizTwoFingerScroll" "1"
    Option "HorizScrollDelta" "-75"

    Option "MinSpeed" "1"
    Option "MaxSpeed" "1"

    Option "AccelerationProfile" "2"
    Option "ConstantDeceleration" "4"
EndSection

I hope this is helpful. I assume it is at least a step in the right direction for other laptops with big, sensitive touchpads.

For home use I’m getting antsy to replace my x201, as I am tiring of its tiny touchpad, paltry number of pixels, and general non-ultraness. Unless Lenovo makes a smaller version of the X1 Carbon I may have to jump ship for the Dell XPS 13 of all things. But something is telling me to wait a bit longer.

[Ubuntu] [ThinkPad] [Touchpad] [Trackpad] [Linux]



1 note

implicit.ly: dispatch 0.10.0

implicitly-notes:

scala.concurrent.Future

From this release forward Dispatch uses the standard Future interface that was introduced in Scala 2.10 and backported for Scala 2.9.3. This required some breaking changes in the API, but the migration is straightforward.

Imports

The shortest import is now this: 

import...

Sooooooooooo glad that’s done.

This post was reblogged from implicit.ly.



17 notes

Blake Matheny: Eliminating Duplicate Requests

mobocracy:

If you’re building a backend service and can avoid the problem of serving duplicate requests, that’s a good thing. A duplicate is defined in this case as: if two requests R1 and R2 both have a response r_1, they are duplicates. Eliminating duplicates avoids doing unnecessary additional work.

At…

This post was reblogged from Blake Matheny.



2 notes

Making Meetup: Measuring Scala 2.10

makingmeetup:

We upgraded from Scala 2.9.1-1 to 2.10.0 and it made some stuff faster.

Upper bound of response times

@softprops did the 2.10 upgrade in a branch a few weeks back with the minimal code changes it required. We were surprised at the time to see some improvements in our benchmarks. I was eager to see if those translated…

This post was reblogged from Making Meetup.

[Scala] [Performance] [2.10]



1 note
Here’s @avibryant engaging in some hand waving about approximate collections, #nescala day 1

Here’s @avibryant engaging in some hand waving about approximate collections, #nescala day 1



1 note

Drawing a Circle on a Map

mlcastle:

Here’s the code for how to draw a circle with a fixed radius on a map, using Google’s new Android Maps v2 API (assuming you are willing to live with the imprecision of doing calculations on a spherical Earth rather than the WGS84 ellipsoid):

Sphereist.

This post was reblogged from mlcastle.

[Android] [Java]



1 note

Participatory Conferencing

We’re less than a week from the Northeast Scala Symposium, and the few remaining RSVPs spots (out of three hundred this year) are dwindling.

The symposium was born as a gathering of the Scala meetups of New York, Boston, and Philadelphia. We simply took the planning and budgeting processes of our meetups and scaled them up. Which is to say, we didn’t do much planning or budgeting at all. We held the first nescala in one of our usual meetup space and we selected speakers with a voting process open to everyone who RSVP’d. This not only seemed fair, it saved us the task of trying to anticipate everyone else’s preferences.

This shooting-from-the-hip style of organizing has worked well for us organizers and, as far as I tell, for the attendees. Or rather, participants. Everyone at the gathering—not just the esteemed speakers—must contribute for it to be special. Otherwise we could all stay at home and watch the same dudes talking on youtube.

Each year nescala has grown in size more or less on its own. We haven’t made growth a priority, but it is gratifying and it’s got to be good for the Scala community that a regional conference is growing.

The greater the number of participants in nescala, the more people who have to be registered, fed, cleaned up after, and—well—taken care of. I would love it if we could do this as a group, but you have to remember that this is a conference by and for programmers. Nobody is going to cut short a conversation about the pros and cons of iteratees for something as mundane as disposing of paper plates with pizza crusts on them.

Meetup organizers excel at throwing away paper plates, but as the conference grows there just aren’t enough of us to keep up. So we’ve done the only rational thing and hired people to do this for us. And it works out: as the conference grows we get $50 from more people and we also get more offers of sponsorship.

But there is one side effect of growth I’m constantly on guard against: commoditization of the experience. The more paid staff there are helping make the day a success, the more people will confuse the organizers with paid staff. The more they will see a customer-service relationship where there is none. The less they will be active participants in the symposium, and the more they may taint the experience of others—including, if I may be selfish, the organizers.

We don’t make money off of nescala and have no reason to. For a living we write software, like you. For a hobby we bring people together, and the payback is in seeing others participate actively in the conference. Watching people help each other. It’s as simple as that.

See you on Friday.

[Scala] [nescala] [Conferences] [Programming]

hvesalai/scala-mode2 · GitHub

Trying this out this new emacs mode for Scala. So far, so good.



2 notes

implicit.ly: dispatch 0.9.3

implicitly-notes:

Retry on application-defined failure

The new dispatch.retry package provides support for retrying requests that end in failure. Failure can be defined in terms of Either with a Left, Option with a None, or any Success.predicate defined by the application. 

def remoteProcedure:...

It’s a big one.

This post was reblogged from implicit.ly.



3 notes

Why I won’t depend on your pre-release software

I’m sure your pre-release software is more fun than heroin, but experience has taught me to consider it off-limits.

It’s for your own good.

Trust me, you don’t want me to depend on your unfinished work. Do you know what will happen if I do that? I can tell you, because I’ve seen it many times before.

Excitement about an upcoming release is contagious. It spreads through user communities, with little correlation to the actual release schedule. For example, at a conference there is naturally great interest in what’s coming next. Out with the old, in with the not-quite-here-yet! Attendees are often left with the impression that the good things are just a few months away, whatever the schedule says or doesn’t say.

So if I’m working on a related project, why not build for the next big thing that seems to be around the corner instead of wasting time on “throwaway code” built for last year’s big thing? My educated guess could be that the next release is about 3 months away. If I start now I could have my release ready to go in tandem with yours.

But skip ahead to 6 months later. My guess was wrong and your software is still not released. In the mean time I may have helped you find some bugs or identify unworkable interfaces. But for the most part, my interests have been to pressure you in two conflicting ways: prioritize the bugs and feature gaps that matter to me, and release this damn thing already. In other words, I have been a bad influence.

However many people you have lured onto your pre-release crazytrain, they’ll have their own special demands. You may try to please all of them, but this will only delay your release further. In the end, all crazytrain passengers are unhappy. And crazy.

There’s just no better way to convert your biggest fans into loudmouthed grumpy-pants than inviting them to upgrade to your “snapshot”.

It’s for my own good.

Programming is uncertain enough without importing the uncertainties of your unreleased software into mine.

I spend some time contributing to open source software, and I would like to spend it as efficiently as possible. The more time I spend diagnosing build problems, broken interfaces, and buggy libraries, the less I want to spend at all. If I’m not careful this cycle will reach an equilibrium state of me contributing nothing.

It’s also bad for my projects. In the hypothetical scenario where I expected your release three months ago, I’ve split my efforts between a maintenance branch and a cool-new-features-branch to be released on a schedule that is outside my control. As a result nobody can benefit from my work and I can’t even tell them when they can.

So instead of doing that, consistently and for a number of years now I just haven’t built anything with pre-release software. I’ll use a beta on occasion if I have reason to believe the interface is stable and if the beta shares distribution channels and build characteristics with releases. In other words, I won’t work with anything that that would impede me releasing my own work today.

As a result I can appreciate your final software releases without suffering the battle scars, the bitter arguments, and inevitable disappointments it took to get there. Not that I’m lazy: I walk that same road in my personal projects. I release my software, and people start to use it Yours is developed over a longer time and released whenever, without holding up mine or those that depend on mine. It’s pretty cool.

You see, non-blocking behavior is useful at this scale, too.

Release early and often.

Far be it from me to tell you how to manage your project, but the easiest way to slip into a pre-release coma is to corrupt naturally arising release cycles—the heartbeat of your software—with marketing. This is not 1995 and you are not Microsoft.

All I need is a versioned release that does what it says and doesn’t take my build process into a new circle of hell. When you have that, you can “ship” it.

See you at the next release!

[Software] [Process] [Open Source] [Free Software]

Page 1 of 47

}