Hello, >From documentation's perspective: -There are two component sets (MeeGo and Symbian) but a subset of them share the same core functionalities (clickable, checkable, etc.) -There should be two sets of documentation for each component set because the component documentation can link to the other components in the set easily. (MeeGo Button doc can mention that there is a MeeGo XComponent).
There is a strong will to bring these two different component sets together, but it doesn't work in their current state, especially if we document their current states as the same component set. Either detach the common components from the MeeGo/Symbian components set so they can exist on their own (Qt "multiplatform" components), or just accept that the component sets are different (MeeGo set and Symbian set). It's quite apparent that the core common API are pure functional properties, and not visual. As soon as we describe the visual properties, we must diverge into Symbian design guidelines and to MeeGo design guidelines. Diverging is not necessarily bad because we can then focus and cater a documentation product(with demos, examples, and guides) to each component set. Here is a look at the documentation of the public repository: http://4fid15742.noe.nokia.com/doc-qt-components/common.html. The APIs haven't been updated, so don't worry about those. We, the doc team, are handling the two components set as two different sets. If we can combine them in the future, then great, but if that's not possible, then we have two documentation products that we can proudly display. Cheers, Jerome P. ________________________________________ From: Hartz Henrik (Nokia-MS-Qt/Oslo) Sent: Wednesday, February 23, 2011 2:20 PM To: Koehne Kai (Nokia-MS-Qt/Berlin); Pasion Jerome (Nokia-MS-Qt/Oslo) Cc: ext Thiago Lacerda; qt-compone...@trolltech.com Subject: Re: [Qt-components] Components Application Template Hi, I think the main issue is that _right now_ and possibly for the near-term, native is not a viable solution as the primary offering because of visual differences as well as the fact that e.g. symbian doesn't have all of meego components or vice versa. Therefore, I suggest that we rather make a duoplicy of wizards that use the platform-specific imports, but we'll still leave the Qt.labs.components.native import there. So, we provide a labs feature that people can try and help move into a future mainline feature - while encouraging developers to optimize for the target platform. The open question to me is how we can handle this in e.g. Documentation. Jerome, what do you think? Sound sensible? Cheers, Henrik On Feb 22, 2011, at 10:37 AM, ext Kai Koehne wrote: > On 2/21/2011 3:34 PM, ext Thiago Lacerda wrote: >> Hi, >> >> Why don't you use the "native" import, instead of "symbian" or "meego"? >> Would not be more suitable in this case that you want the same example >> to run in different platforms? > > You're of course right, thanks for the tip. Anyhow, depending on whether > I install the meego or the symbian plugin last the 'native' components > show up as either meego or symbian. What I would expect is a runtime > switch (maybe an environment variable) so that people on the desktop > have a way to switch between symbian & meego styles without uninstalling > one or the other :) Has anybody looked into this already? > > Regards > > Kai > >> Cheers >> >> On Mon, Feb 21, 2011 at 10:07 AM, Kai Koehne <kai.koe...@nokia.com >> <mailto:kai.koe...@nokia.com>> wrote: >> >> Hi, >> >> I'm trying to come up with a common application template for a Qt >> Creator wizard. That is, a minimal 'hello world' app that runs on both >> Symbian, Meego, and future desktop components. I thought about having an >> ApplicationWindow with 'Exit' as a menu option, and a sole Page on the >> main PageStack saying 'hello world'. >> >> >> Right now I have the following: >> >> main.qml: >> -- >> import QtQuick 1.0 >> import com.meego 1.0 >> //import com.nokia.symbian 1.0 >> >> ApplicationWindow { >> id: appWindow >> >> PageStack { >> id: pageStack >> anchors.fill:parent >> } >> >> MainPage { >> id: mainPage >> } >> >> Component.onCompleted: { >> pageStack.push(mainPage); >> } >> } >> -- >> MainPage.qml: >> -- >> import QtQuick 1.0 >> import com.meego 1.0 >> //import com.nokia.symbian 1.0 >> >> Page { >> id: mainPage >> Button { >> anchors.centerIn: parent >> text: qsTr("Exit") >> onClicked: { >> Qt.quit(); >> } >> } >> } >> -- >> >> The aim is clearly that the same code is generated for the different >> target component sets. >> >> And here are the issues I couldn't solve so far: >> >> - com.nokia.symbian by default already shows an 'Exit' button in the >> bottom menu, but Meego does not. I can create a Menu/MenuItem in Meego, >> but these elements seem not to be available on Symbian so far. >> >> - Is there an easy way to have a 'hello world' label with a decent font? >> I tried Text { text: "Hello World" }, but this one doesn't pick up the >> font size / color for either Symbian (black on black) or Meego (font too >> small). >> >> - While the ApplicationWindow root window on Meego has a decent default >> size when displayed in the qmlviewer, the Symbian example does not: It >> starts with the minimal size enforced by qmlviewer. >> >> - The custom style branch right now seems not to feature any of the >> 'high-level' elements I've used (ApplicationWindow, PageStack, Page). I >> guess it is planned to add these, too? >> >> I'm happy to file each of these as individual tasks if that helps. >> Anyway, feedback on the individual issues + the skeleton itself is >> highly appreciated :) >> >> Regards >> >> Kai >> >> -- >> Kai Koehne >> Software Engineer >> Nokia, Qt Development Frameworks >> >> Nokia gate5 GmbH >> Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany >> Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B >> Umsatzsteueridentifikationsnummer: DE 812 845 193 >> Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori >> _______________________________________________ >> Qt-components mailing list >> Qt-components@qt.nokia.com <mailto:Qt-components@qt.nokia.com> >> http://lists.qt.nokia.com/mailman/listinfo/qt-components >> >> >> >> >> -- >> Thiago de Barros Lacerda >> OpenBossa - INdT >> > > > -- > Kai Koehne > Software Engineer > Nokia, Qt Development Frameworks > > Nokia gate5 GmbH > Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany > Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B > Umsatzsteueridentifikationsnummer: DE 812 845 193 > Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori > _______________________________________________ > Qt-components mailing list > Qt-components@qt.nokia.com > http://lists.qt.nokia.com/mailman/listinfo/qt-components _______________________________________________ Qt-components mailing list Qt-components@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-components
