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

[From: Devesh.Kothari at nokia.com]

> -----Original Message-----
> From: maemo-developers-bounces at maemo.org
> [mailto:maemo-developers-bounces at maemo.org]On Behalf Of ext 
> Shawn Gordon
> Sent: 19 April, 2006 19:15
> To: maemo-developers at maemo.org
> Subject: Re: [maemo-developers] Maemo 2.0 API changes, signals
> andproperties (was: ANN: Eagle)
> 
> 
> I gotta say as a third party developer that the state of Maemo is 
> rather frustrating, it seems like a far from done piece of work and a 
> moving target.  I've seen a lot of complaints on industry reviews of 

- First it is expected to be a moving target :) [improved features, bug fixes, runtime performance improvements etc ..]
- Its strange to say "Maemo ... far from done piece of work". What are your expectations???

IMHO Maemo 1.1 provides a solid start point. Its gives you capability to write, test, cross compile in a easy to use environment. Most of the developers have really appreciated the kind of plumbing less (if a word like that exist:) development environment. There are short commings, but I dont think developers with C/glib/gtk/sdl have any major issues. Community has been great at pro actively providing great support to who asked for it on developer mailing lists, and have produced so much sample code (sdl games, hildon apps, plugins etc), to make up for lot of still missing documentation. 

As for other things source code to almost everything is available (http://maemo.org/lxr/), browse it and you would know in most cases, what is going wrong. Most places, examples could be found together with source e.g http://maemo.org/lxr/source/maemo-examples/

I agree it all can be better organized (and we working on it), as for API breaks, Maemo almost all is built on top of open source projects (hildon/hildon desktop/haf included), so we just need to be able to deal with it (API changes, reasonable effort is made not too), important thing is we are able to communicate them early on (again a work item)


> the device as well to the stability and selection of software 
> included on the device.  What's happening at Nokia to help with this 
> and remove the perception that the device is a beta unit?

As with all devices, you get some good reviews, some ok, and some bad.
What is important is we are commited to delivering good quality products 
for our focused target segment.

Devesh

> 
> thanks,
> shawn
> 
> At 08:52 AM 4/19/2006, you wrote:
> >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-B
ase-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>
>
>_______________________________________________
>maemo-developers mailing list
>maemo-developers at maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
www.mindawn.com
949-713-3276


_______________________________________________
maemo-developers mailing list
maemo-developers at maemo.org
https://maemo.org/mailman/listinfo/maemo-developers