Drag & Drop in Glom

24. October 2007

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…)

Glom drag & drop 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.

Today, I added a very simple feature to anjuta which makes it possible to build your project inside a scratchbox environment. It does not take care about execution and debugging yet but that’s not so important for me at the moment.

The last weeks I mostly hacked on drag-and-drop layout support for glom. It is far from finished at the moment and anyone is free to make suggestions how improve the whole dnd handling.

Today, I heading for the German Cup-Final in Berlin tommorow and I hope Nuremberg will win it’s first title after 39 years (including several years in the second and even one in the third league).

There are new packages availible for maemo bora:

  • Update: Packages for glibmm/gtkmm: These packages fix a nasty bug that will cause a crash when using Gtk::TextBuffer so everybody is encouraged to upgrade
  • New: Package for libgda3 which brings the GNOME database power to maemo. Please note that this is not yet the final release of libgda and that the packages may have some rough edges.

Both packages are available from the bora-extras repository:

deb http://repository.maemo.org/extras/ bora free
deb-src http://repository.maemo.org/extras/ bora free

So, I finally got to hacking on the cairo support for maemo-launcher. Thanks to Behdad and Owen for pointing me in the right direction.

My patch adds a method to booster_preinit which draws some demo text (“Maemo launcher”) to a image surface using pangocairo. Obviously this is enough to init most of the font stuff of pango and thus speeds up the application start-up for my test-case, the hello-world example from the GTK+ tutorial, by 50%. Again, I may be totally wrong with my results of course as times tend to be very small on a normal PC. I would be glad to hear from poeple using embedded devices if this is a real performance gain.

Start-up time Diagram

The only problem with the patch currently is that I use “Sans 10” as hardcoded value for the font. I have not yet figured out a good way to get the default font without opening a display.

Update: Obviously the font is totally irrelevant! I just removed the line and everything was as fast as before which means the upon layout drawing as font initialisation is done!

All this was done for Openismus in case anyone did not know!

Today was the time to get some results on the improvements that can be reached using maemo-launcher. Of course all this tests might be inaccurate and wrong…

At first, I needed a simple example so I took the Hello World! example from the Gtk+ Tutorial. The only code change was to add a GTimer and to print the elapsed time before gtk_main() is called. I now made some test runs (not enough for a statistical correct result…).

Result Gtk: maemo-launcher speeds up this example by about 25%. That could mean the Gtk initialisation takes about 25% of the start-up time. Of course in bigger applications this value will decrease as they do much more than just to init Gtk and create some widgets.

So, the next step was to test what happens to an application that uses Gtkmm instead of Gtk. Again, I used the simplest example from the tutorial, Hello World in gtkmm and modified it to install a timer before Gtk::Main::run(). This test did not give me that nice results as the above. The standard deviation was much higher so I assume caching has a much bigger influence here.

Result Gtkmm: The speed-up reached by the launcher using the gtk booster was about 22% in average but in a range from +54% to -59%. If I used the new gtkmm booster together with the gtk booster I gained 35% more speed and the range was only +65% to -11%.

Overall results: It seems like maemo-launcher does speed things up a bit. On my laptop this only means some milliseconds but maybe it is more important on embedded platforms. I still wonder why I have such a big standard deviation with the C++ code. You can have a look a the exact results (gnumeric sheet)

All this was done using gtk+ 2.10.9, gtkmm 2.10.8 and maemo-launcher from SVN TRUNK. I had to modify the Gtk booster to work with 2.10 which means that it does only init all the GTypes but avoids all the more advanced hacks that no longer work because many leaks in Gtk have been fixed.

Today, I hacked a bit on maemo-launcher to add support for multiple boosters. It was not very difficult but quite annoying because string handling and lists without Glib are a real mess!

The gtkmm-booster seems to work good now and I had no problems to launch the complete maemo-desktop and the maemomm-helloworld example. There are some instructions in the README to set up the launcher correctly.

Anyway, I still miss a real-life test-case and good ideas how to measure the performance. My laptop might be about 10 times faster as the N800 so I can’t “feel” any performance changes. I also have no real idea how to get objective results.

maemo gtkmm booster

1. March 2007

To speed up application start-up the clever people at Nokia wrote Maemo launcher. It is a quite dirty hack that tries to keep many things in memory and to fork to main() once an application is started.

Of course something like this would be nice for gtkmm/maemomm too. maemo-launcher supports different booster modules and thus we can add a gtkmm booster modules. I spent most of the day figuring out how all this works and finally finished a very simple booster. The gtkmm booster currently simply calls the methods from the gtk booster (as we need all the stuff from gtk anyway) but in the future it will also do some gtkmm specific stuff.

If you are interested you can have a look at the sources (you will also need the patch from this bug against maemo-launcher). It is still broken in many places but at least you should be able to start some apps. Start the launcher using maemo-launcher --daemon --send-app-died --booster gtkmm.

Anjuta 2.1.1

12. February 2007

So not even one month after the last release, anjuta 2.1.1 hits the road. We have fixed a lot of annoying bugs so I hope you will enjoy this release. We will continue to concentrate on bug-fixing but will probably create some interesting branches in the meantime to get even more cool feature in. Grab it from Anjuta.org!

As Murray already posted we at Openismus are still working on finishing libgdamm and libgnomedbmm. We did not expect that we would have to work so much on the C sources (see my previous post) but I hope we can finish them soon.

Use construct properties

2. February 2007

This is a comment for all people writing GObject-style libraries that may have to be wrapped for other programming languages (C++, etc). And as you only write cool libraries which will be that useful that they will one day be wrapped, this applies to all your libraries.

Construct properties
Add a property for every parameter of your _new method. These parameters can be restricted to G_PARAM_WRITABLE|G_PARAM_CONSTRUCT_ONLY if it is useless to set them after initialisation. The actual setting is done by overriding the set_property method of GObject. You can also ref/unref you parameters if necessary there.

The *_new method
The new method should just consist of one call to g_object_new(MY_TYPE, “foo”, foo, “bar”, bar, …, NULL). NEVER add anything else to this method!

The _init method
Here you can do as much initialisation work as you like. This method is called by the GObject system and thus will be accessed from all language bindings.

Why?
When wrapping a library it is lots of work and takes lots of time to convert every parameter to a construction property and to move all other initialisation code from _new to _init. Besides it is clean and everybody will start loving you…(and you would have saved me at least two hours today!)