Just a quick blog to say that the old Clutter Odo demo now lives in Mx as a dedicated widget. Its been tidied up so that it's much easier to use and animate. Also in the video, MxWindow which uses client-side window decorations and demonstrates Clutter's support for argb visuals under a compositor. Note that of course the video isn't recorded at 60Hz and also impacts on performance - this runs silky smooth on typical netbook hardware.
Download video
As always, Mx is available from git at git://git.moblin.org/mx
I'll be there.
Since getting back from my month-long holiday a few weeks ago, I've been working on Moblin's next-generation, Clutter-based UI toolkit: MX. You can check this out on moblin git. We're really hoping that we can make this toolkit all you'd need in writing a modern, Clutter-based application for Moblin, so if you're interested, please do check it out and give us some feedback! If you're already acquainted with the Moblin infrastructure, you should know that this obsoletes NBTK.
Today, I 'finished' on one of the new widgets that we'll be providing, MxPathBar. This is very similar to the breadcrumb-bar in the GTK file-chooser, with the added bonus of having an 'editable' mode that allows you to search. We intend to use this in the media library, and perhaps in the file-chooser (more on that at a later date...) Here's a little demonstration - note that this is pre-final stuff and animations/graphics may improve :)
Download video
The astute may have noticed that the default browser installed in Moblin 2.1 is not Moblin Web Browser. There are various reasons for this, but if you're interested in trying out the Moblin Web Browser (and how it would have been had it been included with 2.1), you still can by following the instructions here: How to install Moblin Web Browser in Moblin 2.1.
Note that development has already moved on quite a lot since the snapshot in the 2.1 repositories, and performance has been massively improved (to the point where it is almost indistinguishable, performance-wise, from Firefox, as long as you don't suffer from this bug). If anyone's interested in seeing the latest browser bits, do comment or drop me a mail and I'll see if I can get more up-to-date packages available somewhere.
I get mailed about it on a semi-regular basis, so the following is an updated version of the guide I wrote before on building Moblin Web Browser. Note that many things have changed since the last guide, so if you gave it a go then and weren't impressed (or even if you were), I'd recommend giving it another try! I'll try to keep this updated.
Some notes
I'm going to assume that you build all of this in $HOME/moblin and that you're ok with mozilla living in /opt/mozilla-headless (trust me, it's for the best). I'm also going to assume that you have a system already setup for developing GNOME/Gtk applications. And that you have Mercurial and Git installed. You'll also need to install autoconf2.13 if you don't already have it. For those with non-debian systems without sudo setup, replace 'sudo [stuff]' with 'su -c "[stuff]"' (or setup sudo).
Step 1
Checking out the source
cd ~/moblin
git clone git://git.clutter-project.org/clutter
git clone git://git.clutter-project.org/clutter-gtk
git clone git://git.clutter-project.org/clutter-mozembed
git clone git://anongit.freedesktop.org/ccss
git clone git://git.moblin.org/clutter-imcontext
git clone git://git.moblin.org/nbtk
git clone git://git.moblin.org/mozilla-headless-services
git clone git://git.moblin.org/moblin-web-browser
hg clone http://hg.mozilla.org/incubator/offscreen mozilla-headless
You may also need a check-out of libunique; instructions here.
Step 2
Building Clutter
cd ~/moblin/clutter
git checkout -t origin/clutter-1.0
./autogen.sh
make
sudo make install
cd ~/moblin/clutter-gtk
git checkout -t origin/clutter-gtk-0.10
./autogen.sh
make
sudo make install
cd ~/moblin/clutter-imcontext
./autogen.sh
make
sudo make install
Note that if you want documentation, all three of these accept '--enable-gtk-doc' as a configure parameter. These should all install in /usr/local by default, you should check that this is setup in /etc/ld.so.conf.d, and you may need to run 'sudo ldconfig' after installation.
Step 3
Building Nbtk
cd ~/moblin/ccss
git checkout libccss-0.3.1
./autogen.sh --without-rsvg --without-soup --disable-ccss-cairo --disable-ccss-gtk --disable-examples
make
sudo make install
cd ~/moblin/nbtk
./autogen.sh
make
sudo make install
Note about documentation still applies. You can get nicer build output from libccss by specifying '--enable-shave' too (used by Clutter and co by default), and if you're a developer, you may also want '--enable-debug'.
Step 4
Building Mozilla
Download this file to your home directory before starting.
cd ~/moblin/mozilla-headless
hg checkout headless
make -f client.mk configure
cd ../mozilla-build
make
sudo mkdir /opt/mozilla-headless
sudo chown $USER:$USER /opt/mozilla-headless
make SKIP_GRE_REGISTRATION=1 install
Now, this is the slightly less straight-forward bit. You'll either need to add a file to /etc/ld.so.conf.d to add '/opt/mozilla-headless/lib/xulrunner-1.9.3a1pre/' and '/opt/mozilla-headless/lib/xulrunner-devel-1.9.3a1pre/' to your default library search path, or you'll need to alter your environment to add them to your $LD_LIBRARY_PATH. I'd recommend the latter, and doing it in your ~/.bashrc, making it easier if something goes wrong.
You'll also need to add '/opt/mozilla-headless/lib/pkgconfig/' to your $PKG_CONFIG_PATH. Again, I'd recommend doing this in your ~/.bashrc. Don't forget to run 'sudo ldconfig' after installation, if necessary.
Step 5
Building ClutterMozEmbed
We're almost there now :) If you've followed all the previous steps correctly, it should all be downhill from here (in a good way).
cd ~/moblin/mozilla-headless-services
./autogen.sh --enable-gnome-proxy
make
sudo make install
cd ~/moblin/clutter-mozembed
./autogen.sh --enable-plugins --enable-im
make
sudo make install
Again, the only slightly non-standard thing here is that mozilla-headless-services is a dbus daemon and you may need to setup your system for dbus service activation to work from the /usr/local prefix. Most distributions do this by default, but if yours doesn't, have a look in /etc/dbus-1. If you can't get that to work, you can run the daemon manually with '/usr/local/libexec/mhs-service'. Don't forget 'sudo ldconfig'!
Step 6
Building Moblin Web Browser
cd ~/moblin/moblin-web-browser
./autogen.sh --disable-netpanel
make
sudo make install
You should now just be able to run 'moblin-web-browser', although you may want to run 'moblin-web-browser -w' so that it doesn't launch full-screen (and you may also want to alter the .desktop file to do this by default when launching from the applications menu). If you find any bugs that aren't also present in Firefox on Linux, please file them over here (don't forget to check for duplicates first!) Happy surfing :)
After some back-and-forth e-mails between some potential users of ClutterMozEmbed and myself, I tonight implemented the ability to have transparent page backgrounds. All that's needed is to call clutter_mozembed_set_transparent (it's default off as I'd hope that cairo is more performant when using 24-bit rendering...) and for your page to not have any opaque frames (the window background will already be transparent).
Unfortunately, I'm terribly unimaginative, so I couldn't think of a decent demo. Here's what I came up with - this is a demo from chromeexperiments.com (ironic), running transparently over the test-actors demo in Clutter. To add to the irony, it's Clutter rendering the 2d surfaces and Mozilla rendering the 3d part :)
Click to play
Here are the slides, code and the transcription of my Clutter animation talk. This is the latest version that I gave earlier today at OSCON, based off of the version I gave at GCDS. Hopefully people will find it of use (note, presentation in OpenOffice format, transcription in plain ASCII text, code in tarballs inside the zip).
In case anyone's at OSCON and, miraculously, follows my blog (likely via aggregation) but doesn't follow my twitter and hasn't already heard it from other more popular blogs, I'm reiterating my GCDS talk about animations using Clutter here at OSCON tomorrow at 10:45, Meeting Room C2. I'll also be doing a chalk talk at the Intel booth, 1:30pm, on the work that went/goes into building the Moblin Web Browser (so if you want to check if your pet complaint(s) from the beta have been fixed (they have), please drop by!)
Note that I've beefed up the talk a little bit since GCDS and added a couple of new demos, some more slides and generally more detail. I under-ran pretty spectacularly at GCDS and I don't think it'd be prudent to rely on having as many questions as there were there, so hopefully I'll gauge time a bit better this time around! I hope to see you there :)
And the slides/code will be online soon, honest!
I've not blogged in a while, but now we've released, I figure it's time to break radio silence. Since we were assimi^Wacquired, I've been hard at work on browser bits. I've already blogged about the headless Mozilla back-end and accompanying Clutter library; since then we've created a Mozilla services daemon and we've made the source code for the browser public.
I've been meaning to blog for a while about Mozilla, and the current trend of abandoning it in favour of WebKit. I'm not against WebKit and there are definitely advantages it has over Mozilla in certain situations, but I'd like to highlight some of the great things in Mozilla and why I think we ought to reassess the whole webkit move.
Comparing Mozilla and WebKit is quite a difficult task. They're extremely different. Yes, you can use both to render web pages, but WebKit won't do much more and it's the least that Mozilla can do. This difference affects things at pretty much every level; their structure, their API, their coding styles, their build systems, everything. I'd also say that, in the long run and given its current maturity, this is a huge advantage for Mozilla. Want a download manager? Just use the built in Mozilla download manager. Want to override it? Sure, that's fine, just implement the interface and register it at run-time. This is the same for pretty much any component you can think of that may be required for anything web-related. Use WebKit and you'll have to implement all of these things from scratch, there's no fallback option (generally). On the other hand, the WebKit API to implement these things will probably be a bit nicer. Swings and round-abouts.
And that whole run-time overriding thing? Very cool. Pretty much everything in Mozilla has an interface definition and is accessible and overridable via XPCOM. At runtime. Anything that uses Mozilla has a powerful and accessible extension mechanism, something that I don't believe WebKit can boast. Not only does it have this mechanism, but there's already a huge community of talented developers that are well versed in it.
The last advantage (that I'll mention) that I think Mozilla has over WebKit is a slightly political one; From my experience (and this is purely anecdotal, I don't mean to offend anyone), the Mozilla developer community is a lot more open and a lot more willing to take risks. I think their extensible architecture helps this, but it does seem to be a prevailing mindset amongst Mozilla developers. They really want to see Mozilla succeed in every way, and to encourage its development in all directions. Obviously, I'm sure the powers that be also want to see WebKit succeed, but it's not the innocent, wide-eyed enthusiasm that I'd like to think embodies Mozilla developer spirit. The fact that I've been given a repository hosted upstream at Mozilla.org for our headless backend says something, and the amount of support and encouragement I've received from Mozilla developers has been nothing short of astounding.
So why exactly did we (Gnome) abandon Mozilla? Maybe people thought that contributions to the gtk embedding API (which has some annoying bugs and an API that could really use some love) wouldn't be accepted? From my experience, I think this would be highly unlikely. Why exactly are we creating an entirely new backend and API for a new rendering engine (an API that bears an eery resemblance to gtkmozembed anyway, in a lot of places) when we have a perfectly capable, and in fact more than capable platform, funded by a foundation and accepting of contributions? There are a lot of problems with Mozilla. I do wish they used autotools, for example, and I've often run across a bug in my code that's down to me not having some obscure and highly undiscoverable knowledge... But these problems can be fixed... And are becoming fewer... So what's the deal?
This year's FOSDEM was really quite excellent, not least because I was giving a talk this time ;) It was great to put a face to some new names, and to see familiar ones too. I won't go on, but the highlights for me were definitely the Xorg and Mozilla talks (not to say there weren't some great talks in other rooms too, I enjoyed the webkit/ebooks talk, and the gnustep theming talk, to name just a couple). I was also quite impressed the presence and apparent mindshare that KDE 4.2 displayed as well. It's looking a lot nicer than it once did.
For those who were unlucky enough to miss my talk, or for those unlucky enough to have been there (I admit I don't always speak in coherent sentences), I've uploaded the annotated slides. Load it up in OpenOffice and check out the 'Notes' tab to get a small write-up of what I was talking about during each slide (as well as a lot of information I missed out as I rushed through the talk!) In case you didn't already know, the talk was about the headless Mozilla backend I've written, as well as ClutterMozembed.
Thanks to Intel for helping me get there, the guys in Intel OTC UK for being supportive and great people to work with, and to all those who acted as if my talk wasn't a complete shambles; thanks for humouring me! I kid, of course, I think it went pretty well considering it was my first talk outside of university... But yeah, thanks and good night :)
