Oh dear. Here goes. On Fri, May 28, 2010 at 10:27 PM, JD Zheng <[email protected]> wrote: > 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.
As I *tried* to point out earlier, the situation is *TOTALLY AND UTTERLY DIFFERENT*. You cannot walk up to a project (let's say, Banshee) and say "sorry guys, but you're going to have to switch toolkit". The choice of packaging format affects MeeGo and only MeeGo. But as you rightfully say, let's not go there. > 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 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. No, you just didn't look hard enough. See that big blob marked 'MeeGo API'? Now scroll to the bottom, and see 'Qt' mentioned under that 'MeeGo API' header. Now click to the page to read what the MeeGo API consists of - I'll save you the work of tracking the link that took me under a minute to find: http://meego.com/developers/meego-api If you're going to make alarmist claims, please, at least do your research. There was no change, there is no hidden agenda. Qt is still the primary, recommended platform. If you want to use something else, of course, you'll be free to do so, at your own risk. >> > 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. I never said such a thing. I think your (bad) assumption that 'Qt is recommended therefore it must be used for everything, at the cost of getting a release out the door now just to satisfy religious goals' is a very fundamentally bad one, though. > It implied the core app existing will be using different UI toolkit with the > new ones (community ones?) Not necessarily. See above. > 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. Wrong. You can contribute wherever you like, however you like. Nobody is stopping you. MeeGo is an open platform, and at the end of the day, the recommendation for Qt is just that - a recommendation. Using Qt might mean less pain for you as the libraries underneath e.g. QtMobility might come and go (different multimedia backends and whatnot), but if you want to take the risk, I see nothing stopping you from using them directly. > 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? I don't know the plans for the handset UX, as (obviously) it hasn't been released yet, but it's safe to assume that the two will be fairly divergent. A handheld device with (let's say) a 3" screen requires somewhat different UI and interaction than a 10" netbook you have a keyboard with. >> > 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 As I already covered, you're incorrect there. > -- Only be able to add "addon" app into MeeGo No. > -- Only be able to send patch to *unknown* team and wait for accept/reject I'm not sure what you want here. To take an example (like Banshee, since Aaron keeps mentioning it in the mail below me I'm half reading while replying to this one) - you'd go upstream to banshee, submit a patch, and sooner or later, it would end up in MeeGo, since MeeGo packages banshee. Or end up a Banshee maintainer directly, thus emitting the necessity to deal with patches. If you're specifically talking about the UX category stuff, then, well yes, you'll need to get to know the relevant people working on that, and submit patches. Presumably through Gitorious merge requests. Once you've shown your merit from contributing to that software, you'll end up with access to push stuff yourself and you won't need to send patches. Like the above example. > -- Unable to involve in any core components development (I mean the > components created by *unknown* MeeGo teams.) Obviously - if you haven't talked to them, and they haven't talked to you, they're going to be unknown. This is likely at this stage seeing as things are coming out in the open. Do you have specific examples of such components? Then we can look into the situation. > 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. What are you actually trying to fix? Also, again, give examples. Let's talk specifics, and then perhaps, we can look at action if needed. 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
