[Dev] Qt in Tizen - project proposal

Jaroslaw Staniek staniek at kde.org
Wed Oct 23 11:21:40 GMT 2013


On 23 October 2013 12:21, Kim, Yoonsoo <yesarang.kim at gmail.com> 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


More information about the Dev mailing list