Bug 497 – Miising __lt__ operators in QtMobility::QGeoMapObject

PySide Bugzilla Closed for New Bugs

PySide is now a Qt Add-on and uses the Qt Project's JIRA Bug Tracker instead of this Bugzilla instance. This Bugzilla is left for reference purposes.

Bug 497 - Miising __lt__ operators in QtMobility::QGeoMapObject

Summary:

Miising __lt__ operators in QtMobility::QGeoMapObject

Status:	CLOSED FIXED

Product:	PySide Mobility
Classification:	Unclassified
Component:	PySide.Mobility
Version:	0.1.0
Platform:	All All

Importance:	P3 normal
Assigned To:	Lauro Moura

URL:

Depends on:	495
Blocks:
	Show dependency tree / graph

Reported:	2010-11-24 16:49 EET by Luciano Wolf
Modified:	2011-01-21 15:44 EET (History)
CC List:	3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Luciano Wolf 2010-11-24 16:49:42 EET

Shiboken generates broken code when you have rich-compare operators that
receive object-types (as reference). It depends on bug #495

Comment 1 Matti Airas 2010-11-24 17:07:16 EET

What are the specific functions or classes that were rejected due to this
issue? This should help fixing the issue once bug 495 is resolved.

Comment 2 Luciano Wolf 2010-11-25 15:24:39 EET

Operators "<" and ">" inside QtMobility::QGeoMapObject were rejected.

Comment 3 Lauro Moura 2010-11-25 17:27:53 EET

Also in QFeedbackActuator operator==.

Comment 4 Matti Airas 2010-11-26 14:06:52 EET

Ack. P3. :-)

Comment 5 Bruno Araujo 2011-01-14 15:36:09 EET

Code generation fixed in latest PySide releases, thus removing respective
rejects for the cited operators.

Comment 6 Bruno Araujo 2011-01-14 15:38:15 EET

Fixed in beta3, which closed bug #495, that is :-)

...and closing.

Comment 7 Matti Airas 2011-01-17 06:34:03 EET

The PySide guys are using the practice of closing the bug only when the next
version is released (it stays in RESOLVED state until that). I think it might
be good to use the same strategy for every component in our Bugzilla. What do
you think?

Comment 8 Bruno Araujo 2011-01-17 07:45:37 EET

(In reply to comment #7)
> The PySide guys are using the practice of closing the bug only when the next
> version is released (it stays in RESOLVED state until that). I think it might
> be good to use the same strategy for every component in our Bugzilla. What do
> you think?

Fine by me :-)

Setting back to RESOLVED FIXED.

Comment 9 renato filho 2011-01-21 15:44:38 EET

release beta4