andrewsomething@ubuntu:~$

Just another Ubuntu weblog

Introducing StackBrowser (and random thoughts on the new Ubuntu SDK)

with 2 comments

StackBrowser

If you follow me on Google+, you already know about this, but it seems like it’s time to introduce this to a larger audience. Mostly an excuse to play with the new Ubuntu SDK, I’ve created StackBrowser. It allows you to explore the StackExchange network natively on Ubuntu Touch. It’s written in pure QML/ JavaScript.

Currently you can:

  • Browse and view recent questions
  • Search questions by tag
  • Browse, search, and view users

The roadmap for future releases includes a “convergence” layout (i.e tablet/desktop view) and accessing your global inbox.

StackBrowser is available in the Ubuntu Touch Software Center. It can be tested on a 13.10 Ubuntu desktop system, or on earlier releases if you have the SDK installed, by grabbing its source from Launchpad:

    bzr branch lp:stackbrowser
    cd stackbrowser
    qmlscene stackbrowser.qml

You can of course report bugs there as well.

Some random thoughts on the SDK and Ubuntu Touch apps

  • I’ve enjoyed working with Qml for the most part. It’s really quick and painless to build a nice UI. StackBrowser, admittedly not a very complex app, was built in a hour here and an hour there over the course of just a few days.
  • Though I think that I’ve still got a lot of learning to do about the “Qml way,” if such a thing exists. I guess maybe the term I’m looking for is  “declarative nature.”
  • I’d much rather write code in Python than JavaScript. Hopefully that will be possible.
  • Relatedly, it feels like once an app becomes sufficiently ambitious, you need to use C++.
  • There are some very simple things you can’t do in Qml/JS like write a file to disk.
  • There are places where there are strange holes in what you can do with Qml. For instance, you can take picturesrecord video, and play media all using pure QML. Yet, I can’t find any way to record audio with just QML. Maybe I’m missing something?
  • I’ve got an idea for a location aware app, but I’ve found the docs to be very wanting.
  • There’s a lot of great work going on in the core apps project, and it is very much a community effort.
  • The focus right now seems to be on the velocity of the development, but I’d like to see the core apps project become a more cohesive project (i.e. run more like say GNOME or KDE) and more integrated into Ubuntu governance.
  • I miss the larger collection of standard widgets available in Gtk.
  • Relate to the two above points, I’ve noticed a couple place where some core apps  have different implementations of the same thing (e.g. location selection) with different visual styles and different behaviors.
  • Maybe it’s just because most of my contributions to free software have been packaging things for Debian and Ubuntu, but the fact that people are being encouraged to bundle dependencies in click packages make me feel dirty.
  • That said, just clicking a button in QtCreator and attaching the result to a webform was extremely simple.
  • My app was available to install just a few hours after submission. Wonder how that will scale?

Wow, that was a bit stream of conscience like…

Written by andrewsomething

September 12, 2013 at 9:57 pm

Introducing Bug 2 Trello

with 2 comments

For some time now, I’ve been using Trello to organize my free software contributions. My main use is to give me a cross-project view of what I’m working on. As most of my contributions stem from packaging software for Debian and Ubuntu, I end up working on and following bugs across many different hosting projects (e.g. Launchpad, Debian’s BTS, GitHub). Each does a decent job (some better than others) of displaying and prioritizing issues within a certain project. Though a bug that is critical in a project that I’m only tangentially interested in might be a lower priority from me personally than a wishlist issue in a different project. So Trello has been extremely helpful in giving me a global view of how I should be spending my limited time across projects. Though putting information from all of these different places into Trello can be tedious…

So that’s why I created Bug 2 Trello, a Chrome extension to add bugs/issues to a Trello board.

 

 

It currently supports Launchpad, GitHub, SourceForge, Google Code, BitBucket, and Debian’s BTS. There is also support for some Bugzilla instances. This support currently requires that the JSON-RPC interface is available. It is known to work with with Wikimedia, Mozilla, KDE, Apache, and Redhat. It is known not to work with GNOME, Kernel.org, and Novell.

Bug 2 Trello is licensed under the MIT License.

Written by andrewsomething

June 13, 2013 at 7:35 pm

Posted in Bug 2 Trello

Tagged with , , ,

Introducing TypeCatcher

with 11 comments

After helping to review applications for the Ubuntu App Showdown, I had the urge to take another look at the state of quickly, Ubuntu’s quick starter for app development. So here we have TypeCatcher. It allows you to search, browse, and download Google webfonts for off-line use. You can preview fonts with adjustable size and text.

It was mostly written in one Sunday afternoon a few months back. Though I put it aside for awhile, mostly out of my inability to come up with a name for it. The delay did allow me to flesh it out a bit. For the most part I was quite happy with quickly. The templates really do get you up and running fast. Though as I’m extremely comfortable with both bzr and Debian packaging, I didn’t really employ its ability to hide those parts from users.

(As a side note, on place where quickly fell a bit short for me was renaming the project. Sometimes you just want to start hacking and then think about naming later, but quickly uses your project name in file names and classes all over the place. It would be nice to bake project renaming into its UI. There is already a bug report about this on Launchpad including a renaming script in the comments.)

After dogfooding the app writing tools, I think I’ll probably test the submission process for the Ubuntu Extras repository as well. For now though, you can install it for Ubuntu 12.10 from my PPA:

sudo add-apt-repository ppa:andrewsomething/typecatcher
sudo apt-get update && sudo apt-get install typecatcher

You can also grab the source from bzr on Launchpad:

bzr branch lp:typecatcher

 

Bugs and feature requests welcome there as well.

And of course, who doesn’t love screenshots:

 

Written by andrewsomething

November 11, 2012 at 11:00 pm

Posted in Ubuntu

Tagged with , ,

Automation with Google Apps Script

with one comment

I maintain a GCal of the Ubuntu release schedule, and I just updated it to contain the proposed schedule for the Q-series. As you can imagine, adding all those events by hand can be annoying. Luckily you can use Google App Script, which is more or less JavaScript for the Google Cloud, to automate tasks like this.

I could have probably come up with something to automate the entire process start to finish, scrapping the wiki every few days and pushing out updates. But this isn’t something that I have to do all that often, so I just wanted to write something quick and simple. Here’s what I ended up with:


var EVENT_ADDED = "EVENT_ADDED";

function sheet2cal() {
  var sheet = SpreadsheetApp.getActiveSheet();
  var startRow = 2;  // First row of data to process
  var numRows = sheet.getLastRow()-1;   // Number of rows to process
  var dataRange = sheet.getRange(startRow, 1, numRows, 5);
  var data = dataRange.getValues();
  var cal = CalendarApp.openByName("Ubuntu Release Schedule");
  for (var i = 0; i < data.length; ++i) {
    var row = data[i];
    var tstart = row[0]; 
    var title = row[1];
    var desc = row[2];
    var tstop = "";
    var eventAdded = row[4];
    if (eventAdded != EVENT_ADDED) {  // Prevents sending duplicates
      cal.createAllDayEvent(title, tstart, {description:desc});
      sheet.getRange(startRow + i, 5).setValue(EVENT_ADDED);
      SpreadsheetApp.flush();
    }
 }
}

This iterates through a spreadsheet where the first column is the event’s date, the second one is the title, and the third is the description. It also checks a fourth column to make sure the event hasn’t already been added, marking events added as it goes. It is closely based on the example of how to send emails from a spreadsheet.

To add a script like this, go to Tools > Script editor… in your spreadsheet. This will open an IDE where you can write, run, and debug your script. If you want, you can add a custom menu on your spreadsheet’s tool bar to trigger the script with something like:


function onOpen() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var menuEntries = [ {name: "Add to calendar", functionName: "sheet2cal"} ];
  ss.addMenu("Scripts", menuEntries);
}

You can also set scripts that will be triggered at specific time intervals, communicate with other services, and do things like parse JSON. This opens up a lot of possibilities.

For instance, I’m on a team that is using Trello for internal organization and task tracking. Kevin Pelgrims has a great example of integrating Trello and Google Docs to track project progress over time that I’ve started using.

Written by andrewsomething

March 11, 2012 at 7:56 pm

Posted in Ubuntu

Tagged with , , , ,

Wading upstream

with 3 comments

So I want to start making an effort to share more of the little tips, tricks, and scripts that I use in the course of Ubuntu development. Hopefully someone will find this stuff useful. On the other hand, I also hope someone will come along, look at what I use, and point out just how wrong it is and show me something simpler.

Potomac Wayside Falls Upstream

To start off with, here’s a function from my ~/.bashrc file. Gmail has an unfortunate insistence on forcing line breaks. This can be an issue when working with the Debian BTS as you need to interact with the control server through one line commands sent via email. The place where this is always the most painful for me has been in marking bugs as forwarded upstream. So I figured I’d make my life easier by just doing it on the command line:

function bts-forward () {
    if [[ "$1" == ${1//[^0-9]/} && "$2" == http* ]]; then
        echo "forwarded $1 $2" | \
        sendmail -f"$DEBEMAIL" control@bugs.debian.org;
    else
        echo "Usage: bts-forward DEBIAN_BUG UPSTREAM_URL"
    fi
    }

Written by andrewsomething

November 12, 2011 at 4:08 pm

Posted in Ubuntu

Tagged with , , ,

“Formalities are boring.”

with one comment

Old Faithful

I’ve been following the discussion around the potential switch from Banshee back to Rhythmbox for Precise, and I really don’t have all that much to add. Though I did come across an interesting post from an upstream Tomboy developer that deserves some wider attention. He argues that “upstreams would be more than happy to do a lot of stuff for Ubuntu if only Ubuntu actually let them know what they wanted in some sort of predictable fashion.”

 

Ubuntu either doesn’t know how important they’ve become, or they don’t care. Developers in upstream apps know that getting exposure in Ubuntu means an incredible influx of new users, which in turn leads to new bug reporters, which finally means new contributors. It’s well known that each of these groups is an order of magnitude smaller than the last, so making sure the user group is as big as possible is vital for an application. And because upstream knows this, they are willing to bend over backwards to accommodate Ubuntu’s wishes.

He also tells a story about Tomboy nearly being dropped last cycle due to depending on a number of libraries that the desktop team wanted to drop form the CD images. He goes on to suggest that formalizing the procedure around these sorts of things would reduce a lot of confusion and let upstreams know where they stand.

This seems entirely reasonable to me. The Banshee issue aside, it would be great if there was a formal announcement at some set point in the cycle where the targeted development goals for the platform are laid out in one place. If you follow closely this information is already announced, but it is in a trickle of different messages to the devel and desktop lists. The  idea would be to compile this information into one clear widely-publicized announcement. It would be early enough in the cycle that upstreams, derivatives, and other stake holders would have time to react. It would also make clear that any discussion before that point is just that, discussion not  decisions. The existing Feature Definition Freeze would probably make for a nice fit.

Written by andrewsomething

November 9, 2011 at 6:33 am

Posted in Ubuntu

Tagged with , ,

Fun with graphs

with one comment

For awhile now, I’ve felt like the ubuntu-motu mailing list has been a shadow of its former self. It turns out that empirical data backs up this feeling. I produced a histogram of mailinglist volume over time:

I also figured I should take a look at ubuntu-devel:

That graph raises the question what happened at the end of 2006. Of course, that was when ubuntu-devel-discuss was started:

I’m not sure what this all means, but I do find it interesting in the context of some recent discussion on the direction of the Ubuntu community.

—-

You can find the python code I used in a GitHub gist. It takes an mbox file and produces a histogram using matplotlib. It is shamelessly based off of code by Takafumi Arakaki that was designed to plot a histogram of the commit frequency of a Mercurial or Git repository by reading newline separated unix time via STDIN. I just rewrote the read_dates() function. If someone has a simpler way of doing the date conversion, I’d love to see it. What I did was a bit convoluted.

Written by andrewsomething

October 9, 2011 at 8:01 pm

Posted in Ubuntu

Tagged with , , ,

Follow

Get every new post delivered to your Inbox.