RE: Goal for GNOME Mobile?

[<Carlos Guerreiro nokia com>]

> On Mon, 2008-11-10 at 14:08 +0200, Quim Gil wrote:
> > The trap of keeping the GNOME identity tied to a specific technology
> > (GTK+) as a best replacement for a lack of identity and vision (*).
> > This approach worked during the first decade of GNOME, I 
> just wonder 
> > whether it can be kept for the mobile decade.
> 
> I was meaning to bring this point up over the weekend as part 
> of the Clutter inclusion question.  During the meeting at 
> GUADEC there was a general consensus that:
> 
> a) Clutter should be added to GNOME Mobile
> b) The best way of determining if something can be considered 
> to be using "GNOME Mobile" -- given the flexibility and 
> freedom inherent in the stack -- would be to say "uses either 
> Clutter or GTK+".
> 
> So, do we still agree that Clutter should sit alongside GTK+ 
> in the GNOME Mobile 2.26 diagram, as an 
> optional/complementary user interface library?  Devices can 
> use just GTK+ and be GNOME Mobile (Vernier, current Maemo), 
> or have a primarily GTK+ interface with Clutter parts and be 
> GNOME Mobile (Ubuntu Mobile, Maemo Fremantle I imagine), or 
> be purely Clutter and still be GNOME Mobile (nothing here yet).

Hi,

Here's my take on this (I say yes to Clutter in case you don't want to
read too much ;-)

GNOME Mobile can be two things:

A) A set of software projects roughly clustered based on working well
together.
Maybe glib/gobject is the lowest common denominator but the key point
for me is that
the people developing these packages intend them to work well together
and make sure they stay like that.
So it's possible to release a working set regularly.
Downstream you can take a substantial subset of this software and build
something useful with it, be it a platform like ALP or Moblin, a product
like Vernier's or something like Maemo which is kind of both.
You choose what to use to build the UX you want. If you are careful you
get some portability across different
environments but not complete since the GNOME Mobile stack isn't built
high enough for that.

In this view goals include making the software rock (compared to the
competition and the state of the art), getting it adopted as widely as
possible and increasing the mass of contributors to the effort.

At this point, it is clear for me that Clutter belongs in GNOME Mobile.
Clutter was designed and developed to fit in the GNOME cluster of
technologies and works well with them.
More importantly, GTK+ is in my view not enough any more by itself to
develop a compelling modern UX.
Clutter is the best option we have now to plug the gap in the GNOME
Mobile cluster of technologies.
That's the reason the next iteration of Hildon uses both GTK+ and
Clutter.
I'd rather do a mobile device UI with Clutter only than with GTK+ only
though we're not there.

B) A mobile "desktop" environment with a distinct (but flexible and
customizable) user experience. But as suggested by Lefty and Paul
scoping out kernel and other low level stuff would be a good idea, so it
wouldn't be a complete stack all the way down.
Naturally this "desktop" is built on the software described in (A) so
(B) is a superset of (A) in a way.

(A) Is a reality, demonstrated by many real products in existence. It
can be made better of course and it needs to. There are also various
companies clearly motivated to fund activities because they are
downstream, invested in the success of the software.

(B) Is an exciting possibility but much harder to do. Making it happen
is an ambitious goal in itself. It requires a critical mass of motivated
and available developers, a well-defined scope (range of form factors,
UX principles, key functionality,...), leadership and so on - just as
much as the GNOME Desktop does, or probably even more since the mobile
landscape is more heterogeneous and there are more possibilities to
choose from.
In this case who is downstream to benefit and invest in the whole
(rather than the parts) and more critically to put it in the hands of
actual users in actual devices?

Br,
Carlos