• Combine auto-completions from different sources (called “providers”)
• Add auto-completions in an asynchronous way
• Support to add extra information to the auto-completions

For now, Anjuta uses only the first two but it’s really planned to add API Help for symbols.

Despite having a more stable and tested code and a nicer UI that means that he will never be disturbed while typing because the editor is searching for auto-completions to appear. Instead all this now happens in background and it really feels fast. This also gives us a possibility to add macros/snippets directly into the auto-completion framework. Screenshot:

There are also some other interesting things coming soon:

• a better engine for C++ (auto-completion of class-members, etc.)
• GSoc JavaScript plugin which needs to be merged
• a new bison/flex based automake parser as project-manager backend (probably won’t be finished until 3.0)
• a completely rewritten git UI

GtkNotebook with action widgets

(Note that the buttons here are just examples and this was done mainly for testing purposes).

Why could this be useful:

• Firefox-style “Add tab”-buttons
• Saving space when dealing with notebooks that have a constant (and low) page number
• probably much more

There is nothing in the HIG yet of course and you should use it with care. I hope it’s useful though.

Credits go to Carlos Garnacho for the original patch and to Mathias Clasen for reviewing my patch and adding GtkBuilder support. Also thanks to Openismus for letting me finish this!

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.

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!

PPA for Johannes Schmid

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.

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.

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!

• 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!