[maemo-developers] [maemo-developers] Maemo 2.0 API changes, signals and properties (was: ANN: Eagle)

[From: Tommi Komulainen]

On Tue, 2006-04-18 at 08:51 -0300, ext Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> Eagle (http://www.gustavobarbieri.com.br/eagle/) was ported to
> Maemo/Hildon (http://blog.gustavobarbieri.com.br/2006/04/eagle-in-maemo.html).

In your blog you had mentioned this:

> However I opted to not port every component, like HildonColorButton
> or HildonNote because I think they're not well designed, they don't
> even provide signal "changed", used by Eagle's DataWidget to persist
> data automatically. As API will change in Maemo 2.0, I won't bother
> with this until then.

HildonColorButton and HildonNote APIs are not changing in any signifcant
way, so don't let that stop you from including more widgets in the
supported list.

Hildon-related API changes are more or less limited to HildonApp and
AppView and gtk_infoprint (and widgets no one was supposed to be using
anyway)  See http://maemo.org/maemowiki/HildonWidgets for a bit more
details.


HildonColorButton doesn't need a specific "changed" signal, it is
already provided, though it's called "notify::color" and the callback
signature is slightly strange
(http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#GObject-notify)
(The older version of generated API documentation misses some crucial
bits like signals and properties, the new API has slightly better
generated documentation in
https://stage.maemo.org/svn/maemo/projects/haf/doc/api/hildon-libs/HildonColorButton.html)

It's a less known feature in GObjects that all properties have implicit
"changed" signals associated with them. It has the benefit that you
don't need multiple "foo-changed", "bar-changed", ... signals for
complex objects.

So the lack of "extra" signal is intentional and we plan to use the same
design in new widgets as well, see HildonProgram for example.


-- 
Tommi Komulainen                            <tommi.komulainen at nokia.com>