With the unstable developers release of Clutter 0.7.0 there were some API changes related to the new layout system. So I did another update of the examples and text in Openismus’ Clutter tutorial (also available as PDF). Coming from a GTK+ background I really like the new layout abilities including the height for width (and width for height) layout geometry support. The old Clutter 0.6 tutorial is still available as HTML and PDF.
I have been added to Planet GNOME, so a short introduction:
My name is Jan Arne Petersen, I am a 27 years old software developer living near Cologne, Germany and working at Openismus. I am involved in the GNOME project since 2002. In this time I contributed features and bug fixes to different applications and libraries (like e.g. GnuCash, GTK+, Nautilus and Totem) and supported the GNOME booth at different German Linux events. Before my involvement in the GNOME project I was the initiator and lead developer of the JRuby project.
As announced by Murray I have started working at Openismus. Two of the tasks I did in the first week:
Clutter Tutorial
I updated the source code examples of the Clutter tutorial written by Murray to make them run with the current unstable development version of Clutter. I never used Clutter before but it is a really nice library and the tutorial helps a lot to understand Clutter concepts like Timelines and Behaviours. (Patch to update the examples).
Tool Palette
There is a generic tool palette container developed by Openismus. I continued Mathias’ work by adding new features such as support for scroll to group (show as much items of a group as possible when expanding) or RTL language support:
There is a bug open in GTK+ which allows to use some additional layout options for tool items. It would allow something like an enhanced BOTH_HORIZ style:
or vertical, aligned text in the TEXT style:
The EggToolPalette is already usable. The source code is avaiable: svn co http://svn.gnome.org/svn/libegg/trunk libegg
Viewvc: http://svn.gnome.org/viewvc/libegg/trunk/libegg/toolpalette/
Use
The testtoolpalette.c example shows some more features (like drag and drop support).
I don’t like such applications on my N810:
The application could be ported to use a HildonWindow if compiled for the maemo platform. But it would be much easier if there were an abstract GTK+ widget which would allow it to add a menu and toolbars to a window in a (platform specific) default layout.
I imagine something like:
With this proposal, it would also be possible to implement a Mac-style MenuBar without a GtkMenuBar hack.
See Bug 533003.
p.s. I don’t like the name GtkMainWindow. Maybe something like GtkDefaultWindow or GtkSimpleWindow would be better.
Beside the hidden scrollable interface there is another interface hidden in GtkWidgetClass::activate_signal.
See Bug 532795 for an implementation of an explicit Activatable interface to replace this class variable.
I don’t like to search my rhythmbox icon in the notification area. There is a patch attached to bug 531282 which provides a solution (GConf-Key: /apps/panel/applets/{$notification-area-applet}/prefs/order).
In GTK+ 2 there are scrollable widgets like GtkTreeView, GtkTextView or GtkViewport but no GtkScrollable interface. Instead a scrollable widget is defined by a “set_scroll_adjustments” signal, which id is written to the GtkWidgetClass::set_scroll_adjustments_signal class variable.
If a scrollable widget is added to a GtkScrolledWindow the set_scroll_adjustments_signal is called and the hadjustment and vadjustment from the GtkScrolledWindow are passed as parameters to the scrollable widget. The scrollable widget than replaces its own adjustments with the ones it got from the GtkScrolledWindow. If the scrollable widget is removed from the GtkScrolledWindow it recreates its own adjustments.
This model seems to be simple, but all scrollable widgets need (and set) specific values for GtkAdjustment::lower, ::upper, ::page_increment and ::page_size and the adjustments are required by the size-allocate function. So the adjustments should actually be owned by the scrollable widget and not by the GtkScrolledWindow.
For GTK+ 3 I propose a simple GtkScrollable interface with a readable hadjustment and vadjustment property. If a widget which implements GtkScrollable is added to a GtkScrolledWindow the GtkScrolledWindow should use its adjustments.
See Bug 468689 and the attached patch.