I was planning to announce this on Monday, after a week-end to clean things up, but since another widget with similar features have been announced today, I think I should announce mine as well!

So libchamplain is a Gtk+ widget that aims to display rasterized maps (OpenStreetMap, Google Maps and others) using Clutter to have nice animations.  It is in a workable state (only zooming is limited for now, and that’s what I was planning to iron out this week-end).  See the web site for detailed feature and planned features.

You can grab the LGPLed code on gitorious.  Comments, reviews and patches/branches are welcome

Update: I created a screencast to demo it, but we can’t really see the nice animations here.  How do we do a nice screencast of a Clutter based app?

Update: I pushed the missing marshal file, thanks bpeel.

I’ve been having issues with Google Talk for some days now.  At first, I didn’t bother to look for the source of the problem, but right now I can’t event see all my online contacts (and that’s no mater which Open Source IM client I use).

I’ve started telepathy-gabble with debug to get the right error message:

<error code=”500″ type=”wait”><resource-constraint xmlns=”urn:ietf:params:xml:ns:xmpp-stanzas”/><text xmlns=”urn:ietf:params:xml:ns:xmpp-stanzas”>Too many stanzas sent per day.</text></error></iq>’

It all looks like my account had been suspended for sending too many messages but it isn’t the case.  It is funny because empathy was giving me “Messages is too long” error messages and pidgin was saying “Unauthorized”.

So where’s the problem? Did my account get high jacked to send spam? are there issues with the Google Talk XMPP servers (I recall people having issues yesterday)?

I think the utilmate solution will be to just create an account on a real XMPP server and drop Google Talk at once.

Update: problem solved, the service is back to normal.  Go figure what happened!

This Arstechnica article is quite interesting…

Also, NPAPI support is already in the Gecko web rendering engine.

I’d like to correct a perception here: NPAPI plugins are supported in QtWebKit (current SVN and future releases) and WebKitGtk.  In fact, Marc Ordinas i Llopis made it work months ago!

Alberto, starting from your prototype UI, I let my mind free.  I think the flow feels simpler, and it is less cluttered to the eye.  Since all lists are searchable, I removed the search area.  I moved the buttons under the font list because I think that we always select a font in this order: Font face, font weight and style, then size.

I still think we might need more labels to explicitly tell the user what is listed in the font list.  This version also has the advantage that if a font name is too large, you can always resize the window.

Anyway, that was my 2 cents I am no HIG specialist.

That’s a feature I was missing in Gedit: the ability to quickly switch from the header file (e.g. a .h file) to the body file (e.g. a .cpp file) and vice versa.  So I wrote a plugin!

See the plugin’s page for details.

Everybody have heard that WebKit is the new cool kid.  Here is one reason: it is rather easy to hack on.   My colleague at Collabora, Siraj Razick, mixed up QWebView and QGraphicsItem to allow developers to put the Web inside a QGraphicsScene.  As he demonstrates, you can do crazy graphics with that.

From there, I went to look at how we can implement the same behaviour we have in one of the popular mobile browser these days.  Here’s the result: stefani.ogg (Stefani is the name of our hacking app).

In this video, you can see that each time I click on a paragraph, its content is zoomed to fill the screen.  If you click again, you get back to the full page view.  At all time the page is live and active (it isn’t a static image), although that can prove to be an issue (like mistakenly clicking on a link while in full page view).

You can try it if you want, just keep in mind that this is a quick prototype and it doesn’t really support scrolling yet.  The code is here: http://git.collabora.co.uk/?p=user/pierlux/stefani.git;a=shortlog;h=refs/heads/pierlux-zoom 

Now more details on how this works: on double click, I do a hitTestContent() at that position.  With a patch we wrote, you can access the HitTest’s bounding box.  That is how I determine on what to zoom.  After that, it is simple mathematics, signals and QTimeLines.

Granted this method is rudimentary and does not always gives the best result, it works with patched current available API.  A more elegant solution (which we may write in the future), would be to use a DOM API and access the node that was clicked on.  From there, you could go up the DOM tree and see if a particular div would be more interesting to zoom on  (ie, if a <p> tag is contained in a <div>, zoom on that <div> might also contains the title of the paragraph).  But first, we have to write that Qt DOM API :).