Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[sergio.ahumada]

--
Sergio AhumadaOn 03.08.12 18:13 ext Giuseppe D'Angelo wrote:
On 3 August 2012 08:58, Konrad Rosenbaum  wrote:
>
> For QDateTime this potentially involves heavy calculations. The upside of this
> is that this guarantees unchanged hashes even if the internal representation
> of QDateTime changes. How hard is the requirement to create the same hash over
> several versions of Qt?

This was actually a source of nasty bugs all over the place when I
changed the qHash(QString) implementation for Qt 5.0. (For instance,
rcc used to store it in the binary resource files...).

Therefore, I clearly documented that it's not guaranteed that qHash
will stay the same:

http://doc-snapshot.qt-project.org/5.0/qhash.html#the-qhash-hashing-function

"Note that the implementation of the qHash() overloads offered by Qt
may change at any time. You must not rely on the fact that qHash()
will give the same results (for the same inputs) across different Qt
versions."

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Thiago Macieira]

On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
> noexcept(std::declval().f()) should work.

error: invalid use of incomplete type ‘struct Object’

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Marc Mutz]

On Friday August 3 2012, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 23.57.58, Marc Mutz wrote:
> > noexcept(std::declval().f()) should work.
>
> Unfortunately, while the C++11 compiler support seems to be going fine, the
> library support is lagging WAY behind.  Add to that the fact that some
> compilers are being used with incompatible Standard Libraries, meaning the
> features don't work, even if present. To make it all worse, there are no
> library version numbers, so we can't detect them properly.
>
> Exhibit A: MSVC supports initialiser lists, but it doesn't have
> ...
>
> Exhibit B: ICC compiling certain GCC headers will cause it to fail to link
> complaining about undefined references to functions that should be
> intrinsics.

namespace QtPrivate {
#ifdef Q_COMPILER_RVALUE_REFS
template 
typename remove_reference::type&& declval() Q_DECL_NOEXCEPT;
#else
template 
typename remove_reference::type& declval() Q_DECL_NOEXCEPT;
#endif
}

left undefined, should be equivalent.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Giuseppe D'Angelo]

On 3 August 2012 08:58, Konrad Rosenbaum  wrote:
>
> For QDateTime this potentially involves heavy calculations. The upside of this
> is that this guarantees unchanged hashes even if the internal representation
> of QDateTime changes. How hard is the requirement to create the same hash over
> several versions of Qt?

This was actually a source of nasty bugs all over the place when I
changed the qHash(QString) implementation for Qt 5.0. (For instance,
rcc used to store it in the binary resource files...).

Therefore, I clearly documented that it's not guaranteed that qHash
will stay the same:

http://doc-snapshot.qt-project.org/5.0/qhash.html#the-qhash-hashing-function

"Note that the implementation of the qHash() overloads offered by Qt
may change at any time. You must not rely on the fact that qHash()
will give the same results (for the same inputs) across different Qt
versions."

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[marius.storm-olsen]

On 03/08/2012 07:49, ext Thiago Macieira wrote:
> On sexta-feira, 3 de agosto de 2012 09.58.24, Konrad Rosenbaum
> wrote:
>
> The problem with QDateTime is that the operator== also does some
> calculations. It compares as equal two QDateTime objects with
> different times and timezones, provided that they are the same
> universal time.
>
> And operator== can't change incompatibly.

Does this mean that we should have an
 bool QDateTime::isIdentical(const QDateTime &dt)
function too (effectively an operator===), allowing you to easily check 
if two dates refer to the same time in the same TZ?

-- 
.marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Content freeze for Qt 4.8.3 approaching

[Salovaara Akseli]

Hi all,

It has been great  to notice that Qt 4.8 branch is active and has already well 
over 200 commits since Qt 4.8.2 release.
Therefore it is suitable time to start creating Qt 4.8.3 release, as discussed 
earlier.

We would like to freeze Qt 4.8.3 sha1 in mid-August aiming to have Qt 4.8.3 
release ready, tested and published around the end of August.

If you are aware of some improvement or fix which should be included (and/or is 
possibly pending on review) please send email to 
releas...@qt-project.org . Any information 
from e.g. some fix partially approved is valuable and very welcome.  As has 
been discussed before, we are making the 4.8 patch release directly from 4.8 
branch. So we will not cherry pick anything, getting something in means that we 
take all commits in by that point in time.


There are a few contributions pending to be merged to 4.8 in Gerrit (link: 
http://codereview.qt-project.org/#q,project:qt/qt+status:open,n,z). It would be 
great if all maintainers  who have not yet done so go through these for their 
modules and all  contributors who have received comments try to fix the things 
needed to be accepted.

Qt version bump up and dist/changes-4.8.3 update are under work but you can 
find working draft of changes-4.8.3 file as attachment.

Br,
Akseli

Akseli Salovaara
Software Specialist, Qt Commercial R&D

DIGIA Plc
Piippukatu 11, FI-40101 Jyväskylä Finland
Email: akseli.salova...@digia.com

Visit us at: www.digia.com or qt.digia.com

--
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. DIGIA Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.
--



changes-4.8.3_draft
Description: changes-4.8.3_draft
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Thiago Macieira]

On sexta-feira, 3 de agosto de 2012 09.58.24, Konrad Rosenbaum wrote:
> For QTime and QDate this is uncritical - these are the native storage
> format, although a few methods would have to be marked noexcept as well.

Which I've done, except for inline methods.

> For QDateTime this potentially involves heavy calculations. The upside of
> this is that this guarantees unchanged hashes even if the internal
> representation of QDateTime changes. How hard is the requirement to create
> the same hash over several versions of Qt?

Zero.

The only requirement on a hash is

a == b  →   qHash(a) == qHash(b)

The value returned by the qHash function can be *anything*, provided it meets
the above requirement. So it's possible to change the internal hashing
function.

The problem with QDateTime is that the operator== also does some calculations.
It compares as equal two QDateTime objects with different times and timezones,
provided that they are the same universal time.

And operator== can't change incompatibly.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

[lars.knoll]

On Aug 3, 2012, at 12:25 PM, ext John Layt  wrote:

> On 2 August 2012 13:26, Thiago Macieira  wrote:
>> On quinta-feira, 2 de agosto de 2012 12.02.45, lars.kn...@nokia.com wrote:
>>> 
>>> I intend to move both Qt 3D and Qt Location out of the essentials list and
>>> make them add-ons for now. They are fully usable as-is today, but with the
>>> situation down-under I am currently unsure how well we can maintain and
>>> develop them going forward. If things turn out well, we can still move them
>>> into the Essentials list in a 5.1 or 5.x release.
>> 
>> For 3D and Location, I have a feeling it's a little premature, but I can't
>> blame you for it. Especially in Location's case, with lots of plugins to be
>> kept in working order, it might be tricky in the current situation.
> 
> A few points I picked up from the QtLocation session at QtCS:
> * It depends on Qt3D, so if Qt3D is out so must QtLocation
> * It wasn't yet in feature freeze?
> * It only has QML support in 5.0, C++ support is planned for 5.1? I
> assumed this just meant the map widgets?
> * Nokia Maps might be interested in maintaining it
> 
> 
> With my KDE hat on, I'm not entirely sure QtLocation in it's current
> form meets our requirements, most of KDE only needs the data container
> metatypes or Position services so pulling in Qt3D and Maps and Places
> and Routing seems overkill.  We could probably live with it if
> QtLocation is in Essentials and installed everywhere, but as an add-on
> it would be nice if we could split them up and only depend on what we
> really need.

The main point for both location and 3D is that we give ourselves a bit more 
flexibility and freedom by having them as add-ons for now. When things become 
clearer and we have secured maintenance and ongoing development for these 
modules, we can always re-evaluate.

This change should not hurt anybody that is planning on using these modules. 
They won't disappear or stop working because of this ;-)

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA triggers nested event processing

[Simon Hausmann]

On Friday, August 03, 2012 12:52:08 PM ext David Faure wrote:
> This was quite unexpected: in Qt5, creating a QApplication instance triggers
> event processing already, much before calling QApplication::exec().
> 
> This comes from QWindowSystemInterface::sendWindowSystemEvents calling
> sendPostedEvent(), see bt below. Shouldn't it be more specific about which
> posted events, for which targets, should be flushed at that point?

Yeah...
 
> I'm pretty sure that nobody expects other events (timers, sockets, dbus,
> etc.) to be handled yet. Even processing GUI-related events doesn't sound
> like a good idea to me, so early in the game.
> 
> #7  0x73ba16fd in q_dbus_connection_dispatch (connection=0x61c6b0)
> at qdbus_symbols_p.h:115 #8  0x73ba6e6e in
> QDBusConnectionPrivate::doDispatch (this=0x612600) at
> qdbusintegrator.cpp:1125 #9  0x73bee5fe in
> QDBusConnectionPrivate::qt_static_metacall (_o=0x612600,
> _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x61c220) at
> .moc/debug-shared/moc_qdbusco nnection_p.cpp:130
> #10 0x770ab991 in QMetaCallEvent::placeMetaCall (this=0x61f770,
> object=0x612600) at kernel/qobject.cpp:467 #11 0x770ac8f8 in
> QObject::event (this=0x612600, e=0x61f770) at kernel/qobject.cpp:1048 #12
> 0x770728e8 in QCoreApplicationPrivate::notify_helper
> (this=0x626750, receiver=0x612600, event=0x61f770) at
> kernel/qcoreapplication.cpp:837 #13 0x770725dc in
> QCoreApplication::notify (this=0x7fffd330, receiver=0x612600,
> event=0x61f770) at kernel/qcoreapplication.cpp:783 #14 0x73f0a80e
> in QGuiApplication::notify (this=0x7fffd330, object=0x612600,
> event=0x61f770) at kernel/qguiapplication.cpp:1052 #15 0x770724e8
> in QCoreApplication::notifyInternal (this=0x7fffd330,
> receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.cpp:721 #16
> 0x7707622d in QCoreApplication::sendEvent (receiver=0x612600,
> event=0x61f770) at kernel/qcoreapplication.h:207 #17 0x770735ac in
> QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0,
> data=0x607df0) at kernel/qcoreapplication.cpp:1321 #18 0x7707316d
> in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at
> kernel/qcoreapplication.cpp:1181 #19 0x73efd466 in
> QWindowSystemInterface::sendWindowSystemEvents (flags=...) at
> kernel/qwindowsysteminterface.cpp:509 #20 0x73f0a449 in
> QGuiApplicationPrivate::init (this=0x626750) at
> kernel/qguiapplication.cpp:880 #21 0x73f0860d in
> QGuiApplication::QGuiApplication (this=0x7fffd330, p=...) at
> kernel/qguiapplication.cpp:348 #22 0x746b4d15 in
> QApplication::QApplication (this=0x7fffd330, argc=@0x76bf5568,
> argv=0x624270, GUIenabled=true, _internal=327680) at kernel/qapplication
> .cpp:577
> [...]
> #26 0x00402cf8 in main (argc=1, argv=0x7fffd598) at
> /d/kde/src/kf5-qt5/kdelibs-frameworks/staging/kde4support/autotests/kunique
> apptest.cpp:93
> 
> What's the reason for the sendWindowSystemEvents in
> QGuiApplicationPrivate::init ? It comes from
> ef2efafcc6b28791df6258fa1c5d565090a9577a (hi Simon), but the above looks
> like a rather unexpected large side effect for a small issue...

The specific case of ef2efafcc6b28791df6258fa1c5d565090a9577a comes from the 
MeeGo plugin that uses dbus properties to determine the screen orientation and 
sends a screen orientation change event on startup. Processing this window 
system even here helps to ensure that the initial screen orientation is 
correct.

It sounds like sendPostedEvents() without any parameters is indeed a little 
bit too aggressive. Laszlo, Paul, any thoughts?

Unless perhaps QApplicationPrivate::init should call 
QWindowSystemInterface::flushWindowSystemEvents instead?


Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing Tim Jenssen and Niels Weber for Approver Status

[lars.knoll]

+2 (one for each of them) from me :)

Cheers,
Lars

On Aug 3, 2012, at 12:47 PM, ext andre.poen...@nokia.com 
 wrote:

> Hello everybody.
> 
> I hereby propose to grant Tim Jenssen and Niels Weber "Approver" status
> in the Qt Project.
> 
> Tim and Niels have handled a major parts of the development of the 
> Qt Installer Framework and the SDK releases for more than two years now.
> 
> For reference, see
> 
>   https://codereview.qt-project.org/#q,owner:tim.jenssen%2540nokia.com,n,z
> 
> and 
> 
>   https://codereview.qt-project.org/#q,owner:niels.2.weber%2540nokia.com,n,z
> 
> Best regards,
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: adding Q_DECL_NOEXCEPT to many methods

[Konrad Rosenbaum]

On Thursday 02 August 2012 23:01:55 you wrote:
> On Thursday August 2 2012, Konrad Rosenbaum wrote:
> > On Thursday 02 August 2012, Thiago Macieira wrote:
> > > On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
> > > > Where is qHash(QDateTime) defined? It doesn't seem to be where I
> > > > expected it (qhash.* or qdatetime.*).
> > > 
> > > qdatetime.{h,cpp}
> > 
> > Ok, found it - had the wrong branch checked out for some odd reason. This
> > has a high likelyhood of causing allocations if time zones, calenders or
> > anything fancy is active: it causes time zone calculations, which
> > potentially cause allocations.
> 
> That begs the question whether this is what should happen for a _hash_,
> which is supposed to be _fast_ :)

All three (QDate, QTime, QDateTime) take the somewhat obvious route of 
converting to a linear measure of time (julian day, msecs since midnight, 
msecs since epoch) that is then fed to qHash(qint64 time,int seed).

For QTime and QDate this is uncritical - these are the native storage format, 
although a few methods would have to be marked noexcept as well.

For QDateTime this potentially involves heavy calculations. The upside of this 
is that this guarantees unchanged hashes even if the internal representation 
of QDateTime changes. How hard is the requirement to create the same hash over 
several versions of Qt?

Alternative 1: the hash for QDateTime could be calculated from other internal 
details: the hashes of the QDate and QTime objects making up the QDateTime 
plus TimeSpec, UTC-offset, and later on a reference to the time zone. If we do 
this it means the generated hashes will change in Qt 5.1!

Alternative 2: the hash for QDateTime is calculated solely from the hashes of 
QDate and QTime. Upside: they do not change, they are easy and fast to 
calculate, we already know the sources are noexcept. Trade: we trade 
equivalence of the exact same time relative to Epoch across time zones 
(currently the hash of "2012-08-03 9:54:00 +200" equals the hash of 
"2012-08-03 7:54:00 UTC") for equivalence of the exact same numeric time over 
time zones (hash of "2012-08-03 9:54:00 +200" equals the hash of "2012-08-03 
9:54:00 UTC") - I view both as equivalent for the most common case of using 
local time only.



Konrad


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QPA triggers nested event processing

[David Faure]

This was quite unexpected: in Qt5, creating a QApplication instance triggers 
event processing already,
much before calling QApplication::exec().

This comes from QWindowSystemInterface::sendWindowSystemEvents calling 
sendPostedEvent(), see bt below.
Shouldn't it be more specific about which posted events, for which targets, 
should be flushed
at that point?

I'm pretty sure that nobody expects other events (timers, sockets, dbus, etc.) 
to be handled yet.
Even processing GUI-related events doesn't sound like a good idea to me, so 
early in the game.

#7  0x73ba16fd in q_dbus_connection_dispatch (connection=0x61c6b0) at 
qdbus_symbols_p.h:115
#8  0x73ba6e6e in QDBusConnectionPrivate::doDispatch (this=0x612600) at 
qdbusintegrator.cpp:1125
#9  0x73bee5fe in QDBusConnectionPrivate::qt_static_metacall 
(_o=0x612600, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x61c220) at 
.moc/debug-shared/moc_qdbusco
nnection_p.cpp:130
#10 0x770ab991 in QMetaCallEvent::placeMetaCall (this=0x61f770, 
object=0x612600) at kernel/qobject.cpp:467
#11 0x770ac8f8 in QObject::event (this=0x612600, e=0x61f770) at 
kernel/qobject.cpp:1048
#12 0x770728e8 in QCoreApplicationPrivate::notify_helper 
(this=0x626750, receiver=0x612600, event=0x61f770) at 
kernel/qcoreapplication.cpp:837
#13 0x770725dc in QCoreApplication::notify (this=0x7fffd330, 
receiver=0x612600, event=0x61f770) at kernel/qcoreapplication.cpp:783
#14 0x73f0a80e in QGuiApplication::notify (this=0x7fffd330, 
object=0x612600, event=0x61f770) at kernel/qguiapplication.cpp:1052
#15 0x770724e8 in QCoreApplication::notifyInternal 
(this=0x7fffd330, receiver=0x612600, event=0x61f770) at 
kernel/qcoreapplication.cpp:721
#16 0x7707622d in QCoreApplication::sendEvent (receiver=0x612600, 
event=0x61f770) at kernel/qcoreapplication.h:207
#17 0x770735ac in QCoreApplicationPrivate::sendPostedEvents 
(receiver=0x0, event_type=0, data=0x607df0) at kernel/qcoreapplication.cpp:1321
#18 0x7707316d in QCoreApplication::sendPostedEvents (receiver=0x0, 
event_type=0) at kernel/qcoreapplication.cpp:1181
#19 0x73efd466 in QWindowSystemInterface::sendWindowSystemEvents 
(flags=...) at kernel/qwindowsysteminterface.cpp:509
#20 0x73f0a449 in QGuiApplicationPrivate::init (this=0x626750) at 
kernel/qguiapplication.cpp:880
#21 0x73f0860d in QGuiApplication::QGuiApplication 
(this=0x7fffd330, p=...) at kernel/qguiapplication.cpp:348
#22 0x746b4d15 in QApplication::QApplication (this=0x7fffd330, 
argc=@0x76bf5568, argv=0x624270, GUIenabled=true, _internal=327680) at 
kernel/qapplication
.cpp:577
[...]
#26 0x00402cf8 in main (argc=1, argv=0x7fffd598) at 
/d/kde/src/kf5-qt5/kdelibs-frameworks/staging/kde4support/autotests/kuniqueapptest.cpp:93

What's the reason for the sendWindowSystemEvents in 
QGuiApplicationPrivate::init ?
It comes from ef2efafcc6b28791df6258fa1c5d565090a9577a (hi Simon), but the 
above looks like a rather
unexpected large side effect for a small issue...

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proposing Tim Jenssen and Niels Weber for Approver Status

[andre.poenitz]

Hello everybody.

I hereby propose to grant Tim Jenssen and Niels Weber "Approver" status
in the Qt Project.

Tim and Niels have handled a major parts of the development of the 
Qt Installer Framework and the SDK releases for more than two years now.

For reference, see

   https://codereview.qt-project.org/#q,owner:tim.jenssen%2540nokia.com,n,z

and 

   https://codereview.qt-project.org/#q,owner:niels.2.weber%2540nokia.com,n,z

Best regards,
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Essentials

[John Layt]

On 2 August 2012 13:26, Thiago Macieira  wrote:
> On quinta-feira, 2 de agosto de 2012 12.02.45, lars.kn...@nokia.com wrote:
>>
>> I intend to move both Qt 3D and Qt Location out of the essentials list and
>> make them add-ons for now. They are fully usable as-is today, but with the
>> situation down-under I am currently unsure how well we can maintain and
>> develop them going forward. If things turn out well, we can still move them
>> into the Essentials list in a 5.1 or 5.x release.
>
> For 3D and Location, I have a feeling it's a little premature, but I can't
> blame you for it. Especially in Location's case, with lots of plugins to be
> kept in working order, it might be tricky in the current situation.

A few points I picked up from the QtLocation session at QtCS:
* It depends on Qt3D, so if Qt3D is out so must QtLocation
* It wasn't yet in feature freeze?
* It only has QML support in 5.0, C++ support is planned for 5.1? I
assumed this just meant the map widgets?
* Nokia Maps might be interested in maintaining it


With my KDE hat on, I'm not entirely sure QtLocation in it's current
form meets our requirements, most of KDE only needs the data container
metatypes or Position services so pulling in Qt3D and Maps and Places
and Routing seems overkill.  We could probably live with it if
QtLocation is in Essentials and installed everywhere, but as an add-on
it would be nice if we could split them up and only depend on what we
really need.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request

[a.gra...@gmail.com]

On 3 August 2012 12:32, Ahmad Suleman  wrote:
> Send me some projects so that i could show you my ability

some project about what? How do you show us your ability? Why you do
have to show us it :) ?
If you want to contribute to Qt, just visit the wiki, it contains all
the informations to get started.
Pick an open bug, a missing feature etc.. and submit the patch. That's it!

-- 
Andrea Grandi - Nokia-FNDC/Tampere / Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Request

[Ahmad Suleman]

Send me some projects so that i could show you my ability
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] state of Qt's Australia office

[Alberto Mardegan]

On 08/02/2012 03:02 PM, lars.kn...@nokia.com wrote:
> Talking for me, it's really sad to see this happen. There are a lot
> of bright engineers working in that office and I have been working
> with many of them for quite some time now. I really hope that
> everybody will find a new job soon, and that most of the people will
> actually stay connected to the Qt ecosystem and Qt project in some
> form or another.

While I wish all the best to the affected developers, and have no doubt
that they'll be able to find a new exciting job soon, I hold the selfish
hope that they'll continue to work together as a team and not be
dispersed in different companies. Otherwise, even if the new job is
related to Qt, it's difficult to image that they'll be able to continue
developing the great technologies they've been working on so far, with
the same pace.
That is something which, I believe, can be done only when being part of
a company (or foundation) which invests in R&D.

I don't know whether forming a SW consulting/development company with
focus on QML would be a sustainable business, but I hope that they
consider this possibility before splitting off. :-)

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development