On Fri, May 28, 2010 at 12:37 PM, Robin Burchell <[email protected]>wrote:
> On Fri, May 28, 2010 at 8:06 PM, JD Zheng <[email protected]> wrote: > > I was looking for the answer to "to Qt or not to Qt" for all MeeGo UX and > > seems I am unable to get consistent answer. > > I was calling for community involvement for non-Qt app porting, seems it > is > > just "wasting time", which implies the current GTK app will stay there as > > MeeGo core app and it basically says NO to my original question. > > Why wasn't moving to rpm "wasting time"? We followed the decision even if > we > > disagreed, why decision can easily be reverted now for other reasons? Or > > maybe we shouldn't discuss decision in the first place? > > As Paul points out.. > > A lot of the applications in MeeGo Netbook at least are either > directly from- or working with upstream. Putting work into porting > something that already works essentially for religious work, and then > putting the required effort into maintaining that consistently (as > it's probably unlikely to be upstreamed, quite honestly) is a big > commitment. This is very different to the choice of rpm vs deb, which > is a downstream choice affecting MeeGo only. > > Now, I'm not saying that we (as in the wider MeeGo community) couldn't > probably do this, but two things: > - why should it be done? honestly, even with my bias (I love Qt, I > hack on it when I can, and I work with it on a daily basis) - it's > essentially a religious choice. "if it ain't broke, don't fix it" > applies to some extent here. > - you don't really *gain* anything through this port process, apart > from a longer still time before you have usable software > > With these two in mind, you're unlikely to gain commercial backing > from this, unless you have demonstrable gains and reasons to do so. > > It didn't gain much things when moving to rpm, at least to Maemo guys, But it happened. Why same thing can't happen here? I don't want to start rpm vs deb war again and probably you might notice I didn't say one word about it before. What I am questioning is how decision was made and if decision changes over time silently. Another way to fix this inconsistence is to fix Architecture diagram and any other documents and stop saying Qt is primary GUI toolkit, which I would rather not to see. SORRY, after looking at architecture diagram<http://meego.com/developers/meego-architecture> again, I found I was totally WRONG because Qt as primary GUI toolkit mentioned in previous version is NOT in it any more, though I still think this "removal" should be communicated to community clearly and early. > > Sounds like the things left to any outsider is some applications to be > done > > if no one is coding for that (well, I have no idea what is being > > developing). > > I'm not sure what you're asking here, but I'll guess that you're > asking what the point of Qt is if nobody uses it. > > Well: remember first that you're only seeing half the picture. The > handset UX isn't out yet, and from signs from Nokia[1] suggest that Qt > will have a much larger influence there. Then remember that the > application SDK for MeeGo has been announced to be based on Qt, > meaning that people writing applications for MeeGo are recommended to > use it, so the influence will grow. > > Please correct me as following is my assumption now: Netbook UX will be GTK based and no plan to migrate to be Qt based. It implied the core app existing will be using different UI toolkit with the new ones (community ones?) Handheld UX will be Qt based. Although it can have 3rd party GTK app, I suspect it will be limited. For example,if I only want to write Qt app, I can only possibly contribute to Handheld UX infrastructure when it is opened up. It is technically possible but does it make sense as our goal is to unify it, at least it is my understanding? Does it mean MeeGo Netbook = Moblin NG and MeeGo Handheld = Maemo 6 from UI perspective? > > What does MeeGo really expect from community? (unfortunately so many > emails > > distinguished "We(MeeGo?)" and community and I follow that). I was > expecting > > the answer after 1.0 release and now it is the right time to ask. > > Honestly not sure how to answer this. I don't think anyone is, yet. I > suspect the picture is becoming growingly clear as more parts of the > puzzle (like the meego-arm team) come to work and collaborate in the > open. > > The answer depend on how community is weighed for MeeGo development and how open MeeGo is planned. I don't want to start again to push the openness of MeeGo, really I am tired of it so this is my last try: The following is NOT what I expect as member of community: -- Only be told about decision and only see defensing decision after publishing or even changing decision -- Only be able to add "addon" app into MeeGo -- Only be able to send patch to *unknown* team and wait for accept/reject -- Unable to involve in any core components development (I mean the components created by *unknown* MeeGo teams.) Does fixing these mean MeeGo is an open platform? I am afraid NOT. Are these really hard to fix? It depends. Frankly I don't think so. > Thanks. > > JD Zheng > > I hope this helps you some. ;) > > Robin Burchell > mob: +447702671419 > msn: [email protected] > irc: w00t @ irc.freenode.net > twr: http://twitter.com/w00teh > lac: http://identi.ca/w00t >
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
