On fairness and solutions where the problems are

Via OSNews I just got to this article from CNet news claiming that the European Union might force Microsoft and OEM vendors to force the choice of an Internet browser to users.

Despite being a strong believer that Microsoft’s dominant position in the market is harmful and the lack of freedom of choice for the market is a total disaster for the industry, I think that forcing vendors to throw a choice to users is even worse.

What browsers are gonna be included in this OEM setups? IE+Firefox? IE+Opera? IE+Safari? Who’s going to make that decision? If Microsoft if forced to offer choice, i guess Apple should be forced too right? Not only in Macs but in iPhones too maybe? If we do this with browsers, why not with media players? And office suites? Is the EU going to force vendors to include Wine+IE or Opera in computers with Linux pre-installed?

I think it would be really hard to make such a proposal really fair and Microsoft-agnostic, and if a proposal becomes really hard to execute it probably means that it’s the wrong solution for the problem.I would rather take a closer look at how Microsoft is dealing with OEM vendors and public administrations to get their products mainstream, there is where Microsoft really harms the freedom of choice.

I think the EU is missing something here, it is the market that makes the choice of Operating Systems for users, as in the guy in the shop selling a computer, the geek neighbour helping when the computer crashes, the operating system supported by popular ISV products, the Universities enforcing the tools the students should use, the public administration asking for certain document formats if you want to communicate with them, the job offers asking certain expertise to new employees… these areas is where the EU should be focusing on encourage neutrality. Smashing a dialog asking “do you prefer this blue icon or this orange one to browse your internet?” is not going to solve anything rather than generate annoyances, more unfariness and confusion.

Aza Raskin on modern human-computer interaction

Found this interesting Google TechTalk from Aza Raskin is the son of Jef Raskin (one of the fathers of the Macintosh project), this guy works at Humanized, the company behind Enso.

http://video.google.com/googleplayer.swf?docid=-6856727143023456694&hl=en&fs=true

Video link for aggregators skipping the embedded video.

Enso is an interactive text shell integrated with the Windows desktop, you can actually select text from any application and translate, calculate a function, search on google and a lot of other integrated task, allowing a better integration between applications without a big list of copy paste and file system operations (watch the demo). He is also involved in the Ubiquity plugin from Mozilla Labs, which is a similar shell to integrate web applications.

His idea is to empower users on doing unexpected things from the developer stand point by using natural language, this mean, rethink the CLI as something that can be exposed to end users if well thought.

In GNOME we approached this idea with Deskbar, however I think that it’s UI got to the point where even if the panel has it by default, its use is not discoverable. There’s also GNOME Do. But both of them lacks the kind of integration and posibilities that Enso has on Windows and Ubiquity inside Firefox. It would be interesting to try out some of these ideas in GNOME 3.0 and the new Shell.

This video is a must for anyone interested in human-computer interaction and usability.

Things I’m excited about

Three posts I’ve read today that made me quite excited:

• Multi pointer support for Gtk+ (Carlos Garnacho)
• Parasite: Firebug like UI inspection for Gtk+ (David Trowbridge)
• User experience improvements for Thunderbird 3 (Bryan Clark)

Yay for new cool stuff.

Re: What’s up in GNOME land?

Alexander Neundorf from KDE wonders what’s up in GNOME land, specifically about Vala and what’s up with it. As his blogging system requires me to sing up for an account in kdedevelopers.org and getting approval from someone (even going through OpenID) I decided to answer in my blog.

Alexander GNOME 3.0 and Gtk+ 3.0 are sticking to C. Actually, the core of GNOME won’t move away from C, GObject is the core of our technology, we are happy with it. Anyone willing to see GNOME moving away from that will have to hold his hopes.

Now, one of the main points for us using C is that it makes our life easier when we bind our APIs to other platforms, it also allows not only to bind easily, but to make very platform-alike APIs integrated with the STL in the case of C++, being very Pythonic in PyGtk, very .NET-ish in the case of C# and so on…
Our vision is that the core is done in C, and you write your apps on whatever platform you like.

Now, Vala is not really something to replace C, rather than something that allow us to use C and GObject in a much more usable way. The Vala compiler is a C#-like language that translate C#-like objects to C using GObject.

The “write your stuff on whatever platform you like” point has a risk, we end up having leaks on how much can we reuse from what people build on top of their platforms. Most people are not willing to write new widgets on C because GObject despite its wonders, is tedious to write and all the boilerplate involved is quite scary.

This is where Vala comes in. Vala allows you to write stuff in a high level language (actually, Mono/C# stuff is quite easy to port to Vala) and then that stuff you write is core-compilant, meaning it’s something that could go to the GNOME libraries and being reused by the whole stack. Not to note that it’s actually a very powerful GObject learning tool as you can check what the C output is for the Vala code you write.

Now, Vala is no all wonders, it still needs work on the documentation side, and the APIs are not fully stable (they’ll be stable as soon as GObject-Introspection is stable ;-), however, at the moment it already is a great tool for fast prototyping of things that would potentially go in the core and write apps based on already well tested APIs (which is the case for the most common stuff already).

As for the general trend, there’s no general trend at the moment, some people are trying Vala and I have not heard anyone in the community being against it, some people are using some brand new JavaScript-GObject bridges using GObject-Introspection (the guys doing 3.0’s desktop shell for example).

But there’s not such thing as GNOME 3.0 would be in language X. We are happy with C, and we will stick to C so that others can use our stuff and stick to whatever they already use at the same time.

I wonder if this post is making you feel any less confused. 🙂

Gtk+ CellRender in Vala

How much code does it takes to implement a CellRendererPixbuf-alike CellRenderer for Gtk+ in Vala?

For the very basic stuff, around 40 lines of code actually:

using Gtk;
using Gdk;
class MyCellRenderer : Gtk.CellRenderer
{
  /* icon property set by the tree column */
  public Gdk.Pixbuf icon { get; set; }

  /* dumb constructor */
  public MyCellRenderer () {}

  /* get_size method, always request a 50×50 area */
  public override void get_size (Gtk.Widget widget,
                                 Gdk.Rectangle? cell_area,
                                 out int x_offset,
                                 out int y_offset,
                                 out int width,
                                 out int height)
  {
    /* The bindings miss the nullable property, so we need to check if the
     * values are null.
     */
    if (&x_offset != null) x_offset = 0;
    if (&y_offset != null) y_offset = 0;
    if (&width != null) width = 50;
    if (&height != null) height = 50;
    return;
  }
  /* render method */
  public override void render (Gdk.Window    window,
                               Gtk.Widget    widget,
                               Gdk.Rectangle background_area,
                               Gdk.Rectangle cell_area,
                               Gdk.Rectangle expose_area,
                               Gtk.CellRendererState flags)
  {
    var ctx = Gdk.cairo_create (window);

    if (&expose_area != null)
    {
      Gdk.cairo_rectangle (ctx, expose_area);
      ctx.clip();
    }   

    Gdk.cairo_rectangle (ctx, background_area);
    if (icon != null)
    {
      Gdk.cairo_set_source_pixbuf (ctx, icon,
                                   background_area.x, background_area.y); /* draws a pixbuf on a cairo context */
      ctx.fill();
    }
    return;
  }
}

This works with Vala 0.5.6, check the sample in the Vala site for a working test case.

Using a high level language to generate reusable stuff is priceless 🙂

Back to Dublin

Back to Dublin, it was great to see friends and family again, but I have to admit that I love being back in routine, when I don’t have anything to do I spent too much time in front of the computer till late at night, and then I spend the whole morning sleeping… then I get sad and angry because of the biorythm shift, too bad. Anyway.

I got the chance to organize a gathering with some friends from elementary school, most of us never heard anything from each other since 10 years (when we went to high school). It was really nice to get back with some of the fellows from my childhood and see how things were going for them. I’m glad they all are doing fine.

I went to Madrid with Roberto, Maria, Garnahco and Juanje (yeah, GNOMErs, all of them) for the last two days of my vacation, which turned out to be frozen by the snow, my plane got delayed by 4 hours (not a problem with a good book on physics though) first time ever that the Barjas airport gets closed, and first time ever that I throw snow balls to someone (sorry Maria).

On applets, launchers and notification areas

The last post from Ted Gould nails a pretty obvious problem on the GNOME desktop nowadays: the panel is broken.

Not only because of the fact that is one of the remaining bits holding a dependency against ORBit. But also from the ui perspective. The panel is where we throw stuff when we don’t know where to place it. The topic discussed in Ted’s post is quite interesting, the abuse of the notification area. I kind of disagree that apps tend to use the notification area because is some sort of playground or innovation space or anything like that.

I think applications are leaning towards a better window management handling that cannot be achieved with launchers or the task browser.

Think about it for a moment, we have launchers, like the browser one. You launch your browser, and suddenly, you have to waste, I don’t know… 200 pixels for a new task on the task bar? Plus the already wasted space of the launcher of course. Now your app turns out to be so nice, that people want to use it all the time, becoming a persistent app. Well, wasting 200 pixels for each window of your app seems a bit odd, so you end up using the notification area, or creating your own applet to manage your app.

To me, it seems that we could perfectly merge launchers, applets and notifications. Think about it, remove the text from the task manager (which I think that is useless with the amount of windows that people handle nowadays) , allow iconification/minimize from there, allow notifications and rich interaction (showing the album cover for media players, custom context menus…). From the user perspective, this would remove a lot of redundancy.

I think that a dock-like approach such as avant window navigator  (with some GNOME HIG+usability+accesibility’s sauce first of course) or Karl Lattimers’ toy as even would be a much simpler, uncluttered and usable option than our current box of entropy.