Re: What would you do to encourage application developers on GNOME Mobile?



Am 30.04.2010 00:40, schrieb Stormy Peters:
> I talked to a number of people at the Linux Foundation Collaboration
> Summit about this. Robert McQueen had a great idea. He suggested that we
> use a Google Summer of Code model but not just for students. People I've
> spoken to all seem to like the idea so I wanted to get your opinion.
> 
> Here's how I would see it working:
> * Couple of leaders from this group.
> * Interactive open process to define projects. (People can submit their
> own ideas.) Projects would be doable in a couple of months. Projects
> would all be GNOME mobile app/MeeGo/Maemo related.
> * We would form a group of potential mentors. I'm not seeing this as
> intensive as Google Summer of Code mentorships but we still need people
> to be able to answer questions and provide direction.
> * Hold an application process. People apply and indicate which project
> they want to work on.
> * Mentors/leaders approve applicants. "Success" is defined.
> * The time period is fixed and is the same for all projects.
> * At the end, leaders/mentors decide if projects have successfully been
> completed.
> * Successful applicants get paid.
> 
> If we paid $5,000/project, we could have 10 projects.
> 
> I don't have a good feel for how much work these types of projects would
> take. (That's probably because we need to define what the projects would
> be. :)

Very honestly, I don't like the idea so much. What if we ask the maemo
developers via a surveymonkey survey what the miss most in terms of gtk+
development support. Cutting some projects out of this and then calling for
developers to realize them might work.

Stefan

> 
> Thoughts? Opinions? Interest in helping make this happen?
> 
> Stormy
> 
> On Wed, Apr 14, 2010 at 5:17 AM, Murray Cumming <murrayc murrayc com
> <mailto:murrayc murrayc com>> wrote:
> 
>     On Thu, 2010-04-08 at 08:56 +0200, quim gil nokia com
>     <mailto:quim gil nokia com> wrote:
>     > Hi Murray,
> 
>     Sorry for not replying until now. I got distracted.
> 
>     > In the context of this discussion it is useful to that Maemo 6 API
>     = MeeGo API.
>     >
>     > > If we are talking about Maemo 6, then you need to know that it
>     will be a
>     > > large amount of work to make GTK+ and libhildon properly
>     supported on
>     > > Maemo 6.
>     >
>     > Indeed, if you plan to map all the DUI libraries sitting on top of
>     Qt. What about mapping the Qt UI libraries instead?
> 
>     That would probably be easier, yes, but it's presumably a matter of
>     using Qt in a certain way. I don't believe in the just-recompile mantra.
>     It's not clear yet though.
> 
>     > > So far Nokia has only said that the community may support it.
>     > > But:
>     > > a) That won't be enough, just as it wasn't enough to get Qt
>     supported on
>     > > Maemo 5.
>     >
>     > Manpower was the only problem, right?
> 
>     Maybe, though there was also a lack of adult supervision and a refusal
>     to accept that
>     a) API additions were necessary.
>     b) It was _not_ easy to just reimplement custom widgets in applications
>     so they'd look exactly like what Hildon offered, so the development
>     direction was misguided.
> 
>     I still don't think the official port is really good enough, though it
>     makes Qt on Maemo 5 really viable. But it was quite awful before.
> 
>     > > b) The community won't have access to the necessary information
>     until
>     > > far too late. This needs people who have are on the inside at Nokia.
>     > > (like, say, Openismus. Ahem.).
>     >
>     > MeeGo plans to have a first release in May with all the Handset UX
>     whistles. I would even say that you could go to qt.gitorious.org
>     <http://qt.gitorious.org> and start the work now. Maybe there are
>     relevant bits still available inside Nokia only (honestly I don't
>     know, you might know better than me) but most of the DUI code is out
>     already and Qt itself is already integrated in the MeeGo
>     repositories since Day 1.
> 
>     I don't think anything is very clear. Maybe it will be then, though I
>     expect to have the usual complaints about lack of clear API advice.
>     However, we'll be pushing for clarity, partly by our David King working
>     on developer documentation/assistance for maemo.org <http://maemo.org>.
> 
>     > > c) It will probably require changes to the GTK+ and hildon API
>     on Maemo
>     > > 6, just as Qt has API changes on Maemo 5. So it will get conceptual,
>     > > which will slow things donw.
>     >
>     > It all depends on the approach you want to take on this. You could
>     choose a conservative approach making the current Hildon work on top
>     of MeeGo's GTK+. This probably means that Hildon apps in MeeGo look
>     and behave like Maemo 5 apps, in exchange of less work with bindings
>     and less code changes for app developers.
> 
>     That's obviously far easier, and probably a necessary first step, in
>     case the rest never gets done.
> 
>     It doesn't seem very useful in the long term though. There was no point
>     in having GTK-only (not using Hildon) or QT 4.5 (without massive hacks)
>     apps in Maemo 5, and there would be no point in having GTK+/Hildon apps
>     in Maemo 6 that feel equally out of place.
> 
>     > As a stepping stone looks good enough, and then you can decide on
>     further steps based on feedback and interest.
> 
>     Yeah, I think this should be done. It's an easy decision even if it's
>     only a small part of the plan, and things would be very bad if not even
>     this is done.
> 
> 
>     --
>     murrayc murrayc com <mailto:murrayc murrayc com>
>     www.murrayc.com <http://www.murrayc.com>
>     www.openismus.com <http://www.openismus.com>
> 
> 
> 
> 
> _______________________________________________
> mobile-devel-list mailing list
> mobile-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/mobile-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]