Re: [MeeGo-dev] Segmentfault one calling QSensorManager::createBackend ( QSensor * sensor )

[He, Yunlong]

I also compiled sensor_explorer from the example code, it also cause segment 
fault on real device.

Is there any other ways to get sensor capabilities?

I am using MeeGo 1.1, is it the reason? Will it work on MeeGo 1.2?

B.R.
He Yunlong

From: Zhao, Forrest
Sent: Wednesday, May 11, 2011 1:06 PM
To: He, Yunlong; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Segmentfault one calling QSensorManager::createBackend 
( QSensor * sensor )

Did you ever look into qtmobility-examples? You can find the proper usage of 
sensor API.

If you’re sure that you use the API in correct way, please file a bug at 
bugs.meego.com and attach your program to reproduce the bug.

Thanks,
Forrest

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of He, Yunlong
Sent: Wednesday, May 11, 2011 12:55 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Segmentfault one calling QSensorManager::createBackend ( 
QSensor * sensor )

Hi, Experts,

  I am trying to get sensor types supported by one device, so I tried to use 
QSensorManager::createBackend ( QSensor * sensor ), however, it cause 
application segment fault with QOrientationSensor, do you know whether this is 
a bug? Or is there other ways to get supported sensor list?

Best Regards
He Yunlong (何云龙)
Cube: GTC-18M08
iNet: 8751-1645
Tel: +86-010-57511645
Email: yunlong...@intel.com



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] QtContacts/KCal-EDS

[Christophe Dumez]

Hi,

Please find attached two patches for QtContacts EDS backend:
0001: Make the QContactAbstractRequest::start() method return a boolean so that 
the caller knows when an error occurred and the request could not be started.
0002: Make the QContactFetchRequest and QContactLocalIdFetchRequest really 
asynchronous to improve performance. Tests were updated to check the 
functionality. 

The only supported asynchronous request that still runs pseudo-asynchronously 
is the QCOntactDetailDefinitionFetchRequest because it would not help. This is 
a fast and ultimately synchronous operation anyway.

I have a question for you Patrick. Is there a reason to keep the "#ifdef 
SUPPORT_HASH" everywhere in QContactEBook?
The hash support code is no longer needed due to your EDS id patch afaik and 
this code is outdated anyway.
I ask because it would really make the code more readable if I could get rid of 
this part.

Kr,
Christophe Dumez.

-Original Message-
From: Ohly, Patrick 
Sent: Thursday, April 21, 2011 5:16 PM
To: MeeGo-dev
Subject: QtContacts/KCal-EDS

Hello!

I got permission to publish the bridge code between QtContacts resp.
KCalCore and EDS. Sorry for the delay, I had to take care of some other 
business first. The code is now here:

http://meego.gitorious.org/meego-middleware/qtcontacts-eds
http://meego.gitorious.org/meego-middleware/kcal-eds

There's also an overview diagram in the Wiki showing the key difference between 
the two approaches:
http://wiki.meego.com/images/Qtcontacts-kcal-eds.png

The difference is that QtContacts allows plugging a new backend into the 
existing API. KCal doesn't allow that: an app needs to reference some 
additional class, using their specific API, to load and store a calendar.

mKCal is one such additional API. I thought a bit about emulating that API, but 
eventually decided against it because much of that API is by design mKCal 
specific and wouldn't translate well to EDS (example: the notebook concept).

QtContacts-EDS
==

This is derived from the Maemo 5 contact manager. The code wasn't very clean to 
start with (IMHO, for example aborting the process on errors) and uses a extra 
private implementation class which I find unnecessary.
Usually that is done to ABI compatibility, but the only public interface in 
this case is the QtContacts plugin API, which remains stable even if just one 
class is used.

I kept the structure for now, to document how individual aspects of the code 
can be translated back to upstream EDS. Long term I'd like to see QContactEBook 
and QContactEBookEngine merged.

Code quality aspects aside, right now reading/writing and change notifications 
work. To install qtcontacts-eds, compile it and ensure that 
/usr/lib/qt4/plugins/contacts/ has the resulting .so (or a symlink to it). It 
depends on a patched EDS, see below.

To use the new storage, use "eds" as manager name. There is a test program for 
the change tracking included. Manipulating data in EDS can be done via 
Evolution or the SyncEvolution command line:

http://syncevolution.org/blogs/pohly/2010/manipulate-evolution-kcalextendedmkcal-qtcontacts-pim-items-uniform-command-line

To access EDS via QtContacts-EDS in the SyncEvolution command line, use the 
following "database" value for syncevolution backend=qtcontacts \
  database=qtcontacts:eds:source=local:/system \
  --print-items \
  @foo bar

Never mind the "@foo bar" part, the values don't matter in this context.

Open work items:
  * add a QtVersit formatter which
 A. maps QtContactDetails to the corresponding properties as
used in EDS
 B. loads/stores arbitrary QtContactDetails as X-
extensions, similar to the SyncEvoQtContactsHandler in
[1]
  * refactor the code (rewrite from scratch?), add error handling,
consistent resource tracking (RAII as in SyncEvolution and
KCal-EDS [2]?)
  * have Evolution maintainers review the EDS patch (attached) that
QtContacts-EDS depends on (no mapping between int32 QContactId
and traditional EDS string ID) and get it into MeeGo

[1] 
http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/qtcontacts/QtContactsSource.cpp
[2] 
http://meego.gitorious.org/meego-middleware/kcal-eds/blobs/master/src/gnome-support.h


KCal-EDS


This code was written from scratch. It currently supports reading from EDS, but 
not writing. Change notifications work on a per-item level by updating the 
opened calendar with changes made in the underlying EDS.
This is an improvement over mKCal, where apps currently need to reload the 
whole calendar each time the database changes.

Open work items:
  * add writing
  * clarify endDate() semantic

My plan is to look into that next week.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although I am an 
employee of Intel, the 

Re: [MeeGo-dev] Segmentfault one calling QSensorManager::createBackend ( QSensor * sensor )

[Zhao, Forrest]

Did you ever look into qtmobility-examples? You can find the proper usage of 
sensor API.

If you’re sure that you use the API in correct way, please file a bug at 
bugs.meego.com and attach your program to reproduce the bug.

Thanks,
Forrest

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of He, Yunlong
Sent: Wednesday, May 11, 2011 12:55 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Segmentfault one calling QSensorManager::createBackend ( 
QSensor * sensor )

Hi, Experts,

  I am trying to get sensor types supported by one device, so I tried to use 
QSensorManager::createBackend ( QSensor * sensor ), however, it cause 
application segment fault with QOrientationSensor, do you know whether this is 
a bug? Or is there other ways to get supported sensor list?

Best Regards
He Yunlong (何云龙)
Cube: GTC-18M08
iNet: 8751-1645
Tel: +86-010-57511645
Email: yunlong...@intel.com



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] Segmentfault one calling QSensorManager::createBackend ( QSensor * sensor )

[He, Yunlong]

Hi, Experts,

  I am trying to get sensor types supported by one device, so I tried to use 
QSensorManager::createBackend ( QSensor * sensor ), however, it cause 
application segment fault with QOrientationSensor, do you know whether this is 
a bug? Or is there other ways to get supported sensor list?

Best Regards
He Yunlong (何云龙)
Cube: GTC-18M08
iNet: 8751-1645
Tel: +86-010-57511645
Email: yunlong...@intel.com



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] (not) refocusing meego-dev, was: Re: Howto lock screen orientation in MeeGo/Tablet 1.2 ?

[Foster, Dawn M]

On May 10, 2011, at 1:16 PM, Attila Csipa wrote:

> On Monday 09 May 2011 18:22:17 you wrote:
>>> This has been discussed - and agreed before - but the changes never
>>> seemed to happen :-(
>> 
>> The suggestion to rename the mailing lists was discussed but never
>> agreed to. I, for one, don't believe that renaming the list will solve the
> 
> Just out of curiosity, who exactly needs to agree (or, to put it another way, 
> who disagreed) ? I kind of recall pretty much everybody either agreeing or at 
> least liking the idea at some point (see 
> http://lists.meego.com/pipermail/meego-dev/2010-August/005082.html ) but then 
> the whole thing seem to have taken a U turn somewhere off-list between that 
> moment and the message you linked to.

Mailing list creation, naming, etc. falls under the community office, so I
typically make the final decision on mailing list changes.

Dawn
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] (not) refocusing meego-dev, was: Re: Howto lock screen orientation in MeeGo/Tablet 1.2 ?

[Attila Csipa]

On Monday 09 May 2011 18:22:17 you wrote:
> > This has been discussed - and agreed before - but the changes never
> > seemed to happen :-(
> 
> The suggestion to rename the mailing lists was discussed but never
> agreed to. I, for one, don't believe that renaming the list will solve the

Just out of curiosity, who exactly needs to agree (or, to put it another way, 
who disagreed) ? I kind of recall pretty much everybody either agreeing or at 
least liking the idea at some point (see 
http://lists.meego.com/pipermail/meego-dev/2010-August/005082.html ) but then 
the whole thing seem to have taken a U turn somewhere off-list between that 
moment and the message you linked to.

Best regards,
Attila Csipa
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] Moving sources from .debuginfo to .debugsources RPM package?

[Anas Nashif]

thats looks good to me, I will take a closer look and see how it can be 
integrated.

Anas
On 21 Jan 2011, at 20:06, Carsten Munk wrote:

> 2011/1/19 Carsten Munk :
>> Hi,
>> 
>> One of the biggest problems about debugging on mobile devices running
>> MeeGo is that our debuginfo packages currently contain the entire
>> source of the software. While this is nice for stepping through source
>> code, it is horrible for simple backtraces that QA can use - as the
>> needed debuginfo are too big for typical SD cards. Qt debuginfo as an
>> example is -huge- to install :)
>> 
>> openSUSE is having since 2008 debuginfo packages for the debug symbols
>> and debugsources for the sources of the software in question on top of
>> that, for those that want to step through code to debug deeper.
>> 
>> Since this looks like a relatively straightforward patch, as seen at:
>> 
>> https://build.opensuse.org/package/view_file?file=debugsource-package.diff&package=rpm&project=openSUSE%3AFactory&srcmd5=3b22d3db294c852fb824c0b11f49d51b
>> 
>> Would it be accepted if I submitted a patch that added this
>> functionality to our rpm (or the 4.9 work that is ongoing)?
>> 
>> I personally think this could make our platform development a lot easier.
> 
> I've implemented/adapted this from the openSUSE patches, patches added
> at http://bugs.meego.com/show_bug.cgi?id=12724 - one patch for
> meego-rpm-config, one for rpm.
> 
> It was tested in devel:hardfp:base and as seen on
> http://download.meego.com/live/devel:/hardfp:/base/standard/i686/ and
> no ill effects seen (unless if you apply rpm before meego-rpm-config,
> as there will be unpackaged files in debuginfo else)
> 
> BR
> Carsten Munk
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] QtContacts/KCal-EDS

[Patrick Ohly]

On Di, 2011-05-10 at 08:40 +0100, Dumez, Christophe wrote:
> Please find attached a few patches for QtContacts EDS backend:
> 0001: Make the contact save/remove requests really asynchronous. This
> should increase performance because the async requests can now
> actually run in parallel instead of sequentially. It also
> improved/rewrote the contacts saving/removing code at the same time (I
> save one DBus round-trip in contact removing for example).
> 0002: ut_filtering: Slight async request improvement and more debug
> output
> 0003: ut_signals: More debug output

All looks good to me. Admittedly, I am now only looking at obvious code
deficiencies and check that it runs and compiles for me. The tests still
fail to run for me, but I merged anyway for the time being.

We should stop patching EDS separately and instead start a devel:eds
sub-project in OBS where we package the necessary bits and pieces. That
way we can be sure that we really use the same environment =>
https://bugs.meego.com/show_bug.cgi?id=17355

> I added the two last patches to help debugging a possible race
> condition in EDS: The ut_signals test sometimes fails for me because I
> get a contactsChanged() signal back instead of a contactsAdded() one
> for one of the two contacts although e_book_add_contact_async() is
> called for both contacts. It might be related to ID reuse since the
> previous unit test has contacts that get the same ids (they are
> properly removed at the end of the test though).

I suspected that this happens because EDS buffers changes for a short
period, then combines multiple changes into a single EBookView update
D-Bus message. But notify_add() in e-data-book-view.c ensures that
deletes and changes are flushed first. So I need to look more deeply.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

[MeeGo-dev] Dialer Project meeting - Agenda for Tuesday 5/10

[Shane Bryan]

Agenda for the Dialer Project meeting - Tuesday, May 10th, 2011 
  

* General information/business (Shane)
  - QML Dialer status (Shane/Tom)

* Which dialer in N900 DE image for MeeGo SF2011? (DE Team rep.)

* Bug, patch and merge-request status (Shane)
  Bugs:
  - We'll review what folks want to review.  Send me hot ones you want
to discuss, or have them ready when we get to this topic

* Any Other Business

-- 
Shane...
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Arjan van de Ven]

On 5/10/2011 2:16 AM, Murray Cumming wrote:


I hope to see some official acceptance for Maalit in Meego 1.3. After
all, it's gotta have a serious input method framework. The libmeegotouch
dependency seems to be the only problem so far. But you need to be loud,
clear and direct to Nokia that they need to devote time to removing that
libmeegotouch dependency from Maalit.


Since it was Nokia itself that told us a year ago that libmeegotouch 
should be designed out...

... I'm pretty sure they know.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Thiago Macieira]

On Tuesday, 10 de May de 2011 10:42:06 Michael Hasselmann wrote:
> On Tue, 2011-05-10 at 11:29 +0300, Sakari Poussa wrote:
> > That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year
> > as you can read from the blog.
> > 
> > These are big and complex things which need long cycles to be planned
> > and communicated correctly. That's what we (MeeGo) are doing now. And
> > not saying do MTF apps now and then say year later that use something
> > else.
> > 
> > So yes, we need to start the preparation now.
> 
> Again, nothing has been mentioned in that document that either QWidget
> or QGraphicsView are or will be deprecated with Qt 5.

They aren't deprecated. They are "Done" (I'll announce this tomorrow). See the 
definition at:

http://labs.qt.nokia.com/2011/05/03/qt-modules-maturity-level/

Unless someone takes them up and moves them back to Maintained.

> Qt 5 probably will be released next year. The ABI promise then would
> demand a new major release for Qt before QGraphicsView could be
> removed/marked as deprecated, and that next version (Qt 6) will
> certainly *not* happen in 2012.

Indeed. Graphics View and the widgets will not be removed in Qt 5, so they'll 
be around for a number of years to come.

> With the upcoming Open Governance, deprecation of modules is not
> decision of the Qt team alone, but outside maintainers could step in (if
> they realize they are heavily invested in a certain module) and take
> over.

Indeed. Someone has been paying attention to what I've been saying :-)

> If we already plan for the removal of QGraphicsView (which, by the way,
> is far more mature than what QML2 will be upon its release, simply
> because it takes time to mature software), then I think we are planning
> too far ahead here.

We can plan ahead. And Arjan's point is that we want to remove libmeegotouch 
eventually. For that to happen, we need to know *how* we'll go about it: what 
is obsoleted by newer technology elsewhere, what should move to other 
libraries because they are very useful, what needs research and development to 
be replaced.

This is independent of there being a Qt 5 release. This is something MeeGo has 
decided it wants to do anyway.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Murray Cumming]

On Tue, 2011-05-10 at 11:16 +0200, Murray Cumming wrote:
> On Tue, 2011-05-10 at 01:45 -0700, Arjan van de Ven wrote:
> > regardless of that, for MeeGo libmeegotouch is not our preferred way
> > of 
> > writing applications, or even a supported one.
> >  so cleaning that up is a target anyway.
> 
> As Meego 1.3 is planned for 6 months from now, that doesn't seem
> entirely unreasonable. But we need to make sure that everyone
> understands that libmeegotouch dependencies must be removed from
> anything that is being proposed as part of Meego. And that work needs to
> start now if it has a chance of being done in time.
> 
> I'm most concerned with the the Maalit

Ahem. I mean Maliit, of course:
http://wiki.meego.com/Maliit

>  virtual keyboard (Meego Input
> Methods). This is a really successful project that's working well,
> meeting real requirements. It's being developed in a truly open way - a
> side-effect of my company Openismus being the one doing much of the
> contracting work for Nokia.
> 
> I hope to see some official acceptance for Maalit in Meego 1.3. After
> all, it's gotta have a serious input method framework. The libmeegotouch
> dependency seems to be the only problem so far. But you need to be loud,
> clear and direct to Nokia that they need to devote time to removing that
> libmeegotouch dependency from Maalit.
> 

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Murray Cumming]

On Tue, 2011-05-10 at 01:45 -0700, Arjan van de Ven wrote:
> regardless of that, for MeeGo libmeegotouch is not our preferred way
> of 
> writing applications, or even a supported one.
>  so cleaning that up is a target anyway.

As Meego 1.3 is planned for 6 months from now, that doesn't seem
entirely unreasonable. But we need to make sure that everyone
understands that libmeegotouch dependencies must be removed from
anything that is being proposed as part of Meego. And that work needs to
start now if it has a chance of being done in time.

I'm most concerned with the the Maalit virtual keyboard (Meego Input
Methods). This is a really successful project that's working well,
meeting real requirements. It's being developed in a truly open way - a
side-effect of my company Openismus being the one doing much of the
contracting work for Nokia.

I hope to see some official acceptance for Maalit in Meego 1.3. After
all, it's gotta have a serious input method framework. The libmeegotouch
dependency seems to be the only problem so far. But you need to be loud,
clear and direct to Nokia that they need to devote time to removing that
libmeegotouch dependency from Maalit.

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Arjan van de Ven]

On 5/10/2011 1:42 AM, Michael Hasselmann wrote:

On Tue, 2011-05-10 at 11:29 +0300, Sakari Poussa wrote:

That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you 
can read from the blog.

These are big and complex things which need long cycles to be planned and 
communicated correctly. That's what we (MeeGo) are doing now. And not saying do 
MTF apps now and then say year later that use something else.

So yes, we need to start the preparation now.

Again, nothing has been mentioned in that document that either QWidget
or QGraphicsView are or will be deprecated with Qt 5.


regardless of that, for MeeGo libmeegotouch is not our preferred way of 
writing applications, or even a supported one.

 so cleaning that up is a target anyway.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Thiago Macieira]

On Tuesday, 10 de May de 2011 11:29:09 Sakari Poussa wrote:
> > "In future version*s*" could be 10 years from now, for all we know
> > (given it took 5 years from Qt 4 to Qt 5 already, the latter not being
> > there yet). You really think you need to prepare for that right now?
> 
> That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as
> you can read from the blog.
> 
> These are big and complex things which need long cycles to be planned and
> communicated correctly. That's what we (MeeGo) are doing now. And not
> saying do MTF apps now and then say year later that use something else.

By the way, please note that the Qt 5 objectives are pretty much aligned with 
MeeGo's requirements:

Wayland support
Best possible use of GPU integration
QML-based application development (Qt Quick) at the forefront
The rest remaining the same

Also note that, as a binary-incompatible upgrade, Qt 4 and 5 *can* be 
installed side by side. They just can't be both loaded into memory at the same 
time.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Michael Hasselmann]

On Tue, 2011-05-10 at 11:29 +0300, Sakari Poussa wrote:
> That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you 
> can read from the blog.
> 
> These are big and complex things which need long cycles to be planned and 
> communicated correctly. That's what we (MeeGo) are doing now. And not saying 
> do MTF apps now and then say year later that use something else.
> 
> So yes, we need to start the preparation now.

Again, nothing has been mentioned in that document that either QWidget
or QGraphicsView are or will be deprecated with Qt 5.

Qt 5 probably will be released next year. The ABI promise then would
demand a new major release for Qt before QGraphicsView could be
removed/marked as deprecated, and that next version (Qt 6) will
certainly *not* happen in 2012.

Also, if you followed a strict deprecation cycle (where modules first
need to be marked as deprecated before they can be removed in the next
version), then QGraphicsView can only go away with Qt 7.

With the upcoming Open Governance, deprecation of modules is not
decision of the Qt team alone, but outside maintainers could step in (if
they realize they are heavily invested in a certain module) and take
over.

If we already plan for the removal of QGraphicsView (which, by the way,
is far more mature than what QML2 will be upon its release, simply
because it takes time to mature software), then I think we are planning
too far ahead here.

regards,
Michael

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Sakari Poussa]

On May 9, 2011, at 4:01 PM, Michael Hasselmann wrote:

> On Mon, 2011-05-09 at 14:49 +0200, Carsten Munk wrote:
 As we know, in the future Qt versions the QtGraphicsView will be
 deprecated in the favor of SceneGraph.
>>> 
>>> Never heard of this. AFAIK, the scene graph doesn't even exist as an API
>>> yet.
>>> What's your source?
>> I believe http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/
>> should help answer that question.
> 
> It mentions a *vision* that Qt will be less QWidget centric. It does not
> say that QGraphicsView will be deprecated.
> 
> We should be more careful with such unfounded speculations, really.
> 
> "In future version*s*" could be 10 years from now, for all we know
> (given it took 5 years from Qt 4 to Qt 5 already, the latter not being
> there yet). You really think you need to prepare for that right now?

That (Qt5) is a vision with timeline. It's not 10 years, it is 1+ year as you 
can read from the blog.

These are big and complex things which need long cycles to be planned and 
communicated correctly. That's what we (MeeGo) are doing now. And not saying do 
MTF apps now and then say year later that use something else.

So yes, we need to start the preparation now.

-sakari

> 
> regards,
> Michael
> 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Re: [MeeGo-dev] libmeegotouch in 'MeeGo Core' in 1.3?

[Sakari Poussa]

On May 9, 2011, at 3:49 PM, Carsten Munk wrote:

> 2011/5/9 Alberto Mardegan :
>> Hi,
>> 
>> On 05/09/2011 01:23 PM, Sakari Poussa wrote:
>> [...]
>>> 
>>> As we know, in the future Qt versions the QtGraphicsView will be
>>> deprecated in the favor of SceneGraph.
>> 
>> Never heard of this. AFAIK, the scene graph doesn't even exist as an API
>> yet.
>> What's your source?
> I believe http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/
> should help answer that question.

Yes, that is one of the sources. Perhaps the most reliable one, too.

-sakari

> 
> /Carsten
> 
> 
>> 
>> Ciao,
>>  Alberto
>> 
>> --
>> http://blog.mardy.it <-- geek in un lingua international!
>> ___
>> MeeGo-dev mailing list
>> MeeGo-dev@meego.com
>> http://lists.meego.com/listinfo/meego-dev
>> http://wiki.meego.com/Mailing_list_guidelines
>> 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines