…and brought the new Google Summer of Code Shirt:

The main feature of the T-Shirt is being not black and actually really looking kind of non-geeky which makes it possible to wear it outside geek areas.

Based on the awesome work from Joel Holdsworth making it possible to add custom widgets to the dock item grips, I finally patched anjuta to use this ability. This can save quite a bunch of pixels:

Anjuta with new buttons in grip feature

Old pixel-wasting version

There may be still some style issues especially for the message window tabs. Suggestions welcome!

I just created a tiny ppa which contains anjuta and gdl 2.26.2 as Ubuntu is a bit slow in updating those. If you are a jaunty user I really recommend an update to the latest stable version which contains some important bug-fixes:

PPA for Johannes Schmid

As Murray already mentioned we updated the Clutter Tutorial over the last weeks for the upcomming Clutter 0.9/1.0 release. Clutter 0.9 makes some hacks obsolete that were necessary to archieve some functionality in the past so we could concentrate more on straight-forward ways this time.

The tutorial features some new sections:

• The new GtkClutterViewport widget allows scrolling of GtkClutterEmbed widgets and is decribed in the new Stage Widget Scrolling section.
• Some notes were added for using Timeline markers.
• ClutterAnimation has replaced the obsolete ClutterEffects API and thus ended up in the new Animations section. This section also explains how to use ClutterAlpha properly.
• The biggest new API is probably the new ClutterText widgets that allows use-cases from a simple label over a single-line entry to a full-featured multi-line text input box.

Unfortunately some links to the API documentation are not working yet because the clutter-gtk API documentation for 0.9 is not yet available online. The tutorial is also available as pdf.

Development of the tutorial happens in the clutter-tutorial module on GNOME git.

So, from the little hacker in me I am a bit annoyed about forking strategies some projects have. I have been (co-)maintaing gdl for about 4 years know, brought it into GNOME, fixed lots of deprecated stuff and got rid of all the non-docking stuff in the library and lots of other people helped there.

Now what happend:

• inkscape* has a fork of gdl that is probably quite old.  They made some additions that are probably useful
• Niepce forked the inkscape fork
• MonoDevelop made yet another fork of gdl, ported in to C# and dropped it again later

Nobody ever popup up in bugzilla, the mailing list or on IRC to ask if they could put some patch upstream that they needed. I am quite sure the upstream version fixes lots of problems still present in other versions and I am also sure the other versions contain some useful additions to gdl and that it would be no big deal to merge them. But as long as nobody from the projects steps up and says “Hey, here is our patch, can you have a look at it” it’s unlikely that upstream will ever be able to fill their needs. On the other hands they will never profit from upstream bug-fixes in any way.

* I think an inkscape dev once asked for a non-gnome version of gdl which was added later (and is now obsolete as there are only gtk+/glib dependencies left). But there was no further conversation.

So, please STOP this!

Act like Joel Holdsworth from the Lumiera Project. He poped up on the mailing list and said he would need gdl but would need some small additions. Afterwards he put in lots of patches, documentation updates and bug-fixes to make life easier for everybody.

That being said, both inkscape and Niepce are in C++ so it would make lots of sense for them to share a common gdlmm binding. Inkscape uses some non-standard binding method for gdl with lots of hand-written code.

Some people might say that gdl should be merge into gtk+. This may be done someday but gdl is not in a stage where it makes sense to consider it. It does a good job but it is far from perfect and it is even the question from a UI perspective if the averange application really needs to have such a heavy docking library in a general-purpose toolkit.

Some instructions here because the porting guide in the Gtk+ docs is quite short at the moment:

Convert the files

gtk_builder_convert <old_glade_file> <new_gtkbuilder_file>

Code changes

• Remove #include <glade/glade.h>
• GladeXML* => GtkBuilder*
• glade_xml_new (FILE, “first_widget”, NULL) becomes
  
GError* error = NULL;
GtkBuilder* builder = gtk_builder_new();
if (!gtk_builder_add_from_file (builder, FILE, &error)
{
g_warning ("Couldn't load builder file: %s", error->message);
g_error_free(error);
}

• glade_xml_get_widget (gxml, “widget_name”) becomes GTK_WIDGET (gtk_builder_get_object (builder, “widget_name”))
• glade_get_widget_name (widget) can be replaced by gtk_widget_get_name(widget)
• glade_xml_get_widget_prefix (gxml, “prefix”) can be emulated by gtk_builder_get_objects(builder) together with manual filtering. It returns a GSList* instead of a GList* though.

That’s it basically. Don’t forget to adjust your Makefile.am to install the correct files and update POTFILES.in!

Just some self-promotion: The Anjuta News Blog already has some interesting entries and might be worth reading. It should hopefully appear on news.gnome.org soon, too

After reading the 3.0 plan of the release-team I was curious what the end-users would say. It is rather difficult to find out because there is no average end-user. Anyway, I tried to summarize opinions from two popular german computer magazines:

• Heise-online: The biggest computer magazine in Germany (online and offline). They feature a rather big and detailed article on GNOME 3.0.
• Pro-Linux News: This is a non-profit Linux News site. Their article is smaller and the Nerd-factor of the readers is certainly a bit higher here.

Apart from some more off-topic posts (GNOME vs. KDE, MacOS is the only real thing, etc.) on the Pro-Linux board the reactions were quite similar with those main points:

1. Don’t make it a KDE 4.0! People rely on a stable desktop…
2. This looks interesting and cool! GNOME really needed some revamp…
3. Hmm, I cannot see why this is better than now – do we need it?

The rest of the comments are mostly based on misunderstandings (heise writes that “Zeitgeinst” will replace Nautilus which is simply untrue). Funny enough though, quite a lot of people comment that they liked our little steps in 2.x a lot which most sums up with point 1. These was much less critism than I expected actually and instead people applaud us for the work in the past years.

Of course this is no representative review about user comments, it is just a small limited summary (only German, people who are really interested in computing). In the end I think we seem to do well, but should mind the three points raised: Make it stable, make it cool, make it useful!

Yesterday, I started to implement Murray’s/Mathias‘ idea to add the ability in GTK+ to add a widget beside the tabs of a notebook. This makes of course only sense in application where only a few notebook pages are used usually and there is a lot of space left in the tab area. But of course it will also allow to add little combo boxes in this area like Mozilla Firefox, to give the user some additional features for the notebook navigation.

The basic code is now in place and it is less complicated then I expected. Anyway, there is still some stuff to do:

• Position of the widget (like GTK_PACK_START/END)
• whether the widget should take the whole space available (GTK_EXPAND)

The API is pretty simple up to now and only consists of gtk_notebook_set_tab_widget (). Patch coming soon to your nearby bugzilla.

So, yeah, we relaesed another version some days ago. You may want to read the previous posts about the new features here. Most notibly in the final version was the addition of  version control information to the file viewer. You can now see the status of your files using an emblem system like the famous TurtoiseSVN for Windows. It is actually meant to also work for git and we hope to get this done very soon in the next stable versions. There are some bugs preventing it at the moment. Otherwise everybody has done a great job and we significantly reduced the amount of bugs (from about 120 to 70, exluding enhancements)

As usual you can get the lastest version here:  http://download.gnome.org/sources/anjuta/2.26

Another interesting thing for some people is probably a new alpha version of the vala plugin. It’s still a bit buggy and incomplete but I would invite some of the vala developers out there to try and improve it.  It’s completely written in Vala so you can have some fun in this area!

Happy coding!