Sugar now on Mandriva's cooker

Today I managed to run Mandriva's development stream (cooker) on kvm-qemu and gave a test to the Sugar packages that Aleksey Lim has been working on during the last weeks.

And all I have to say is big kudos to Aleksey. Thanks to him we have Sugar on the path to be well supported in one more major distribution, and one that is working hard to put linux to work on education.

Galeon and learning

Reinout van Schouwen said about Embedding Mozilla...
> Let's build a GTK+ shell around it and call it Galeon! =)

Actually, that's an interesting point. What I talked about is more like a mixture of embedding a browser (Galeon) and messing with the document content in a scripting language (Greasemonkey).

So, nothing new under the sun, but one more way of doing the same that may be more convenient in some occasions.

In Sugar, the single reason why we cooked our own solution is so the user can study the code of our browser and make modifications to it as easily as possible (freedom 3). We don't want the user to just 'use' the software we provide and to calmly wait for the next release, but we want them to 'create' new tools based on what we provide.

If we had kept using gtkmozembed, our browser would have had a bigger proportion of C/C++ code (less easy to study and modify) and would have mixed javascript and python (more effort required to study and modify).

At the end of the day, Sugar is not one more productivity desktop, but a learning platform. And in the same way that each individual learns in his/her own way, they need to be able to suit their learning tools to their learning habits.

Perhaps not everybody that uses Sugar will learn to code, but at least those people that have the inclination to write small amounts of code (spreadsheet macros, for example) will be able to add a button there, transform the document viewed, etc. And then share it with their friends.

Embedding Mozilla

To finish this series on embedding existing GNOME stuff in new apps, this is one of the design mockups of the browser in Sugar:


We are implementing it with Mozilla for now (though would love to have an alternative in WebKit as well, code welcome) and after some time using gtkmozembed, Marco decided that we would be better off with something lighter (read less buggy), with less amount of C code and with easy access to PyXPCOM. Then hulahop was born.

This is the simplest snippet that will bring you an embedded instance of mozilla into your pygtk app:

import os

import gobject
gobject.threads_init()
import gtk

import hulahop
hulahop.startup(os.path.expanduser('~/.hulahop_test_profile'))
from hulahop.webview import WebView

w = gtk.Window()
w.show()

v = WebView()
w.add(v)
v.show()

v.load_uri('http://planet.gnome.org')

gtk.main()

But that isn't anything that gtkmozembed cannot do, so if you add the following snippet just before the call to gtk.main(), you will get something more interesting ;)

import xpcom
from xpcom.components import interfaces

class ProgressListener(object):
    _com_interfaces_ = interfaces.nsIWebProgressListener

    def onStateChange(self, webProgress, request, stateFlags, status):
        if not (stateFlags & interfaces.nsIWebProgressListener.STATE_IS_NETWORK and \
                stateFlags & interfaces.nsIWebProgressListener.STATE_STOP):
            return

        images = v.dom_window.document.documentElement.getElementsByTagName('IMG')
        for i in range(images.length):
            image = images.item(i)
            if image.src.startswith('http://planet.gnome.org/heads'):
                image.height *= 3
                image.width /= 3

listener = ProgressListener()
wrapped_listener = xpcom.server.WrapObject(listener,
                                           interfaces.nsIWebProgressListener)
v.web_progress.addProgressListener(wrapped_listener,
                                   interfaces.nsIWebProgress.NOTIFY_STATE_ALL)

As you can see, with hulahop you have ready access to most mozilla internals, in the example above we are manipulating the document DOM, but you can also access network stuff, security, user events, etc

Right now, those snippets will work only on Fedora 10 unless you build your own stuff. But as in the abiword case, people are already working on packaging hulahop for all the major distros.

And what about the future? I would love to see more applications to provide their canvases as proper gtk widgets and moving them to libraries. The ones on the top of my list are gnumeric and inkscape, any suggestion?

Embedding abiword

After yesterdays bit about how really soon we'll be able to easily embed evince in any gtk app, today is abiword's turn.

This is the UI that Eben designed for the Write activity in Sugar:



And this is one of the quickest ways to embed abiword using python:


from abiword import Canvas
import gtk

w = gtk.Window()
w.show()

c = Canvas()
w.add(c)
c.show()

gtk.main()


If you are curious about what you can do programaticaly with that Canvas instance, just type pydoc abiword.Canvas.

The only distros I know where this snippet should work are Fedora 10 and 11, but there are already some beautiful souls in #sugar who are working to make sure that it will be available in the next releases of Ubuntu, Debian, Mandriva, Gentoo, OpenSUSE and others.

Update: more and better info about PyAbiword here.

Embedding Evince, GNOME Mobile and GNOME 4.0

Evince gets embeddable

The fine evince hackers, with special mention to Carlos Garcia Campos, have been of great help during the last week as I was trying to get upstreamed our sugar-evince fork.

Sugar had to modify Evince so we could link python programs against it and build the intended user experience, quite different from that in GNOME. Several people (Marco Pesenti Gritti, Reinier Heeres and Daniel Drake) had worked on it during the last two years, though in the rush to ship a complete learning environment, never got to upstream the changes. Check out the design mockup by Eben Eliason of our document viewer:


So Evince 2.25.5 is going to ship with libevview and I'm going to ask for an exception of the API freeze so we can get the python bindings in the next release of gnome-python-desktop. Then you will be able to write something like this and get your own document viewer:

import evince
import gtk

w = gtk.Window()
w.show()

e = evince.View()
w.add(e)
e.show()

document = evince.factory_get_document('file:///home/tomeu/Desktop/comic.pdf')
e.set_document(document)

gtk.main()


What has this to do with GNOME Mobile?

GNOME Mobile is a platform for other people to build their own software on. Most of the solutions that people base on GNOME Mobile will be able to run unmodified GNOME applications, but given hardware constraints or different intended user experiences that won't happen too often.

Platforms like Maemo have had to maintain their fork of Evince and apply patches to it so they can provide a document viewer that conforms to the Hildon UI guidelines. I can only guess that this is very expensive for Nokia, and what about other vendors interested in basing their software on GNOME Mobile? Will they have the resources needed to maintain forks of all the GNOME applications they wish to reuse?

So I hope other people will feel attracted by the advantages of exposing widgets out of apps and we can work together so as time passes more and more GNOME apps can be embedded and new UIs get built around them.

And GNOME 4.0?

I have no idea what GNOME 4.0 will be, but I know that lots of people (and organizations) in the GNOME world are not resigning themselves to build a Windows-clone and are willing to explore new user experiences that help computing to bring more benefits to more people.

By splitting base functionality to shared libraries and making easier to build new UIs around them, we have a better base on which to play and experiment, until the day will come ;)

Upstreaming the evince changes

The other day in #sugar happened a little conversation that left me quite a bit worried. Turns out that in order to have distros shipping a working pdf reader (Read) in Sugar, we need first to upstream changes we did a couple years ago and have been periodically rebasing.

As OLPC isn't the only kid playing in SugarLand any more, we really really need to have distros to ship a minimally complete Sugar environment in their next releases in a couple of months from now.

So started the upstream process and any help is more than welcome: http://sugarlabs.org/go/Evince

What I've been up since the last post

Haven't had much time to blog because of the holidays and the imminent feature freeze on Jan 16th.

So here comes a summary of what I have been up to since the last post on Dec 20th:

• Review and push Ryan Kabir's work on moving some actions from the palette of the big XO icon in the favorites view to the frame, so it's always accessible regardless of which view you are in:
  
  


• Kept working on the file transfer UI, lots of polish is still needed


• Added an utility class (util.TempFilePath) that hopefully will remove the temp file leaks we have been suffering in past releases


• Bunch of bugfixing, specially in the journal: #36, #38, #126, #131, #132, #165, #3060


• Lots of work on removable devices in the journal. It should be pretty much usable now without using an index nor ever writing to the device. Performance isn't too bad and it's near to be feature complete


• Change the favorites view to display the last entries for every activity and resume by default when the icon is clicked. There's still quite a bit of work to do in order to not confuse people, specially hint more strongly about naming activities.