hacking | lucasr.org

Posts Tagged ‘hacking’

Cheese in The Board

April 04, 2011

Cheese in The Board

I spent a few spare hours during this week to finally implement webcam support on The Board‘s photo elements. I still need to polish the design a bit but it’s pretty nice already! Click the image above to see a video demonstrating how it works.

As you can see, I haven’t shown my face on the demo video. This is because I recorded it too late today and I would definitely have to shave—yes, I’m looking like an ogre at the moment. So, I preferred to introduce the feature using one of my daughter’s favourite toys, my pet mug, and my charming hands instead.

This feature was very simple to implement thanks to Cheese‘s library (libcheese) which recently received a lot of love from Luciana. Thanks to her and the Cheese team I was able to use Cheese’s functionalities in The Board with little hassle. The photos are saved on the location than the photos taken with the Cheese app. When you don’t explicitly write a caption before taking the photo, The Board gracefully defaults to a date and time caption—see third photo on the video.

This work is not in git master just yet because I need to get a few fixes in Cheese first. So, I’ve pushed the code to a remote branch for now. This feature should be available to testers soon—in the next development release. Stay tuned!

The Board 0.1.1

February 01, 2011

The Board 0.1.1

Here we go again. About a month ago, I made the first-ever release of The Board. Now it’s time to roll a new release with some pretty nice features and bug fixes. So, what’s new in The Board 0.1.1?

It also has a couple of important bug fixes such as 637703 and 637484. Just like 0.1.0, this is not a release for end-users. The Board is currently unstable, buggy, and often loses data. Early testers are more than welcome though—to provide general feedback and report bugs. Distro packages for 3 popular distros (Ubuntu, Fedora, and openSUSE) are coming soon—I will announce them in my blog, don’t worry. That should help early testers get started easily.

Versioning. I decided to use the classic odd-unstable/even-stable style of versioning. This is a common practice in GNOME and should be natural for most contributors in the community. In terms of milestones, this means that you’ll see a bunch of 0.1.x development releases from now on and 0.2.0 will be the first release for end-users. I honestly have no final answer as to when 0.2.0 is going to happen yet.

What’s next. I will be rolling a new development release (0.1.2) in the next few weeks—depends on the amount of spare I end up having. I’ll focus on two things: toolbars and element stacking. I’ll do a second design iteration on the toolbars with focus on scalability. In practice, this means fixing bugs like 636637 and 636634. Element stacking is the final major feature for multiple elements which I ended up moving to 0.1.2. You’ll be able to create stacks of elements in the page. I’m quite excited about this one!

Micro Commits

January 29, 2011

Branches by Andrew Storms (CC-BY-SA)

It’s been a few years since I became a full-time git user both at work and in the FLOSS projects I contribute to. I guess there’s no need to argue in favour of git at this point as it has become a sort of given on any sane software project—along with some other DVCS. I can’t really remember anymore how my life with Subversion was. Sad, I guess…

One of my favourite cultural shifts in software development brought by DVCS is the use of micro commits. JP has just blogged about it. Here are what I consider the most useful benefits of micro commits.

Tell a story. When you send one huge patch implementing a feature or fixing a bug, you’re completely hiding the incremental process through which you reached your final solution. On the other hand, a well written series of micro commits tell the reviewers the whole story of your code changes, step by step.

Discipline. If you want to tell a coherent story with your commits, you obviously need to organize them properly. Each commit should be a self-contained step towards the new feature or bug fix. Writing good patch series requires quite a bit of practice. It’s a very good exercise in terms of splitting a complex solution into a well-defined sequence of code changes—leading to more disciplined development practices.

Better code reviews. Because micro commits are, well, small, they are much easier to review because they do only one thing at a time. You get better code reviews as a consequence because the patches tend to contain no unrelated code changes.

Bisect and cherry-pick. Huge commits makes bisect and cherry-pick close to useless. And you don’t want that! Micro commits make it much easier to spot what caused a regression. Plus, they make it very easy to cherry-pick commits from one branch to another.

Git makes it utterly simple to move, split, squash, reorder, and remove commits providing the best ways to write good series of micro commits. It allows you to look like the perfect developer to the outside world by incrementally fixing your commits before submitting your patches for review. If you’re not micro-committing yet, you should.

Selection in The Board

January 26, 2011

Selected Elements

Since I started dogfooding The Board on a daily basis, it became clear to me that not having a simple way to arrange multiple elements in the page is quite annoying. If you wanted to arrange multiple elements in a specific area of the page, you’d end up having to move each element separately, one by one. Argh! This is why I decided to focus on an initial set of features targeting this specific issue for the upcoming release.

You can now select, move, align, distribute, and remove multiple elements in a page. Click on the image above to see a video demonstrating the new features. Selection can done in three ways: the usual dragging from background to start selecting a region of the page, Ctrl+clicking on elements, or using Ctrl+A to select all elements in the page.

Once more than one element is selected, a context toolbar slides in presenting all available operations for the selection. I’m following the same obviousness, clarity, and consistency principles I’ve discussed before. The available operations for any app state are always visible and easily accessible. No need to dig around to find out what to do.

As usual, feedback on the design decisions are more than welcome. So, what’s next? I’ll be fixing a few critical bugs and then roll a new release. I’ve been pestering distro guys to create packages for The Board. I’ll hopefully be announcing the next release with links to distro packages.