Qt Mobility 1.1 for Fremantle

... and a happy new year !

We have kickstarted a community 'compatibility program' with a little Forum
Nokia help which will focus on bringing the latest Qt and related tech
tools/fixes/updates to developers, without having to worry about Nokia release
schedules and support status. The first component that is released as part of
this effort is QtMobility 1.1 (as 1.0.2 is getting long in the tooth),
currently available as libqtm-11-* in extras-devel. If/when a SSU is released
with 1.1 as the official, these libraries will be replaced with placeholders
that point to those 1.1 libs. The bleeding edge can always be attained with
libqtm-experimental which will permanently remain in extras-devel (after we
test 1.1 this will switch to 1.2, etc). To use these packages you need do to
CONFIG += mobility11 in your .pro file instead of just 'mobility' (as mobility
will reference always the official one from the firmware).

Enjoy (and provide feedback/patches !)

Best regards,
Attila

Attila,

This is really great news! I assume applications using it can not promoted
to extras-testing until we have the SSU with libqtm-11-*, right?

Please let me know if I can help in any way.

Felipe

-----Original Message-----
From: maemo-developers-bounces@maemo.org
[mailto:maemo-developers-bounces@maemo.org] On Behalf Of Attila Csipa
Sent: Wednesday, December 29, 2010 9:04 AM
To: maemo-developers
Subject: Qt Mobility 1.1 for Fremantle

... and a happy new year !

We have kickstarted a community 'compatibility program' with a little Forum
Nokia help which will focus on bringing the latest Qt and related tech
tools/fixes/updates to developers, without having to worry about Nokia
release
schedules and support status. The first component that is released as part
of
this effort is QtMobility 1.1 (as 1.0.2 is getting long in the tooth),
currently available as libqtm-11-* in extras-devel. If/when a SSU is
released
with 1.1 as the official, these libraries will be replaced with placeholders

that point to those 1.1 libs. The bleeding edge can always be attained with
libqtm-experimental which will permanently remain in extras-devel (after we
test 1.1 this will switch to 1.2, etc). To use these packages you need do to

CONFIG += mobility11 in your .pro file instead of just 'mobility' (as
mobility
will reference always the official one from the firmware).

Enjoy (and provide feedback/patches !)

Best regards,
Attila

Great news and thanks - this is really needed.

Are those based on the 1.1 release version or on 1.1 branch from Git?

Cheers,
Conny


On Wed, 2010-12-29 at 16:03 +0200, Attila Csipa wrote:
> ... and a happy new year !
>
> We have kickstarted a community 'compatibility program' with a little Forum
> Nokia help which will focus on bringing the latest Qt and related tech
> tools/fixes/updates to developers, without having to worry about Nokia release
> schedules and support status. The first component that is released as part of
> this effort is QtMobility 1.1 (as 1.0.2 is getting long in the tooth),
> currently available as libqtm-11-* in extras-devel. If/when a SSU is released
> with 1.1 as the official, these libraries will be replaced with placeholders
> that point to those 1.1 libs. The bleeding edge can always be attained with
> libqtm-experimental which will permanently remain in extras-devel (after we
> test 1.1 this will switch to 1.2, etc). To use these packages you need do to
> CONFIG += mobility11 in your .pro file instead of just 'mobility' (as mobility
> will reference always the official one from the firmware).
>
> Enjoy (and provide feedback/patches !)
>
> Best regards,
> Attila

On Wednesday 29 December 2010 16:47:54 you wrote:
> This is really great news! I assume applications using it can not promoted
> to extras-testing until we have the SSU with libqtm-11-*, right?

Right (well, mostly :). For now promotions should not be possible - but we
might let these packages through to Extras as a compatibility measure later
on, depending on feedback and SSU content.

Best regards,
Attila Csipa

On Wed, 29 Dec 2010 16:03:38 +0200
Attila Csipa <maemo@csipa.in.rs> wrote:

> ... and a happy new year !
>
> We have kickstarted a community 'compatibility program' with a little
> Forum Nokia help which will focus on bringing the latest Qt and
> related tech tools/fixes/updates to developers, without having to
> worry about Nokia release schedules and support status. The first
> component that is released as part of this effort is QtMobility 1.1
> (as 1.0.2 is getting long in the tooth), currently available as
> libqtm-11-* in extras-devel. If/when a SSU is released with 1.1 as
> the official, these libraries will be replaced with placeholders that
> point to those 1.1 libs. The bleeding edge can always be attained
> with libqtm-experimental which will permanently remain in
> extras-devel (after we test 1.1 this will switch to 1.2, etc). To use
> these packages you need do to CONFIG += mobility11 in your .pro file
> instead of just 'mobility' (as mobility will reference always the
> official one from the firmware).
>
> Enjoy (and provide feedback/patches !)
>

Will a similar effort be done for N8x0 folks? Is there any technical
reason why Diablo should be locked in to qt 4.5.x instead of 4.7.1?

Joseph Charpak
josephcharpak@comcast.net

On Wednesday 29 December 2010 17:04:21 you wrote:
> Will a similar effort be done for N8x0 folks? Is there any technical
> reason why Diablo should be locked in to qt 4.5.x instead of 4.7.1?

Well, yes and no. You can certainly compile it (in fact at one point I
compiled 4.7.0 for Diablo myself, but for some reason it was fairly sluggish),
but there are things that need to be worked on before it makes sense to
release it onto unsuspecting N8x0 users

1. inputmethod stuff - this is very custom work on 4.5, so those patches need
to be transplanted carefully

2. the maemo5 module will not be available - IIUC it requires/wraps some
hildon functionality which is not available on Diablo

3. It's big. I guess most people who had interest in Qt cloned their roots
already, but it takes up significantly more space than 4.5

4. look into what's causing the performance regression

Otherwise, if I look at it from the QtQuick angle, it's actually fairly OK
(one of the QtQuick promise is actually observable here - a QML/components
based application most of the time far easier to port to Diablo with 4.7 than
a QWidget based application from Fremantle, performance notwithstanding).

Best regards,
Attila Csipa

On Wed, Dec 29, 2010 at 3:47 PM, Felipe Crochik <felipe@crochik.com> wrote:
> Attila,
>
> This is really great news! I assume applications using it can not promoted
> to extras-testing until we have the SSU with libqtm-11-*, right?
>

I've put a block in place to prevent a mess, but once we have a SSU
with newer qtm we can remove the block.

> Please let me know if I can help in any way.
>
> Felipe

--
Niels Breet
maemo.org webmaster

On Wed, Dec 29, 2010 at 5:19 PM, Niels Breet <niels@maemo.org> wrote:

>> This is really great news! I assume applications using it can not promoted
>> to extras-testing until we have the SSU with libqtm-11-*, right?
>>
>
> I've put a block in place to prevent a mess, but once we have a SSU
> with newer qtm we can remove the block.

I believe we can remove the block early next year anyway, after we see
some apps using these successfully in extras-devel. The SSU delivery
of qtm 1.1 (if/when it happens, but let's not count on it) is a
replacement for 1.0.2, and can exist parallel to these packages.

--
Ville M. Vainio @@ Forum Nokia

On Wed, Dec 29, 2010 at 4:47 PM, Felipe Crochik <felipe@crochik.com> wrote:

> This is really great news! I assume applications using it can not promoted
> to extras-testing until we have the SSU with libqtm-11-*, right?

Not really (see my reply to Niels).

> Please let me know if I can help in any way.

You and everyone else can help by switching your apps to use 1.1
packages and see whether they still work.

--
Ville M. Vainio @@ Forum Nokia

On Wednesday 29 December 2010 16:50:33 you wrote:
> Great news and thanks - this is really needed.
>
> Are those based on the 1.1 release version or on 1.1 branch from Git?

Should be the release, but the plan is to follow any point releases, i.e.
should a 1.1.1 tag appear which is an identical API bugfix release, the same
qtm-11 packages will update to that. We should also have qtm-12 which
(currently) will follow releases, i.e. 1.2 techpreview, beta, etc.

Best regards,
Attila Csipa