github lens — now with previews

After reading Michael Hall’s blog about adding Unity Previews to Singlet, I knew it was something I needed to add to my singlet lenses.  The most obvious choice to me was allowing users to git clone a GitHub repo from the Preview.  After a couple days of experimenting, I finally figured out what to do and how to do it.  Instead of git cloning repos into any random directory, I had the lens search for a gconf key for your “Projects Directory”, where you would want to git clone projects to.  (In my case, ~/Projects).  That gconf key is found at /app/unity-lens-github/project-dir.  If you don’t supply a directory, it will default to your home directory.

If you search @username, it will use the users gravatar as an image

To get some feedback for the user, I decided to run git clone in a newly opened gnome-terminal, as well as to ensure no hiccups happened along the way.

Github Lens Previews from chris wayne on Vimeo.

The lens is again available in the Scopes Packagers PPA. To upgrade simply run apt-get update && apt-get upgrade. To install, run:

 

Note that this update will only be available for 12.10 users, and you will need quantal-backports enabled to get the updated version of python-unity-singlet.

Posted in Uncategorized Tagged , , , .

writing good bugs for Ubuntu on nexus 7

Now that Ubuntu is up and running on the Google Nexus 7 tablet, the community has become very active, logging bugs, asking questions on Ask Ubuntu, and trying to help out with the project. This level of community involvement is absolutely fantastic, and we’d love for it to keep up, as this will help make Ubuntu better for everyone. One area I’d like to focus on (as a QA person) is bug logging. A good bug report is instrumental in getting your bug fixed. An informative, well-written bug will always garner more attention than a simple “Onboard sucks, please fix it.” In this post, I’m going to go over what people will be looking for in a bug report, and walk through how to write a concise, informative, helpful bug report.  An example of a well-formed bug report can be found here.  If you have never logged a bug before, I would also suggest reading through this wiki page.

Where does the bug go?
Many of the bugs filed against ubuntu-nexus7 are valid bugs on other platforms as well. Due to this, we need to make sure that the bugs are logged to their respective upstreams. This will allow for the right people to find and fix the bugs, and for the fixes to make it into the Upstreams, meaning the fix will be available for everyone. It is sometimes obvious what the correct upstream package would be, although sometimes its not so simple. For example, if you are logging a bug against the on-screen keyboard, it should be logged against ‘onboard’. A kernel bug will be logged against ‘linux’, a Unity bug against ‘unity’ and so on. If there is a case in which you are unsure of the upstream, it’s okay to log the bug to the ubuntu-nexus7 project. We will do our best to find the upstream and make them aware.

If you do know the upstream, please log the bug using ubuntu-bug. This is as simple as running ubuntu-bug <package-name>. This will auotmatically grab all of the relevant logs and information, making it easier to log a good bug. One thing to make sure of is once the bug is logged in launchpad, make sure to make it ‘Also Affect’ the ubuntu-nexus7 project. To do this, open the bug in launchpad, and find the “(+) Also affects project” button and when prompted, input ‘ubuntu-nexus7′ as the project.

What should the bug contain?

A good bug will contain 6 essential pieces.

  1.  A good title. A good title describes the exact problem succinctly and easily. An example of a good bug title is “When in portrait mode, mouse movement glitches rightward intermittently”. Notice the title goes into specifics about exactly what happens in the bug. This title is *much* more useful than a simple “Mouse doesn’t work right when screen rotated”.
  2. A brief summary.  It is important to keep this brief.  With a good enough title, this can be just 1 or 2 sentences long.  If the bug is complicated, this can obviously be quite important.
  3. Steps to reproduce.  Steps to reproduce make the job of a bug triager or developer *much* easier.  Instead of wasting time figuring out how to reproduce the bug, they can get right to trying to fix it.  Try to step through exactly what happened to cause the bug, something that will show the bug reliably (i.e., reproduces the bug 100% if possible).  These should be clear and concise.  A good example could be: 1) Run /usr/bin/xrotate in terminal 2) Click and hold titlebar of window 3) Try to drag the window down
  4. Expected Results.  Describe here what you would expect to happen when you follow the steps to reproduce.  In the above example, an adequate expected result could be as simple as “Expected the window to drag down smoothly”
  5. Actual results. Describe what happens instead of the expected results.  Again with the above example, this could be something along the lines of “While dragging the window down, the window seems to jump around randomly.”
  6. Logs! This will usually be automatically taken care of if ubuntu-bug is used to log the bug.  If not using ubuntu-bug, it is very helpful to attach logs to the bug.  The most often needed logs are /var/log/syslog, dmesg, or /var/log/kern.log
What if I don’t have all of the needed info?
 If you do not have all of the info referenced above, that’s okay.  A bug that requires work is still better than no bug at all.

Posted in QA Tagged , , .

GitHub lens, now in the software center!

After a couple of weeks back in forth with the nice people over at the ARB (application review board), it seems that the GitHub Lens is now finally available for all without having to go through the hassle of adding a PPA. Yes, anyone with a 12.10 install can now simply install straight from the Software Center (or even apt-get install if you’re up for it). To download from here, simply click this awesome button:

To see it on the apps site, click here

Posted in Uncategorized Tagged , .

A call for help regarding github lens

Hey guys, so it turns out I’ve got a bit of an issue. I’m trying to get the GitHub Lens into the Ubuntu Software Center, but I can’t with the current set of icons (as they are against the GitHub policies). If anyone reading this is super awesome (both as a person and as a graphic designer), any help creating an icon I can use would be fantastic. Basically, what I need is an Icon for a user item, an icon for a repo item, and a (monochrome) icon for the lens itself (to show up on the bottom bar). If anyone can help with this, we can get the github lens into the software center, and all be awesome

Turns out, this icon is not ok:

Posted in Uncategorized Tagged , .

bring on uds

I’m in Copenhagen, eagerly waiting the start of UDS (Ubuntu Developer Summit).  This will be the 4th UDS I’ve attended in person, and the 7th since I’ve started working at Canonical.  To be honest, each UDS is more and more exciting for me, as I get my feet in more doors around the community and at Canonical, I get more and more excited about what we’re all doing here.  It’s great to see the community come together and play a real, honest role in the development of this *awesome* software.  I’m also excited since I’ll be taking a more active role in a lot more sessions than usual, mostly thanks to my work on Ubuntu Core running on the Nexus 7.

This place will be swarming with nerds tomorrow morning

I’ll also be attending/leading some sessions talking about Xpresser (my favorite python gui automation tool), and the plans we have for it in Raring Ringtal and beyond.  This should definitely be a pretty interesting couple of sessions, as I’d really like development and community participation to pick up on that front.

Something I’m also super excited about:  Steam on Linux!  There’s a lot of murmurs around Copenhagen that they’re going to announce the Public Beta here at UDS, now I just need to hope that that session doesn’t conflict with any of mine, because that would be AWESOME to see.

Long story short, if anyone out there is going to be at UDS, feel free to come over and say hi, unless you want to tell me the lenses I write suck or something.  In that case, just ignore me.

Posted in Uncategorized.

you got your ubuntu on my nexus 7

I just wanted to be one of the cool kids, and show off a Nexus 7 running Ubuntu.  Want more info?  Keep your eyes peeled this UDS!

THATS NOT ANDROID

"Man, your android looks funny"

Posted in Uncategorized.

Probably last one for awhile — unity-scope-thesaurus ready for testing

Well, my last scope was a dictionary, it seems only natural that the next one would be a thesaurus, right?  It’s building in scopes-packagers/ppa as we speak, and should be available for downloading and testing soon.  This uses the same api as the dictionary scope, but gives you a list of synonyms, as well as a list of antonyms.

Looks a bit like this

As always, testers are appreciated, any issues shoot me an email at cwayne@ubuntu.com.

To install:

 

Posted in Uncategorized Tagged , .

unity-scope-dictionary ready for testing!

So in a ever-so-slightly different bit of news, today I’m announcing a new Unity Scope, instead of a whole new Unity Lens.  This scope is a Dictionary, using the Wordnik API, which I have built into David Calle’s awesome Utilities Lens for Precise.  What this means, is that there will be no icon or anything for you to cick to define a word, you just need to type it into the Home Lens, and there you’ll find some definitions!  Right now this only really works on Precise, so if anyone’s willing to give it a try and let me know how it works for them, that’d be great!

 

Looks like this

As always, the scope can be found in the scopes packagers ppa (although this time, you’ll need the utilities lens as well).

To install:

 

 

 

Posted in Uncategorized Tagged , .

lens ideas

As you guys have probably noticed, I’ve been making a bunch of lenses lately (whether or not they’re good is obviously up to you guys).  I’ve found that it’s pretty fun to write them, and I plan on writing a quick sum-up so that people can write their own, but first, I’d like to ask if theres any lenses someone wants but hasn’t found yet.  If you think of one, leave it in the comments, and if it’s feasible, I’ll get to it!

Posted in Uncategorized.

Unity VM Lens now in Ubuntu extras (plus software center)

The first Unity lens that I wrote, about 6 months ago or so, allows you to search and start Virtualbox VM’s straight from the dash.  The reason I made this, was because in my testing for work, I had a lot of different VM’s, and got sick of waiting for VirtualBox to open to then search through my 25+ Virtual Machines.  This lens (again) is written with Singlet + Unity.  Today it got accepted into the extras archive, which means you now don’t even need to add a PPA to install it in Precise!  This also means that it will soon be found in the Ubuntu Software Center, where you can install it, and rate it!

To install is now as simple as:

Like all the other lenses, you’d have to either setsid unity or restart your computer for the changes to take effect.

(PS I know this doesn’t seem that awesome, but it’s quite cool to think someone can install something I wrote from a fresh install of 12.04 without even having to add a PPA!)

Posted in Uncategorized.