On 23 October 2013 12:21, Kim, Yoonsoo <[email protected]> wrote:
> Thanks for your clarification. > But it's still vague what optionality means in your context. > > IMO, optional library(or feature) in compliance is quite different > from downloadable and upgradable library. Optional feature means that > if one manufacturer chooses to support the feature, the feature > implementation should be compliant to the related compliance > specification. But if you want to make Qt downloadable and upgradable > as a separate package, it should be dependent only on publicly > available API in each profile. > I guess that current Qt implementation is dependent on various core > components which are not officially available to applications. > If my guess is right, you are thinking that Qt should be an optional > feature in some profile's compliance specification, aren't you? > > Could you clarify more clearly what you mean by "add-on, optional > packages" to discuss this matter more effectively? or do you just want > to see Qt is supported on Tizen in one way or another? Hi Yoonsoo, Any approach is a good start but I'll give you some examples first. For example, on Android and iOS Qt is (automatically) bundled in each app package. This is technically suboptimal, on Tizen it can be considered as a first step, while on Android and especially iOS flexibility of Tizen is missing. So Tizen has potential to do much better in this regard. When Qt is bundled with app, despite overhead, there's still convenience for developers. This is also how Qt supports Tizen right now, exactly because Qt is not marked as a "system" library on Tizen profiles. Ideal situation would be if Qt was installed and shared within all processes that depend on it. Be upgradeable, have clear usage guidelines, best practices documented, and so on. In par with OSP. That's especially important for embedded use cases. At technical level the better approach is a matter of simple change. Back to the example, non-rooted Android, despite deeper differences to Linux, has a way for sharing Qt (using so-called Ministro app - https://play.google.com/store/apps/details?id=org.kde.necessitas.ministro ). On Tizen there are no technical need for adding such workarounds. So we're basically talking about approach for deployment and compliance, all that can be hopefully worked out. Qt for Tizen depends on some lower-level facilities, especially in places where performance matters, e.g. in the OpenGL-based graphics stack. I *believe* this is also the case for game engines too (Havok, Unity?) - please correct me if I am wrong. So yes, to have the best "return on investment" for this effort, explicitly letting official Qt libraries to use these facilities would be the way to go in mid term. -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
