I must admin that I am getting a bit afraid about how some people starting to "dictate" what should be included in Meego.
I have seen more than once how especially Arjan is saying ideas and codes comming from .... may not be included? I can understand the 11 february bigfail (IMHO) but still should we trash everything comming from Nokia now? I dont think soo, cause it will be a big mistake for the Open community and Meego in the long run! As Kate says Handset UI is different from Tablket UI and soo on soo both are needed hopwever the API should be compatible as much as possible... So lets discuss this open before making decisions. That includes both "hobbyists" and the companys involved in Meego. Personally i think Nokia should open the QT-Components for Meego ASAP. That would also help the Nokia N900 DE project is my guess... Please dont take this as flamewar. I just saying what I think about this. And maybe I am misunderstand Arjan but anyway :-) (CC:ed to all involved) Regards Mikael 2011/5/4 <[email protected]> > > On May 3, 2011, at 4:15 PM, ext Arjan van de Ven wrote: > > > On > >> + Will be developed open soon > > > > and is thus completely irrelevant. > > sorry. > > too little too late. > > we're shipping in 2 weeks.... > > whatever we do afterwards better be compatible with what we shipped, or > we will likely pass on inclusion. > > > > I think that it should be completely irrelevant about argue that issue. > Intel and Nokia both developed their components > this year as closed, both ended different solution, Intel just happened > release their result same weeks before Nokia. > > > >> we'd have two incompatible sets of tablet apps. Those that use MeeGo > >> UX Components, and those that use Qt Components, with either tablet > >> not able to run the other framework. > > > > today, compliance does not yet cover the components, but you're making a > very good case that it should.... > > And I really hope that we should look this issue in larger context, not > only as MeeGo tablet, not even > MeeGo only. Still, largest Qt and Linux communities lives outside of MeeGo > scene and there > is no good reason branch own way. > > Even Qt components are developed as mobile origin they hopefully will > replace old QWidget > API in all Qt applications including all mobile environments and desktops. > As far as I know, > we least have now Desktop components for Linux desktops/Mac/Windows, Nokia > MeeGo Components, > Intel MeeGo component and Nokia Symbian components. Lets see what Android > Qt community does... > > It is advantage to all developers to get API's harmonized and application > portability between > environments as easy as possible. > > Just having Qml made already porting easier when C++ part does not need to > be modified, components > made it even more easier when there were ready made UI components and > having common API > for components makes it even easier. We should still remember that no > solution removes all porting work. > There is no automatic way to make exactly same Qml code offering optimum > user experience in > desktop, tablet and different handset platforms because just the native UX > differs between platforms. > Just as example desktops does not have stacked windows concept at all and > using concept of fill in forms in > handset is in most of cases insane, you should use rather scrollable list > .. > > Thing is little bit easier in mobile touch screen devices but no automatic > magic can provide solution even > between different device classes with same platform. Compare iPhone and > Ipad or Android phones and tablets. > different physical screen size and different resolution affects to mobile > UI code a lot. > > > Kate > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines >
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
