On Fri, May 28, 2010 at 3:02 PM, Robin Burchell <virot...@viroteck.net>wrote:
> Oh dear. Here goes. > > On Fri, May 28, 2010 at 10:27 PM, JD Zheng <entropy....@gmail.com> 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. > Does Netbook UX follow this MeeGo (Qt 4.6.2) API? Will it? Or GTK 3.0(?) API will be added? I think I wasn't too lazy to research but few things can be researched. What I got is "Qt is primary API, but we want to use these "good old" application/components so that they can be exceptions for "good" reasons". Can I change it? Does someone want to change it? Probably not. I am just one lonely guy who wants a unified platform for MeeGo :-( > >> > 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. > > My ("bad") understanding is Qt won't be primary API if core components are written in GTK. Yes I like Qt, but I don't hate GTK. The issue is inconsistent and NOT unified platform. I didn't say that everything had to be Qt based because of this. You guys must know much more than me about whether it is feasible to create a good, consistent UX using 2 UI toolkits. > > 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. > Nobody is stopping me but such kind of misinformation and lack of information is stopping me. How to dig information is what I learned in these months with MeeGo. Unfortunately I was really bad at that even though I think I am a good reader. Wrong/inconsistent information frustrates people, doesn't it? > > > 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. > > Screen size is a totally different story. I don't buy it if someone says this toolkit fits in 10 inches screen while for 3 inches we need to use another. > >> > 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. > I don't know how much you involved in closed door MeeGo development. Most likely it is incorrect to you but it is true to me as a totally individual member/outsider. > > > -- 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. > > About all rest, I did ask project definition and was told to wait (see TSG meeting minutes) and wait. As neither Intel/Nokia employee nor paid contributor, do I have multiple channels to get contact information? Do I have to submit patch to get contact someone? Even if I contact someone, how can I know if I am not talking to wrong person so that I won't waste my (and his/her) time? > Robin Burchell > mob: +447702671419 > msn: m...@viroteck.net > irc: w00t @ irc.freenode.net > twr: http://twitter.com/w00teh > lac: http://identi.ca/w00t >
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
