I’m at home now. I don’t do non-public unpaid work. So let’s blog the example I’m making for him.

Imagine we want an editor that has undo and redo capability. But the operations on the editor are all asynchronous. This implies that also undo and redo are asynchronous operations.

Dear friends and Maemoans. It is again the time for us to elect the new Community Council.

The schedule for the voting process is as follows:

• The nomination period starts next Monday, on the 1st of May 2017 and will continue until the 23rd of May 2017.
• The election starts on Thursday, on the 1st of June 2017 and will continue until the 7th of June 2017. In order for us to keep the community strong, we need to have new people with fresh ideas to carry on the torch. So, please consider volunteering for the position of Maemo Council.

  On behalf of the outgoing Community Council,

  eekkelund

As mentioned in my Working on Android post, I’ve been using a mechanical keyboard for a couple of years now. Now that I work on Flowhub from home, it was a good time to re-evaluate the whole work setup. As far as regular keyboards go, the MiniLa was nice, but I wanted something more compact and ergonomic.

Combining QFuture with QUndoCommand made a lot of sense for us. The undo and the redo methods of the QUndoCommand can also be asynchronous, of course. We wanted to use QFuture without involving threads, because our asynchronosity is done through a process and IPC, and not a thread. It’s the design mistake of QtConcurrent‘s run method, in my opinion. That meant using QFutureInterface instead (which is undocumented, but luckily public – so it’ll remain with us until at least Qt’s 6.y.z releases).

So how do we make a QUndoCommand that has a undo, and that has a redo method that returns a asynchronous QFuture<ResultType>?

We just did that, today. I’m very satisfied with the resulting API and design. It might have helped if QUndoStack would be a QUndoStack<T> and QUndoCommand would have been a QUndoCommand<T> with undo and redo’s return type being T. Just an idea for the Qt 6.y.z developers.

Yes, I'm looking for a job. :-)

These six years I've spent at Canonical have literally been flying. I enjoyed my work from the very first day, when I was assigned to the Unity 2D team, developing a lightweight desktop environment for Ubuntu, though I stayed in that team just for a few weeks. The next task, which I've been carrying on till today, has been implementing the Online Accounts feature in Ubuntu; this project has been especially dear to me, given that I got to reuse and improve much of the work we developed for the Nokia N9 phone. Seeing it being adopted also by Sailfish OS and KDE has been a major satisfaction, and a proof that we were on the right track. And indeed, porting the UI to Qt/QML for running in Unity 8, plus extending and simplifying the APIs and helping with the development of client applications has been a fantastic ride.
In the times where calm was reigning in the project, I reached out to other teams and offered help, mainly for improving the geolocation service and the webapps project.

Unfortunately, with the decision to terminate the development of Unity8 and to set aside the convergence goals, all of the above is no longer relevant for Canonical's future and I, along many other developers, have left the company.

So, here's my CV.

Given that reading is boring, here's a few pictures (and even a video!) of programs I've done, not as part of my daily work but in my spare time; though, to be honest, I do enjoy middleware and logic development (and even kernel, though I got little chances to work on that so far) more than UI development:
Imaginario on the Ubuntu phone Imaginario for your desktop (under development)
Mappero Geotagger If you wish to see my code, please have a look at my gitlab, github and launchpad accounts.

Among the problems we’ll face is that we want asynchronous APIs that are undoable and that we want to switch to read only, undoable editing, non-undoable editing and that QML doesn’t really work well with QFuture. At least not yet. We want an interface that is easy to talk with from QML. Yet we want to switch between complicated behaviors.

Perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

A lot of good things have happened to the Media Source Extensions support since my last post, almost a year ago.

The most important piece of news is that the code upstreaming has kept going forward at a slow, but steady pace. The amount of code Igalia had to port was pretty big. Calvaris (my favourite reviewer) and I considered that the regular review tools in WebKit bugzilla were not going to be enough for a good exhaustive review. Instead, we did a pre-review in GitHub using a pull request on my own repository. It was an interesting experience, because the change set was so large that it had to be (artificially) divided in smaller commits just to avoid reaching GitHub diff display limits.

394 GitHub comments later, the patches were mature enough to be submitted to bugzilla as child bugs of Bug 157314 – [GStreamer][MSE] Complete backend rework. After some comments more in bugzilla, they were finally committed during Web Engines Hackfest 2016:

Some unforeseen regressions in the layout tests appeared, but after a couple of commits more, all the mediasource WebKit tests were passing. There are also some other tests imported from W3C, but I kept them still skipped because webm support was needed for many of them. I’ll focus again on that set of tests at its due time.

Igalia is proud of having brought the MSE support up to date to WebKitGTK+. Eventually, this will improve the browser video experience for a lot of users using Epiphany and other web browsers based on that library. Here’s how it enables the usage of YouTube TV at 1080p@30fps on desktop Linux:

Our future roadmap includes bugfixing and webm/vp9+opus support. This support is important for users from countries enforcing patents on H.264. The current implementation can’t be included in distros such as Fedora for that reason.

As mentioned before, part of this upstreaming work happened during Web Engines Hackfest 2016. I’d like to thank our sponsors for having made this hackfest possible, as well as Metrological for giving upstreaming the importance it deserves.

Thank you for reading.

 

Imagine you have a duck. Imagine you have a wall. Now imagine you throw the duck with a lot of force against a wall. Duck typing means that the duck hitting the wall quacks like a duck would.

ps. Replace wall with API and duck with ugly stupid script written by an idiot. You can leave quacks.