GNOME.ORG

24 hours a day, 7 days a week, 365 days per year...

January 27, 2012

Ubuntu Developer Summit Sponsorship Now Open

The Ubuntu Developer Summit (UDS) is the most important event in the Ubuntu calendar. It is where we get together to discuss, design, and plan the next version of Ubuntu; in this case the Ubuntu 12.10 release.

The next UDS takes place at The Oakland Marriott City Center, Oakland, California, USA from the 7th – 11th May 2012. You can find out more about why UDS is interesting from the perspective of a member of the community, an upstream contributor, and a vendor. We also welcome everyone to participate remotely if you can’t attend the event in person. More more details on how to get there, see this page.

At the heart of a great UDS is a diverse group of attendees who can bring their experience and expertise to the discussions. You don’t have to be technical, or be a programmer or packager to attend – UDS is open to everyone (including non-Ubuntu folks) and free to attend. We encourage everyone with an interest in Ubuntu to attend.

Sponsorship

For every UDS Canonical sponsors the hotel and accommodation of a set of community members to ensure they are free to contribute and bring value to the discussions. We have a limited budget so we can’t sponsor everyone, but we are always keen to have a capable and diverse group to sponsor:

  • We strive to support community members who are actively involved in Ubuntu and who are providing significant and sustained contributions to the Ubuntu project.
  • We always welcome Upstream contributors who are bring value to Ubuntu indirectly via active participation in their upstream project, but who are keen to see quality support for that upstream in Ubuntu.
  • Contributors are willing to actively participate not only throughout the full Ubuntu Developer Summit week, but also following with active contributions throughout the release cycle.
  • We are always keen to welcome members of the community who have never been to UDS before and are keen to participate and experience the event.
  • You don’t have to provide technical contributions to apply – if you have participated in the areas of advocacy, documentation, testing, art, design etc, you are encouraged to apply.
  • UDS is an event that encourages diversity – we welcome everyone to apply for sponsorship, irrespective of gender, race, impairment, technical expertise, or other factors.

If you are participating in the Ubuntu community, we would love you to apply for sponsorship. This is how it works:

  1. You can apply for sponsorship by following these instructions. Apologies for the different forms you need to fill in – we are going to consolidate these forms at the next UDS. The deadline for submissions is Wed 22nd February 2012 so be sure to get yours in!
  2. When the deadline is reached we will assess the applications and finalize who we will be able to sponsor.
  3. You will then receive an email outlining whether we can sponsor you or not.

Simple! I look forward to seeing your applications, and seeing many of you in Oakland!

Platforms as a side effect

What I want to talk about here is a simple statement that I believe to be true:

The best platforms are written by the people who are forced to invent them as they make a product.

Years ago I learned a bit about J2EE; never actually wrote an app using it, but enough to get a sense. I came away with the very strong impression that the people working on it were driven by committee, with managers in their respective contributing corporations telling them what to do. They weren’t the same people out in the field writing apps using it, day in and day out, under time pressure to produce as much as possible. On the other hand, from Ruby On Rails Wikipedia:

David Heinemeier Hansson extracted Ruby on Rails from his work on Basecamp, a project management tool by 37signals (now a web application company).[10]

Now, I’ve never written a Rails app either, but it’s pretty clear from the Internet which one of these wins. Another excellent example is the Amazon Web Services. Amazon had a lot of this internally because they were forced to in order to make a web shopping site before CEO Jeff Bezos made the key decision to spin it off as a platform.

And the most topical example here – GTK+ was originally spun out of the GIMP project because Motif sucked. Anyways, some food for thought. Basically if you’re one of those people in the trenches writing a platform – you should consider asking your manager to switch to writing apps for a bit. At least hopefully this blog post reminds me later that I have a few GTK+ apps that I really should get back to hacking on…


FlattrStat, a small statistic tool for Flattr

I'm a big fan of Flattr. But I find it hard to have some statistics about your things that have been flattered.

On my Flattr account, I receive flatts for both my blog and for Getting Things GNOME!. But I want to keep a clear separation. There are multiple persons now involved in GTG and they deserve part of the money (we will use that to buy beers at FOSDEM).

Also, on my own blog, I was interested to know which posts where the more successful, speaking of revenue. I knew that, so far, this post had the most clicks but I had no idea which one received the most money (for the curious, it is that one).

In order to do that, I quickly wrote FlattrStat, a python script. You need to download all the csv files from flatr, put them in a folder then run the script with "python flattrstat.py".

output of flattrstat

It will outputs the total clicks and revenues for each domain separately and, for each domain, sort all your things from the most successful to the least one.

Ideally, it should download the CSV files automatically and have a nice GUI but I don't really need that. It was for my own needs but I realize that it might be useful to someone else. So, feel free to use it or to contribute, it is under the WTFPL license.

FlattrStat on GitHub


Flattr our API Documentation

previous two weeks work on GTG


In these two weeks I continue my works on Google task syncing. In order to make it consistent with other backends, I break the authentication into three stage, add the pin request when authenticating. So in the first stage it will open the browser to ask for the allowance of syncing. Then the browser gives a code. After type the code in GTG and checking, finally the authentication succeed and the program start syncing.


Another thing I did is fix the task content cannot shown in google tasks problem. All the task content shows like <content></content>.
After that I did more tests on it and finally push my final version on launchpad.

Then after discussion with my mentor Luca, I got my next mission, which is write unity lens for GTG. This is really a bit challenge for me, because I didn't what unity lens is at the first time. After  a few days learning, now I have some basic ideas in my mind and found it very interesting. So in the next weeks I plan to start working on it.

Accessibility support in WebKit2GTK+

As Piñeiro already mentioned in some posts, last week a bunch of hackers attended the ATK/AT-SPI Hackfest 2012 here at the Igalia offices, in the lovely city of Coruña.

As the guy working on accessibility support for WebKitGTK+, I attended the hackfest to join some other great people representing different projects, such as Mozilla, Orca, AT-SPI, ATK, GTK+ and Qt. So, apart from helping with some “local” organizational details of the hackfest and taking some pictures, I spent some time hacking in WebKitGTK+’s accessibility code and participating in some discussions.

And from that dedication I managed to achieve some interesting things too, being my favorite ones a big refactoring of the a11y code in WebCore (so it’s now better organized and hence more readable and easy to hack on) and pushing my patch for enabling accessibility support in WebKit2GTK+, after going through a meticulous process of review (see the related WK bug), which started with the patch I wrote and attached back when attending to the WebKitGTK+ hackfest, as I mentioned in my previous entry in this blog.

Yeah, I know that some weeks have already passed since then and so perhaps you’re thinking this could have been done faster… but I’ve spent some weeks on holidays in Barcelona in December (pictures here!) and so I wouldn’t have much time before January to devote to this task. However, the patch got integrated faster than what I would expect when I proposed the first version of it, so I’m quite satisfied and happy anyway just by being able to announce this at this moment. Hope you share my joy :-)

So, what does this mean from the point of view of accessibility in GNOME? Well, that’s an easy question to answer: from now on, every browser that uses WebKit2GTK+ will be as much accessible as those using the previous version of WebKitGTK+, and this is definitely a good thing. Of course, I’m certain there will be bugs in this specific part that will need fixing (as it always happens), but for the time being this achievement means “yet another thing less” preventing us from pushing for upgrading some applications to switch to WebKit2GTK+, such as devhelp (some ongoing work already done, as my mate Carlos announced yesterday), yelpliferea… and the mighty Epiphany browser, which is rocking more and more ech day that goes by.

Last, I’d like to share with you an screenshot showing this new stuff, but as I am a little bit tired of always using Minibrowser (that small browser we use for testing WebKit2), so I decided to try instead that new branch Carlos recently pushed for devhelp, so you could check that what I mentioned before is actually true.

So here you have it (along with a couple of additions done with Gimp):

As you can see, devhelp is running and Accerciser is showing the full hierarchy of accessible objects associated to the application, starting in the UI process (GTK+ world) and continuing in the Web process, where all the accessible objects from the WebKitGTK+ world are being exposed. As I explained in a previous post, the magic making possible the connection between the two process is done by means of the AtkSocket and the AtkPlug classes, also represented in the screenshot attached above.

So, that’s it.

Losing Planet GNOME Feed

Looks like I'll be losing my Planet GNOME feed in the next few weeks based on the new policy changes. I'll still be blogging at the same frequency, but you'll have to pick up the feed from Blogspot. I've greatly enjoyed the interaction with all of you and hope that it continues.

Wacom tablets in GNOME 3.4

Working from designs.


The cool stuff first

Cosimo Cecchi presents the updated Wacom settings

Go to YouTube directly if you can't see the video here.

A new arrival

As mentioned by Cosimo, we have a new library to help us implement the settings you saw: libwacom.

libwacom is there to give us metadata about tablets, whether or not they are connected to your system, the list of styli it supports, as well as information about the styli themselves. As you can see from the UI, it's pretty important that we know:

  • whether the tablet is builtin (so we know whether you can calibrate it)
  • which form factor it has
  • the list of styli it supports
  • for each stylus, its full name, the number of buttons, what it looks like
In the past, all this information was only available within the drivers (as comments), exported in different ways (sysfs attributes), non-machine readable in public documentation, or, worst of all, hidden in Wacom's internal drivers for OS X or Windows.

So if you have a Wacom tablet, send us a definition file for your tablet, so you can configure it with the impression that the software actually knows about your device.

Where's that configuration again

After knowing what each tablet had to offer, we had to have a way to match the definitions to XInput devices, assign settings per-tablet, and importantly, switch stylus configuration when the user switches stylus. This is done using the new GsdWacomDevice and GsdWacomStylus objects, shared between gnome-settings-daemon (which will apply the configuration) and gnome-control-center (which will set the configuration).

This also means we have a few debugging applications, such as list-wacom in gnome-settings-daemon, to show you the attached GsdWacomDevices, or test-wacom in gnome-control-center, to test display of particular tablets if you don't own them (this is the place where I spend a lot of time).

What's next

Peter Hutterer, my input buddy at Red Hat, who made the original Wacom panel for GNOME 3.2, and the first version of libwacom, is currently spending a lot of time on Multi-Touch, and fixing bugs I report in the Wacom driver.

Jason Gerecke, from Wacom, who did most of the initial work on calibration support, is working on the related display-mapping. This will allow choosing whether a tablet's working area is the whole desktop, or a single monitor when in multiple monitors are used.

For my part, after fixing the layout bugs that so annoy me in the settings panel, I'll be starting work on tablet button mapping. I look forward to making the LEDs on the tablet match up with the selected keyboard shortcut!

Many thanks to Cosimo and Monty for helping out with presenting the work, and doing the video.

Online Glom: More Translation

Online Glom’s standard UI strings are now translated too, instead of just the strings that are in the .glom files. I added some initial translation files (mentioned here too) but I need people to translate them, please. Feel free to just email the file to me. I am tempted to add them to the desktop UI’s translations so I can copy them across.

I also changed it from using a lang= token in the URL to using GWT’s regular locale= query value, re-simplifying much of my previous Online Glom code to support translations.

Now that I see how each new translation adds another set of gwt-java-to-javascript permutations to the already-slow build, so it now builds 41 permutations, I might switch later from the Constants to the Messages technique for GWT translation, because I don’t think that string lookup will be a big performance problem.

Apply for your GNOME membership!

Many of you have probably already seen Alberto’s post that Planet GNOME will only include members going forward.

I wanted to take the time to urge all of you who have been putting it off or have been unsure – now’s the time to apply for membership!. It may seem intimidating (I actually put off applying for membership myself until I was already Executive Director – shameful!) but all kinds of contributions to GNOME can count towards membership and you don’t need to be a maintainer or super hacker. The rules say:

Any person who has made non-trivial contributions to the GNOME project and who submits a proper application to the Membership Committee will be approved for membership. A non-trivial contribution is any activity which contributes to the development of the project at a level significantly above that expected of a normal user or fan of GNOME.

Examples of non-trivial contributions include hacking, bugfixing, extensive testing, design, documentation, translation, administration or maintenance of project-wide resources, giving GNOME talks at conferences and community coordination such as bugzilla or release management. Any activity, such as advocacy or submitting bug reports, must substantially exceed the level of contribution expected of an ordinary user or fan of the project to qualify an individual for membership in the Foundation.

Not sure if you’ve contributed enough to get your membership already? Let’s have a mini membership hackfest! Email me or find me in IRC (I’m karenesq on GIMPNet) and I’ll try to help come up with good tasks you can work on in the next few weeks. We really have a lot going on right now that we can use help with. For example, we’re working to put together our annual report and could really use more articles and other content to make it good, which probably doesn’t require a large learning curve to get started. Being a member of the Foundation is important – not only do you get a say in who’s on the board, keep your blog on the planet, qualify for travel sponsorships and get a great @gnome.org email address, but you are showing your support for a great organization that’s making the world a better place.

Goodbye Planet GNOME

I have been a Planet GNOME blogger for almost three years now. Every post has been a pleasure. I learned some truly odd and interesting things, like how to strangely pass parameter in C and how the kernel reads shebangs.

For over two years PGO has put up with my oddities, like buying AskJeevesMom.com and writing poems about Mars, and discussing interplanetary CDNs. I never received warnings to stay on topic or to get my act together, but I can’t say I never feared it. All those fears were unfounded. The GNOME community is the most friendly and welcoming online community I know. #gnome-hackers was my home as a teenager and I don’t think I heard a dirty word once. The GNOME community simply rocks.

Knowing that my posts end up on PGO has always made blogging seem like a bold and glorious undertaking, though I felt a midget among giants. My posts end up on the same page where HP blogs and Mark Shuttleworth announces and incredible kernel hackers post all sorts of things I don’t understand, but maybe one day will.

Tonight I’m saying goodbye because in three weeks my blog will be removed from PGO and I support that decision.

You see, my blog was once about GNOME and Linux. When I was added to PGO in 2009, I was a new and passionate GNOME user who blogged about Zeitgeist. Today I use OS X and occasionally GNOME 2. I used to be passionate about FOSS, but nowadays I’m a student and I’m just happy if I eat two meals a day, preferably with a cup of fresh squeezed orange juice, assuming that isn’t over-budget, but of course it always is.

I’m not going to apply for GNOME membership because I don’t deserve it. There are great hackers who hold that badge and dedicate their time to making GNOME and the GNOME community as amazing as they are. I’m not one of them, but maybe I will be when I grow up, if I’m not too grown up already.

It has been a pleasure. If you want to follow me, subscribe to my blog’s RSS feed, or follow @aantn or nyellin on reddit, or plus me, or even just email me and ask me to send emails back occasionally (aantny at gmail). Do people still use RSS? I still use email. You can even send me an old fashioned letter with a cookie inside, but you’ll have to email me for my address and I can’t promise to eat the cookie. Okay, I wont eat it. But I’ll stay in touch and hopefully some of you will too.

So long and thanks for all the fish.

Planet GNOME: Changes in planet membership policy

Hello Planet GNOME readers and GNOME community members,

The board of directors has agreed that from now on, to be part of Planet GNOME, it is mandatory to be a member of the GNOME Foundation. In three weeks we will proceed to remove all blogs from people that are not foundation members. This policy change means a few things:

  • If your blog is in Planet GNOME and you are not a member of the GNOME Foundation, you have three weeks to become a member!
  • New planets additions from now on will take this policy into account.
  • This doesn't mean that your blog automatically gets into Planet GNOME if you are a member, the same blog review process will be applied to requests for addition.
  • There will be a slight exception with GSoC/GOPW members we will encourage them to join in the meantime, but being able to use the planet to report progress to the community is an important part of their work as interns.
  • We will delete blogs if your membership expires.

The rationale behind this new policy is simple, we want to increase the value of becoming a foundation member. Think of this as the blogging equivalent of rocking an @gnome.org e-mail address.

Foundationally yours,
the Planet GNOME editors team. 

January 26, 2012

The Case for the /usr Merge

One of the features of Fedora 17 is the /usr merge, put forward by Harald Hoyer and Kay Sievers[1]. In the time since this feature has been proposed repetitive discussions took place all over the various Free Software communities, and usually the same questions were asked: what the reasons behind this feature were, and whether it makes sense to adopt the same scheme for distribution XYZ, too.

Especially in the Non-Fedora world it appears to be socially unacceptable to actually have a look at the Fedora feature page (where many of the questions are already brought up and answered) which is very unfortunate. To improve the situation I spent some time today to summarize the reasons for the /usr merge independently. I'd hence like to direct you to this new page I put up which tries to summarize the reasons for this, with an emphasis on the compatibility point of view:

The Case for the /usr Merge

Note that even though this page is in the systemd wiki, what it covers is mostly orthogonal to systemd. systemd supports both systems with a merged /usr and with a split /usr, and the /usr merge should be interesting for non-systemd distributions as well.

Primarily I put this together to have a nice place to point all those folks who continue to write me annoyed emails, even though I am actually not even working on all of this...

Enjoy the read!

Footnotes:

[1] And not actually by me, I am just a supportive spectator and am not doing any work on it. Unfortunately some tech press folks created the false impression I was behind this. But credit where credit is due, this is all Harald's and Kay's work.

Resources in glib

Last week I landed a new feature in Glib that I’ve been wanting to do for a long time: A resource framework. Resources are things that are naturally part of an application or library, but not really normal code. For instance, our code increasingly uses xml  to describe user interfaces and menus.

Traditionally these either had to be manually inserted into the code, like so:

static const gchar *ui_info =
"<ui>"
"  <menubar name='MenuBar'>"
"    <menu action='FileMenu'>"
"      <menuitem action='Quit'/>"
"    </menu>"
"  </menubar>"
"</ui>";

Or a file was stored in /usr/share/$application/ and you had to write code to manually find and load the file, and cache it if used often. This is not a lot of code, but it can be tricky as all I/O code needs to handle errors and the external file makes it harder to make the library/app relocatable.

Instead, with resources you store your data file as plain files in your source tree, edit them with your favourite editor, with full syntax highlighting, automatic indentation, etc. Then you reference these files from a resource description file (another xml file) and use glib-compile-resources to compile these into a binary chunk which is linked into the application.

The resource framework then automatically registers all such resource bundles in a global namespace, where you can quickly look up resource data by a resource path. There are API calls to get the data as a direct pointer, as well as streaming data, but in most cases there are helper functions that let you just specify the pathname. So, for instance, you can just do:

 gtk_builder_add_from_resource (builder, "/org/gnome/appname/menu.ui", &error);

Which would handle all the work for you. And while this looks like an I/O operation its really just a hashtable lookup on linked-in data, reading from the (shared, readonly) data section in your executable, so its very fast and safe.

Additionally there are some tricks the resource compiler can do for you. For instance, you can specify that a resource should be compressed, which means that the data is stored compressed, and the APIs uncompress for you automatically. You can also specify that xml files should be pre-processed to strip away whitespace, which avoids wasting time and memory on something that is not useful at runtime.

There is also support for resource:// URIs, which means you can easily reference resource data like icons from e.g. CSS and UI files.

On Linux we use some gcc specific extensions to store the resources in separate ELF sections, which means its very easy to extract resource data from the binaries. Glib even ships with a tool that lets you do this:

$ gresource list libgtk-3.so
/org/gtk/libgtk/cursor/dnd-ask.png
/org/gtk/libgtk/cursor/dnd-copy.png
/org/gtk/libgtk/cursor/dnd-link.png
/org/gtk/libgtk/cursor/dnd-move.png
/org/gtk/libgtk/cursor/dnd-none.png
/org/gtk/libgtk/gtk-default.css
/org/gtk/libgtk/gtk-win32.css
$ gresource extract libgtk-3.so /org/gtk/libgtk/gtk-default.css
@define-color fg_color #000;
@define-color bg_color #dcdad5;
@define-color text_color #000;
...

If you’re interested in using resources in your application, check out the documentation, or look at this example commit that converts Nautilus to use resources.

Politician Market – Post Launch Writeup on Conversions, AppEngine, and Launching

On Tuesday, I released Politician Market. I brought it online, posted to Hacker News, and went to take a shower. 15 minutes later, I’m wearing a towel when I notice that Politician Market is #1 on HN and the server is melting. 12 requests per second. Gosh. I spent the next hour coding in underpants only. My roommate walked in with family members in the middle. He just pointed, said something with the word “roommate”, and walked out.

I wanted Politician Market to be entirely static site, so I used JotForm for signups. There were so many sign-ups that I crashed JotForm’s servers after only 10 minutes and had to move the sign-up form to Google Docs.

Signups and Conversions

Conversion tip: If you want to optimize sign-ups, don’t use  an external service. Sign-ups stopped almost entirely after moving to Google Docs. (I received only 40 signups after the move.) If you want to gain feedback, do place a feedback form on the homepage and you’ll get plenty of feedback.

12,000 uniques and 4 hours later, Politician Market mysteriously disappeared from the homepage and traffic started to subside. Some time before then, I had to disable the contact form entirely because I was about to overrun my JotForm quota. Despite disabling the form, people kept submitting it, often blank. (A browser bug?) At that point, I changed the form’s action to “#” and added an overlay (see below), but people kept submitting the damn form. My brother told me that he wrote me a long message in the contact form, because he was convinced that it really did get sent after all. What must you do for people to believe you?

Another conversion tip: Adding social sharing buttons seems to matter. There were 12,000 hits while we were on HN for four hours. After pg killed the submission, the long tail brought (and is still bringing) another 2k. If you add sharing buttons, make sure to include Google Plus. The break down was 259 shares on Twitter, 40 on Google Plus, and a bunch on Facebook. (For an unknown reason, Facebook wont show me the stats anymore.)

I didn’t have time to A/B test, but conversion rates seemed to rocket when I placed annoying sharing links so far up that they pushed content below the fold. I hated that, so I soon reverted the changes. (Startup idea: I wish I could run automatic A/B tests by including a javascript file that would hash the page, check with a 3rd party server to see if it changed, and provide conversion data when I’m cowboy coding. Create that and I will pay a one time $10 fee for the service.)

For absolutely no reason, I asked for phone numbers in the signup form. About 30% of all sign-ups included them.

Avoid AppEngine Like the Plague

I originally wanted to host on S3, but it wouldn’t accept my credit card so I used AppEngine and static-app-engine-hoster. Don’t do that. There is no caching and you lose all the benefits of a static site. I wasn’t expecting so many hits, so I didn’t think this through.

More on AppEngine: Deployment is easy, but payment sucks. AppEngine makes you pay per-week, so if you want to use $10 a day, you have to deposite at least $70. (Slimeballs.) AppEngine has absolutely no support for paying customers. I sent two emails about urgent issues and never heard back. Avoid AppEngine like the plague.

Publicizing

I tried publicizing Politician Market on Reddit, Slashdot, and Digg. It almost took off on Reddit, but Slashdot ignored it despite votes on the Firehose submission and Digg was a laughable waste of time. (What they say about Digg is correct: If you aren’t part of the oligarchy you might as well submit the link to /dev/null.) I emailed a few tech and political bloggers. Most of them ignored me, but some had incredibly kind words and published a link. Do have the chutzpa to email bloggers.

This is the second launch I have done. Third time ice cream. Does anyone know where that weird Israeli saying comes from?

Full Steam Ahead

Now that the tuning issues have been resolved, we have started to move more and more users over to the GNOME server. Just now we hit a new high of 108 concurrent users logged into one server.




And as promised let's see how the server is doing with the 108 users. (shots below). The answer is: excellent. Time to ramp up workstation upgrades and move more people over. There have been a few bumps in completing this project but it's been worth the effort. All City employees will be able to log in and get core software packages (Browser, authentication, word processing, image editing and more) without any license costs.





Lately, in Rygel land…

In General

I know I have been quite silent about Rygel in general lately because I was quite busy with my day job. Since Zeeshan left Nokia after the MeeGo turmoil I took over his task of bringing Rygel in good shape to form the basis for Harmattan’s DLNA functionality.

These efforts, started long ago by Zeeshan, are finally coming to a close and entering the wild. With the release of PR1.2 beta for the N950, the alert reader might have spotted the release note entry “Media sharing with DLNA compatible devices”. You can probably guess what that’s powered by ;-)

One of the goals that we’d set ourselves has already been reached. The device is UPnP certified. The DLNA compatibility is in really good shape as well.

That is one of the reasons why the upstream Rygel development looks kind of stalled. The other one is that we’ve been focusing on ironing out the rough edges with emphasis on stability. Naturally, all of the patches that resulted here have been upstreamed, either to Rygel, GUPnP or libsoup.

On the device

So what’s on the device? A more or less pristine upstream snapshot taken several commits after 0.11.3 with later patches cherry-picked and some minor adjustments to adapt ourselves to the environment, like different device details and icons.

What can it do?

It implements a M-DMS, a mobile media server, enabling you to share the media content of your phone in your home network.

In addition to the rather useless mandatory media formats defined by DLNA we have decided to include a LPCM transcoder and the necessary profiles to share all the videos and images you’re going to take or already have taken on the device.

The server runs in a strict sharing mode where only media files that conform to one of the supported DLNA profiles are shared. This is configurable and we plan to release a “tweaking app” later to help the average end user to fine-tune and undo some of the limitations that had to be done due to the DLNA guidelines.

So, to all that already can, enjoy Rygel on your mobile phone.

GStreamer Hackfest in Malaga update

Things have been going really well here at the GStreamer Hackfest in Malaga. Thanks to the help of Ara and Yaiza from Nido Malaga, we have a great venue in downtown Malaga and they have also helped us greatly with sorting out food.
We have a great group of people here and are making great progress, and by tomorrow I hope we will have screenshots of quite a few applications running with GStreamer 0.11, for instance both Rhythmbox and Jokosher for instance is already screen shootable, if not fully functional :)

GStreamer Hackfest Malaga 2012

GStreamer Hackfest Malaga 2012

Also making good progress on Transmageddon, even if the move to GObject Introspection bindings are making things a bit more complicated. Screenshot below of the progress so far.

Transmageddon at Hackfest in Malaga 2012

Transmageddon at Hackfest in Malaga 2012

Also a big thanks to Fluendo who is sponsoring the lunches at the hackfest and Collabora who is sponsoring tonight’s dinner. Ensuring that no hacker is left hungry during this hackfest.

Update: Yaiza took these photos from the hackfest

Porting devhelp to WebKit2

When MiniBrowser was ported to the new WebKit2 GTK+ API, I said we had plans to create a webkit2 branch for epiphany. And we’ll do it as soon as we have enough API, but epiphany uses most of the WebKit API so this is going to take a bit. In the meantime, we have decided to focus on other applications that use a small part of the WebKit API like devhelp, yelp, liferea, etc. Yesterday I pushed a webkit2 branch into the devhelp git repository with some initial commits that allow to use devhelp with WebKit2. Even though WebKit2 is available in the latest WebKit unstable releases, there’s a bug and public headers are not installed, so you need to build WebKit from git to be able to build the devhelp webkit2 branch. The main functionality works, but there are still some features missing that we are currently working on:

  • Policy client: used by devhelp to decide what to do with unknown content and to open links in a new tab with middle click. Martin Robinson is working on Policy Client API for WebKit2, the patches are pretty good and will be pushed soon.
  • Search: We already agreed on the new API and Sergio Villar wrote the patch that will also land soon.
  • Printing: This is not only about adding API, it requires adding support for printing in the Web process too. The main problem is that we need to show the print dialog in the UI process and render pages for printing in the Web process, so we can’t use GtkPrintOperation. We have already patches to implement basic printing support and adding initial API. These patches only work for UNIX, so patches to make it work in win32 would be really appreciated.
  • Editing commands: There’s already a patch to add cut, copy and paste API, but we are discussing the possibility to move to a more generic approach for editing commands.

And here is the mandatory screenshot, although there’s nothing special since WebKit2 changes don’t affect the UI.

Devhelp using WebKit2

Devhelp using WebKit2

We will keep updating the webkit2 branch when new API lands in WebKit until there aren’t regressions. Then we’ll focus on yelp which requires two important challenges: DOM bindings and context menu API.

Karen Sandler’s Keynote address to Linux Australia conference

 

This is the keynote address that Karen Sandler (executive director of the GNOME Foundation) recently gave to the Linux Australia conference. It goes to the heart of why software is important, and why we should all have access to the sourcecode of the products which we all use everyday.

Karen has a rare heart condition and needed a defibrulator/pacemaker. One of her first questions when talking to a cardiologist about it was ‘what does it run’ – to which he had no answer, and didn’t understand why she cared. Yet, she cared for the same reason that *everyone* should care. ‘New’ defibrulators today are openly broadcasting over wifi patient details – so that when a patient walks into his/her doctors office, they no longer have to take their pulse – its on the computer already. Seems like a nifty feature, right? But the problem is, its not just broadcasting that info in the doctors office. It’s broadcasting it 24/7. In the mall. At school. In the airport. Everywhere. And the devices have been *proven* to be hackable – that is to say, it *IS* possible to hack into them and make them give the patient a shock. Or stop working entirely. Or any number of other things.

And yet, no-one can legally look at the software. And its not even reviewed (or tested!!) by any 3rd party – not by the FDA, not by anyone at all outside of the company that makes it. They say its ‘bug free’ – but anyone who knows about computers knows that there is *no such thing* as bug-free code. No. Such. Thing.

It goes to the heart of why open source is so important today – because we use computers constantly, everyday, without even thinking about it. We no longer drive cars; we ride in computers that drive. We no longer fly in airplanes; we ride in computers that fly. We no longer vote in elections; we tell a computer how to vote *for* us. Etc. And virtually all of these computers run on proprietary software which no-one outside the company that makes it has access to, to double check its safety, its security or anything else. And most of us don’t think twice about it.

Anyhow, its a long talk (nearly an hour), but is completely worth it. Its the reason that I use, love, and support Open Source Software. Its the reason why we all should.


GStreamer 0.11 Application Porting Hackfest

I’m in the quiet town of Malaga these three days to attend the GStreamer hackfest. The goal is to port applications over to the 0.11 API which will eventually be 1.0 There’s about 18 people here, which is a good number for a hackfest.

The goal for me is to figure out everything that needs to be done to have Flumotion working with GStreamer 0.11. It looks like there is more work than expected, since some of the things we rely on haven’t been ported successfully.

Luckily back in the day we spent quite a bit of time to layer parts as best as possible so they don’t depend too much on each other. Essentially, Flumotion adds a layer on top of GStreamer where GStreamer pipelines can be run in different processes and on different machines, and be connected to each other over the network. To that end, the essential communication between elements is abstracted and wrapped inside a data protocol, so that raw bytes can be transferred from one process to another, and the other end ends up receiving those same GStreamer buffers and events.

First up, there is the GStreamer Data protocol. Its job is to serialize buffers and events into a byte stream.

Second, there is the concept of streamheaders (which is related to the DELTA_UNIT flag in GStreamer). These are buffers that always need to be send at the beginning of a new stream to be able to interpret the buffers coming after it. In 0.10, that meant that at least a GDP version of the caps needed to be in the streamheader (because the other side cannot interpret a running stream without its caps), and in more recent versions a new-segment event. These streamheaders are analogous to the new sticky event concept in 0.11 – some events, like CAPS and TAG and SEGMENT are now sticky to the pad, which means that a new element connected to that pad will always see those events to make sense of the new data it’s getting.

Third, the actual network communication is done using the multifdsink element (and an fdsrc element on the other side). This element just receives incoming buffers, keeps them on a global buffer list, and sends all of them to the various clients added to it by file descriptor. It understands about streamheaders, and makes sure clients get the right ones for wherever they end up in the buffer list. It manages the buffers, the speed of clients, the bursting behaviour, … It doesn’t require GDP at all to work – Flumotion uses this element to stream Ogg, mp3, asf, flv, webm, … to the outside world. But to send GStreamer buffers, it’s as simple as adding a gdppay before multifdsink, and a gdpdepay after fdsrc. Also, at the same level, there are tcpserversink/tcpclientsrc and tcpclientsink/tcpserversrc elements that do the same thing over a simple TCP connection.

Fourth, there is an interface between multifdsink/fdsrc and Python. We let Twisted set up the connections, and then steal the file descriptor and hand those off to multifdsink and fdsrc. This makes it very easy to set up all sorts of connections (like, say, in SSL, or just pipes) and do things to them before streaming (like, for example, authentication). But by passing the actual file descriptor, we don’t lose any performance – the low-level streaming is still done completely in C. This is a general design principle of Flumotion: use Python and Twisted for setup, teardown, and changes to the system, and where we need a lot of functionality and can sacrifice performance; but use C and GStreamer for the lower-level processor-intensive stuff, the things that happen in steady state, processing the signal.

So, there is work to do in GStreamer 0.11:

  • The GStreamer data protocol has not really been ported. gdppay/depay are still there, but don’t entirely work.
  • streamheaders in those elements will need adapting to handle sticky events.
  • multifdsink was moved to -bad and left with broken unit tests. There is now multisocketsink. But sadly it looks like GSocket isn’t meant to handle pure file descriptors (which we use in our component that records streams to disk for example)
  • 0.11 doesn’t have the traditional Python bindings. It uses gobject-introspection instead. That will need a lot of work on the Flumotion side, and ideally we would want to keep the codebase working against both 0.10 and 0.11 as we did for the 0.8->0.10 move. Apparently these days you cannot mix gi-style binding with old-style binding anymore, because they create separate class trees. I assume this also means we need to port the glib2/gtk2 reactors in Twisted to using gobject-introspection.

So, there is a lot of work to be done it looks like. Luckily Andoni arrived today too, so we can share some work.

After discussing with Wim, Tim, and Sebastien, my plan is:

  1. create a common base class for multihandlesink, and refactor multisocketsink and multifdsink as subclasses of it
  2. create g_value_transform functions to bytestreams for basic objects like Buffers and Events
  3. use these transform functions as the basis for a new version of GDP, which we’ll make typefindable this time around
  4. support sticky events
  5. ignore metadata for now, as it is not mandatory; although in the future we could let gdppay decide which metadata it wants to serialize, so the application can request to do so
  6. try multisocketsink as a transport for inside Flumotion and/or for the streaming components.
  7. In the latter case, do some stress testing – on our platform, we have pipelines with multifdsink running for months on end without crashing or leaking, sometimes going up to 10000 connections open.
  8. Make twisted reactors
  9. prototype flumotion-launch with 0.11 code by using gir

That’s probably not going to be finished over this week, but it’s a good start. Last night I started by fixing the unit tests for multifdsink, and now I started refactoring multisocketsink and multifdsink with that. I’ll first try and make unit tests for multisocketsink though, to verify that I’m refactoring properly.

Thank You EFF

For the last 8 years I’ve donated to the Electronic Frontier Foundation, one of my favorite non-profit organizations.  The EFF continues to fight to protect our freedoms in the digital world – and for that I’m grateful.

January 25, 2012

2012-01-25: Wednesday

  • Chewed mail, quick call with Vojtech, then Charles. Finally got around to submitting a LinuxTag paper or two. Lunch. More mail, patch pieces.
  • J. out for Rosemary's leaving pizza party. Up extremely late poking android's wedging on ANativeWindow_lock - sadly the debugger gives no trace: an thread un-attached to the VM ?

Nominated for OpenSource.com People’s Choice Award

Based on my series of MPL posts for opensource.com, I’ve been nominated for a “people’s choice award” as a top contributor to opensource.com. It’s a nice little honor. That said, there are lots of folks on the list of nominees who have written and thought far more than I have this year- so you should go check out the list and vote for one of them instead :)

Interview with Arun Raghavan about PulseAudio

With all the talk generated by Arun Raghavans blog post comparing PulseAudio and Audioflinger I thought it would be good to follow up with an interview with Arun about the latest developments in PulseAudio and the way forward for the project. You can find the PulseAudio interview here. I also made a new page listing all the Collabora developer interviews done so far. Enjoy :)

Compositing in Maliit

Introduction

The development for Maliit, a cross-platform text input method framework for mobile devices, until 0.8 was mainly based on requirements for MeeGo Harmattan, the operating system on the Nokia N9. Harmattan applications are fullscreen. Animation of orientation changes is, together with other animations, done by the application. This is in contrast to Maemo Fremantle on the Nokia N900, were such animations were done by the X window manager.
When the virtual keyboard is up, the application remains fully interactive. Instead of using a proxy text entry, the text input goes directly to the application’s focused text entry. Showing the virtual keyboard should not change the layout, nor can it affect the application’s stability. The virtual keyboard runs in a separate process (maliit-server). But it requires animations showing, hiding and switching between different language layouts. In addition it should be possible to display overlays for word candidates or extended keys.
To satisfy these requirements the virtual keyboard window is shown in fullscreen mode. The visible parts of the virtual keyboard cover the bottom area of the application and screen, whereas the remaining area of the toplevel window is seemingly translucent. This keeps most of the application visible, including the focused text entry, which will render any text input immediately. It is also possible to pan the application’s page contents and to switch focus to another text entry, or remove focus altogether.

Shaped input region

To pass input events through to the application we use the shape extension of the X server and XFixesSetWindowShapeRegion to set the input shape of the MPassThruWindow to the region which the virtual keyboard and overlays really occupy. The X server will deliver events inside this region to the input method, and the rest to the application window.

void MPassThruWindow::updateInputRegion()
{
	XRectangle * const xrects = convertQRectanglesToXRectangles(region.rects());
	const XserverRegion shapeRegion =
		XFixesCreateRegion(display, rects, region.rects().size());
    	XFixesSetWindowShapeRegion(display, winid, ShapeInput, 0, 0, shapeRegion); 	XFixesDestroyRegion(display, shapeRegion);
	delete[] xrects;
}

Compositing Window Manager

RGBA window with translucent background

When the window manager supports compositing, it is possible to use 32 bit translucent RGBA windows for the overlay. Mcompositor, Harmattan’s window manager, supports this feature. That is why we turned the background of the top level virtual keyboard window translucent. In Qt this can be done like:

MPassThruWindow::MPassthruWindow()
{
	setAttribute(Qt::WA_TranslucentBackground);
}

Since compositing window managers are widely available for Linux desktops and the performance is acceptable it has been the default for Maliit 0.8.

Direct rendering

Compositing Window Manager

When the active application window is fullscreen and the application features a non-translucent background (which is the case on Harmattan), then the redirection of the active window into an off-screen window and additional compositing is unnecessary. Under circumstances, this redirection cuts the frame rate in half, which was unacceptable for animations and scrolling. For that mcompositor supports direct rendering of the active window into the frame buffer.
Since in this mode the keyboard window is transparent mcompositor cannot use the direct rendering optimization. Additional the context switches between the three processes, application, keyboard and compositor results in increased latency for text input, which affects the user experience. To reduce latency we wanted to further optimize performance for Harmattan and the N9 by using direct rendering with a 16 bit window for the keyboard.

Compositing using shaped output region

Our first approach used the same technique for the in- also for the output, with the help of XFixesSetWindowShapeRegion:

void MPassThruWindow::updateInputRegion()
{
	...
    	XFixesSetWindowShapeRegion(display, winid, ShapeBounding, 0, 0, shapeRegion);
	...
}

This solution does not require a compositing window manager but made it difficult to use shadows and overlays. It also was not performing as well as expected, since there is no support for direct rendering of shaped window. A better solution had to be found.

Compositing in Maliit

Compositing in Maliit

We were able to try another approach for using direct rendering. A 16bit RGB window together with the composite and damage X extensions is used to compose the content of the application window into the background of the virtual keyboard window. Instead of using the window manager for the compositing, Maliit handles the compositing itself.
The application window is represented through MImRemoteWindow in Maliit. XCompositeNameWindowPixmap is used to get a pixmap of the application’s window content:

void MImRemoteWindow::setupPixmap()
{
	xpixmap = XCompositeNameWindowPixmap(display, winId);
	pixmap = QPixmap::fromX11Pixmap(xpixmap, QPixmap::ExplicitlyShared);
}

This pixmap is blitted into the background of a QGraphicsView:

void GraphicsView::drawBackground(QPainter *painter, const QRectF &rect)
{
        painter->drawPixmap(rect.toRect(), remoteWindow->pixmap(), rect.toRect());
}

To get notified about updates in the application window the damage extension is used:

void MImRemoteWindow::setupDamage()
{
    damage = XDamageCreate(display, winId, XDamageReportNonEmpty); 

}

On damage events there is a signal emitted, which is used to trigger a repaint.

void MImRemoteWindow::handleDamageEvent(XDamageNotifyEvent *e)
{
    XserverRegion parts = XFixesCreateRegion(display, 0, 0);
    XDamageSubtract(display, e->damage, None, parts); 

    QRegion region(convertXRegionToQRegion(parts)); 

    XFixesDestroyRegion(display, parts); 

    Q_EMIT contentUpdated(region);
}

RGB window with application content composited into the background

When handing over compositing from the the window manager to the input method process brief flicker can occur. To suppress it, mcompositor had to be patched to only map the virtual keyboard window after the application window has gotten redirected for compositing in Maliit. Additional QWidget attributes need to be set for all QWidgets in the virtual keyboard:

MPassThruWindow::MPassthruWindow()
{
	setAttribute(Qt::WA_OpaquePaintEvent);
	setAttribute(Qt::WA_NoSystemBackground);
}

In addition to improving the performance this approach also allowed to synchronize the rotation animation of the application and keyboard.
This mode is used on Harmattan and the Nokia N9 and can be activated by starting maliit-server with the -use-self-composition flag.

Plugins

Since plugins up until Maliit 0.8 are using fullscreen sized children widgets of the MPassThruWindow, their sizing and positioning depends on the toplevel window being a fullscreen window.
For compositing in Maliit to work, those widgets have to blit the application window content into their background. A QGraphicsView for example can use MAbstractInputMethodHost::background to paint the application window content as its background in QGraphicsView::drawBackground.

Conclusion

The fullscreen keyboard window approach was the proper choice for the Nokia N9 device. But on other devices, where orientation change animations are done by the compositor, or on a desktop system without a compositing window manager a non-fullscreen keyboard window could be a better choice. Unfortunately input method plugins based on Maliit 0.8 releases are tied to the fullscreen keyboard window concept and even need to take care for implementation details like the compositing in Maliit. The Maliit 0.9 series, which provide the basis for a first stable 1.0 release, should be used to find a better solution for plugins which allows different window modes and makes it easier for plugin developers by not burden them with any implementation details.

Restoring from backups

I’m currently in Málaga for the GStreamer hackfest. Hopefully, many bugs will perish. In the meantime, here’s a quick status update of stuff I’ve been doing in recent times in Pitivi.

  • Cleanup the code for gtk actions so that the code is more readable and robust, fixing 629208 in the process.
  • Cleanup the menus (again).
  • Avoid having the viewer eating the CPU while idle.
  • Fix various problems such as “Select unused clips” not working in treeview mode or reimplement removing all timeline instances of a clip when removing it from the media library.
  • With the help of Brian Grohe, merge and delete spam user accounts on the wiki. I only have to fix image uploads and the https certificate issue now.
  • Start fixing 629855; see below for details.

It turns out that pitivi was secretly writing autosave/backups of your project files (and deleted them when successfully saving/closing), but it did not actually use them. You’d have to know they exist, when they exist and where to find them, which is hardly intuitive.

So, I set out to fix this. Along the way, I ended up making the “unsaved changes” dialog more helpful. This is the result:

Then I worked on the actual dialog to prompt the user about the existence of an autosaved project file. It uses uses the same mind-blowing human-readable time formatting nekohayan technology, as you can see in the various following scenarios:

If you ignore the backup file, it will obviously be deleted when you cleanly save/close the project.

The big question is however, what we should do if the user selects to restore from backup:

  • Should we simply rename the backup file to overwrite the “old” project file and then load it? This would mean the “old” project would be lost. In theory nothing should go wrong with that…
  • If we want to be paranoid perhaps we could load the backup file as a temporary file and force the user to use “Save as” instead of a regular Save, but I’m not sure if that’s what users need. Thoughts welcome on this one, but I’d really like to have a simple solution.

January 24, 2012

2012-01-24: Tuesday

  • Up early, misc. mail chew, question processing, patch review, re-building action etc. Inched through more startup problems, Lunch.
  • Chat with Kendy, more mail cleanout. Lydia over for dinner. Up late hacking android main-loop pieces with Tor.

The HUD: Call For Testers

Today we announced the HUD that is landing in Unity. This is an awesome new feature. See Mark’s blog post, the coverage on PC Pro, and the interview with John Lea on OMG! Ubuntu!. Here is a video of the feature in action:

Can’t see it? See it here.

I wanted to point you folks at Nicholas’s blog post about how to test the HUD. You will need to be running Ubuntu 12.04 (which is still in development) to test.

We would like to encourage everyone to test so we can get this rock-solid for 12.04!

The Java ecosystem and Scala ABI versioning

On the sbt mailing list there’s a discussion of where to go with “cross versioning.” Here’s how I’ve been thinking about it.

Disclaimer

I’m a relative newcomer to the Scala community. If I push anyone’s buttons it’s not intentional. This is a personal opinion.

Summary

Two theories:

  • The largest problem created by changing ABI contracts is an explosion of combinations rather than the ABI change per se.
  • The ABI of the Scala standard library is only one of the many ABIs that can cause problems by changing. A general solution to ABI issues would help cope with ABI changes to any jar file, even those unrelated to Scala.

Proposal: rather than attacking the problem piecemeal by cross-versioning with respect to a single jar (such as the Scala library), cross-version with respect to a global universe of ABI-consistent jars.

This idea copies from the Linux world, where wide enterprise adoption has been achieved despite active hostility to a fixed ABI from the open source Linux kernel project, and relatively frequent ABI changes in userspace (for example from GTK+ 1.2, to 2.0, to 3.0). I believe there’s a sensible balance between allowing innovation and providing a stable platform for application developers.

Problem definition: finding an ABI-consistent universe

If you’re writing an application or library in Scala, you have to select a Scala ABI version; then also select an ABI version for any dependencies you use, whether they are implemented in Scala or not. For example, Play, Akka, Netty, slf4j, whatever.

Not all combinations of dependencies exist and work. For example, Play 1.2 cannot be used with Akka 1.2 because Play depends on an SBT version which depends on a different Scala version from Akka.

Due to a lack of coordination, identifying an ABI-consistent universe involves trial-and-error, and the desired set of dependencies may not exist.

Projects don’t reliably use something like semantic versioning so it can be hard to even determine which versions of a given jar have the same ABI. Worse, if you get this wrong, the JVM will complain very late in the game (often at runtime — unfortunately, there are no mechanisms on the JVM platform to encode an ABI version in a jar).

Whenever one jar in your stack changes its ABI, you have a problem. To upgrade that jar, anything which depends on it (directly or transitively) also has to be upgraded. This is a coordination problem for the community.

To see the issue on a small scale, look at what happens when a new SBT version comes out. Initially, no plugins are using the new version so you cannot upgrade to it if you’re using plugins. Later, half your plugins might be using it and half not using it: you still can’t upgrade. Eventually all the plugins move, but it takes a while. You must upgrade all your plugins at once.

Whenever a dependency, such as sbt, changes its ABI, then the universe becomes a multiverse: the ecosystem of dependencies splits. Changing the ABI of the Scala library, or any widely-used dependency such as Akka, has the same effect. The real pain arrives when many modules change their ABI, slicing and dicing the ecosystem into numerous incompatible, undocumented, and ever-changing universes.

Developers must choose among these universes, finding a working one through trial and error.

For another description of the problem, see this post from David Pollak.

Often, projects are reluctant to have dependencies on other projects, because the more dependencies you have the worse this problem becomes.

One solution: coordinate an explicit universe

This idea shamelessly takes a page from Linux distributions.

We could declare that there is a Universe 1.0. This universe contains a fixed ABI version of the Scala standard library, of SBT, of Akka, of Play — in principle, though initially not in practice, of everything.

To build your application, rather than being forced to specify the version of each individual dependency, you could specify that you would like Universe 1.0. Then you get the latest release for each dependency as long as its ABI remains Universe-1.0-compatible.

There’s also a Universe 2.0. In Universe 2.0, the ABI can be changed with respect to Universe 1.0, but again Universe 2.0 is internally consistent; everything in Universe 2.0 works with everything else in Universe 2.0, and the ABI of Universe 2.0 does not ever change.

The idea is simple: convert an undocumented, ever-changing set of implicit dependency sets into a single series of documented, explicit, testable dependency sets. Rather than an ad hoc M versions of Scala times N versions of SBT times O versions of Akka times P versions of whatever else, there’s Universe 1.0, Universe 2.0, Universe 3.0, etc.

This could be straightforwardly mapped to repositories; a repository per universe. Everything in the Universe 1.0 repository has guaranteed ABI consistency. Stick to that repository and you won’t have ABI problems.

One of the wins could be community around these universes. With everyone sharing the same small number of dependency sets, everyone can contribute to solving problems with those sets. Today, every application developer has to figure out and maintain their own dependency set.

How to do it

Linux distributions and large multi-module open source projects such as GNOME provide a blueprint. Here are the current Fedora and GNOME descriptions of their process for example.

For these projects, there’s a schedule with a development phase (not yet ABI frozen), freeze periods, and release dates. During the development phase incompatibilities are worked out and the final ABI version of everything is selected.

At some point in time it’s all working, and there’s a release. Post-release, the ABI of the released universe isn’t allowed to change anymore. ABI changes can only happen in the next version of the universe.

Creating the universe is simply another open source project, one which develops release engineering infrastructure. “Meta-projects” such as Fedora and GNOME involve a fair amount of code to automate and verify their releases as a whole. The code in a Universe project would convert some kind of configuration describing the Universe into a published repository of artifacts.

There are important differences between the way the Linux ecosystem works today and the way the Java ecosystem works. Linux packages are normally released as source code by upstream open source developers, leaving Linux distributions to compile against particular system ABIs and to sign the resulting binaries. Java packages are released as binaries by upstream, and while they could be signed, often they are not. As far as I know, however, there is nothing stopping a “universe repository” project from picking and choosing which jar versions to include, or even signing everything in the universe repository with a common key.

I believe that in practice, there must be a central release engineering effort of some kind (with automated checks to ensure that ABIs don’t change, for example). Another approach would be completely by convention, similar to the current cross-build infrastructure, where individual package maintainers could put a universe version in their builds when they publish. I don’t believe a by-convention-only approach can work.

To make this idea practical, there would have to be a “release artifact” (which would be the entire universe repository) and it would have to be tested as a whole and stamped “released” on a certain flag day. There would have to be provisions for “foreign” jars, where a version of an arbitrary already-published Java jar could be included in the universe.

It would not work to rely on getting everyone on earth to buy into the plan and follow it closely. A small release engineering team would have to create the universe repository independently, without blocking on others. Close coordination with the important packages in the universe would still be very helpful, of course, but a workable plan can’t rely on getting hundreds of individuals to pay attention and take action.

Scala vs. Java

I don’t believe this is a “Scala” problem. It’s really a Java ecosystem problem. The Scala standard library is a jar which changes ABI when the major version is bumped. A lot of other jars depend on the standard library jar. Any widely-used plain-Java jar that changes ABI creates the same issues.

(Technicality: the Scala compiler also changes its code generation which changes ABIs, but since that breaks ABIs at the same time that the standard library does, I don’t think it creates unique issues.)

Thinking of this as a “Scala problem” frames it poorly and leads to incomplete solutions like cross-versioning based only on the Scala version. A good solution would also support ABI changes in something like slf4j or commons-codec or whatever example you’d like to use.

btw, it would certainly be productive to look at what .NET and Ruby and Python and everyone else have done in this area. I won’t try to research and catalog all those in this post (but feel free to discuss in comments).

Rehash

The goal is that rather than specifying the version for every dependency in your build, you would specify “Universe 1.0″; which would mean “the latest version of everything in the ABI-frozen and internally consistent 1.0 universe of dependencies.” When you get ready to update to a newer stack, you’d change that to “Universe 2.0″ and you’d get another ABI-frozen, internally-consistent universe of dependencies (but everything would be shinier and newer).

This solution scales to any number of ABI changes in any number of dependencies; no matter how many dependencies or how many ABI changes in those dependencies, application developers only have to specify one version number (the universe version). Given the universe, an application will always get a coherent set of dependencies, and the ABI will never change for that universe version.

This solution is tried and true. It works well for the universe of open source C/C++ programs. Enterprise adoption has been just fine.

After all, the problem here is not new and unique to Java. It wasn’t new in Linux either; when we were trying to work out what to do in the GNOME Project in 1999–2001 or so, in part we looked at Sun’s longstanding internal policies for Solaris. Other platforms such as .NET and Ruby have wrestled with it. There’s a whole lot of prior art. If there’s an issue unique to Java and Scala, it seems to be that we find the problem too big and intimidating to solve, given the weight of Java tradition.

I’m just writing down half-baked ideas in a blog post; making anything like this a reality hinges on people doing a whole lot of work.

Comments

You are welcome to comment on this post, but it may make more sense to add to the sbt list thread (use your judgment).

 

Searching Menus

One of the neatest parts about starting to get more application data into the open is that we can start to use it in interesting ways. I'm happy to talk about a new way that we're using the menu data: the HUD. The idea behind the HUD is that you can quickly find functionality in an application without having to know the menu structure. But how does it do it? How can you make it better?

Getting the data

We're using the same Dbusmenu data that is currently exported to the global menu, just remixing it for search. We are searching through the labels in the menu items which gives us already localized data straight from the application. This means that it should work for the language that the application is in. In the future we hope to use information like accessibility data as well as any tooltips that might be attached to a menuitem (though we don't show tooltips in the global menu).

Any application that works with the window menus today should also work with HUD out of the box.

Matching the label

To match the label we're basically using an implementation of the Levenshtein distance with a few additions. What this allows us to do is rank possible solutions in a relevancy order, and present some solutions that might occur via "fat finger" or other similar type errors. But, this also means that there is some fuzzy algorithms involved in the matching which will have to be tuned.

We expect to tune them over the next few releases, and to do that we have a set of test cases that we're using for the tuning. The problem with those test cases? They're only in the languages I speak. You probably speak in more/different/better languages than I do, please feel free to propose merges that extend this test suite so that as we continue to tune the search algorithms we don't leave any language behind.

Remembering Favorites

One of the additions that we add to the distance calculation is an offset based on which entries you've used most recently. Your favorite functionality in the application. Quite simply we're storing a list of items you've used over the last thirty days and a timestamp of when you used them. This database is simple but it can be fun to look into for the curious and I wanted to talk a bit about a couple of the tools that you can use to see the data.

$ hud-list-applications

This will list all the applications that have data on them in your HUD usage database. They are identified by the path to their desktop file as determined by BAMF. You can then look at the menu items used in a specific application:

$ hud-dump-application /usr/share/applications/inkscape.desktop 

This shows the individual items that you've used, and the number of times that you've used them. If you want to inspect the exact file tracking the data it is available at:

~/.cache/indicator-appmenu/hud-usage-log.sqlite

While talking about various tools to work with HUD I thought I'd also mention that you can also, just for fun, work with HUD from the command line using the command line tool:

$ hud-cli

Application initial bias

Application designers have always had a problem figuring out how to promote specific functionality that is commonly used to the forefront, while still making the rest of the functionality easily available. The most recent ways that they've done this is with toolbars and ribbon style. You can't adjust the positioning even when you know that the particular toolbar isn't best for the user because it will mess up the user's spacial memory. HUD sidesteps this issue by providing all the options, just promoting certain ones based on usage. They're all in the same place (the HUD) but with always improving ordering.

What happens on first usage of the application? At that point we don't have any way to know what the user wants to do, we we've provide a way for the application designer to provide the most likely items for general users. Effectively, this is the HUD's version of the default toolbar setup in an application; though it automatically decays and adjusts to the user's usage pattern.

The files that control this initial bias are very simple and there is an example in the test suite. Basically they have the various menu items along with a value that describes how to preload the usage database. A '5' there would mean that 5 entries are added to the usage database for that item on the first time that application is used; one for today and each of the four days previous. In this way, as values drop off by being too old, there isn't a step function in how the item is ranked, it just slowly drops down in priority. Application designers should start to think about how they would rank the menu items in their application, and start getting these integrated into either the releases or the packages of those applications so that users have a good first experience with their application.

Development notes

The code for the HUD lives in the indicator-appmenu repository. Currently it exists on a branch that needs to be reviewed before merging, but that shouldn't be for long. I expect it to get merged to trunk in the next couple of weeks.

After that the biggest change will be integration with indicator-appmenu. It was originally implemented as it's own service to make development more agile, but it clearly shares a large amount of data with the global menu and there's no reason to have two repositories in memory of the same data. It also needs to synchronize heavily with the application menu and BAMF, which is also already in indicator-appmenu. Thanks to the magic of DBus no one should notice the change in processes as the names and objects will migrate over to the new process.

As this is more of a first prototype there are also some missing features that need to be added. The first of those is to simply improve the matching. We also need to get better descriptions from application indicators, today we're using their accessibility description (you set those, right?) but that typically has too much information. Lastly, we need to integrate better with applications that expect the about-to-show signal for their menus. This includes XUL applications and some Qt ones, so it's an important feature for making the HUD usable for everyone.

Merges and bugs should be directed towards the indicator-appmenu project and also make sure you've signed the Canonical Contributor Agreement for any code contributed.

Comments: Identi.ca | Twitter

Back from LCA!

After a long series of flights this weekend, I’m finally home from my trip to linux.conf.au.

My time in Australia kicked off with AdaCamp in Melbourne over the weekend, which was fantastic and which I’ll give its own post in the coming days. I find conferences to be very intense and can never seem to find the time to blog while I’m there. I’m impressed with those who manage to pull it off.

LCA was a fantastic conference. I greatly enjoyed meeting people and catching up with old friends. It was great to be able to talk about GNOME with everyone. Many people didn’t know about extensions.gnome.org and others hadn’t actually seen GNOME3 and were impressed when I showed them my laptop. (And happily quite a number went away excited to try it.)

I gave two talks at the conference. The first was at the Business of Open Source Miniconf on Monday which was organized by Martin Michlmayr, where I talked about the nuts and bolts of nonprofit law. Since the talk was outside the United States, I kept the discussion mostly on a conceptual level, focusing on issues like governance and common pitfalls for nonprofit management. Usually I worry that these kinds of talks are very boring but perhaps this approach was better, as this time the audience seemed really engaged. I was the last talk of the day, and the Q&A session lasted well past the scheduled end time. Unfortunately, the talk wasn’t recorded but I’d be happy to send the slides on to anyone who is interested.

The keynote I gave on Thursday was my medical devices talk but longer and with more of a focus on GNOME – the thrust of the talk being that software has become critical to our lives and to our society and that since free and open source software is safer over time, we must make it usable so that we can build a bridge to ordinary users. I loved being able to talk about GNOME’s accessibility campaign in this context too. I hope that folks who listened to the talk will give to the campaign so we can make real headway on accessibility.

I was totally overwhelmed with the responses to my keynote. The twitter stream was amazing, but I especially loved the fact that folks were saying that they now want to hack on GNOME after my talk. GNOME developers should be proud about what they’re doing. They’re really making the world a better place. I’m so glad to be able to represent and support the community.

This point was underscored by Jacob Applebaum in his keynote (which was amazing but I think hasn’t been posted yet). He of course talked about security, our governments and ways that we can protect ourself against surveillance. He made great points and I learned quite a lot from his talk. In his conclusion, Jake made several calls for action, including hacking on GNOME (I was particularly proud that he quoted me as saying “the Guh in GNOME is for freedom”). He suggested we build Tor as a default into our desktop to promote more secure web use, and I think that’s a really fabulous idea. One of the problems that we have with improving security generally is getting ordinary people to understand why it’s important and how to implement it. GNOME could be the perfect place for this, as our community understands these issues and is skilled at making beautiful software that is accessible and easy to use.

It may be silly, but thanks to Jake and also Paul Fenwick who got all the crickets out of my room the night before my talk so I could prep and sleep!

I also met with a few reporters and will link to other articles if they wind up getting published.

Kudos to the LCA2012 team, especially Josh Stewart and Kathy Reid. The conference was well organized, interesting and fun. Thanks for bringing me to Australia!

GNOME & Computer Science at KSU

Today was the start of my 3rd week back at school for the first time in, well, 5.5 yrs. Its been a while, and is proving to be slightly more stressful than I remember… Anyhow, I’m currently majoring in Spanish Translation at Kent State University, and have been trying to decide what I want to minor in (most likely computer science). I’ve always wanted to learn to program, and have simply never been very successful in teaching myself (basically, I know just enough to break stuff:). When I was in college previously, I was simply never willing to take the required math classes to be able to get into the computer classes that I actually wanted to take. Oh, and I refused to use windows. Which, for some reason was required by both of the colleges at which I’ve previously inquired. All of which added up to me simply not taking computer classes in the past.

Today though, I finally went and hunted down a computer science adviser, and as I was talking to him about classes, system requirements, etc, realized that he was actually running GNOME! GNOME 2.x granted, but still, GNOME! I was (am!) elated!  As you may suspect, I was assured that no, I will not have to use windows in any of their computer science classes, which is of course exactly what I was hoping for.

All of this adds up to me looking forward to taking a computer science class or two in the coming semesters. Assuming I can pass Algebra for Calculus. Which, at this point, is quite the assumption, since its been a solid, oh, I don’t know, 10 years since I’ve done *ANY* math besides basic addition, subtraction, multiplication and they very occasional division?? Yeah. Its not looking so hot right now.


New cycle

Lot of time without write a single post… too bad…

The thing is I was thinking about my live these last months… And after awhile I decided to make a big change: leave my job and move back to Canaries

After 6 years living in Seville and working at Emergya I found there was the end of a cycle so I have to move forward and start new things.

These 6 years have been great. I’ve learnt a lot and met great people. I truly wish the best for my (now) former company and the people there. They deserve it. They will be always my family :-)

Now I like to have a bit of personal time to learn new things, to have back my technical skills (mostly programming) and try new projects. I have some ideas in my mind that I hope to share (as code) soon and I also hope some of them to be useful for GNOME developers, testers and translators. Will see…

Happy haking from my new life at Canarias! :-)

ATK/AT-SPI2 Hackfest 2012: Days 2,3,4,5

Well, as in the previous hackfest, I planned to make a post per day, but in the end I didn’t. Next time I will not make any plan.

Yesterday we had our last day of the hackfest. It was, in my opinion, a productive Hackfest where each one had the opportunity to work with other people working in the same field, and discuss several topics regarding the current situation. If you want to know all of the details and conclusions, you could read a minutes-like brainstorming document on the wiki. But If you were to ask me to pick just one, I would mention the discussion about enabling the accessibility support by default. The main conclusion was stop to use the atk-bridge as a module, and instead have that feature integrated. Doing that has several advantages, including having it compiled (and thus tested) when someone compiles GTK+ or any GTK+ app, and not only when you want to compile the “accessibility stuff”. The implementation details are still not clear. Convert atk-bridge to a library and add a dependency on GTK+ and others? Integrate it in ATK (making the bridge something like the DBUS backend)? Integrate it in GTK+? Forget ATK, and let GTK+ talk directly with the accessibility tools using GDBUS (an option that I feel is too drastic or non practical, but still in the mind of Benjamin)? Now is the time to debate it, in order to have something decided by 3.4, which we can start to testing properly at the beginning of the 3.6 cycle. Interesting times these days.

As in the previous hackfest, other conclusion is that there is a lot of work to do, but not a lot of people to do it. And this was reflected by the amount of people in attendance (some photos here). Anyway, although we were not a lot of people, we had a lot of different backgrounds represented at the hackfest. People from GTK+, ATK, AT-SPI2, WebkitGTK, Mozilla, assistive tools and QT. For example, in several discussions Frederik Gladhorn explained how the qt-bridge implements certain features, in some cases in an different way than how atk-bridge does the same thing, as Mike noted recently on his blog.

Finally, I want to thank everyone who came to this hackfest, as they made this hackfest possible. I also want to thank Igalia, GNOME Foundation and Mozilla Foundation for their sponsorship.

January 23, 2012

gnome release schedule

as i needed a graphical representation for my master thesis i did attempt a shameful rip-off of my friend andreas' beautiful contemporary piece of art.

and to quote vincent

I like it. It’s pure art, you know. Not understandable.

source

Mon 2012/Jan/23

Maliit and third party input method plugins (video)

Maliit has an architecture where input methods are implemented as plug-ins. This enables a multitude of different input methods to exist and be used in the same way by applications. Maliit comes with a set of reference plug-ins, but there are also third party plug-ins. This video gives a quick introduction to some of them:

Gitorious Merge Request Monitor

In Maliit, all changes have to be reviewed by two people in order to be merged to mainline. This helps us catch issues early and keep code quality high. Since the code is hosted on Gitorious, we use their merge requests feature for that purpose. Up until now we have periodically checked the website for changes (potentially going through each and every one of the repositories), and manually mentioned updates in the IRC channel. This is both tedious and inefficient, so I wrote a simple tool to help the issue: Gitorious Merge Request Monitor

It provides an IRC Bot which gives status updates on merge requests in an IRC channel:

16:01 < mrqbot-AfFa1> desertconsulting requested merge of ~desertconsulting/maliit/desertconsultings-maliit-framework with maliit-framework in http://gitorious.org/maliit/maliit-framework/merge_requests/126
16:01 < mrqbot-AfFa1> mikhas updated http://gitorious.org/maliit/maliit-framework/merge_requests/125  State changed from Go ahead and merge to Merged

One can also query the current status from it:

15:02 < jonnor> mrqbot-7ACeB: list
15:02 < mrqbot-7ACeB> maliit-framework/127: - New - Allow QML plugins to add custom import paths for QML files and QML modules
15:02 < mrqbot-7ACeB> maliit-framework/126: - Need info - configurable importPath for qml
15:02 < mrqbot-7ACeB> maliit-plugins/26: - New - Add PluginClose from main view and add key repetition support
15:02 < mrqbot-7ACeB> maliit-plugins/25: - New - Clear active keys and magnifier on keyboard change
15:02 < mrqbot-7ACeB> maliit-plugins/24: - New - Remove QtGui dependency from libmaliit-keyboard
15:02 < mrqbot-7ACeB> maliit-plugins/23: - New - Get rid of Qt keywords
15:02 < mrqbot-7ACeB> maliit-plugins/22: - New - Add phone number and number layout getters.

Status changes are retrieved by periodically checking the Gitorious project activity feed (Atom)*, and the status itself is scraped from the website. There is no other API right now, unfortunately. Implemented in Python with Twisted, feedparser and BeautifulSoup doing all of the heavy lifting.

Get it from PyPi, using easy_install or pip:
pip install gitorious-mrq-monitor
gitorious-mrq-monitor --help # For usage information

For now this solves the immediate need for the development work-flow we have in the Maliit project. Several ideas for extending the tool are mentioned in the TODO. Contributions welcomed!

New Schrödinger Release

I recently added support for 10- and 16-bit encoding and decoding to Schrödinger, so I did a little release. Presenting Schrödinger-1.0.11. Also pushed changes to GStreamer to handle the new features. Although these changes have been in the works for some time, a little prompting from j-b caused me to finish this off, so this will probably appear in VLC soon, too.
This was the last piece needed to create a 10-bit master of Sintel, which I’ve been planning to do for some time.

UEFI and bugs

I gave a presentation on UEFI at LCA 2012 - you can watch it here, with the bonus repeat (and different jokes) here. It's a gentle introduction to UEFI, followed by some discussion of the problems we've faced in dealing with implementation bugs.

The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There's no reason to assume that the people who've actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we'd probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.

Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I've been working on UEFI I've discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I've seen cases where it was possible to create variables, but not to delete them. I've seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I've tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven't even tested the majority of consumer-grade hardware with UEFI.

The problems with UEFI have very little to do with its design or the ability of the people implementing it. After a few years of iterative improvements it stands a good chance of being more reliable and useful than BIOS. Increased commonality of code between vendors is a blessing and a curse - in the long term it means that these bugs can be shaken out, but in the short term it means that at least one hardware-destroying bug has ended up carried by multiple vendors. Right now we're still in the short term and it's likely that we'll find yet more UEFI bugs that cause all sorts of problems. The next few years will probably be a bumpy ride.

comment count unavailable comments

Unpacking Boxes...

For the impatient people running Fedora 16 but who still want to get an aperçu of Boxes, today's your lucky day! I set up a preview repository with all the needed package to install Boxes on Fedora 16.
If you want to try it, download this file to /etc/yum.repos.d and then run  
yum install gnome-boxes && yum update



To go back to your previous setup, you can either use the convenient yum history, or remove /etc/yum.repos.d/gnome-boxes-preview.repo and use
yum remove libvirt-glib && yum distro-sync

Keep in mind that this is a new application still in heavy development, so you're likely to find bugs and missing features. But I'm sure you will enjoy it nonetheless :)

Feel free to join us in #boxes on irc.gnome.org if you have any issues, or if you just want to chat with us.


There is no tech industry

In the aftermath of the big protest against the US SOPA bill, I've seen a fair few people (including Joel Spolsky) ask the question: why are we not lobbying for laws? Why is it that other interests try and oppress the internet and we fight back; shouldn't we be taking the fight to them? Lobby and push for laws that make the net better, and have them fight us for once?

This thought, while it's got the fist-in-the-air fight-the-power undertones that go over well with the internet crowd, is a bit worrying.

The movie and TV industry spent ninety million dollars lobbying the American government in 2011. Where's our ninety million? Most of the tech industry is struggling to stay alive on VC money and the occasional payment; there's no central fund, and no-one with the expertise to do the lobbying anyway, especially when that's combined with the sneaking sense that paying money for attention and to get laws passed is Not Really Cricket.

Hang on, though; the big players have a whole ton of money. Ninety million is about two days profit for Apple, about four days profit for Google, about the same for Microsoft, about the same for Oracle. Seriously, if those four firms donated one day's profit, the tech industry could throw a hundred and fifty million dollars into the pot without serious effort. The MPAA have recently started demanding quid pro quo for their donated money; maybe this is the time to get in the game and outspend them. Any one of the four firms above, and probably others besides, could swallow up the whole movie industry without so much as a gulp if they wanted.

But then we hit the biggest problem. I've been talking about "the tech industry" like it's a thing. There is no tech industry.

The movie people get this right. No-one's lobbying for only movies by Twentieth Century Fox to get extra copyright protection. No-one's arguing that TV programmes should be blocked from being written to DVDs but only if they've got Martin Sheen in them. They work together. What we laughingly call "the tech industry" does not. Do you honestly think that if Apple or Microsoft or Oracle throw down a hundred million notes on a law that that law will benefit startups and Canonical and Red Hat and hobby programmers? If Microsoft throw down that money, do you think the resulting legislation will benefit Apple? Hell no. There's almost no sense of collaboration in the "tech industry" at all; we're a bunch of scratching yowling cats in a bag, too busy fighting one another to maintain a front against outside opposition.

What's the solution here? I don't know. But I'm wary of a world where the interests of the movie industry are less effective in the American Congress but have been replaced by the interests of multi-billion-dollar computer companies. That doesn't seem to benefit the internet all that much.

Hello GOPW!

This is my first blog post for Gnome Women Outreach Program and my first blog post on Planet GNOME. I know that this post comes a “bit” late but I’ll try to write everything that I wanted to write one … Continue reading

Too Much Documentation?

When trying to run ‘make distcheck’ on gnome-user-docs, I got this error:

make[1]: execvp: /bin/sh: Argument list too long

This roughly translates to “You have so much documentation translated into so many languages that your poor build system can’t handle it.” Congratulations to everybody involved in reaching this wonderful error.

Update: I’ve added a custom distdir target to yelp.m4 to fix this problem. If you maintain a package with a large document and a lot of translations (gnome-user-docs, ubuntu-docs), install yelp-tools 3.3.2 before making your next release. You may need to run ‘make distclean’ and rebuild completely to get the new build rules.

 

January 22, 2012

1000 words…




http://bugzilla.gnome.org/show_bug.cgi?id=628195

EDIT: some people have been asking for a better screenshot (there’s only two pixels of difference above). Here’s a highly exaggerated example:

We’ll do it live!

Live extension enabling and disabling has landed! This allows users to do this!

I could do that all day. It’s quite fun.

But there’s one little problem. Extension developers? We need to talk.

“What did I do?”

Nothing bad, I promise. You just have a new responsibility: in case the user doesn’t like the extension, you need to undo all the changes that you ever made to the shell. Make it look like your code never touched the place. Otherwise: that video above? The giant illusion will drop to the ground and crack into a thousand pieces. Like that China I broke last weekend.

“Uh, OK. How?”

If your extension looked like this before, you need to make it look like either this, or this.

Put simply: main(), uh, how do I say this? main() has been, uh, let go. Sure. Don’t worry though, he’s been replaced with init(), enable() and disable(). They’re just as cool. I promise. The in-depth obitua — uh, termination notice can be read here. init()‘s best friend, the “helper” object couldn’t make it for this trip. He’ll be here next year.

There’s three simple rules to take into account:

  • There used to be one required method: main(). This has been removed. It has been replaced with a new hook, init(). You should use init() to initialize any state. Do not modify the Shell inside of this function.
  • The init() may return an object, called the “state object”. If you do not return an object, the module is considered the state object. This object is supposed to have two new methods: enable() and disable(). These should modify Shell in the appropriate way. For lack of better vocabulary, extensions which use the module (return nothing from init()) as their state object are called “stateless” objects, and those which don’t are “stateful”.
  • init() is guaranteed to be called at most once per shell session. enable() and disable() may be called at any time. If your extension is enabled at the start of the session, enable() will be called. If your extension is disabled at the start of the session, disable() will not be called, and there is no guarantee that init() will be called.

Additionally, keep in mind that Shell extensions are versioned, so only extensions that are targeted for 3.2 should port to the new API. Some extensions that want to support both 3.0 and 3.2. Fortunately there is an easy way to do exactly that. Just run init(), and then enable():

function main() { init(); enable(); }

… Stateful extensions just need to run enable() on their state object.

function main() { init().enable(); }

Oh, and one last thing. Thank you. You don’t have to believe it, but I’m doing this for you. I’m trying to make it easier for users to safely try out your awesome work. There’s more awesome stuff for you guys on the way. I promise.

The infrastructure of the Maliit project

Maliit T-Shirts! It took us a while to transform the Maliit project into a real opensource project. At first there was only public code, later some wiki pages @ meego.com together with constantly changing components in the official MeeGo bugtracker, then a public mailing list.

After that we tried to become independent of MeeGo, but neither freedesktop.org nor the GNOME project could give us a suitable home. So we had to go with our own infrastructure in the end, which probably was the best we could do, in any case. We now enjoy our own website (mostly a wiki, for which we can also analyze the traffic), our own IRC channel, our own public bugtracker, our own mailing lists and a build bot. We also make use of other services such as launchpad.org and the openSUSE Build Service, both for packaging but also as part of our continouous integration setup. Both services provide nightly builds for Maliit, for example (though we still lack packages for ARM).

But there was always one thing missing: T-Shirts. Now that this is solved, too, we can finally call Maliit a real opensource project ;-) Hopefully we'll soon have another group photo of the people who've been involved in the project over the years. I'll make sure to bring a couple of T-Shirts to FOSDEM, so make sure grab Jon or me if you want one.

Google Code-In 2011

22nd Jan 2012 : Yay, this is my first blog post for the year 2012. The year began with a successful completion of another round of Google Code-In , a program to encourage pre-university students to participate in open source. Having completed google summer of code with GNOME recently , I was really curious to mentor for GCI for my friend GNOME. Andre Klapper ,the man whom I troubled a lot initially, for melange system bugged me. Thanks Andre:-)
I mentored for the following tasks : -

A kid (/me) mentoring another kid was the best part :P It was immense fun to communicate with the feelings of kids and watch their growing enthusiasm towards Open Source.

Hail Open Source !

January 21, 2012

Sweeping Away the Dust

I knew from the moment I created this blog that I wouldn't be much of a blogger. It's a bit intimidating; writing my thoughts. I feel like I'm standing in front of a giant bulletin board trying to figure out the best location for a dull yellow Post-It same as all the rest. And it's been ages since I've written anything creative. I read some of the stuff I wrote as a child and think: wow, I wrote that? Well, here I am again. Thinking again. Writing again.
So I have recently been looking into building a mobile application for the Droid. I have a pretty sweet idea for something a bit fun that could be quite useful for users, but I'm having a little bit of trouble motivating myself to go on with the project. I have Eclipse with Android all ready to go...and I'll be willing to give some more details of the project once I get some code down.
After bombing my very first technical interview ever, and with Twitter at that, I have had trouble staying concentrated on this project. There's just so much I still need to learn and refresh my memory on about programming and data structures and concurrency and even with the internet at my fingertips there doesn't seem to be enough time to absorb it all! And now with February tech interview hell and school only a couple of days away I can really feel the pressure weighing me down..
Anyways, I'll try to be better about posting here. For now I leave you with expectations, and maybe I'll do another hackathon to crank out that app!

Nohemi

Hackfest Brno Docs 2012

This year “2012″ the first “face to face” meeting I will have with GNOME people is going to happen in Developer Conference 2012.  I am going to be part of the Hackfest Doc Sprint Brno 2012. My contribution will be related with writing and updating documentation.

My purpose is also get involved in technical writing and find some way to help the accessibility team.

Brno here we come!


Filed under: GNOME Tagged: Brno, Developer Conference 2012, GNOME, http://lleksah.wordpress.com, Julita Inca, Julita Inca Chiroque

January 20, 2012

Weeks 09 Jan- 20th Jan


What I did in past weeks

I have done some document translation and they are quite tricky. It is the reason that my pace tend to drop a little bit. For now I have downloaded a help file for Cheese and Gnome-control. The other document is from Damned Lies website with general information about the Open source License.

I have worked on the following files:
Jan. 9, 2012 gnome-documents - master - UI translations - Xhosa Translated
Jan. 9, 2012 gnome-video-effects - master - UI translations - Xhosa Translating
Jan. 10, 2012 gnome-contacts - master - UI translations - Xhosa Translated
Jan. 11, 2012 alacarte - master - UI translations - Xhosa Translated
Jan. 11, 2012 caribou - master - UI translations - Xhosa Translating
Jan. 12, 2012 gnome-shell - master - UI translations - Xhosa Translated
Jan. 13, 2012 gnome-backgrounds - master - UI translations - Xhosa Translated
Jan. 17, 2012 gnome-font-viewer - master - UI translations - Xhosa Translated
Jan. 17, 2012 gnome-screenshot - master - UI translations - Xhosa To Review
Jan. 17, 2012 gnome-screensaver - master - UI translations - Xhosa Translated
Jan. 18, 2012 gnome-power-manager - master - UI translations - Xhosa Translating
Yesterday gnome-user-share - master - UI translations - Xhosa Translating

- My plans for the next week
My plan for next week is to download more po files and translate them.
Proofreading


- Things that I am waiting for that keeps a task from completing

Proof reading and testing can takes time before I upload the po file in the Damned Lies website.
Correcting work also take some time.

Plumbers Wishlist, The Third Edition, a.k.a. "The Thank You Edition"

Last October we published a wishlist for plumbing related features we'd like to see added to the Linux kernel. Three months later it's time to publish a short update, and explain what has been implemented in the kernel, what people have started working on, and what's still missing.

The full, updated list is available on Google Docs.

In general, I must say that the list turned out to be a great success. It shows how awesome the Open Source community is: Just ask nicely and there's a good chance they'll fulfill your wishes! Thank you very much, Linux community!

We'd like to thank everybody who worked on any of the features on that list: Lucas De Marchi, Andi Kleen, Dan Ballard, Li Zefan, Kirill A. Shutemov, Davidlohr Bueso, Cong Wang, Lennart Poettering, Kay Sievers.

Of the items on the list 5 have been fully implemented and are already part of a released kernel, or already merged for inclusion for the next kernels being released.

For 4 further items patches have been posted, and I am hoping they'll get merged eventually. Davidlohr, Wang, Zefan, Kirill, it would be great if you'd continue working on your patches, as we think they are following the right approach[1] even if there was some opposition to them on LKML. So, please keep pushing to solve the outstanding issues and thanks for your work so far!

Footnotes

[1] Yes, I still believe that tmpfs quota should be implemented via resource limits, as everything else wouldn't work, as we don't want to implement complex and fragile userspace infrastructure to racily upload complex quota data for all current and future UIDs ever used on the system into each tmpfs mount point at mount time.

Multitouch is near…

So, after a few strives during the last year, the multitouch Xorg patches were posted and merged to master last month, making multitouch available in the upcoming Xorg release. This turns the multitouch GTK+ branch into a suitable candidate for GTK+ 3.4, which obviously deserves a video demoing what’s up there:



Hopefully soon in master, very soon…

Slides from DLNA talk

Last week I did a talk about DLNA, what it is and how it relates to UPnP during a DeveloperGarden event hosted in Berlin’s famous hacker space c-base.

A video of the event will be available later but the slides are already available.

Note: Both talk and slides are in German. I will also be giving a short talk about Rygel on this year’s FOSDEM in Brussels.

Announcing GFreenect

As mentioned in my last post, Edu the mighty Cuban and I have been playing with the Kinect and developed an interactive installation for Igalia‘s 10th anniversary party using OpenFrameworks. (By the way, some people asked me for that application’s code so yesterday I cleaned it and it’s available on Gitorious)
OpenFrameworks offers a number of functionalities either from its core libraries or by means of add-ons and indeed there is an add-on that wraps libfreenect, the Free Software library that allows to control the Kinect.

Using OpenFrameworks was easy, it makes it fast to start developing with it but in many aspects it’s completely different from the way we’re used to work on GNOME. We are used to have single, independent libraries that do one thing and do it well and are used as needed by application developers, for example, do not include a sound library if my application is never going to use it.
Having modules such as GTK+, Clutter, Cairo, GStreamer, etc. already gives us flexible ways to develop certain parts of applications similar to the demo mentioned before: we just had to draw the fish using Clutter/Cairo, implement their behavior and show the Clutter stage. Of course we also would need a way to control the Kinect and it would be really nice if it could offer us an easy to use API for those familiar with GLib…

Ladies and gents, we give you… GFreenect

GFreenect is a wrapper for the Freenect library written using Glib in order to control a Kinect device and make it easy to use with GNOME technologies.
It doesn’t simply wrap the Freenect library but also offers ways of using it that are familiar to you if you have developed something using other GNOME libraries.
One example of this enhanced functionality is that we focused on offering an asynchronous API (although there are some synchronous alternative methods as well). Another example is that when setting the device’s tilt angle, a signal will be emitted when it has finished setting the angle, since it might be useful for some applications.

One of the purposes of having it written with GLib is the GObject Introspection capability. This allowed us to include an example application that controls the various features of the Kinect and was written in Python effortlessly. A screenshot of this app is shown below:

GFreenectView Screenshot

And that’s it! You can find the code for GFreenect in Gitorious (including documentation for this 0.1.2 version). Bear with us if you find some bugs, it is fresh out of the oven.

We hope you find GFreenect useful for your projects and please give us feedback if you find some issues or have any good suggestions.

Online Glom: Now easy to build

Building gwt-glom

At least on Ubuntu, it’s now easy to build and test gwt-glom. You can just do:

$ sudo apt-add-repository ppa:openismus-team/openismus-glom-unstable
$ sudo apt-get install default-jdk maven2 libjava-libglom-java glom-utils
$ git clone git://gitorious.org/online-glom/gwt-glom.git
$ cd gwt-glom
$ mvn gwt:run

This opens the GWT Development Mode GUI, which serves gwt-glom via jetty and lets you see it in your browser.

Chrome is the most likely to have the gwt plugin that you need for development mode, though it’s available for some versions of Firefox.

How we made it this easy

GWT projects, like other Java projects, typically use maven (mvn) for their build system. maven is nothing like autotools.

Maven usually downloads dependencies automatically, either from the central maven repository, from some (maybe private) other maven repository that you specify. This sounds unstable, but you specify exact version numbers, so you can be sure that your project will continue to build. So maven doesn’t have the separation of building and packaging that I’m used to in the C/C++/autotools world. It feels odd to me, but I’m going with the flow.

However, java-libglom uses JNI to provide a Java API around a C++ (libglom) API, so it uses both Java (architecture-independent) and C++ (compiled and linked for particular architectures).

java-libglom installs a native shared libary. We packaged that for Ubuntu in our Glom PPA (stable and unstable) as libjava-libglom-java so you can install it easily.

java-libglom also creates .pom and .jar files (for the API, the sources, and the javadoc). These are in the central maven repository so maven can just download the .jar.

That libjava-libglom-java Ubuntu package also installs the .pom and .jar files that maven needs, but those are only useful for mvn-debian, which is apparently only useful for building other Debian/Ubuntu packages. There is no apparently no way to using mvn-debian’s local repository while also using the central maven repository for other stuff.

Java with autotools

By the way, java-libglom uses autotools, although the autotools Java support is barely useful and limiting, so we have custom rules for most stuff. However, autotools does let us generate the Java and C++ files from swig, and build the native shared library. That seemed harder to do with maven, though maven would have made it easier to deal with the generated Java code.

I do like how maven just defaults to using your .java files, and test ,java files properly if you put them in the correct places. For instance, see the maven quickstart project.

January 19, 2012

All aboard the Bendy Bus

Have you ever written a client for a D-Bus service, then had difficulty in testing it because you need to find a way to set up the state of the D-Bus service, run your test, then set up the service in a completely different manner, rinse and repeat…all while running a modified version of the service’s binary in parallel with your system installation of it, and without doing anything which might cause your personal data to be accidentally eaten?

Having done some hacking on Telepathy and EDS clients I can, unfortunately, say “yes” to all of the above. Since problems are problematic, I’ve been hacking on a tool called Bendy Bus, which will hopefully alleviate some of this pain.

Bendy Bus is a project I’ve been working on as my final year university project, but I intend for it to be most useful outside of (hopefully) getting me marks for my degree. The basic idea of Bendy Bus is that you fuel it up with a description of a nondeterministic finite state automaton which represents the D-Bus service you’re using, plus a D-Bus introspection XML file describing all the relevant D-Bus interfaces. Bendy Bus will use the FSM description to simulate the D-Bus service, and run as a wrapper around the client program you’re trying to test. It’ll set up a private dbus-daemon instance for your client program, and expose all the simulated D-Bus objects on this bus.

Bendy Bus will listen for D-Bus method calls and property changes made by your client program, and execute transitions within the FSM as coded in your FSM description file. These transitions may, for example, change the FSM’s state, change data stored in the FSM (technically making it a nondeterministic DFSM, but that’s immaterial), emit D-Bus signals, throw D-Bus errors, etc. Why do I say it’s a nondeterministic FSM? Because you may specify several transitions between the same pair of states which are triggered by the same (for example) D-Bus method call. Bendy Bus will randomly choose one of the transitions to take. For example, if your client program calls a frobnicate : string → string D-Bus method, you could code one transition which successfully replies to the method call with a string return value, and another transition which simulates a failure in the D-Bus service by throwing a D-Bus error instead.

It’s in this fashion that Bendy Bus is actually designed as a fuzzing tool. You can code up a full description of every possible state and transition in your D-Bus service, then set your client program running in the Bendy Bus wrapper, and it’ll randomly explore the service’s state space until a termination condition is met. For example, the client program could crash (in which case a bug’s been found!), a D-Bus activity timeout could be reached (if your client program hasn’t made any D-Bus calls for a few seconds, for example), or a global timeout could be reached. At this point, the test harness can restart your client program and start the whole thing all over again with a different random seed value, causing different execution paths to be explored, and more of your client’s code to be covered.

Of course, Bendy Bus is still young, so features are missing, there are plenty of bugs, and documentation is basically non-existent. A couple of the big features on the list are to implement support for unit testing (which would tone down the fuzz testing aspect of Bendy Bus, and allow deterministic unit tests to be written for D-Bus client programs), implement better error reporting in the machine description parser and better logging during simulation, write a language specification and GtkSourceView highlighter, and write documentation. Help on any of these (except the unit testing stuff, which I have to keep for myself for my university project) would be greatly appreciated.

More than anything, it would be great if people could play with Bendy Bus and see if it’s useful for them (and if not, what could be done to improve it). In the repository at the moment are a couple of example machine description files for Telepathy. They can be used to get a randomly-generated contact list to appear in Empathy, using the following command:

bendy-bus machines/telepathy-cm.machine machines/telepathy-cm.xml \
--test-program-log-file=test-program.log \
--dbus-daemon-log-file=dbus-daemon.log \
--simulator-log-file=simulator.log \
-E FOLKS_DEBUG=telepathy -E EMPATHY_DEBUG=all -E G_MESSAGES_DEBUG=all \
-- empathy

That’s all from me at the moment. The Bendy Bus git repository is on gitorious, and all bug reports should be e-mailed to me: philip {at} tecnocode.co(.)uk.

In the News…

In the last couple of weeks, I have worked on various gnomie tasks:

  • I submitted a nomination application entering GNOME for a 2012 Computer World Honors Award. Thank you so much to Karen SandlerJuanjo Marin,  and Bryen Yunashko for all your help. Collaboration works, and what a fun way to get the job done! We’ll keep our fingers crossed.
  • Started working with Allan Day on the big project of improving the news infrastructure of GNOME. We hope to streamline the process for gathering and distributing news, with the goals of stimulating more contributions, ensuring fresh content on www.gnome.org, and communicating more effectively with our 16,000 followers on social media like Facebook and Twitter.
  • Our current thoughts are represented in the diagram below, which I added to the wiki, along with comments. Sri has suggested creating some quality videos from events like GUADEC. I’d be more than happy to make the videos happen at GUADEC, if I get to go!  BryenY has made several suggestions about the News Crew editorial process based on his experience creating news for openSUSE. Of course, he reminded me again of the importance of  subtitles in all of our videos- thank you Bryen :)

Finally, our fearless leader, Karen Sandler, has received rave reviews for her keynote presentation at Linux Conference Australia. According to Jacob Applebaum, “Karen Sandler’s keynote at #LCA2012 is hilarious; she’s a great public speaker and her talk about heart implants is thought provoking.”  Thank you, Karen.

And since my hackergotchi has not yet appeared on planet, here I am:                                


free() inconsistencies


Hi, folks!


Last week I was porting a program from uClibc to glibc. Everything went fine, until I found a crash to always happen in a certain part of it. The failure was in a call to the free() function. First thing that came in my head: Why the hell is it crashing now, while it used to run fine on uClibc? I made a simple program that simulates the problem:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
  char *field1;
} s_test;

s_test test = {
  .field1 = NULL
};

int main (int argc, char **argv) {
  s_test *t;

  t = &test;
  free (t);
  t = &test;
  t->field1 = "bug";
  printf ("%sn", t->field1);

  return 0;
}


Look at line 16. I’m executing a free() in a pointer to a static variable, instead of a pointer in the heap (previously allocated with malloc() or similar). It’s expected a crash here, right? Maybe! Yes, if you’re using glibc. No if you’re using uClibc. The above code works like [not] expected. Weird! Everything we learned at the programming school is ruined now :D !


So, we have a similar code here that have been worked for a long time, exactly because it was compiled and run on top of uClibc. I’ve seen this and other behavior differences between uClibc and glibc. The solution? Change the code to make it portable, not only to make it compile, but also so that it have the same behavior on every platform.


I thought it was a bug in uClibc, but I was told it doesn’t break the standards. In fact, standards say, in that case, the behavior is “undefined”. Ah, standards :) … So, in order to avoid surprises like that, here is what I learned: Always code in the right way, even if it comes with a harder job. Don’t say: “hey, it’s working, let’s deploy it!”.


See you!

Quick Description of Modules (PiTiVi) - and do I see them used-

Core

GLib
low-level - Provides us with the implementation of fundamental types and algorithms. It is a base upon which, everything is constructed.
-In PiTiVi, I see the GLib basic types (gboolean, gchar, gint, gfloat, gdouble etc)-

GObject
With the GObject, GLib provides us with the implementation of an object-oriented framework for C.
-In PiTiVi, I see the gobject functions (http://www.pygtk.org/pygtk2reference/gobject-functions.html)-

GStreamer
A multimedia framework that allows us to do anything multimedia-related. It is very flexible and uses elements
that are packaged in the form of plugins.
These elements can be codecs/demuxers/lmuxer/effects etc.
One set of these plugins are the GNonLin plugins, which are the ones who implement anything related to the logic
of video editing in GStreamer. Mainly, handle the timing of reading different multimedia files.

GES (GStreamer Editing Services)
A library created on top of GNonLin plugins, making the use of GNonLin plugins easier to use. It wraps the
GNonLin elements by offering an API of higher level.

In Pitivi, the GNonLin plugins were used directly, up to now and this is why the porting to GES will facilitate
a lot the design of the project.
So, we are using GStreamer via GES and the most objects used are GES ones (even if they come from GStreamer classes).

UI

GTK+
Toolkit for creating graphical user interfaces. Providing standard widgets and event handling. Based also in GLib.

GooCanvas
One of GTK+ widgets, used for drawing.

All of these components are based in GLib and communicate through it and its signals.


So, if I just want to add quickly GES in the PiTiVi' s wiki diagram (https://wiki.pitivi.org/wiki/Architecture), I would add it here:





Feeds