Glom now bascially starts up on maemo fremantle which means that gtkmm, libgda, libgdamm and pygda are working together now on the maemo platform. Of course lots of bug-fixing and UI work left to make this really cool.

Screenshot:

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.

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.

Since viewing log files can be some kind of annoying when you are only interested in a special problem I wrote a patch to filter/highlight specific sections of a logfile with gnome-system-log. A screenshot says more than thousand words:

Screenshot of gnome-system-log highlighting all gdm messages

The filters are based on regular expressions and should thus be quite flexible. The work was done (and paid) by Openismus Gmbh!

Has anybody experienced with gtk+ an idea about this bug?

Thanks!

P.S.: Hello Planet Openismus! And yes, I am working on this hackergotchi thing…

After working the last couple of weeks for Openismus on updating libgdamm to the new API of libgda 4.0 I can finally announce libgdamm 3.99.0, the first unstable release of what will eventually become libgdamm 4.0.

It breaks API with the existing libgdamm 3.x line and replaces various classes with superior implementations. This should bring a lot better performance. Thanks to Vivien Malerba for his great work on libgda and for fixing all the C++ relevant bugs I filed.

You can download libgdamm here: http://download.gnome.org/sources/libgdamm/3.99/

Now, we can finally start to port glom to the new API and fix bugs!

As I am usually far to lazy to RTFM I had to learn how to add externals definition to subversion the hard way. But as other might probably need it, too, here is how it works (mind the dot at the end…):

svn propset svn:externals "<directory name> -r<revision> http://svn.gnome.org/svn/yourmodule/trunk/your_directory" .

The problem is that after that command it will not work because you have to commit the property change first:

svn commit -m "Changed external property"

So here is the final example:

svn propset svn:externals "eggtoolpalette -r853 http://svn.gnome.org/svn/libegg/trunk/libegg/toolpalette/" .
svn commit -m "Added eggtoolpalette"
svn update


And now you will have eggtoolpalette revision 853 in your tree. Thanks to herzi for helping me solving this problem on IRC.

Joining the recent discussion about Ubuntu packaging policies I would really prefer if they would update their versions to the stable branch. For us developers it’s a lot of work to backport things to the stable branch and fix the major bugs in it. We do that because we don’t want to force people to use unstable versions and because the stable version has lots of users and therefore lots of testing. In general it is unlikely that a x.0 version will ever be released without some minor/major bugs because the development version has never enough testers and something will be missed. Anyway, we do more stable releases for the one and only reason that distributions can update their packages and give their users better software. If you don’t trust us that our new stable version won’t brake everything than we really can’t help you that much.

Anjuta 2.3.3 was released yesterday and this will mean that UI should now be frozen. We did a lot of bug-fixing in the last weeks. Thanks to all those people testing and reporting bugs and writing patches. Also thanks to my two GHOP Students, Philipp Kerling and Boleslaw Kulbabinski for their work and I hope to see future constributions from them. [EDIT] Forgot that I wanted to ask for some volunteer artists to have a look at #511000 and maybe also #510047.

In the meantime I have been working on the Glom drag & drop stuff for Openismus. Unfortunately there is still nothing that could be shown but be sure that I will post a screencast once it is finished.

There has been a lot of discussion about locking upstream translations in Launchpad. Many translation teams agreed here but we probably have to sent some official request to the Launchpad people. I hope that is no big deal as we usually have a good relationship with Ubuntu.

Glom drag & drop layout

Currently I am working on drag & drop layout support for glom (see #35809). After fighting a lot with GtkContainer internals I finally got the preview working more or less. On the screenshot you can see how the preview currently looks like. Of course this could be improved in many ways and it would be nice to get some feedback from UI designers how to improve the visual appearance of the preview. (Unfortunately you cannot see the mouse pointer in the screenshot…)

The next steps are to create a nice toolbar-like window you can drag the new layout items from. Murray proposed a vertical bar which could fit good IMHO.

Anjuta progress

As you probably noticed already, we released a new bug-fix version (2.2.2) which should fix most critical bugs and some little usability problems. Anyway, the more interesting things happen in trunk, where Massimo is working on a new symbol browser that will support more languages and gives us much better informations about the available symbols. Sébastien is doing an awesome work on the debugger and many other parts of the code. tpgww (AT) onepost.net created great artwork for all kind of things and is continuing to add a lot of patches to bugzilla. I will show you more of the new features, once we have our first beta release (hopefully together with GNOME 2.21.1).

Blog migration

BTW, if you can read this I successfully migrated my blog from my own (outdated and probably insecure) wordpress installation to blogs.gnome.org. Thanks to Jeff for updating p.g.o and to the sysadmins for creating and maintaing this service!

This post is for all people that need debian packages for their software but are far too lazy to really learn all this packaging from the beginning. But be aware that it is really easy to build broken packages. I will not explain how to build packages for simple applications since this is explained quite good in the Debian packaging guide. Anyway, it does not explain library-packaging at all.

Packaging a library is not really difficult most of the time. Given that most GNOME libraries share a very common build system layout it would be a waste of time to start from scratch. So we search for a library the seems to be a good starting point for our own package. In my case, packaging libnotifymm, this was obviously glibmm. So first step, get the sources of that package:


apt-get source libglibmm-2.4-dev


Next step, copy the debian directory over to your project, not very tricky either, and delete the useless changelog:

cp -r glibmm-2.4-2.13.3/debian libnotifymm
cd libnotifymm/debian
rm changelog


Now, you end up with some files in the debian directory:

• copyright: Check the license, put your name in, etc
• control: The most important file. Replace the name of the library you took as sample with the name of your actual library, take care of the versions and update the dependencies. With an appropriate sample file the format is quite obvious.
• *.dirs, *.install: These file show where the library gets installed on the system. Normally you should not have to change much here apart from renaming the files from oldlib.dirs to newlib.dirs. But always take a look a the files as there is probably mentioning the old package somewhere and you want to change that.
• rules: Do not touch for now. Hopefully it will just work, otherwise you will notice that later

In the end, create a changelog using this command which will ensure you have the correct format:

dch --create


Now, let’s give it a go:

dpkg-buildpackage -rfakeroot


If you are (too) lucky, you will have fresh debian packages now. If not, it’s time to check the rules file for stupid shell scripting. The error messages normally give you some indication what could have been wrong. You may need some tries before everything works smoothly.

When you have finished, check if the packages install cleanly on your system and explore them with file-roller to see if they really install all the files needed.

As said before, this is really not the greatest way to create packages and you will do better if you read all the documentation about building packages. But often you get the idea from looking at other packages.